1. 版本控制概述
大家好，我是这次课程的主讲。咱们直接进入正题——数据版本控制。
先问一个问题：你手头有没有一份数据，改着改着就不知道哪个版本是对的了？
我遇到过不少团队，数据文件命名是这样的：report_v1.xlsx、report_v2.xlsx、report_v3_final.xlsx、report_v3_final_真的不改了.xlsx。嗯，看着眼熟吧？
这种混乱，说白了就是没有版本控制。代码有 Git，数据呢？数据也需要一套类似的机制来管理它的生命周期。
1.1 为什么需要数据版本控制？
数据不是静态的。它会变。模型训练数据要更新，报表数据要修正，ETL 流程要重跑。每一次变化，都可能引入新的问题。
我个人习惯把数据版本控制的核心价值总结为三点：
- 可追溯：知道数据「从哪来、到哪去、中间改了什么」。
- 可复现：任何时候都能回到某个历史状态，重新跑一遍实验或报表。
- 可协作：多人同时操作同一份数据，不会互相覆盖、不会丢失变更。
你想想看，如果模型上线后发现效果不对，你怀疑是训练数据出了问题。没有版本控制，你连「之前用的到底是哪份数据」都说不清。有了版本控制，直接 checkout 到那个时间点的数据快照，一对比就知道差异在哪。
核心观点：数据版本控制不是「锦上添花」，而是数据工程的「基础设施」。没有它，数据质量就是空中楼阁。
1.2 核心概念：快照、变更集、时间线
聊概念之前，我先说个真实经历。我曾经在一个金融项目中负责风控模型的数据管道。有一次上游数据源改了字段类型，下游模型直接崩了。排查了整整两天，最后发现是数据版本没对齐。从那以后，我强制团队所有数据变更必须打标签、写变更说明。
好，咱们来看几个必须搞懂的概念。
| 概念 | 说明 | 类比代码版本控制 |
|---|---|---|
| 快照（Snapshot） | 某一时刻数据的完整副本 | Git 的 commit |
| 变更集（Change Set） | 两次快照之间的差异记录 | Git 的 diff |
| 时间线（Timeline） | 所有快照按时间顺序排列的链条 | Git 的 log |
| 分支（Branch） | 从某个快照分叉出去的独立数据线 | Git 的 branch |
| 标签（Tag） | 给某个快照打上语义化标记 | Git 的 tag |
这里有个容易混淆的点：快照和变更集有什么区别？
快照是「全量」的，变更集是「增量」的。存储快照占空间，但恢复快；存储变更集省空间，但恢复慢。实际项目中，我建议混合使用——定期打快照，中间用变更集串联。
我的经验：数据量在 100GB 以下时，全量快照更省心。超过 1TB，必须用增量变更集 + 定期全量快照的策略。否则存储成本会让你哭。
1.3 核心业务场景
光说概念太干。咱们看几个真实场景，你就知道这东西到底用在哪儿了。
场景一：机器学习模型训练
模型训练对数据版本极度敏感。你训练了一个模型，效果不错。三个月后想复现，发现原始数据已经被清洗过好几轮了。没有版本控制，你根本拿不到当初那份数据。
我建议的做法是：每次训练前，把输入数据打一个快照，关联到模型版本。这样模型和数据的绑定关系就清晰了。
# 伪代码示例：数据版本与模型版本绑定
data_snapshot_id = dvc.commit("training_data_v3.2")
model_version = mlflow.log_model(model, data_ref=data_snapshot_id)
# 以后通过 model_version 就能找到对应的数据快照
场景二：BI 报表与数据分析
业务部门经常问：「上个月的报表数据跟这个月对不上，是不是你们改过数据？」
有了数据版本控制，你可以直接回答：「上个月报表用的是数据版本 v2.1，这个月用的是 v2.3，中间有一次字段映射调整。差异在这里。」
场景三：监管合规与审计
金融、医疗行业对数据溯源有硬性要求。监管机构要你证明「某笔交易在某个时间点的数据状态」。没有版本控制，你拿什么证明？
注意：监管审计对数据版本的要求不仅仅是「能查到」，还要「不可篡改」。所以生产环境的数据版本控制系统，必须支持写保护或签名校验。我曾经见过一个团队用普通文件系统做版本管理，审计时发现历史快照被人为删除了……后果很严重。
1.4 数据版本控制 vs 代码版本控制
很多人觉得「数据版本控制不就是把 Git 用在数据上吗？」——不完全对。
数据有几个特点，让它的版本控制比代码更复杂：
- 体积大：代码仓库通常几百 MB，数据仓库动不动 TB 级。
- 格式多样：结构化表格、非结构化文本、图片、音视频……
- 变更粒度粗：代码改一行，数据可能改整个分区。
- 存储成本敏感：全量快照的存储开销远高于代码。
所以，数据版本控制工具（比如 DVC、LakeFS、Delta Lake）在设计上跟 Git 有本质区别。它们更关注：
- 如何高效存储大文件（指针 + 对象存储）
- 如何支持增量变更（避免全量复制）
- 如何与数据湖/数据仓库集成
1.5 本章知识体系总览
下面这张图，把本章的核心逻辑串起来了。你可以把它当作后续学习的「地图」。
这张图展示了从「为什么需要」到「核心概念」再到「业务场景」和「工具选型」的完整链路。后面的章节，我们会沿着这个链路一步步深入。
1.6 小结
这一章我们聊了：
- 数据版本控制的三个核心价值：可追溯、可复现、可协作
- 五个核心概念：快照、变更集、时间线、分支、标签
- 三个典型业务场景：模型训练、BI 报表、监管合规
- 数据版本控制与代码版本控制的差异