为什么不该用 Git 管理机器学习数据？AI 存储架构的正确打开方式
在构建现代人工智能系统的过程中，数据存储策略往往被低估，却直接影响着整个 ML 工作流的效率与可维护性。一个常见的误区是：既然代码用 Git 管理效果很好，那为什么不把训练数据也一并放进 Git 仓库？这种做法看似逻辑自洽，实则埋下了性能瓶颈、协作障碍和成本失控的隐患。
想象这样一个场景：你刚从生产数据库导出一份约 500GB 的原始数据集，准备进行清洗、归一化、特征工程等预处理操作。团队成员需要协同迭代这份数据，同时还要频繁地将其用于模型训练。于是，你决定使用 Git LFS（Large File Storage）来“版本化”这些 Parquet 文件。起初一切顺利，但很快问题浮现：每次克隆仓库耗时超过 20 分钟；CI/CD 流水线因拉取大型数据而停滞；新成员加入项目时面对庞大的历史数据束手无策。更糟糕的是，哪怕只修改了一行数据，Git LFS 也会强制上传整个文件的新副本，导致存储空间指数级膨胀。
这并非个例，而是当前 AI 工程实践中普遍存在的“存储错配”现象。要解决这一问题，首先需厘清现有三大存储范式的适用边界及其在 ML 场景下的失效点。
标准文件存储（POSIX）：快但孤岛
本地或服务器上的 POSIX 兼容文件系统（如 ext4、NTFS 或 NFS）凭借极低的 I/O 延迟和高吞吐能力，成为开发调试和 GPU 训练阶段的理想选择。当你在 Jupyter Notebook 中快速读取样本、或在训练循环中频繁访问小批量数据时，NVMe SSD 提供的毫秒级响应无可替代。
然而，POSIX 存储本质上是“单点式”的。它缺乏跨团队共享机制，难以实现细粒度权限控制，且扩容成本高昂。更重要的是，它与云原生 ML 平台天然割裂——将本地数据迁移到云端训练集群不仅耗时，还可能产生可观的网络出口费用。因此，尽管 POSIX 在“热数据”处理上表现优异，却不适合作为 ML 数据的长期归档或协作中枢。
传统对象存储（如 AWS S3）：规模大但笨重
作为大数据时代的基石，S3 类对象存储凭借近乎无限的扩展性、高持久性和低廉的单位存储成本，已成为数据湖和 Lakehouse 架构的事实标准。Iceberg、Delta Lake 等表格式均以 S3 为底层存储，Spark、Flink 等计算引擎也对其深度集成。
但 S3 在 ML 工作流中存在明显短板。首先，其“最终一致性”模型可能导致训练任务读取到不一致的数据快照。其次，S3 对象本身不可变——任何更新都需重写整个文件，这对于频繁迭代的中间数据集（如每轮训练生成的 checkpoint）极为低效。再者，S3 与代码仓库分离，安全体系依赖 IAM 策略，使得数据访问权限难以与开发流程对齐。最后，跨区域数据传输的高昂 egress 费用进一步抬高了运营成本。
Git 仓库：版本控制利器，非数据存储良方
Git 的核心优势在于对文本文件的高效差异追踪与分支合并能力。但对于二进制大文件（如 Parquet、TFRecord、HDF5），Git LFS 仅能记录文件哈希指针，无法提供有意义的 diff 信息。任何微小变更都会触发全量文件替换，历史版本则永久保留在仓库中，除非手动执行复杂的清理操作（如 BFG Repo-Cleaner）。
虽然可通过 GIT_LFS_SKIP_SMUDGE=1、lfs.fetchexclude 或浅层克隆等技巧缓解问题，但这要求每位工程师掌握额外的配置知识，违背了“开箱即用”的工程原则。更关键的是，Git 的设计初衷是管理不可变的代码快照，而非支持高频 mutable 的数据迭代。将动态演进的数据强行塞入静态版本控制系统，本质上是一种架构反模式。
破局之道：专为 ML 设计的存储抽象
面对上述困境，我们需要一种既能继承 S3 的扩展性与生态兼容性，又能支持高效增量更新、内置智能去重、并与开发流程无缝集成的新型存储方案。Hugging Face Buckets 正是为此而生。
兼容 S3 API，零迁移成本
Hugging Face Buckets 提供标准的 S3 兼容端点（https://s3.hf.co），开发者只需将现有工具链（如 AWS CLI、boto3、Spark S3A 连接器）的 endpoint URL 和凭证替换为 HF Token 生成的密钥，即可立即使用。这意味着无需重写数据加载逻辑，现有 ETL 脚本和训练 pipeline 可平滑迁移。
Xet 去重引擎：块级智能同步
Buckets 的核心创新在于其底层采用 Xet 内容可寻址存储（Content-Addressable Storage）架构。Xet 将文件切分为平均 64KB 的逻辑块，并基于内容哈希进行全局去重。当用户执行 hf buckets sync 时，系统仅传输发生变化的块，而非整个文件。
以 Parquet 文件为例：若你在末尾追加了 1000 行新数据，传统方案需上传完整的 1GB 文件；而借助 Hugging Face 的 Parquet 内容定义分块（Content-Defined Chunking, CDC）技术，系统能识别出仅最后几个 row group 发生变化，从而只同步这几个块。实测表明，在典型数据迭代场景下，数据传输量可减少 70% 以上。
值得注意的是，CDC 需在写入 Parquet 时显式启用（例如在 PyArrow 中设置 use_dictionary=False 并配合特定压缩策略），但一旦配置完成，后续所有读写操作均可自动受益于块级去重，无需修改业务代码。
Mutable 语义 vs. Versioned 归档
与 Git 强调不可变历史不同，HF Buckets 采用 mutable 模型——文件可被覆盖更新，旧版本不自动保留。这一设计精准匹配 ML 工作流中“中间产物频繁变更”的特性：训练日志、临时特征集、未冻结的 checkpoint 等无需版本追溯的数据，可高效存取而不产生冗余。
当数据集最终定稿后，用户可将其“提升”至 Hugging Face Dataset Hub 的版本化仓库中，获得完整的 Git-like 版本历史、社区协作功能和长期归档保障。这种“mutable 中间态 + immutable 终态”的双模策略，兼顾了开发敏捷性与发布可靠性。
构建 AI 存储的黄金法则
基于上述分析，可提炼出适用于绝大多数 AI 项目的存储架构原则：
Git 专注代码与配置：仅将源代码、Dockerfile、YAML 配置、Notebook 脚本等文本资产纳入 Git。避免任何形式的大文件提交，即使使用 LFS。
POSIX 用于热数据处理：在本地开发或 GPU 训练节点上，使用高速本地存储缓存当前任务所需的数据子集，确保低延迟访问。
HF Buckets 承载数据湖与中间产物：将原始数据湖、清洗后的特征集、模型 checkpoint、agent trace 日志等统一存入 Buckets。利用其 S3 兼容性和 Xet 去重能力，实现高效协作与低成本迭代。
版本化归档最终数据集：当数据集通过验证并用于正式训练时，将其发布至 Dataset Hub，赋予唯一版本号，便于复现与审计。
此外，HF Buckets 还提供 CDN 预热加速全球访问、低于行业平均水平的 egress 费用、以及符合 SOC 2 的安全合规保障，进一步强化其作为 ML 基础设施的竞争力。
结语：存储即体验
在 AI 工程日益复杂的今天，存储不再仅仅是“放文件的地方”，而是直接影响开发体验、训练效率和团队协作的关键基础设施。继续滥用 Git 管理 ML 数据，无异于用螺丝刀敲钉子——工具错配必然导致事倍功半。转向专为机器学习设计的存储抽象，不仅是技术选型的优化，更是对工程文化的一次升级：承认数据与代码的本质差异，尊重各自的最佳实践，才能构建真正可持续的 AI 系统。