对象存储为什么成为 AI 数据平台的重要组成部分，大规模训练数据应该如何管理

过去几年，人工智能基础设施最明显的变化之一，就是数据存储的重要性快速上升。模型参数规模不断扩大，训练数据从几十 GB、几 TB发展到数百 TB甚至 PB级别以后，存储已经不再只是“把文件放进去”的后台设备，而成为整个 AI 数据平台的一部分。

尤其是在图像、视频、音频、文本、遥感数据、传感器数据以及各种半结构化数据大量进入训练流程以后，传统单机文件系统或者单纯依赖高性能块存储的架构开始暴露出扩展成本高、容量扩展困难、数据共享不方便等问题。

对象存储因此成为现代 AI 数据平台非常常见的一层基础设施。Amazon S3、Google Cloud Storage、Azure Blob Storage以及大量私有云和企业对象存储系统，都可以承担数据湖、训练数据集、模型检查点、数据归档和中间数据等不同角色。

但对象存储之所以适合 AI，并不是因为它可以简单理解成“一块特别大的硬盘”，而是因为它把海量数据的容量扩展、数据持久性、访问控制、生命周期管理和跨计算资源共享放在了一个相对统一的存储抽象中。

AI 为什么需要对象存储

传统块存储的基本单位是块，文件系统则负责在块之上组织目录、文件和元数据。对象存储采用完全不同的抽象方式。应用通常通过 API 操作一个对象，每个对象拥有唯一的键以及相关元数据，而不是要求客户端直接管理底层磁盘和文件系统。

这种模式特别适合 AI 数据平台。

一个训练数据集可能包含数百万张图片，也可能包含大量视频、音频、JSON、Parquet或者其他数据文件。数据规模增加以后，企业希望计算集群可以不断增加 GPU 节点，同时不必为每一批 GPU 单独建设一套数据存储。

对象存储可以作为计算资源之外的共享数据层。训练集群、数据处理集群、标注系统、ETL任务、模型评估环境甚至不同云环境，都可以通过标准 API 访问同一套数据。

这种计算与存储分离的架构，也是现代云数据平台的重要基础。

GPU 集群可以根据训练任务动态扩容，而数据本身不需要随着 GPU 数量增加而复制成很多份。

AI 训练真正关心的是吞吐，不只是延迟

原稿把“亚毫秒级访问延迟”作为对象存储支持 AI 的重要指标，这种表达容易产生误解。

对于大规模训练，单个对象请求延迟当然重要，但训练系统通常同时发起大量并行 I/O。一个训练任务可能有数百甚至数千个计算进程同时读取数据。

这时候决定训练效率的往往是整体吞吐能力、并发请求能力、数据布局以及计算节点是否能够持续获得数据。

如果 GPU 每秒能够执行大量计算，但数据加载速度跟不上，GPU 就可能出现等待 I/O 的情况。昂贵的 GPU 因为数据供应不足而空闲，对于大型 AI 集群来说是一项非常昂贵的浪费。

因此，AI 存储系统通常需要同时考虑：

容量

聚合吞吐

并发读取

请求延迟

网络带宽

元数据操作能力

数据格式

缓存命中率

预取能力

以及训练框架的数据加载方式。

不能只拿一个“平均访问延迟”判断对象存储是否适合 AI。

对象存储与数据湖为什么天然容易结合

现代 AI 平台经常把对象存储作为数据湖的底层存储层。

原始数据可以保存在对象存储中，清洗后的数据可以生成新的数据集，特征数据、训练集、验证集、模型输出以及历史版本也可以继续保存在同一个存储体系中。

上层再使用 Spark、Flink、Trino、Databricks、BigQuery等数据处理和分析系统，或者通过专门的 AI 数据管道读取这些数据。

这里需要区分对象存储和数据湖表格式。

对象存储负责保存对象本身，而 Apache Iceberg、Delta Lake、Apache Hudi 等技术解决的是更高层的数据表管理、Schema、快照、分区以及数据版本等问题。

因此，不能简单说“Iceberg就是对象存储的元数据服务”。更准确的理解是，对象存储可以作为 Iceberg 等数据湖表格式的底层存储，而表格式负责在大量数据文件之上建立更加可靠的数据管理层。

大量小文件可能成为 AI 数据平台的麻烦

对象存储非常适合海量数据，但“海量对象”并不意味着“文件越碎越好”。

AI 数据处理中经常会遇到一个非常现实的问题：小文件太多。

例如一个数据集拥有数亿个只有几十 KB 的小对象。虽然总容量可能并不夸张，但大量对象意味着大量元数据操作、LIST请求、GET请求和网络交互。

训练任务启动以后，如果每个 worker 都不断读取大量小对象，API 请求和网络往返本身就可能成为瓶颈。

