4、DVC进阶：数据版本切换、数据共享与远程存储、DVC管道基础

好，咱们继续往下走。上一章我们把DVC的基本流程跑通了，你大概知道了怎么给数据打标签、怎么回滚。但说实话，那只是开胃菜。真正到了团队协作、多机训练的场景，你会发现事情远没那么简单。

这一章，我们来啃几块硬骨头：数据版本怎么灵活切换？怎么跟队友共享数据？远程存储怎么配？还有，DVC最核心的武器——管道（Pipeline），到底是个什么东西。

我个人习惯把这一章叫做「从单机玩具到工程化实战」的转折点。你想想看，如果只是自己玩，Git LFS其实也够用。但一旦涉及多人、多机、多环境，DVC的这些进阶功能才是真正的杀手锏。

4.1 数据版本切换：不只是checkout那么简单

上一章我们用了 dvc checkout 来切换数据版本。但实际项目中，我遇到过不少坑。比如，你切换了Git分支，但DVC的数据文件没跟着变——嗯，这其实是个经典问题。

为什么会这样？因为DVC的数据版本和Git的提交是绑定的，但数据文件本身并不在Git仓库里。你切换Git分支后，DVC的 .dvc 文件变了，但缓存里的数据没动。你需要手动执行：

# 切换到目标Git分支
git checkout experiment-v2

# 同步DVC数据到工作区
dvc checkout

# 如果你改了数据文件，想看看当前状态
dvc status

我个人建议，养成一个习惯：每次切换Git分支后，第一时间跑 dvc status。它会告诉你当前工作区的数据和缓存是否一致。如果不一致，再跑 dvc checkout。

还有一种更精细的切换方式——只恢复某个特定文件：

# 只恢复某个数据文件到缓存中的版本
dvc checkout data/raw/train.csv.dvc

这在调试时特别有用。你不需要把整个数据集都拉回来，只恢复你关心的那个文件就行。

4.2 数据共享：远程存储的配置与使用

好了，现在你本地玩得很溜了。但你想把数据分享给同事，或者放到服务器上训练，怎么办？

DVC支持多种远程存储：S3、GCS、Azure Blob、SSH，甚至本地文件系统。说白了，它就是一个「数据的中转站」。你 push 上去，队友 pull 下来。

我个人最常用的是S3和本地存储。先说说本地存储——适合小团队内网共享：

# 添加一个本地远程存储（可以是NFS挂载点）
dvc remote add -d myremote /mnt/shared/dvc-storage

# 推送数据到远程
dvc push

# 队友拉取数据
dvc pull

这里有个细节：-d 表示设置为默认远程。这样你以后 dvc push/pull 就不用每次都指定远程名字了。

如果是S3，配置稍微多一点：

# 添加S3远程存储
dvc remote add -d myremote s3://my-bucket/dvc-storage

# 配置AWS凭证（建议用IAM角色或环境变量）
# 不要硬编码密钥到配置文件里！
dvc remote modify myremote region us-east-1
dvc remote modify myremote profile my-aws-profile

配置好之后，你的工作流就变成了：

# 本地训练完，提交数据版本
dvc add data/processed/
git add data/processed.dvc
git commit -m "add processed data v3"

# 推送到远程存储
dvc push

# 队友那边
git pull
dvc pull

你看，是不是很丝滑？数据本身不经过Git，但版本信息通过Git同步。这就是DVC的设计哲学。

4.3 DVC管道（Pipelines）基础：把流程串起来

前面我们做的都是手动操作：先处理数据，再训练模型，每一步都要手动 dvc add。但实际项目中，这些步骤是有依赖关系的。比如，模型训练依赖于特征工程，特征工程依赖于原始数据。

DVC管道就是用来管理这种依赖关系的。它有点像Makefile，但专门为数据科学场景设计。

我们先看一个最简单的例子。假设你有三个步骤：

