4. 数据版本控制
在可重复研究里，代码版本控制早已是默认动作，但“数据版本控制”常被忽略。很多团队把数据集放在共享盘或对象存储里，用文件名区分版本，例如 train_v2_final.csv。一旦实验结论需要回溯，就说不清当时到底用了哪份数据。本节先厘清数据版本控制与代码版本控制的本质差异，再概览 DVC、Git LFS、Pachyderm 三类主流工具，帮助你为研究数据集选择可落地的版本锁定方案。
核心原理：代码与数据的版本控制差异
代码版本控制的核心对象是“文本差异”。Git 通过行级 diff、合并和分支管理，把每次提交记录成轻量的变更链。代码文件通常只有几十 KB 到几 MB，变更以行增删为主，因此 Git 能高效存储和比较。数据版本控制面对的是二进制大文件、列式存储、图像、模型权重，动辄 GB 到 TB 级。它们无法做有意义的行级 diff，且每次微调都会产生全新二进制块。若直接塞进 Git，仓库会迅速膨胀，克隆和拉取变得不可用。
因此，数据版本控制的关键不是“把数据放进 Git”，而是“把数据的身份、位置和血缘关系纳入版本管理”。常见做法是：Git 记录数据指针或元数据，真实数据存放在对象存储、NAS 或专用数据仓库中；通过内容哈希（如 SHA-256）保证同一版本可被精确寻址；通过流水线把“代码提交 + 数据版本 + 参数”绑定成一次可复现实验。
方法流程：把数据版本锁定进实验链路
无论使用哪种工具，数据版本锁定通常遵循以下流程：
- 确定版本单元：明确一次实验对应的数据范围，是单个 CSV、一个目录，还是带分区的大规模数据集。
- 生成内容指纹：对数据文件或目录计算哈希，作为该版本的唯一标识。
- 登记元数据：把哈希、路径、大小、生成时间、上游来源写入版本清单，并提交到 Git。
- 绑定代码与参数：在实验配置中同时引用代码 commit、数据版本哈希和超参数。
- 按需拉取与校验：复现时根据清单从存储后端拉取数据，并重新计算哈希校验一致性。
核心原则：Git 管“代码和指针”，数据仓库管“真实字节”，哈希管“身份”，流水线管“绑定”。四者缺一不可。
工具概览：DVC、Git LFS 与 Pachyderm
| 工具 | 核心机制 | 适用场景 | 注意事项 |
|---|---|---|---|
| DVC | Git 中保存 .dvc 指针文件，数据存远端；支持流水线 DAG 与实验管理 | 机器学习数据集、模型权重、可重复实验流水线 | 需配置远端存储；大目录首次推送耗时 |
| Git LFS | 用指针替换大文件，真实内容存 LFS 服务器；对 Git 透明 | 仓库内少量大文件、图像、二进制资产 | 不适合频繁变更的大数据集；LFS 配额与带宽成本需评估 |
| Pachyderm | 数据仓库原生版本化，基于 commit 的不可变数据分支，自动触发流水线 | 大规模数据管道、持续数据更新、数据血缘追踪 | 部署与运维成本较高；适合团队级平台 |
DVC 的使用非常典型。初始化后，用 dvc add 把数据纳入版本控制，Git 中会出现一个 .dvc 指针文件：
dvc init
dvc add data/raw/train.csv
git add data/raw/train.csv.dvc data/raw/.gitignore
git commit -m "锁定训练集 v1"
dvc push
复现时，先 git checkout 到目标提交，再执行 dvc pull，DVC 会根据指针文件中的哈希从远端拉取对应数据。若数据被意外修改，dvc status 会提示哈希不一致，从而避免“用错数据却不知道”的问题。
Git LFS 更适合“仓库里偶尔有几个大文件”的场景。安装后通过 git lfs track "*.psd" 声明追踪规则，提交时 Git 自动把大文件替换为指针。它不提供数据流水线能力，也不擅长管理目录级数据集，因此常作为轻量补充，而非完整的数据版本控制方案。
Pachyderm 则把版本控制下沉到数据仓库层。每次数据写入产生一个 commit，流水线订阅输入 commit 并自动运行，输出也形成新的 commit。这样数据血缘天然可追溯，适合需要持续更新、多人协作的数据平台。代价是它引入了一套独立基础设施，学习和运维成本高于 DVC 与 LFS。
案例与场景：一次“数据漂移”复盘
某研究团队用 DVC 管理图像数据集，Git 中只保留指针。一次实验复现失败，排查发现：成员在本地直接覆盖了 data/raw 下的图片，但没有执行 dvc add 和 dvc push。Git 提交记录里的指针仍指向旧哈希，而本地实际数据已变。复现者执行 dvc pull 后拿到的是旧版本，与实验者本地不一致，导致指标无法对齐。
误区：把数据放进 DVC 就万事大吉。若修改数据后不重新 dvc add、不提交指针、不推送远端，版本链就会断裂。数据版本控制要求“每次数据变更都产生新版本”，而不是覆盖旧文件。
正确的做法是：数据变更后立即 dvc add 生成新指针，提交 Git，并 dvc push 到远端；实验配置中记录该指针对应的 Git commit。这样任何人 checkout 该 commit 并 dvc pull，都能得到完全一致的数据。
选型建议：个人或小团队做机器学习实验，优先 DVC；仓库内少量大文件，用 Git LFS；需要平台化数据管道与血缘追踪，再考虑 Pachyderm。关键不是工具多先进，而是“代码、数据、参数”三者是否被同一条版本链锁定。
数据版本控制与代码版本控制并非替代关系，而是互补关系。代码版本控制回答“逻辑改了什么”，数据版本控制回答“这次实验用了哪份数据”。只有把两者通过哈希和清单绑定，研究数据集的可重复生成才有可靠基础。