在大家刚开始投入到预训练模型时，有这样一种观点：GPU 很贵，相比之下存储的成本忽略不计，可以直接选性能最好最贵的存储方案。典型的高性能文件系统有 GPFS、Lustre、Weka，以及其他高性能 NAS 等。这些系统通常依赖全闪存(NVMe) 和高性能网络提供极致性能。
同时，当算力、数据与团队投入都增大的时候，我们又看到了几个新的事实：
1. 零一万物在其最新发表的论文《Yi: Open Foundation Models by 01.AI[1]》(以下简称《Yi 论文》)，其预训练数据集包含 3T tokens，通过 BPE tokenization 处理，每个 token 大约占 2Bytes，这意味着 3T tokens 大约等于 6TB 数据。然而，准备可用于正式训练的数据集的过程包括数据抓取、清洗、转换等多个前置步骤，涉及大量的实验。这些实验处理的数据量通常是正式训练数据集的 100 倍以上。随着团队规模的扩大，将产生更多实验结果和中间数据，加上各种模型的 checkpoint 和日志数据，预训练环节总数据量预计将达到 10PB 到 100PB。
2. 正式训练环节，如上文推算，虽然数据集规模固定为 6T，企业可以将全部数据存储于高性能存储系统中。但是，高性能文件系统的性能都与容量是关联的。例如，每 TB 容量提供 250MBps 吞吐，也就是说仅仅把 6TB 数据集存在高性能文件系统，仅能提供 1500MB/s 的吞吐，如果要达到训练所需的 I/O 性能，需要扩大高性能文件系统容量。
于是，出于成本考虑用户通常不会将所有数据仅存储于之前提及的高性能文件存储系统。用户开始采用对象存储与高性能文件存储相结合的策略。这种做法虽然成本更低，但随之而来的是需要额外人力和时间去处理两套存储系统间的数据同步、迁移和一致性管理等任务，这些工作不仅过程繁琐，而且与追求高效率的目标相悖。
一、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场景至关重要的存储能力，方便企业在选择存储产品时进行比较。
二、AI 数据存储需要的关键能力
第一：POSIX 兼容性和数据一致性
在 AI/ML 领域，POSIX 是数据访问最普遍的接口。上一代分布式文件系统，除了 HDFS，也都兼容 POSIX，但是近几年云上的产品在 POSIX 支持上的做法并不一致。
1. 兼容度。用户不能只是通过「产品兼容 POSIX」这样的描述判断，可以使用 pjdfstest 和 LTP 框架进行测试。
2. 数据强一致性保证，这是保证计算正确性的基础。存储系统有多种不同的一致性实现，比如对象存储通常是最终一致性(Eventually Consistency)，文件系统通常是强一致性(Strong Consistency)，我们做存储系统选型时需要注意。
3. 用户态还是内核态的选择。早期开发者选择内核态，因为这种方式 I/O 路径有可能做到最极致的优化。但是这几年，我们遇到了越来越多「逃离内核态」的开发者，原因有这样几个：第一，使用内核态需要文件系统客户端与内核版本绑定，然后 GPU 和高性能网卡的驱动往往也需要适配特定的内核版本，几样东西排列组合对内核版本的选择和运维是很大的负担。第二，内核态客户端的异常会宕住宿主机操作系统，这一点对于 Kubernetes 平台是非常不友好的。第三，用户态的 FUSE 库也在持续迭代，性能有了很大提升，在 JuiceFS 的客户中已经很好的支持了自动驾驶感知模型训练、量化投资策略训练等业务需求，可见在 AI 场景中已经不是性能瓶颈。
准备高质量的训练数据是构建出色基础模型的基础。数据准备本身是一个复杂的流程，正如《Yi 论文》中所展示的那样：
零一万物数据预处理清洗流程
每个环节的数据处理需求都是不同的，而且这个过程在今天仍然没有一个统一的范式，数据工程师仍在不断实验。
1. 数据工程师几乎都在用 Python，在并行处理中会用到 Ray，如果使用 Spark 也大多通过 PySpark 编程。这些操作的灵活性和高效性要求底层文件系统具备 POSIX 兼容性，这样可以比较高效地满足各种数据处理的需求。
2. HDFS 只支持追加写，无法支持需要覆盖写的数据处理方法，比如 Pandas。同时，HDFS 的 Python SDK 也不够成熟。
3. S3 等对象存储不支持高效的追加或者修改，不支持重命名操作。目录操作的性能会很慢。有成熟的 Python SDK，但使用上仍然没有 POSIX 的方式简单直接。另外，数据处理工作还可能会遇到对象存储的带宽限制，高并发下可能会遇到 API 的 QPS 限制。
4. 使用 S3FS 等方案挂载 S3 等对象存储时，可以支持 POSIX 方式访问，但很多操作的性能会比我们预期的慢很多。比如对一个文件做覆盖写，需要将它下载到本地进行修改，然后再完整上传，和文件系统中的局部覆盖写是完全不同的。对一个目录做重命名也会遇到同样的问题。
5. 使用公有云的 NAS 产品，可以用 pjdfstest 做一下 POSIX 兼容性测试。另一个问题是 NAS 的性能与数据量是线性相关的，所以使用中可能会遇到当前数据量提供的性能不能满足计算需要的问题。
第二：吞吐的线性扩展能力
不同的文件系统，在扩展吞吐能力时的原理是截然不同的。上一代分布式存储系统的设计中，比如 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，成本也会大幅上升。
可见，在容量、性能和成本三角上很难去平衡，基于这三个角度的容量规划也就成为了一个难题。因为事先规划，我们无法预测真正业务的发展、变化和其中的细节。
第三：海量文件
管理百亿文件，对存储系统有三方面要求：
弹性扩展。用户从数千万扩展到数亿，再到数十亿，这个过程靠给几台机器加配置是不行的，一定是存储集群增加节点实现横向扩展，才能最好的支持用户业务成长。
横向扩展时的数据分布。在系统扩展的过程中，很多系统的数据分布设计是基于目录名前缀做哈希分布的，这种规则在真实业务数据中可能会造成分布不均衡。
扩缩容复杂度。随着文件数的增加，系统扩容是否简单，运维是否简单稳定并且有足够的工具来掌控存储集群，是海量文件存储系统一直的挑战。有些系统在文件数量增长到几十亿之后会越来越「脆弱 」。容易运维，稳定性高一定是业务增长需要的。
第四：在 Kubernetes 环境中的并发负载能力与功能支撑
当我们查看存储系统的规格，有一部分存储系统会明确告知并发访问上限，用户需要结合业务去做实际的压测。同时，客户端多了，也需要进行 QoS 治理，包括每个客户端的流量控制，对读写进行临时封禁策略等，这样才能保证整个平台的管理可行性。
在 Kubernetes 中还要注意 CSI 的设计和支持的功能。比如挂载进程的部署方式，是否支持 ReadWriteMany，Subpath 挂载，Quota 配额，热更新等等。
第五：成本
成本是一个非常综合的概念，软硬件的采购成本是容易计算的，人们容易忽略的是运行和维护成本。AI 业务规模从小到大，数据量的增长跨越了两个、甚至三个数量级。存储系统容量和吞吐要有足够的扩展能力，而且要方便调整。
在过去机房中建设 Ceph、Lustre、BeeGFS 等系统时，一般都按年度规划用量，然后采购机器，等待到位上架，再完成软件配置的变更，整个时间周期一般需要 2-3 个月，单单服务器准备好，完成软件上的扩容配置，也需要 1 周左右。这里的时间成本往往是企业中最昂贵的成本，而且往往不容易被关注。如果存储系统在容量和性能上可以弹性配置，容易扩展，意味着业务也能更快推向市场。
再看第二个容易被忽视的成本：效率。AI 业务流程是一个非常长的 Data Pipeline，每个环节都需要和存储系统打交道，包括数据的采集、清洗转换，标注、特征提取、训练、回测，到上生产环境。企业在一个业务阶段内使用的数据往往不超过全部数据的 20%，对于这部分热数据有很高的性能需求，其他温冷的数据偶尔访问或不访问。
所以我们可以看到很多团队会构建多套存储系统应对不同的需求，常见的方案是用一套对象存储做全部数据的归档，做到大容量低成本，但性能不高，在 Data Pipeline 上承担数据摄取和预处理、清洗环节。在对象存储完成数据的预处理并不是最高效的方式，但因为数据量太大，出于成本原因往往是不得已的选择。然后工程师又需要等待大量时间把数据复制到训练用的文件存储中，完成模型训练环节。
所以，除了存储系统的软硬件成本，集群运维(包括采购供应链)投入的时间成本，业务在多个存储系统之间管理数据所投入的时间成本都应该计算在总成本中。
三、存储系统选型比较
最后部分，我们把前文提到的存储产品做个比较，方便大家选型时参考。
(信息来自网络 可能有偏差)
在过去 10 年里，云计算快速发展。上一代在机房中设计的存储系统并不能集成云带来的优势，比如弹性伸缩。这期间，对象存储从无到有，为我们带来了极致的扩展性、可用性和低成本，但是它在 AI 场景中也有明显的短板。
四、多云架构：数据同步、一致性管理的挑战
无论是训练或是推理的需求，单一数据中心或单一云区域内的 GPU 资源往往无法满足用户的全部需求。特别是对于面向 C 端消费者的应用，为了提供更佳的用户体验，常常需要在多个地理区域进行部署。在这种情况下，用户面临的挑战包括数据集和模型在多区域之间的分发、同步及一致性管理等。
下图是某用户在最初使用多云架构时的数据管理方案示意图。用户需要面对的挑战有：
多云架构数据同步示意图
1. 对象存储 A 到对象存储 B 的数据同步：在处理对象存储间的数据同步时，虽然可以采用定时同步特定前缀的数据或设计对象更新回调以触发同步，这些方法在小规模数据处理时简单有效。然而，当同步作业面对大规模数据时，这些同步方案的复杂性急剧上升。挑战包括如何管理同步任务的并发执行、确保数据同步的可靠性、任务失败后的数据重建、系统的观测性、流量控制以及数据一致性校验等一系列问题。
2. 高性能文件存储与对象存储之间的数据同步：由于高性能文件存储的容量有限，需要人工决策哪些数据是近期必需的，并安排合适的时间将这些数据从对象存储中复制过来。当存储空间不足时，又必须协调众多团队成员共同决定删除哪些数据，以释放空间。这一过程中，每个人都倾向于保留自己的数据，从而避免它们被删除，这使得是否扩容或是进行团队内部协调成为一个复杂的决策问题。而扩容并非仅仅关乎成本，还涉及到额外的运维工作和资源投入，增加了同步工作的复杂度和管理难度。
3. 两边高性能文件系统中的数据同步：当用户的任务在区域 A 完成执行后，其可能被调度至区域 B 执行。这就要求任务 A 所使用的数据集需要在区域 B 内可获取，而且其先前的执行输出和日志也必须同样可访问。
4. 同步管理与一致性保证的挑战：选择强一致性还是最终一致性依赖于业务需求和技术实现的复杂度;如果选择最终一致性，明确其时间窗口的界定也是必要的，以保障系统的整体可靠性和预期行为。
5. 存储系统差异问题：这些系统在产品性能、使用限制以及管理策略等方面往往存在细微差异，这些差异要求用户采用精细化的同步和管理方法来确保数据一致性和系统效率。
还没有评论，来说两句吧...