1. prepare.py：读取原始数据，生成训练集和测试集
2. featurize.py：对训练集做特征工程
3. train.py：用特征数据训练模型

用DVC管道来定义它们：

# 第一步：数据准备
dvc run -n prepare \
        -p prepare.split_ratio,prepare.seed \
        -d src/prepare.py -d data/raw/ \
        -o data/prepared/ \
        python src/prepare.py

# 第二步：特征工程
dvc run -n featurize \
        -p featurize.max_features \
        -d src/featurize.py -d data/prepared/ \
        -o data/features/ \
        python src/featurize.py

# 第三步：训练
dvc run -n train \
        -p train.lr,train.epochs \
        -d src/train.py -d data/features/ \
        -o models/model.pkl \
        -M metrics/accuracy.json \
        python src/train.py

这里解释一下参数：

• -n：给这个步骤起个名字，方便后面引用
• -p：指定参数文件（params.yaml）中的键，DVC会自动追踪这些参数的变化
• -d：依赖文件或目录，只要这些文件变了，DVC就知道需要重新运行
• -o：输出文件或目录
• -M：指标文件，DVC会解析里面的数值，方便对比不同实验

运行完之后，DVC会生成一个 dvc.yaml 文件，里面记录了整个管道的依赖关系。你可以用 dvc dag 来可视化这个管道：

dvc dag

输出大概长这样：

+--------+       +-----------+       +-------+
| prepare | ====> | featurize | ====> | train |
+--------+       +-----------+       +-------+

现在，如果你修改了 params.yaml 里的 train.lr，DVC会自动检测到变化，然后只重新运行 train 这一步，而不会重新跑 prepare 和 featurize。这就是增量执行的威力。

我曾经在一个项目中，管道有十几个步骤，每次调参都要跑半小时。用了DVC管道之后，大部分时候只需要重跑最后两步，几分钟就搞定了。嗯，那种感觉，真的很爽。

4.4 实战：一个完整的管道示例

我们来写一个完整的 dvc.yaml，把上面三个步骤串起来。假设你的项目结构是这样的：

.
├── data/
│   ├── raw/          # 原始数据（由dvc管理）
│   ├── prepared/     # 准备后的数据（管道输出）
│   └── features/     # 特征数据（管道输出）
├── src/
│   ├── prepare.py
│   ├── featurize.py
│   └── train.py
├── models/
│   └── model.pkl     # 训练好的模型（管道输出）
├── metrics/
│   └── accuracy.json # 评估指标（管道输出）
├── params.yaml       # 参数文件
└── dvc.yaml          # 管道定义

params.yaml 内容示例：

prepare:
  split_ratio: 0.8
  seed: 42

featurize:
  max_features: 5000

train:
  lr: 0.001
  epochs: 10

然后运行 dvc repro，DVC就会按照依赖关系自动执行整个管道：

# 执行整个管道
dvc repro

# 只重跑某个步骤及其下游
dvc repro train

你想想看，如果每次改参数都要手动跑三个脚本，还要自己记着哪个版本对应哪个参数，那得多痛苦。DVC管道把这些都自动化了，而且每个步骤的输入输出都有版本记录。

4.5 本章小结

这一章我们覆盖了三个核心进阶功能：

• 数据版本切换：记住 git checkout 后要跟 dvc checkout，小心未提交的修改被覆盖
• 远程存储：S3、GCS、本地都支持，配置好之后 dvc push/pull 就能团队共享
• DVC管道：用 dvc run 定义步骤，用 dvc repro 自动执行，增量计算省时省力

说实话，这些功能单独看都不复杂。但把它们组合起来，就能构建出一个非常健壮的实验管理流程。下一章我们会深入管道的更多细节，比如如何嵌套管道、如何与CI/CD集成。但先把今天这些基础打牢，你就能应付大部分实际场景了。

---

公众号:蓝海资料掘金营，微信deep3321