从 HPC 到 AI：探索文件系统的发展及性能评估

随着 AI 技术的迅速发展，模型规模和复杂度以及待处理数据量都在急剧上升，这些趋势使得高性能计算（HPC）变得越来越必要。HPC 通过集成强大的计算资源，比如 GPU 和 CPU 集群，提供了处理和分析大规模数据所需的算力。

然而，这也带来了新的挑战，尤其是在存储系统方面，包括如何有效处理大量数据、确保数据访问的高效性以及如何控制成本和运维管理。分布式文件系统，作为一种高成本效益高的解决方案，正逐渐在 AI 和 HPC 场景中广泛应用。它们通过跨多个节点分布存储资源，有效地处理和管理大数据集，满足 HPC 对数据存取速度的高要求。

人民大学在人工智能和计算机科学领域进行了多项研究，其高性能计算中心为科研提供了强有力的支持，并在结合 HPC 与 AI 应用方面积累了一些的经验。本文将为大家介绍 HPC、大数据及 AI 应用的数据模式和特性；人大对几款主流分布式文件系统 Lustre、Alluxio 以及 JuiceFS 也做了初步性能测评，我们将分享这些测评结果，并介绍常用的性能评测工具，希望为选择 HPC 和 AI 存储解决方案的用户提供有价值的参考。

01 大规模数据应用场景：HPC vs 大数据 vs AI

高性能计算 (HPC)

高性能计算（HPC）在科学研究和工程应用中发挥着关键作用，诸如气候预测、蛋白质折叠以及计算流体力学等领域均依赖于其提供的计算能力。与机器学习和人工智能采用的方法不同，HPC 常基于模拟和科学公式推演来解决复杂问题。

在 HPC 中，任务可分为计算密集型和数据密集型。例如，天气预测既需要大量计算资源模拟天气变化，又需处理和分析庞大数据集。而如分子动力学模拟等计算密集型任务，则更侧重于计算处理，对数据依赖较少。

HPC 环境通常采用高带宽、低延迟的网络，如 InfiniBand，以支持快速数据传输。软件配置上，多节点间的高效数据通信依赖于如消息传递接口（MPI）这样的标准。

此外，GPU 的应用在 HPC 中也日益增多，加速各类计算任务。HPC 集群与传统数据中心相比，显著区别在于其网络配置和共享文件系统的使用，这些特点使得 HPC 能够有效处理计算密集型任务。

大数据

区别于 HPC，大数据应用在互联网公司的运用更为普遍，主要是因为这些公司可以持续收集庞大的用户数据量，如用户行为和上传内容等。这些通常是非结构化的数据，比如图片、音频和视频。

在这些公司中，大数据工程师常常负责 ETL 工作，即提取、转换和加载数据到数据仓库，在那里数据会被加工整理以供分析或机器学习使用。这与 HPC 的计算密集型任务不同，大数据应用更侧重于数据的处理和分析。

成本是大数据应用的一个重要考量，互联网公司倾向于使用性价比高的标准硬件和开源软件，以控制成本。例如，Hadoop 这样的开源软件因其强大的社区支持和成熟性而广受欢迎。互联网公司可以根据自身需求选择合适的软件解决方案，无论是采用开源版本以利用其优势，还是选择商业版本以获得更多支持。

AI

近年来，人工智能（AI）领域的发展已经广为人知，其工作负载主要包括训练和推理。特别是随着大型模型如 GPT 和 Bert 的出现，AI 对高性能计算（HPC）的依赖日益加深，这些复杂的模型迫切需要依靠强大的计算资源来缩短训练时间；同时，它们也带来了如何高效管理和分析海量数据的挑战。

在这个背景下，文件系统面临特殊要求，尤其是处理众多小型的图片或视频文件时，这些文件通常只有几 KB 到几 MB 大小，对 IOPS 提出了高要求。

此外，在 AI 模型的训练过程中，还有一个显著特点，即同一份数据可能会被用于多种不同参数的调优。这意味着算法工程师会不断地对模型结构进行调整和优化，包括尝试不同的参数设置、修改网络架构，以及实验各种优化技巧。

因此，AI 模型训练不仅是一个计算密集型的任务，同时也是一个需要精细操作和细致调整的过程。这种对参数和模型结构不断调整的方法是实现高效、精准 AI 模型的关键。

