聊聊 AI 平台存储方案和选型

最近火爆全网的 ChatGPT 再次带来一股 AI 热潮。过去的五年，AI 快速发展并应用到很多领域中。作为一家存储企业，我们也感受到了 AI 行业的活力，和我们交流团队中，AI 企业越来越多，有自动驾驶、蛋白质结构预测、量化投资等不同行业。

AI 场景给数据存储带来新挑战，原有的存储方案并不能完好地满足。今天借这篇文章抛砖引玉，和大家分享我们看到的AI场景的特点和趋势，以及现有的解决方案有哪些，他们的优劣势分别是什么。在文末，我们比较了 12 款共享文件系统，欢迎一起讨论交流。

01- AI 数据工程的存储挑战

高吞吐的数据访问挑战。在 AI 场景中，随着企业使用 GPU 越来越多，底层存储的 IO 已经跟不上计算能力。企业希望存储系统能提供高吞吐的数据访问能力，充分发挥 GPU 的计算性能。举个例子，在智能制造生产线上通过高精度相机给物品拍照，用缺陷识别模型自动找出质量问题。这类模型的训练集只有 1~2 万张图片，但每张都是 GB 大小的高精度照片，总容量有 10TB 了。训练过程中，如果存储系统吞吐不足，会成为 GPU 训练的瓶颈。

AI 场景对于 10 亿以上文件规模的存储管理和高性能访问的需求越来越强。在自动驾驶领域，用于模型训练的是百 KB 的小图片，一个训练集由数千万张百 KB 图片组成，一张图片就是一个文件，总的训练数据多达几十亿、甚至一百亿文件。海量小文件管理一直是文件存储领域的难题。

为热点数据提供吞吐扩展能力。在量化投资领域，用于模型训练的金融市场数据量相比 CV 领域小了很多，但是需要被多个研究团队共享，这会带来数据热点问题，就是数据存储的磁盘吞吐已经用满，但是仍然不能满足应用端的需求。

除了由 AI 场景带来了新的数据模式，基础的计算环境也发生了巨大的变化。

如今在资源建设中，上云几乎已经是默认选项。虽然很多团队会建设自己的 IDC，但也会做私有云的设计。同时，Kubernetes，已经成为了云原生架构的事实标准。我们看到在 AI 业务中，整个 Data Pipeline 都构建在 Kubernetes 上，算法工程师在平台上申请资源，使用 Notebook 编写代码完成算法调试，使用 Argo、Airflow 等工作流引擎编排数据处理工作流，使用 Fluid 管理数据集，使用 BentoML 部署模型到应用中。云原生技术栈也是企业在建设存储平台时，普遍会考量的一个因素。随着云计算的成熟，AI 业务更多转向大规模分布式集群完成。集群中的节点数大幅度增加，存储系统如何面对 Kubernetes 集群中上万 Pod 的并发访问是新的挑战。

基础架构的IT人员面临来自业务场景、计算环境的巨变，反观现有的存储方案，软硬一体机普遍存在这样的痛点：1）不弹性；2）没有分布式高可用；3）集群规模受限，已经越来越少被使用；而分布式文件系统，比如 GlusterFS，CephFS，还有面向 HPC 设计的 Lustre， BeeGFS 和 GPFS。它们都是面向物理机、裸磁盘设计的存储系统，虽然可以部署大容量的集群，但是在云环境中同样不能提供弹性容量，更无法提供弹性的吞吐能力，在上百亿文件的存储需求上也已经力不从心。

结合上文提到的这些挑战，我们罗列了对AI场景至关重要的存储能力，方便企业在选择存储产品时进行比较。

02- AI 数据存储需要的关键能力

第一： POSIX 兼容性和数据一致性

在 AI/ML 领域，POSIX 是数据访问最普遍的接口。上一代分布式文件系统，除了 HDFS，也都兼容 POSIX，但是近几年云上的产品在 POSIX 支持上的做法并不一致，有几点需要大家特点注意。

兼容度。用户不能只是通过「产品兼容 POSIX」这样的描述判断，可以使用 pjdfstest 和 LTP 框架进行测试，我们做过一次云文件系统的 POSIX 兼容性测试供大家参考。
数据强一致性保证，这是保证计算正确性的基础。存储系统有多种不同的一致性实现，比如对象存储通常是最终一致性（Eventually Consistency），文件系统通常是强一致性（Strong Consistency），我们做存储系统选型时需要注意。
用户态还是内核态的选择。早期开发者选择内核态，因为这种方式 I/O 路径有可能做到最极致的优化。但是这几年，我们遇到了越来越多「逃离内核态」的开发者，原因有这样几个：第一，使用内核态需要文件系统客户端与内核版本绑定，然后 GPU 和高性能网卡的驱动往往也需要适配特定的内核版本，几样东西排列组合对内核版本的选择和运维是很大的负担。第二，内核态客户端的异常会宕住宿主机操作系统，这一点对于 Kubernetes 平台是非常不友好的。第三，用户态的 FUSE 库也在持续迭代，性能有了很大提升，在 JuiceFS 的客户中已经很好的支持了自动驾驶感知模型训练、量化投资策略训练等业务需求，可见在 AI 场景中已经不是性能瓶颈。

第二：吞吐的线性扩展能力

