Версионирование данных (DVC)

Версионирование данных — практика хранения истории изменений датасетов и моделей так же, как Git хранит историю кода. Оно позволяет ответить на вопросы «на каких данных обучена эта модель?», «что изменилось в выборке между версиями?» и «как воспроизвести результат полугодовой давности?». Самый известный инструмент — DVC (Data Version Control): он работает поверх Git, но большие файлы кладёт во внешнее хранилище, оставляя в репозитории только маленькие файлы-указатели с хешами.

Зачем

Git плохо подходит для гигабайтных файлов: каждая версия навсегда остаётся в истории, клонирование становится медленным, а хостинги ограничивают размер репозитория. При этом результат машинного обучения определяется тройкой код + данные + параметры, и без версии данных эксперимент невоспроизводим. Версионирование данных — одна из базовых практик MLOps.

Как работает DVC

Команда dvc add вычисляет хеш файла или каталога, перемещает содержимое в локальный кэш (.dvc/cache) и создаёт текстовый файл-указатель:^[1]

# data/train.csv.dvc
outs:
  - md5: 3863d0e317dee0a55c4e59d2ec0eef33
    size: 145276800
    path: train.csv

Указатель коммитится в Git, а сам файл добавляется в .gitignore. Команда dvc push отправляет данные в удалённое хранилище (remote) — S3, Google Cloud Storage, Azure, сервер по SSH или сетевой диск.^[3] На другой машине git clone и dvc pull восстанавливают ровно те данные, что соответствуют коммиту.

pip install "dvc[s3]"
dvc init
dvc remote add -d storage s3://ml-data/project
dvc add data/train.csv
git add data/train.csv.dvc data/.gitignore
git commit -m "train: выгрузка за октябрь"
dvc push

# вернуться к данным прошлой версии
git checkout v1.0 -- data/train.csv.dvc
dvc checkout

Так как хранилище адресуется по хешам, одинаковые файлы не дублируются, а переключение версий сводится к замене ссылок в рабочем каталоге.

Конвейеры

DVC умеет описывать этапы обработки и обучения в dvc.yaml — с зависимостями, параметрами и результатами:^[2]

stages:
  prepare:
    cmd: python src/prepare.py
    deps: [src/prepare.py, data/raw]
    outs: [data/prepared]
  train:
    cmd: python src/train.py
    deps: [src/train.py, data/prepared]
    params: [train.lr, train.epochs]
    outs: [models/model.pkl]
    metrics: [metrics.json]

dvc repro перезапускает только те этапы, у которых изменились входы, — как make, но с учётом хешей данных. Файл dvc.lock фиксирует хеши всех входов и выходов, поэтому коммит в Git полностью описывает, как получена модель.

Эксперименты

dvc exp run -S train.lr=0.01 запускает эксперимент с изменёнными параметрами, не создавая коммитов; dvc exp show выводит таблицу экспериментов с параметрами и метриками, а лучший можно превратить в ветку.^[4] Для визуального сравнения есть расширение для VS Code. Многие команды совмещают DVC (данные и конвейер) с MLflow (трекинг метрик и реестр моделей).

Альтернативы

DVC хорош для проектов, где данные — файлы (выгрузки, изображения, аудио) размером до сотен гигабайт и где важна связь данных с коммитом кода. Для таблиц в корпоративном хранилище естественнее time travel самих таблиц.

Практика

• Храните в DVC сырые выгрузки и итоговые обучающие наборы; промежуточные результаты конвейера восстановятся через dvc repro.
• Указывайте версию данных в метаданных модели (хеш из dvc.lock), чтобы связать модель в продакшене с выборкой.
• В CI/CD используйте dvc pull с ограниченными правами только на чтение.
• Персональные и чувствительные данные в удалённом хранилище должны подчиняться тем же правилам доступа и удаления, что и исходные системы.

См. также

• MLOps
• Git
• MLflow
• Feature store

Источники

1. DVC Documentation
2. DVC — Data Pipelines
3. DVC — Remote storage
4. DVC — Experiment management
5. Git LFS
6. lakeFS Documentation