正是基于这种背景，数据预处理在 AI 模型训练中显得尤为关键。举一个实际的例子，来自hugging face 子公司开发的大型模型展示了数据预处理的重要性。在处理大型模型的数据时，他们设定了一个较长的处理流程。从最初收集的原始外部网页数据开始经过多次预处理，如URL 过滤、去重等步骤，原始数据量被大幅压缩。

通过下图可以看到，每个步骤都在逐渐减少数据集的大小。经过一系列处理后，最终只有不到10% 的数据量适合用于训练大型语言模型（LLM）。因此，我们看到在大型模型的训练过程中，数据预处理占据了大量工作，包括清洗数据、提取 HTML 标签、过滤广告和文本识别等复杂任务。这些步骤虽然繁重，但对于保证数据质量和优化训练结果至关重要。

02 AI 应用与分布式文件系统的演进

首先，让我们一同简单回顾文件系统的演变历程，其中每一个阶段的新兴需求都催生了新一代的文件系统。

• Lustre 是最早期的文件系统之一，专为高性能计算（HPC）设计，由美国政府资助并由多个国家实验室共同开发，以支持科学研究。

• 随后，Hadoop S3 等文件系统的出现主要是为了应对互联网数据量的爆炸性增长，与此同时，也出现了Ceph 等面向大数据处理的文件系统。这些系统旨在支持大数据应用。Alluxio 提供了一个内存缓存层。

• AlexNet 神经网络等技术的发展进一步推动了文件系统的多样化。

• 进入到 Kubernetes 时代，云原生数据管理和应用逐渐成为焦点，众多新兴的数据管理系统和应用如 JuiceFS 等都是为了适应这一环境而设计的。

文件系统作为数据存储和访问的基础设施，对于 AI 模型的训练和推理过程有着直接的影响。将文件系统应用于 AI 场景时，往往面临这两个关键挑战。

• 对 IOPS 的性能要求：首要挑战是处理包含大量小文件的数据集，如图片和视频，这对文件系统的IOPS提出了高要求。当前带宽通常足够，但文件系统的 IOPS 处理能力往往限制了性能。

• 对兼容性的要求：AI 工作流程的复杂性和跨业务团队的协作要求文件系统必须具有高度的兼容性，以支持各种数据处理和模型训练工具，确保数据能够在团队间顺畅交换和处理。

为提高性能，一些解决方案采用了 SSD 或 NVMe 等高性能存储介质，并实施本地缓存策略。这里简单介绍一下学术界的一个常见概念：Burst Buffer ，主要指通过临时存储大量数据来缓解传统存储系统在处理高速数据流时的瓶颈。在这方面，不同的文件系统提供了各自独特的解决方案，会在下文逐一介绍。

同时，在解决兼容性问题时，提供 POSIX 接口确保了兼容性和可移植性，也能解决用户的学习成本。POSIX 指的是 Linux 操作系统一系列文件接口，可以支持 POSIX 的文件系统可以像操作本机一样操作分布式文件系统。但从开发的角度来看，实现 POSIX 兼容性可能增加了额外的开发成本和复杂性。而 HDFS 和 S3 这类产品则未采用 POSIX 完全的兼容性，简化了某些方面的实现，但它们也要求开发人员或用户适应新的操作模式，这可能涉及改变现有的使用习惯和学习新的工具。

接下来将分别介绍几款适用于 AI 场景的文件系统，希望能够帮助用户更好地理解各个文件系统在 AI 应用的优势和局限。

Lustre

Lustre 在 HPC 场景中表现出色的原因在于，它从设计之初就是为了满足超级计算机的需求，特别是它对 POSIX 协议的支持以及使用 C 和 C++ 进行开发，这些特性使得 Lustre 非常适合于处理大规模并行计算任务。

Lustre 的架构特别适用于典型的超算集群环境，其中包括使用 InfiniBand 网络进行高速数据传输。集群中包含了多个计算节点（Computation）和存储节点（Data Management），用于处理元数据的 Metadata server，而实际的数据则存储在对象存储（object storage）上。这种设计优化了对 MPI 应用的支持，特别是 MPI-IO，即多个进程同时对一个文件进行读写的能力，这对于并行计算和科学研究应用尤为重要。

虽然在 AI 和机器学习应用中，MPI-IO 的直接应用可能较少，主要因为这些应用的文件操作主要写入 checkpoint，而不涉及分布式进程的直接写入。然而，对于需要并行处理和复杂数据交互的科学计算应用，MPI-IO 这样的特点仍然极其重要。

