С Git всё просто: изменили код → сделали commit → при необходимости вернулись к предыдущей версии

Но что делать с данными?

Датасеты тоже меняются: появляются новые записи, исправляются ошибки, меняется логика подготовки. И тогда возникает вопрос

на каких именно данных был получен этот результат?

Здесь и появляется версионирование данных. Один из инструментов для этого — DVC (Data Version Control)

Для Data Analyst

Аналитику версионирование особенно полезно, когда данные участвуют в регулярных расчётах, исследованиях или командной работе

Например:

данные v1 → SQL → витрина → дашборд

Потом источник изменился:

данные v2 → тот же SQL → другой результат

Без истории изменений может быть сложно понять, почему показатель вдруг стал другим

Поэтому для аналитика версионирование помогает:

- фиксировать состояние данных - воспроизводить расчёты - понимать, на каких данных получен конкретный результат - синхронизировать работу команды - отделять изменения данных от изменений SQL и логики расчётов

Но здесь DVC — скорее дополнительный инструмент. Во многих аналитических задачах важнее хорошо организованные таблицы, документация, Git для SQL и понятный data pipeline

Для Data Scientist

У Data Scientist ситуация интереснее

Здесь результат напрямую зависит от комбинации:

код + данные + параметры → модель → метрики

Допустим, сегодня модель показывает F1 = 0.82, а через месяц — 0.76

Что изменилось? код? датасет? preprocessing? признаки? параметры обучения?

Если версии данных не зафиксированы, разобраться становится гораздо сложнее

DVC как раз позволяет связывать версии данных и моделей с Git-репозиторием, хранить большие файлы отдельно и воспроизводить эксперименты. Его можно использовать и для построения воспроизводимых пайплайнов

🙊 Для аналитика версионирование данных — прежде всего про надёжность и воспроизводимость аналитики, а для Data Scientist — ещё и про воспроизводимость экспериментов и моделей