DVC vs GIT. Почему GIT'а недостаточно в проектах машинного обучения

[AigizK]

Сами пользуетесь? Можете поделиться опытом?
Просто не понятно, если pipeline начинается допустим с чтения данных из базы, тогда что, надо добавить отдельный шаг, который все это сохраняет в файлы и дальше версионировать эти файлы?

[Yoskutik]

DVC отслеживает то, когда последний раз были изменены файлы. Нужно вручную прописывать какой скрипт зависит от какого скрипта и от какого набора данных. И в если в момент сборки один из файлов был изменён, DVC пересоберет только необходимые файлы.

Так что да, если хотите использовать базу данных, нужно добавить шаг с сохранением.

[old_bear]

Немного портит статью то, что изображение (которое, как я понимаю, хостится где-то на DVC) выдаёт

Not Found
You just hit a route that doesn't exist… the sadness.

[Yoskutik]

Да, согласен. Того изображения больше нет, но я вставил подходящее по смыслу

[Kopilov]

Работа с DVC + Git выглядит примерно так:
https://dvc.org/static/img/model-versioning-diagram.png

Кажется, у иллюстрации reproducibility crisis.

P.s. Комментарий выше, когда я писал свой, не был виден, хотя было написано, что комментариев 2 (был виден только один, первый). Уже несколько дней с комментариями на Хабре какие-то глюки

[molec]

Для многих баз данных есть крутая встроенная похожая штука — temporal tables, они же таблицы с системной версионностью. Работал с ними на MS SQL Server — муторно, но оно того стоит. Можно реально изолировать состояние данных на более менее любую дату. Но весь код обновления и использования данных становится объемным и надо с умом проектировать хранилище, чтобы при каждой заливке свежей порции данных не обновлялась вся таблица. Но действительно появляется возможность прогнать свежий код на старых данных "как тогда" и посмотреть, насколько лучше новая модель.

[somurzakov]

делаю ручками что-то похожее в data warehouse.
каждая таблица имеет кластерный индекс типа date на день когда данные были залиты (Report date), и можно сгенерить отчеты на самую последнюю дату, либо же сделать time-travel на предыдущий месяц.

[molec]

Тоже с этого начинали. Системное версионирование, если его разложить на физический уровень, это 2 таблицы. Одна — текущий срез данных, актуальный прямо сейчас. Другая — своеобразная лог таблица, из которой никогда ничего не удаляется, зато в ней присутствует 2 поля — данные валидны С и ПО. Вместо удаления строки просто обновляется ПО на текущее время. В принципе, ничего не мешает повторить эту структуру на неподдерживающем версионирование движке вручную. Единственное — море оберток, триггеров, доп индексов, процедур обновления данных. Для каждой таблицы, если их десятки и сотни, это тяжело поддерживать. Но для некоей итоговой таблицы датасета вполне.

[amarao]

Чем оно лучше условного nexus'а, который хранит рандомные блобы без особых раздумий об их сути? В целом, можно представить себе даже условный ceph/swift, которые ровно так же хранят блобы, а в git'е на них ссылки.

Т.е. то, что эта штука приносит полиси, это понятно. А что она хорошего даёт в замен?