4、数据版本管理：DVC等工具的使用，数据集、特征、模型的版本化

核心原理：为什么ML流水线需要数据版本管理

在传统软件工程中，Git已经完美解决了代码的版本追踪问题。但ML流水线的产物远不止代码——一个训练好的模型由代码 + 数据集 + 特征工程逻辑 + 超参数共同决定。如果只对代码做版本管理，当模型效果回退时，你将无法复现“当时用了哪份数据、哪个特征组合”的训练环境。DVC（Data Version Control）的核心思想是：将大文件（数据集、模型、特征文件）的元数据存入Git，而将实际文件内容存入本地或远程存储（如S3、OSS、NAS）。Git仓库中保存的是轻量的.dvc文件，它记录目标文件的哈希值（MD5），从而让Git的版本指针与数据文件形成一一对应关系。

方法流程：DVC在ML流水线中的标准操作

DVC的操作与Git高度相似，但针对数据文件增加了dvc add、dvc push、dvc pull、dvc repro等命令。下面是一个典型的ML项目版本管理流程：

1. 初始化与配置：在项目根目录执行dvc init，然后通过dvc remote add -d myremote s3://mybucket/dvcstore配置远程存储。
2. 数据注册：对原始数据集执行dvc add data/raw.csv，DVC会计算文件哈希，将文件移入缓存目录，并生成data/raw.csv.dvc指针文件。
3. 版本提交：使用git add data/raw.csv.dvc和git commit -m "更新训练数据"记录版本。
4. 远程同步：执行dvc push将缓存中的实际数据上传到远程存储，实现团队共享。
5. 流水线追踪：通过dvc run命令记录训练步骤，自动生成dvc.yaml文件，追踪数据→特征→模型的依赖关系。

# 初始化DVC并配置远程存储
dvc init
dvc remote add -d myremote s3://mlops-bucket/dvc-store

# 注册数据集并提交版本
dvc add data/raw.csv
git add data/raw.csv.dvc
git commit -m "新增2024年Q2用户行为数据"

# 训练模型并追踪依赖
dvc run -n train_model \
        -d data/raw.csv \
        -d src/train.py \
        -o models/model.pkl \
        python src/train.py

# 推送数据到远程
dvc push

案例场景：多版本数据集与模型回退实战

假设你正在开发一个用户流失预测模型，经历了三次数据迭代：v1.0（基础数据）、v2.0（增加用户行为特征）、v3.0（修正标签噪声）。每次迭代都对应不同的数据集和模型版本。当发现v3.0模型在线上表现反而不如v2.0时，需要快速回退。

回退到v2.0版本的操作非常简单：

# 查看历史版本
git log --oneline
# 输出: a1b2c3d v3.0修正标签噪声
#       e4f5a6b v2.0增加行为特征
#       7a8b9c0 v1.0基础数据

# 回退到v2.0的提交
git checkout e4f5a6b
# 恢复对应的数据集和模型文件
dvc checkout
# 此时工作区中的data/raw.csv和models/model.pkl
# 自动恢复为v2.0版本的内容

误区与复盘：数据版本管理的常见陷阱

误区一：只对原始数据做版本管理，忽略特征工程产物。特征文件（如features.parquet）往往是模型效果差异的直接原因。如果特征工程代码有变动，但特征文件没有重新生成并注册，后续复现时会出现“代码与数据不匹配”的问题。正确做法是将特征文件也纳入DVC管理，并通过dvc.yaml建立数据→特征→模型的完整依赖链。

误区二：将DVC缓存目录放在项目目录内且未加入.gitignore。这会导致缓存文件被Git追踪，造成仓库膨胀。应在.gitignore中添加.dvc/cache，确保只有指针文件进入Git。

误区三：多人协作时直接覆盖远程数据。DVC本身不提供文件锁机制，如果两人同时dvc push相同路径的数据，可能产生冲突。建议在团队中约定：每个实验使用独立的数据路径，或通过Git分支隔离不同实验的数据版本。

误区四：忽略数据血缘的可视化。当流水线复杂后，仅靠dvc.yaml难以直观理解数据流转。应定期使用dvc dag命令查看流水线依赖图，确保每个阶段输入输出清晰。