因此，大规模 AI 数据平台通常会重新考虑数据布局。

对于适合的场景，可以把大量小文件整理成更适合批量读取的数据文件，例如 Parquet、WebDataset、TFRecord或者其他训练数据格式。

具体采用哪一种格式，需要根据训练框架、数据类型、随机访问需求以及并行读取模式决定。

这也是为什么“对象存储容量够不够”往往不是 AI 数据平台最难的问题。真正困难的是如何把数据组织成 GPU 集群能够高效消费的形式。

数据分片应该由访问模式决定

原稿把“基于哈希的分片”作为 AI 数据分片的通用优化策略，这也过于简单。

对象存储底层如何分布对象，是存储系统自己的实现问题。AI 数据平台更应该关注的是训练数据如何被组织、读取和分发。

例如图像训练可能需要随机抽样，视频训练可能需要顺序读取大量大文件，而日志分析则可能更适合按照时间和业务维度组织。

因此数据布局应该围绕访问模式设计。

如果训练过程大量随机读取，应该考虑数据索引、缓存和随机访问效率。

如果训练主要是顺序读取，可以通过合理的数据文件大小和预取提高吞吐。

如果不同 GPU worker 读取高度重复的数据，则缓存可能比重新设计底层分片算法更加有效。

这里涉及的已经不只是存储系统，而是数据工程、训练框架和网络架构共同决定的 I/O 路径。

大文件上传与训练数据完整性

AI 数据集中的视频、模型检查点以及大型压缩文件可能达到数 GB甚至更大。

对象存储通常支持 Multipart Upload，也就是分段上传。大型对象可以被拆分成多个部分并行上传，网络中断后也可以避免整个文件重新传输。

对于 PB级数据集，数据完整性尤其重要。

除了存储系统本身的持久性机制，还应该在数据管道中建立校验机制。例如记录对象大小、校验和、数据集版本以及生成时间。

训练数据不能因为一次上传中断或者数据处理程序异常而悄悄产生损坏。

更成熟的数据平台通常会把数据集当成有版本、有来源、有校验信息的资产，而不是一堆随意放在 Bucket 里的文件。

纠删码为什么适合大规模对象存储

对象存储另一个重要特点是能够采用复制和纠删码等不同的数据保护方式。

简单复制比较容易理解：一份数据保存多个副本，以换取更高的数据冗余。

纠删码则通过数据块和校验块组合，使系统在部分存储节点或磁盘发生故障时仍然能够恢复数据。

在超大规模容量场景下，纠删码通常可以比多副本方案节省大量存储空间，因此被广泛用于对象存储和归档系统。

但它并不是任何情况下都优于复制。

对于频繁访问、低延迟要求高的数据，系统可能采用不同的存储策略；对于冷数据和归档数据，则更适合追求容量效率。

而且“纠删码一定降低30%成本”并不是通用结论。最终节省多少，取决于纠删码参数、故障域、硬件成本、网络、计算开销以及云厂商具体定价。

AI 数据安全需要临时权限，而不是共享密钥

训练集通常涉及企业内部数据、用户数据、代码、商业资料甚至受监管的数据，因此对象存储权限设计不能只依靠一个长期有效的 Access Key。

比较成熟的做法是使用 IAM、Bucket Policy、Service Account、Role以及临时凭证等机制，让训练任务获得完成当前任务所需要的最小权限。

例如一个训练 Job 可能只需要读取：

training/dataset/v17/

而不应该同时拥有整个 Bucket 的删除权限。

这种最小权限原则尤其重要，因为 GPU 集群数量多、生命周期短，而且训练任务经常由自动化系统创建。如果每个任务都共享一个拥有完整权限的长期密钥，一旦凭据泄漏，影响范围会非常大。

加密、密钥和审计需要分层考虑

对象存储中的 AI 数据通常需要同时考虑传输和静态存储保护。

网络传输应该使用 TLS；静态数据可以使用云平台提供的服务器端加密，也可以根据业务需求使用客户管理密钥。

对于要求更高的环境，还需要考虑密钥轮换、密钥访问权限、审计日志以及谁在什么时候访问了什么数据。

但不能把“AES-256、TLS 1.3、HSM”写成所有 AI 平台必须同时采用的固定组合。

不同云平台和企业环境支持的加密机制、协议版本、密钥管理方式以及硬件安全模块架构并不完全相同。

安全设计应该根据威胁模型、法规要求和平台能力确定，而不是简单堆砌几个安全术语。

数据版本比“防止覆盖”更加重要

AI 数据最大的价值之一，是可重复性。

假设一个模型在八月份训练，使用的是数据集 V17。如果两个月以后，数据工程团队修改了同一批文件，那么再次训练时得到的数据可能已经不是原来的版本。

