4、DVC数据版本控制：DVC安装与初始化、DVC管理数据集和模型文件、DVC与Git协同工作流

做边缘AI的兄弟们，你们有没有遇到过这种情况？

模型迭代了50个版本，数据集换了3次，结果想回退到两周前的那个效果最好的模型，却发现——找不到了。Git里只存了代码，几百兆的模型文件和几个G的数据集，根本推不上去。

嗯，这就是我们今天要解决的问题。DVC（Data Version Control），说白了就是给数据和模型也装上版本管理。我自己的项目里，自从用了DVC，再也没出现过「那个模型去哪了」的尴尬场面。

4.1 DVC安装与初始化

安装DVC其实很简单。我个人习惯用pip，干净利落：

pip install dvc

如果你在边缘设备上跑，比如树莓派或者Jetson系列，建议用conda：

conda install -c conda-forge dvc

安装完之后，验证一下：

dvc --version

看到版本号，就说明装好了。

接下来是初始化。注意，DVC是跟Git项目绑定的。你得先有一个Git仓库：

git init my_edge_ai_project
cd my_edge_ai_project
dvc init

执行dvc init之后，你会发现项目里多了个.dvc目录。这里面存的是DVC的配置信息。我刚开始用的时候，差点把这个目录删了——千万别手抖。

注意： dvc init之后，记得把.dvc目录提交到Git里。不然别人拉下来项目，DVC根本不知道该怎么工作。 
git add .dvc .gitignore
git commit -m "初始化DVC"

4.2 DVC管理数据集和模型文件

好了，现在项目初始化完了。怎么把数据集和模型交给DVC管呢？

假设你有一个数据集目录叫datasets/，里面是训练图片。还有一个模型文件models/gesture_model.onnx。直接这样操作：

dvc add datasets/
dvc add models/gesture_model.onnx

执行完之后，你会发现：

  • datasets/目录下多了个datasets.dvc文件
  • models/目录下多了个gesture_model.onnx.dvc文件
  • 原始文件被加入了.gitignore

为什么会这样？DVC的逻辑其实很巧妙。它不把大文件直接塞进Git，而是生成一个轻量级的.dvc文件，里面记录的是文件的哈希值和元信息。真正的数据文件，被存到了DVC的缓存里。

你想想看，这样一来，Git仓库里只有几KB的文本文件，而几百MB的模型文件在缓存里。推代码、拉代码，速度飞快。

核心概念： DVC把数据和模型的管理，抽象成了「指针文件」（.dvc文件）和「缓存存储」两层。指针文件进Git，缓存数据进远程存储。

接下来，把指针文件提交到Git：

git add datasets.dvc models/gesture_model.onnx.dvc
git commit -m "添加手势识别数据集和模型"

那真正的数据存在哪？默认在.dvc/cache目录下。但你不能把这个目录推到Git里，太大了。我们需要一个远程存储。

配置远程存储，我一般用S3或者本地文件系统。举个例子，配置一个本地远程存储：

dvc remote add -d myremote /mnt/shared_storage/dvc_cache

然后推送数据：

dvc push

这样，数据集和模型就安全地存到了远程。团队成员拉下来项目后，执行dvc pull就能拿到一模一样的数据。

我的经验： 在边缘AI项目里，我经常把远程存储配置到NAS或者对象存储上。这样不同设备之间共享数据特别方便。有一次在Jetson上训练，数据存在NAS里，DVC pull一下，几分钟就准备好了。

4.3 DVC与Git协同工作流

这才是重头戏。DVC和Git怎么配合？说白了，就是「Git管代码，DVC管数据」。

一个典型的迭代流程是这样的：

  1. 开发新版本模型
# 切换到新分支
git checkout -b experiment/v2

# 修改代码，训练新模型
python train.py

# 新模型生成在 models/v2_model.onnx
dvc add models/v2_model.onnx

# 提交代码和DVC指针
git add models/v2_model.onnx.dvc
git commit -m "实验：v2模型，使用数据增强"

# 推送数据和代码
dvc push
git push origin experiment/v2
  1. 回退到旧版本

假设你发现v2模型效果反而变差了，想回到v1。怎么做？

# 回到v1的提交
git checkout <v1的commit_hash>

# 恢复数据
dvc checkout

# 搞定！现在代码和数据都回到了v1的状态

嗯，这里要注意。dvc checkout会根据.dvc文件里的哈希值，从缓存里把对应的数据文件恢复出来。整个过程不需要重新下载，只要缓存还在，就是秒级恢复。

  1. 多人协作

团队里有人更新了数据集，你怎么办？

# 拉取最新的代码
git pull

# 拉取最新的数据
dvc pull

就这么简单。DVC会自动对比.dvc文件的哈希值，只下载有变化的数据。

工作流总结：

操作 Git命令 DVC命令
初始化 git init dvc init
添加文件 git add dvc add
提交 git commit （自动生成.dvc文件）
推送 git push dvc push
拉取 git pull dvc pull
切换版本 git checkout dvc checkout

我曾经在一个项目里踩过坑：团队成员只执行了git pull，忘了dvc pull，结果跑训练脚本的时候，用的还是旧数据。训练了一天，发现模型没提升，白费功夫。从那以后，我在项目的README里加了一行大字：

「拉完代码，记得 dvc pull！」

避坑指南： 如果你修改了数据集或模型，但没有执行dvc add，直接git commit了。那别人拉下来项目，数据还是旧的。记住：数据变了，一定要重新dvc add并提交.dvc文件。

4.4 实战小技巧

最后分享几个我在边缘AI项目里常用的技巧：

  • 使用.dvcignore：跟.gitignore类似，可以排除不需要版本控制的文件。比如缓存目录、临时文件。
  • 分阶段管理：数据集、预处理后的数据、训练好的模型，分别用不同的.dvc文件管理。这样更新其中一个，不会影响其他的。
  • 结合流水线：DVC还支持定义流水线（dvc pipeline），可以自动追踪数据、代码、模型之间的依赖关系。这个我们后面章节会详细讲。

好了，DVC的核心用法就这些。你想想看，有了这套流程，边缘AI项目的版本管理是不是清晰多了？下一章，我们会讲怎么用DVC的流水线功能，把训练、评估、部署整个流程串起来。

小提示： 刚开始用DVC的时候，建议先在一个小项目上练手。我当初就是拿一个MNIST分类器试水，跑通了整个流程，才敢用到正式项目里。别一上来就搞几十G的数据集，容易手忙脚乱。
← 上一章 📖 返回目录 下一章 →