数据版本管理

为什么需要数据版本管理

在传统软件开发中，Git 已经是代码版本管理的标准工具。但在 ML/AI 项目中，数据同样是核心资产，却往往缺乏系统化的版本管理。

ML 实验的可复现性：模型的表现由代码、超参数和训练数据共同决定。无法回溯数据版本就无法复现实验结果。数据版本管理确保每次实验都能与特定的数据快照绑定。
数据集迭代：真实项目中的数据集会不断演变——新增标注、修正标签、扩充样本。没有版本管理，很难追踪数据集在不同时间点的状态。
团队协作：多人协作时需要使用一致的数据集。手动拷贝数据容易导致版本混乱，版本管理工具可以保证所有人拉取到相同版本的数据。

DVC (Data Version Control)

DVC 是目前最流行的开源数据版本管理工具，由 Iterative.ai 开发，专为 ML 项目设计。

核心思想

DVC 的设计哲学：用 Git 管理轻量的元数据文件（.dvc 文件），将实际的大文件存储在远程存储中。这样既能利用 Git 的版本控制能力，又不会让仓库因大文件而臃肿。工作流程：

用 dvc add 追踪大文件，DVC 生成对应的 .dvc 元数据文件
将 .dvc 文件提交到 Git
用 dvc push 将实际数据上传到远程存储
其他人通过 git pull + dvc pull 获取代码和数据

基本命令

# 在 Git 仓库中初始化 DVC
dvc init

# 追踪数据文件或目录
dvc add data/training_set.csv
dvc add data/images/

# 将生成的 .dvc 文件和 .gitignore 提交到 Git
git add data/training_set.csv.dvc data/images.dvc .gitignore
git commit -m "Add training data v1"

# 配置远程存储
dvc remote add -d myremote s3://my-bucket/dvc-storage

# 推送数据到远程存储 / 从远程拉取数据
dvc push
dvc pull

# 切换到某个历史版本的数据
git checkout v1.0
dvc checkout

.dvc 文件结构

.dvc 文件是 YAML 格式的元数据文件，通过 MD5 hash 唯一标识数据版本：

outs:
- md5: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6
  size: 1073741824
  hash: md5
  path: training_set.csv

当数据变化时 hash 值随之改变，.dvc 文件更新后提交到 Git，就建立了代码版本与数据版本的映射。

Remote Storage

DVC 支持多种远程存储后端，通过 dvc remote add 配置：

Amazon S3：dvc remote add -d myremote s3://bucket/path
Google Cloud Storage：dvc remote add -d myremote gs://bucket/path
Azure Blob Storage：dvc remote add -d myremote azure://container/path
SSH / 本地文件系统：dvc remote add -d myremote ssh://user@host/path

DVC Pipeline

DVC 还能通过 dvc.yaml 定义数据处理流水线：

stages:
  preprocess:
    cmd: python src/preprocess.py
    deps:
      - src/preprocess.py
      - data/raw/
    outs:
      - data/processed/
  train:
    cmd: python src/train.py --lr 0.001
    deps:
      - src/train.py
      - data/processed/
    outs:
      - models/model.pkl
    metrics:
      - metrics.json:
          cache: false

核心优势：DVC 根据依赖关系自动判断输入变化，只重新执行必要的步骤（dvc repro），避免重复计算。可通过 dvc dag 查看 Pipeline 的 DAG 结构。

DVC Experiments

DVC 提供实验追踪功能，记录和对比不同超参数下的实验结果：

dvc exp run --set-param train.lr=0.01   # 运行实验并修改参数
dvc exp show                             # 查看所有实验结果
dvc exp diff exp-abc123 exp-def456       # 对比两次实验

其他数据版本管理工具

Git LFS (Large File Storage)

Git LFS 是 Git 官方扩展，用指针文件替代实际大文件，紧密集成在 Git 工作流中。

git lfs install
git lfs track "*.h5"
git add .gitattributes model.h5
git commit -m "Add model file"

适用于几百 MB 以内的文件，团队已使用 GitHub/GitLab 且不想引入额外工具。局限性：对超大规模数据集支持不够理想，存储费用较高。

Delta Lake

Databricks 开源的存储层，为数据湖提供 ACID 事务支持，基于 Parquet 格式，通过 Transaction Log 实现版本管理。核心特性：ACID 事务、Time Travel（版本号或时间戳查询历史数据）、Schema Evolution。适用于 Spark 生态下 TB 级以上的结构化数据。

LakeFS

提供类似 Git 的操作语义（branch、commit、merge）管理数据湖中的数据，兼容 S3 API，可与现有数据基础设施无缝集成。适合需要在生产环境中安全测试数据变更的团队。

Hugging Face Datasets

Hugging Face Hub 面向 ML 社区的数据集托管和版本管理服务，基于 Git LFS，提供友好的 API。

from datasets import load_dataset
dataset = load_dataset("squad", revision="v2.0")  # 加载指定版本

数据管理最佳实践

数据与代码分离

大文件不应直接存放在 Git 仓库中。推荐的项目结构：

project/
  src/           # 代码 -> Git
  configs/       # 配置 -> Git
  data/          # 数据 -> DVC / 远程存储
  models/        # 模型 -> DVC / 远程存储
  dvc.yaml       # Pipeline 定义 -> Git
  dvc.lock       # Pipeline 锁文件 -> Git

不要把大文件提交到 Git

一旦大文件被提交到 Git 历史中，即使后续删除，仓库体积也不会缩小（Git 保留完整历史）。应在 .gitignore 中排除数据目录，使用 DVC 或 Git LFS 管理。

数据集文档化 (Datasheets for Datasets)

每个数据集都应有清晰的文档，记录：来源与采集方式、规模与分布、标注规范、已知偏差（bias）、许可协议。源自 Gebru 等人提出的 "Datasheets for Datasets" 框架。

数据血缘追踪 (Data Lineage)

Data Lineage 记录数据从原始来源到最终使用的完整变换路径：这份数据是怎么来的？经过了哪些处理？ DVC Pipeline 天然提供一定程度的 Data Lineage 能力，更复杂场景可借助 Apache Atlas、Amundsen 等工具。

MLOps 中的数据管理：Feature Store

Feature Store 是 MLOps 中重要的基础设施组件，集中化的特征管理平台，核心问题：如何在团队中高效地共享和复用特征。核心功能：

特征注册与发现：搜索和复用已有的特征定义
在线/离线一致性：保证训练（offline）和推理（online）使用相同的特征计算逻辑
特征版本管理：追踪特征定义和特征值的变化历史
Point-in-time Correctness：避免 data leakage，确保训练时只用该时间点之前的特征值

常见实现：Feast（开源轻量）、Tecton（商业全托管）、Hopsworks（Spark/Flink 集成）、Databricks Feature Store。Feature Store 与数据版本管理互补：DVC 管理原始数据和数据集版本，Feature Store 管理特征生命周期。