在缓存方面，Lustre 文件系统近期提供了一个功能叫做 PCC（Lustre Persistent Cache on Client）。但实际操作中，它需要运维人员进行大量的配置。

Alluxio

我们尝试部署了Alluxio 作为数据缓存层。Alluxio 的设计理念主要是作为底层存储系统（例如 HDFS 或 S3 ）之上的缓存，以此加速数据访问的速度，Alluxio 特别适用于大数据场景，如配合 Spark 等大数据处理系统使用。

在 AI 和机器学习应用场景下的测试表明，性能未达到预期。在 AI 场景中，特别是当首次请求包含大量小文件的数据集时，这一过程极为缓慢。以 ImageNet 数据集为例，我们注意到首次将数据加载到 Alluxio 可能需要几个小时，这对性能造成了严重影响。据最新消息，Alluxio 也针对这个问题做了优化，提供了专门为 AI 设计的存储方案，目前为商业版，没有开源。

JuiceFS

我们对 JuiceFS 社区版进行了初步的 POC 测试，尚未在在我们的生产系统中全面部署。

JuiceFS 是一款高性能的云原生分布式文件系统。它的设计目标是在云环境下提供高效的数据存储和访问能力。

在 JuiceFS 中，数据被分块存储在如 S3 等对象存储中；元数据则存储在如 Redis、MySQL 或 PostgreSQL 这样的数据库系统中。这种设计使得元数据管理既高效又灵活。客户端通过挂载 FUSE（Filesystem in Userspace）接口来访问 JuiceFS，这使得它能够在多种操作系统上无缝运行。同时，JuiceFS 还为用户提供了一个熟悉的文件系统接口 POSIX。另外，JuiceFS 的缓存功能可以直接支持 burst buffer。

从成本角度来看，JuiceFS 的运营成本远低于传统的磁盘阵列。这主要得益于其云原生的设计，能够有效利用云存储资源，减少物理硬件的依赖。

03 测评工具和 PoC 结果

在评估文件系统性能时，iozone, mdtest 和 fio 等 benchmark 工具被广泛用于测试 IOPS 和带宽。然而，标准的 benchmark 工具无法完整地反映真实业务场景下的需求和负载特性，为了得到更接近实际工作负载的性能评估，MLPerf 这样的工具被设计出来。

MLPerf 模拟了真实的 AI 工作负载进行评估，提供了一系列的测试。在计算机视觉领域，它可采用 ResNet 模型进行测试；而在文本处理领域，可能会使用 GPT-3 或 BERT 模型，并在维基百科或 C4 数据集上进行测试。

下面这张图表概述了在不同领域中 AI 性能基准测试的标准，包括视觉、语言处理和推荐系统等。它指定了每个测试所用的数据集，旨在达到的性能目标（如准确率、错误率等），以及各个测试的参考模型（如 ResNet、BERT、GPT-3等）。这为评估和比较 AI 模型的性能提供了一套统一的框架。

PoC 结果

以下是我们的初步测试结果。我们使用 fio 进行了测试，比较了 Lustre 、JuiceFS 和 XFS。

• 在 IOPS 和带宽读取性能上，配置了全 NVMe 闪存的 Lustre 表现出了非常高的性能。

• 在 PyTorch 上运行 ImageNet 数据集的测试中，所有文件系统完成任务的时间都相近，JuiceFS + S3 和 xfs + local SSD 共享最低。

• 在进行大型语言模型（LLM）的 checkpoint 测试时，Lustre + all flash 只用了1分钟，远快于 Lustre + HDD 的 10 分钟。

04 小结

本文分享了 HPC、大数据和 AI 等需要处理大规模数据的场景及其数据特性。介绍了适用于 AI 场景的常见文件系统及其优缺点，并展示了人大高性能计算中心的内部测试结果。

企业在选择文件系统时，不仅要参考 benchmark 结果，还需考虑实际业务需求和成本。对于运维能力有限的企业，像 Lustre 这样有着完善支持的文件系统更加合适。而有运维能力的公司可能会倾向于成本效益更高的开源解决方案。最终的选择需要综合考虑成本、运维能力和其他因素。

希望这篇内容能够对你有一些帮助，如果有其他疑问欢迎加入 JuiceFS 社区与大家共同交流。