不同的文件系统，在扩展吞吐能力时的原理是截然不同的。上一代分布式存储系统的设计中，比如 GlusterFS，CephFS，还有面向 HPC 领域的 Lustre， BeeGFS 和 GPFS ，大多采用全闪方案构建。这类存储系统的吞吐峰值等于集群中的磁盘总性能，用户需要提高集群的吞吐能力，只能为集群扩容，增加更多的磁盘。

但是，当有些用户对容量的需求和对吞吐的需求并不平衡，如对少量热点数据有非常高的吞吐需求。这些传统的文件系统，此时也只能为整个集群扩容，造成容量的浪费。

举个例子，一个 500TB 容量的集群，如何使用 8TB 一块的 HDD（磁盘），2副本需要 126 块盘，每块盘的吞吐是 150MB/s，集群的理论最大吞吐是 126x150 = 18GB/s。如果业务需要 60GB/s 的吞吐，有两个方案：

1）换 2TB 一块的 HDD 盘（吞吐也是 150MB/s），总共需要 504 块盘；
2）换 8TB 一块的 SATA SSD（吞吐是 500MB/s），还是 126 块盘。
第一个方案因为多出 4 倍磁盘数量，集群的节点数要相应增加。第二个方案由 HDD 换成 SSD，成本也会大幅上升。

可见，在容量、性能和成本三角上很难去平衡，基于这三个角度的容量规划也就成为了一个难题。因为事先规划，我们无法预测真正业务的发展、变化和其中的细节。因此，如果能将存储容量与性能的扩展解耦，对企业来说将是一件事半功倍的方法，这也是 JuiceFS 在设计时就考虑到的需求。

同时，热点数据也是 AI 场景中的一个常见问题， JuiceFS 缓存分组机制，就可以把热数据自动分配到不同的缓存组中，相当于在计算过程中可以自动将热点数据复制多份，来获得更高的磁盘吞吐，计算完成后又可以自动回收这些缓存空间。

第三：海量文件

管理 100 亿文件，对存储系统有三方面要求：

弹性扩展。JuiceFS 用户的真实场景就是从数千万扩展到数亿，再到数十亿，这个过程靠给几台机器加配置是不行的，一定是存储集群增加节点实现横向扩展，才能最好的支持用户业务成长。
横向扩展时的数据分布。在系统扩展的过程中，很多系统的数据分布设计是基于目录名前缀做哈希分布的，这种规则在真实业务数据中可能会造成分布不均衡。
扩缩容复杂度。随着文件数的增加，系统扩容是否简单，运维是否简单稳定并且有足够的工具来掌控存储集群，是海量文件存储系统一直的挑战。有些系统在文件数量增长到几十亿之后会越来越「脆弱」。容易运维，稳定性高一定是业务增长需要的。

第四：在 Kubernetes 环境中的并发负载能力与功能支撑

当我们查看存储系统的规格，有一部分存储系统会明确告知并发访问上限，用户需要结合业务去做实际的压测。同时，客户端多了，也需要进行 QoS 治理，包括每个客户端的流量控制，对读写进行临时封禁策略等，这样才能保证整个平台的管理可行性。

在 Kubernetes 中还要注意 CSI 的设计和支持的功能。比如挂载进程的部署方式，是否支持 ReadWriteMany，Subpath 挂载，Quota 配额，热更新等等。

第五：成本

成本是一个非常综合的概念，软硬件的采购成本是容易计算的，人们容易忽略的是运行和维护成本。
AI 业务规模从小到大，数据量的增长跨越了两个、甚至三个数量级。存储系统容量和吞吐要有足够的扩展能力，而且要方便调整。

在过去机房中建设 Ceph、Lustre、BeeGFS 等系统时，因为集群扩容不方便，一般都按年度规划用量，然后采购机器，等待到位上架，再完成软件配置的变更，整个时间周期一般需要 2-3 个月，单单服务器准备好，完成软件上的扩容配置，也需要 1 周左右。这里的时间成本往往是企业中最昂贵的成本，而且往往不容易被关注。如果存储系统在容量和性能上可以弹性配置，容易扩展，意味着业务也能更快推向市场。

再看第二个容易被忽视的效率成本。从 AI 业务流程看，它是一个非常长的 Data Pipeline，每个环节都需要和存储系统打交道，包括数据的采集、清晰转换，标注、特征提取、训练、回测，到上生产环境。在 Data Pipeline 中，存储系统会影响到每一个环节的效率。而企业在一个业务阶段内使用的数据往往不超过全部数据的 20%，对于这部分热数据有很高的性能需求，其他温冷的数据偶尔访问或不访问。对热数据的需求是高性能，对温冷数据的需求是低成本。在 Ceph、Lustre、BeeGFS 等系统中很难同时满足这两点。

所以我们可以看到很多团队会构建多套存储系统应对不同的需求，常见的方案是用一套对象存储做全部数据的归档，做到大容量低成本，但性能不高，在 Data Pipeline 上承担数据摄取和预处理、清洗环节。在对象存储完成数据的预处理并不是最高效的方式，但因为数据量太大，出于成本原因往往是不得已的选择。然后工程师又需要等待大量时间把数据复制到训练用的文件存储中，完成模型训练环节。

所以，除了存储系统的软硬件成本，集群运维（包括采购供应链）投入的时间成本，业务在多个存储系统之间管理数据所投入的时间成本都应该计算在总成本中。