最后即使模型效果发生变化，也很难判断到底是模型代码改变了，还是训练数据发生了变化。

因此 AI 数据平台需要数据集版本管理。

对象存储本身通常可以提供对象版本控制等能力，但数据集级版本管理还需要更高层的数据编目和数据湖技术参与。

Iceberg 等表格式提供的快照机制，就是解决这类数据版本与一致性管理问题的重要工具之一。

因此，与其笼统地说“使用 MVCC 防止训练数据覆盖”，不如从数据集版本、对象版本、表快照和数据血缘几个层次分别设计。

冷热数据分层可以明显降低长期成本

AI 数据的访问频率通常并不均匀。

刚刚生成的数据集可能每天被多个训练任务读取，而几个月以前的实验数据可能一年都不会访问一次。

如果所有数据长期放在最高性能、最高价格的存储层，成本会迅速增加。

对象存储通常提供不同存储类别以及生命周期管理机制，可以根据业务规则把长期不访问的数据转换到更适合的存储类别，或者进一步归档。

但也不应该简单设定“每天访问次数低于1次就迁移”。

真正的阈值应该根据数据访问分布、恢复时间要求、读取费用、迁移费用和业务价值计算。

尤其是 AI 项目中，一份几个月没有使用的数据，可能突然因为模型重新训练而需要大规模读取。如果为了省存储费把数据放到极冷的归档层，却在训练开始时付出巨大的恢复成本，整体成本未必更低。

GPU 越快，存储架构越重要

AI 硬件的发展正在改变存储系统的压力模型。

过去 CPU 服务器读取数据时，普通网络存储可能已经足够。但现在 GPU 集群的计算能力越来越强，单个训练任务就可能产生非常高的数据消费速度。

于是存储系统不能只看“能不能存下去”，而要回答另一个问题：

能不能持续把足够的数据送到 GPU？

这也是为什么 AI 基础设施中经常出现对象存储加缓存层、分布式文件系统、本地 NVMe、数据预取和训练数据加速层这样的组合。

对象存储负责大容量、持久化和共享数据。

缓存负责降低重复读取成本。

本地 NVMe负责提供高速临时数据。

训练数据加载器负责并发读取和预取。

网络则负责把这些组件连接起来。

不同层承担不同任务，而不是让对象存储单独承担全部 I/O 压力。

什么时候应该考虑高性能文件系统

对象存储并不是 AI 场景唯一正确的答案。

如果训练任务需要大量 POSIX 文件语义、极低延迟的小文件访问、复杂目录操作或者某些特定 HPC 工作负载，那么并行文件系统或者高性能分布式文件系统可能更加适合。

因此实际架构中很常见的一种方式，是对象存储承担数据湖和长期数据源，高性能文件系统或者本地 NVMe 承担训练阶段的高速工作集。

数据先进入对象存储，经过清洗和版本管理后形成训练数据集，训练开始时再根据访问模式预取到更靠近 GPU 的存储层。

这种分层架构往往比试图让一种存储系统解决所有问题更加合理。

AI 数据平台最终管理的是数据生命周期

一个成熟的 AI 数据平台，应该从数据进入系统的第一天就考虑生命周期。

原始数据在哪里？

数据从什么来源产生？

谁拥有访问权限？

数据经过哪些清洗步骤？

哪个版本被用于训练？

训练完成以后生成了哪些模型？

哪些数据仍然需要在线访问？

哪些数据可以归档？

哪些数据应该删除？

出现数据质量问题以后，能否追溯到原始来源？

这些问题实际上构成了 AI 数据治理体系。

对象存储只是底层基础设施，但由于它承载了大量原始数据、训练数据和模型资产，因此往往成为整个数据生命周期管理的重要落点。

随着 AI 模型规模继续扩大，存储系统面对的挑战也会从“容量够不够”转向“数据能不能以足够高的吞吐、足够低的成本、可重复且安全的方式供应给计算集群”。

对象存储之所以成为 AI 数据平台的重要组成部分，核心并不是它拥有某一种神奇的分片算法，而是它提供了一个能够把海量数据、计算资源和数据治理体系连接起来的持久化数据层。真正决定 AI 训练效率的，则是对象存储、数据格式、网络、缓存、本地高速存储、数据加载框架以及训练集群之间是否形成了合理的 I/O 架构。

对于企业来说，建设 AI 数据平台也不应该从“买多少 PB 存储”开始，而应该从数据访问模式和训练工作负载开始设计。只有知道数据如何产生、如何读取、哪些数据经常访问、哪些数据需要长期保存，以及 GPU 集群到底需要多少持续吞吐，才能决定对象存储、高性能文件系统、NVMe 和缓存分别应该承担什么任务。这样的架构才能在模型规模不断扩张以后继续控制性能和成本。