在HPC数据中心中，科学模拟生成和分析海量数据集，以获取洞察力并验证假设。例如，探索磁重联、模拟等离子体相互流动、确定粒子相互作用和轨迹、以及模拟可能导致恐龙灭绝的小行星撞击等，都是科学模拟的典型应用。这些大规模的工作流既耗时又资源密集，单个时间步的数据集就可达数十TB，甚至可能增长到PB级别，因此需要依赖高性能的存储系统来支持。
然而，仅仅提供高吞吐量的文件系统和存储介质往往难以满足需求。我们必须与领域科学家紧密合作，深入了解他们的工作流，进而推动在I/O层面上的效率提升。计算型存储在这方面发挥了关键作用，通过提供存储服务器操作的功能下推、数据过滤、数据索引等功能。将其与业界广泛采用的文件格式、开源文件系统和协议、数据分析引擎、开放科学数据集以及优秀的行业合作伙伴相结合，我们已经取得了多个概念验证的成功案例，充分展示了计算型存储在科学模拟中的重要作用。这些原则同样可以应用于其他计算领域。在本次演讲中，我将深入探讨这些科学工作流，并阐述它们如何从不同的计算型存储配置中获益。
题目：Streamlining Scientific Workflows: Computational Storage Strategies for HPC
演讲者：Dominic Manno, Los Alamos National Laboratory
会议：SNIA Compute, Memory, and Storage Summit
日期：2024年5月22日
-----
大家好，我叫多Dominic Manno，是美国洛斯阿拉莫斯国家实验室（Los Alamos National Laboratory，LANL）高性能计算设计组的一名研究科学家，主要研究方向是存储研究。
今天，我将与大家分享如何简化科学工作流，并探讨如何利用计算型存储来改进HPC中的科学工作流。
首先，让我们简要回顾一下在洛斯阿拉莫斯国家实验室可能会遇到的工作流。当科学家们想要理解特定零件或特定武器的某些现象时，他们会拆解这些部件，并设计实验来帮助理解这些组件以及任何未来的组件。他们会收集材料的物理属性、命名图纸，并确定感兴趣的变量，这些变量将成为遵循所有这些输入的物理模拟的输入。
当进入计算领域时，由于这些模拟变得非常复杂，因此可能需要很长时间来运行——通常需要几个月的时间，有时甚至在成千上万个计算节点上运行。然而，众所周知，计算机组件在集群环境中会发生故障，无论是软件故障、DIMM错误还是电源故障。当这些事件发生时，我们自然不希望每次都从时间步零开始重新模拟，因为这非常耗时。因此，如果遇到错误，能够从一个已知的良好点而不是时间步零重新开始，就显得尤为重要。为了实现这一点，科学家们会定期保存状态，以便在需要时能够重新启动，并从保存的已知良好状态继续模拟。
这些检查点通常占用模拟运行时所消耗内存的80%，其数据集的大小通常在PB级别，较小的也有TB级别。除了支持重启功能外，检查点还具有另一个重要作用：它允许科学家在模拟运行过程中查看当前状态。他们可以调整某些变量或平滑某些属性，然后从那个特定点继续模拟。最后，在模拟结束后，科学家会使用可视化工具来分析结果。这个过程同样非常消耗资源，无论是时间还是计算能力。为了找到感兴趣的属性，科学家们通常会对感兴趣的字段进行排序，如能量或温度。
请注意，当有一万个计算节点时，某个特定感兴趣字段的数据点可能高达数百万个。因此，进行大规模排序，或对下一个感兴趣的列或行进行排序，这些任务都极为耗时且资源密集，我们考虑改进这些过程。
首先，模拟的数据管理。以Crossroads为例，这是一台在2023年安装的超级计算机。用于模拟的系统大约有1PB的内存。单个时间步的检查点通常占用大约80%的内存。通过高速网络连接（Slingshot网络）大约是10倍内存容量的全闪存Lustre文件系统。接下来是一个称为项目存储（Campaign Storage）的较热存储层，这是存储在硬盘上的高度保护数据。为了保护这些数据集，我们实施了两个层次的纠删码。
数据集通常在热或闪存层存放数周，甚至数月。如果数据被高度处理，项目存储（Campaign Storage）层的数据存放时间为数月至数年。最后，当需要缩减数据量时，一旦数据存储在磁带上，它将被永久保存。然而，请注意，这里的10倍内存并没有留下很多空间来存放大量的工作集在闪存文件系统中。因此，我们希望能够实现数据在这些层次之间的灵活移动，并顺利进入项目存储（Campaign Storage）层。我们真正希望提供的是一套高效的数据管理工具，既能方便用户搜索数据集，又能让数据在这些层次之间无缝迁移。
典型用户在操作数据集时的工作流包括在模拟前确定所需的输入参数，这些输入参数包括初始状态、表格常数、网格配置以及任何从检查点重新启动的信息。
首先，他们需要找到数据：数据是存放在临时存储、热存储层、较冷的项目存储（Campaign Storage）层，还是从归档中提取？目前，我们常用的工具是find和stat，因为我们要求用户自行组织数据。糟糕的数据组织不仅复杂而且耗时。在我们的模拟过程中，会经历检查点、数据迁移、运行、再检查点等步骤，循环往复直至模拟完成。分析阶段同样关键，用户可能会调整或修改一些运行变量，继续运行，进行数据可视化，并最终将可视化结果保存到归档中。这就要求用户对自己的数据组织有清晰的认识，否则他们将在搜索数据集上浪费大量时间。当前的系统并没有提供一个良好的机制来注释数据集，用户只能将信息存储在文件中。元数据搜索可能非常缓慢，这通常受限于每个文件系统的能力或并行搜索工具的性能。数据移动是并行进行的，但过程复杂，需要一个单独的集群来处理。这些都是我们想要解决的一些问题。
右边的表格简要概述了我们的开放环境，这个环境明显小于Crosswords所在的环境。然而，即使在这个较小的环境中，我们也拥有近7亿个文件，因此数据组织成了一个亟待解决的问题。
为了应对这些挑战，我们采用了关键技术，包括元数据索引。Grand Unified File Index （GUFI） 会对数据中心各存储层的元数据进行快照保护，确保管理员和用户能够同时访问。我们通过复制目录结构并在该目录层级上实施POSIX权限，来遵循源存储系统的POSIX权限设置。我们没有复制文件本身，而是将SQLite数据库嵌入到目录中，用于存储有关文件和子目录的信息。这一强大的工具使得在数据中心的所有存储层上进行快速搜索成为可能，用户和管理员可以在几秒钟内完成通常需要几分钟或几小时的查询。
第二个工具与数据移动相关，名为CONDUIT。它允许我们调度数据迁移，而无需用户登录到单独的集群。CONDUIT提供了一个CLI和与Slurm调度器的集成，通过串行化数据移动来防止用户在迁移大数据集时相互干扰。它利用并行复制工具和一个独立的数据传输集群，用户无需在单独的系统上执行命令。
第三点是用户定义的元数据。GUFI允许用户通过利用扩展属性来定义元数据，但并非所有文件系统都支持这些扩展属性，也并非所有用户都熟悉其使用。我们与LANL的数据科学基础设施（DSI）项目合作，允许用户在源文件系统内存储数据库。我们将GUFI连接到这些源数据库，使用户能够插入有关模拟的信息，并通过GUFI查询用户定义的元数据和感兴趣的数据集。
最后，计算型存储通过将计算型存储技术应用于元数据索引所在的系统，进一步加快了查询速度。我们还改进了ZFS和Lustre等存储系统，为用户透明地卸载压缩和数据保护等任务。我们在SDC和其他SNIA活动中报告了这些改进，如AOF，这些报告是与Tycom、Aon Computing、SK Hynix和NVIDIA等公司合作完成的。
在底部，是GUFI模型的示意图。可以查阅相关论文，并利用这些图表深入了解GUFI的工作原理。
接下来，我们进入第二个探索主题。
假设一位科学家正在进行等离子体模拟，以理解磁重联现象。在等离子体模拟中，会让两个等离子体相互流动。尽管我不是物理学家，但通过讨论我了解了用户的思考方式。他们希望识别出高价值粒子。“数据是无序的”意味着这些数据是为了写入而优化的，而非读取，因为排序操作非常耗时。为了理解高价值粒子，数据需要从存储中移回系统内存进行排序或可视化，这非常消耗资源。
这些模拟通常采用每个进程生成一个文件的方式，记录基于粒子的数据，包括粒子ID和与之关联的值。
例如，粒子模拟的可视化可能展示每个时间步长，其中红色粒子表示具有最高动能的粒子。构建这些可视化需要对每个时间步长的数据进行字段排序，尽管代价高昂，但对模拟科学家来说非常有用。
为了加速这一过程，我们采用了键值对API技术。如前所述，我们有粒子ID和与该粒子相关的值，因此这与面向记录的格式（如键值对）非常匹配。显然，SSTables（LevelDB和RocksDB等工具）在这里发挥了重要作用。次级索引支持范围查询，这一点很重要，因为我们关注的是与粒子相关的值的排序。
我们与SK海力士进行了大量优化工作，通过将整个键值存储系统卸载到设备内部，以及在设备内部放置特定功能（如过滤或压缩），实现了显著的加速效果。我们还与另一家出色的合作伙伴AirMettle合作，研究直方图生成技术。
当我说我们必须定义“高”的概念时，科学家在分析时往往难以判断哪些值代表“高”。他们没有一个明确的基准来判断“高”。虽然可以查看数据的最大值和最小值，但这通常涉及到排序操作。然而，如果我们能在数据写入时就构建出空间高效的直方图，那么我们就可以利用这些直方图在执行更高级查询之前设定一些界限。正如我所说，通过采用这些方法，我们在整个端到端的工作流程中观察到了显著的加速效果。
我之前提到的例子相对简单，因为它只涉及粒子和粒子ID及其对应的值，这些模拟中并没有复杂的网格行为。但我们的目标更为宏大，比如追踪超出等离子体模拟范围的冲击波的高能量区域。用户可能希望按时间跟踪冲击波边缘的高能量区域，他们可能会查看先前的二维或三维模拟以了解过去的行为，并为当前的模拟设定一组输入参数。他们可能希望利用我们的数据管理工具来搜索先前的模拟数据。他们会进行GUFI查询，询问“在模拟的早期或晚期，冲击波前缘的最大能量位于何处？”这些问题正是他们可以利用我们用户定义的元数据方案来定义的。
再次强调，我们将沿用相同的运行、检查点和分析流程，并且这种流程将保持不变。但用户真正关心的是冲击波如何随时间移动、能量高的地方在哪里、“高”到底意味着什么，以及在高能量区域附近发生了什么。正如我一开始所说，这是一种更为复杂的数据组织方式。基本上，可以将这种数据组织方式理解为列存储。它们将数组存储到文件中，这种场景下，这被称为N对1的工作负载，其中N个进程将各自的数据全部写入一个文件。因此，这是一种共享文件的模式。这种方式是列存储，而不是面向记录的，因为每个进程会将所有的温度数据存储在文件的同一部分。文件中将包含N个进程对应的N个温度值，然后依次向下写入它们的能量值和其他感兴趣的变量。因此，这与我之前描述的键值对或面向记录的格式有着截然不同的访问模式。
最后需要注意的是，数据组织变得更为复杂的原因在于高兴趣区域——比如这些红色或蓝色区域——在这些区域，网格会被细化。例如，大的方块会变成四个较小的方块，或者四个较小的方块会变成八个更小的方块。这是因为我们特别关注这些区域的数据。由于我们无法将整个模拟数据都装入内存，因此我们需要通过这种方法来处理：“好吧，如果某些区域不那么有趣，我们就把网格变粗，因为我们并不关心那里发生了什么。但在真正高兴趣的区域，我们要增加更多的网格块，这样我们就有更多的感兴趣区域可以探索。”
如果你观察一个二维波跟踪的例子，你会看到在这个材料的前方发生了一些现象。可以看到网格在变形。虽然我不确定这是温度还是能量的变化，但我们通过给变量上色来跟踪它，并查看多个时间步长，以了解波动如何影响该材料。如果你想要对每个感兴趣的变量进行上色并构建这些可视化，这将变得非常复杂，因为这需要对PB级的数据进行大规模排序。
再来看一个三维冲击波跟踪的例子，同样，我们在查看多个时间步长，因为这是一个视频序列。但如果我们暂停并查看单个时间步长，我们可以看到冲击波后效应的发生。科学家们希望跟踪这些波的边缘，并观察它们如何相互作用和扩散。网格在感兴趣的区域发生变形，变得更加细化，这样我们可以跟踪感兴趣的项目，而可能不再感兴趣的区域则网格变粗。由于这些数据集非常庞大，达到PB级，因此进行排序操作非常耗时且资源消耗大。我们如何在这种列存储的情况下改进这一点？
关键技术：
我们当然希望利用一个开放的生态系统和现有的数据分析工具。我们不希望用户必须学习全新的数据工具或开发可能不被开源支持的新工具。
目前，每个应用程序都使用列式文件格式，尽管并不总是采用如Parquet这样的开放文件格式；有些是自定义的，拥有自定义的读取器和写入器，并且并非所有都提供索引功能。我们确实在推动使用类似Parquet的开放标准。已经有工具支持Parquet；这是我们希望向行业标准迈进的一部分。
我们还希望利用推送机制，如Substrait这样的技术来实现计算型存储。如果我们有PB级的数据集，我们不想移动整个PB级的数据来进行过滤。我们更希望在数据存储的地方尽可能接近地进行过滤操作。这将极大地减少数据检索的数量级。我们当然对替代的推送协议感兴趣。
块存储显然是主流选择，但我们也想看看文件协议在设备层面是否同样具有吸引力。
对象存储和NVMe键值存储在直方图工作中已经被证明是有用的。
这些操作可以在客户端进行，也可能在存储系统内部的分析阶段进行。但同样，这里的主要目标是减少分析阶段所需的资源，无论是时间还是计算资源。我们不希望占用我们的超级计算机资源进行数据排序工作。
最后，我们要决定是否使用中间件是正确的方法。如果中间件用于直方图构建、文件转换、数据可视化或最终是推送机制，如果我们需要为用户提供透明使用这些功能的中间件，这绝对是我们可以实现的目标。
若我们将这些元素综合起来，审视我们当前部署的系统，以及未来必然会设计和部署的系统，我们可能会发现系统中存在类似智能内存这样的技术。我们将充分利用这一技术。通过直接向计算客户端提供这些数据管理工具及前端服务，并解耦我们的存储和存储服务器，我们可以为用户提供他们所需的特定IO模式或IO架构的更多服务。这些服务可能包括列式键值特定服务或仅提供高带宽的大数据服务。在同一网络上的介质外壳可以直接暴露给数据服务服务器，或者直接暴露给计算客户端。这两个层面都可以应用计算型存储技术。您可以在这些服务器中部署加速器，或者直接在您的网络连接外壳中采用符合计算型存储标准的NVMe驱动器。
我们将建设一个规模较小的数据分析集群，可能包含数十个节点，根据内存需求而定。同时，我们仍然拥有右侧的数据传输集群。但如今，数据的移动是通过计算节点进行调度的，而不再是直接登录并在数据传输集群上运行命令。
计算型存储在过去几年里对我们而言极具吸引力。它代表了我们存储研究的前沿，我们坚信它能够解决我们面临的许多数据挑战
--【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/单位/关注领域）
