Data version control

Лев Коваленко — Senior DS Engineer

Почему это важно?

Воспроизводимость исследований.

Распространение данных в команде.

Версионирование исследований.

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

Перове и самое важное, что дает версионирование данных, это воспроизводимость исследований. Теперь кроме кода вы можете указать на каких данных было проведено то или иное исследование. Как я уже говорил в правилах воспроизводимых исследований:

«Цель воспроизводимых исследований - привязать конкретные инструкции к анализу данных и экспериментальным данным, чтобы исследование можно было воссоздать, лучше понять и проверить».

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

Во-вторых мы решаем проблему того как распространить данные в команде. Когда в команде работает несколько человек, то одновременно может проверяться несколько гипотез. В ходе их проверки могут быть созданы новые версии данных и надо как-то распространить эти данные в команде. Всегда есть доисторический способ выгрузить на флешку и таким образом дать возможность каждому члену команды их к себе скачать. Но это долго и больно, и никак не укладывается в процесс git workflow. Когда мы начинаем версионировать данные, то что бы получить новые версии данных необходимо выполнить одну команду, это сильно упрощает обмен данными.

Да конечно стоит сказать, что данные можно получить на основе кода, используя исходные данные, но тут есть некоторые ограничения, во-первых, не всегда есть возможность повторно выполнить исследование из-за недостатка ресурсов (это может быть просто долго), во-вторых, над данными могли быть проведены какие-то внешние манипуляции, не описанные в коде (да это плохо, но пока у нас нет никаких ограничений и проверок на это). Версионирование данных позволит решить эти проблемы.

Ну и последний поинт, почему это важно - вы можете начать версионировать исследования. Кроме того, чтобы версионировать входные данные необходимые для эксперимента, вы можете так же версионировать и результаты вашего эксперимента, это же тоже данные - графики, таблицы, метрики, модели. то есть после того как вы внедряете версионирвоание данных, вы можете говорить о полноценном версионировании исследований. То есть к вашему коду привязаны не только входные данные, но и результаты и таким образом вы можете отследить как те или иные исследования и преобразования данных повлияли на качество решаемой задачи.

Почему я не могу просто использовать git?

Первый и закономерный вопрос который появляется, почему я не могу просто использовать git?

Вот данные, вот код, все в одном месте и даже версии отслеживаются, можно перейти в другой комит и получить другую версию данных.

Основная причина не использовать git - размер данных, он многократно больше размеров исходного кода. Git предназначен для работы с небольшими текстовыми файлами, а типичные наборы данных, используемые в машинном обучении, слишком велики, да и сами данные далеко не всегда текстовые. Попробуйте добавить несколько больших файлов в репозиторий, а потом поменять их, git сразу начнет тормозить, так как ему понадобится больше времени для определения изменений в разных версиях этих файлов.

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

Требования к DVC

Независимость от формата данных.

Независимость от хранилища.

Self-hosted версия.

Workflow похож на git.

Нет зависимости на уровне кода.

Анализ различий.

Переиспользование в проде.

Вроде как разобрались с бенефитами контроля версий данных, теперь давайте поймем, что нам нужно от инструмента контроля версий данных, какие требования мы можем ему предъявить.

Независимость от формата данных. В проектах могут быть различные формата данных, от таблиц excel или csv, до музыки, видео и бинарных данных с датчиков. Наша система контроля версий данных, должна не зависеть от формата данных и уметь работать с любым из них.
Мы уже разобрались, что git для хранения не подходит, а данные должны где-то храниться, поэтому у инструмента контроля версий должно быть какое-то хранилище. Хотелось бы иметь возможность подключения различных хранилищ. Так как в проектах могут быть разные объемы и форматы данных, и под каждый вариант хотелось бы выбирать и разворачивать хранилище в котором такие данные оптимально хранить.
Этот момент скорее важен для работы в компании, так как хранить данные на чужих серверах мало какая компания захочет, так как это потенциальная уязвимость и потеря данных. Поэтому необходимо иметь возможность развернуть систему контроля версий и ее хранилище в контуре компании.
Workflow похож на git. Поскольку мы ведем контроль версий кода в git, то хотелось, что бы версионирование данных интегрировалось или накладывалось на существующий workflow. Это сильно упростит работу исследователя. Еще было бы хорошо иметь git-like интерфейс.
Нет зависимости на уровне кода. То есть нам не нужно использовать какие-то структуры данных, классы датасетов и моделей предлагаемые инструментом. В результате мы можем запускать и использовать наш код вне зависимости от состояния и доступности dvc. В идеале - код работает даже без установленного инструмента.
Анализ различий, хотелось, что бы инструмент версионирования данных позволял анализировать изменения в данных, Хотя бы показывать такой же diff как git. А еще лучше наглядно бы показывал, как изменились графики, таблицы метрик и так далее. По сути давал представление о том, что стало лучше, а что хуже.
Возможность переиcпользовать его в проде для поставки моделей. То есть дать возможность выгрузить нужную версию модели. Так как в любом случае перед нами стоит задача по поставке наших результатов в продакшен.

Versioning problem

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

Другая проблема в этой области связана с учетом: возможность идентифицировать прошлые входные данные и процессы, чтобы понять их результаты, для обмена знаниями или для отладки.

Появляется экспоненциальная сложность проектов по науке о данных.

Solve problem

Управление версиями данных (DVC) позволяет сохранять версии ваших данных и моделей в коммитах Git, сохраняя их локально или в облачном хранилище. Он также предоставляет механизм для переключения между этим различным содержимым данных. В результате получается единая история для данных, кода и моделей машинного обучения, которую вы можете просматривать — настоящий журнал вашей работы.

DVC обеспечивает управление версиями данных посредством кодификации. Вы создаете простые метафайлы один раз, описывая, какие наборы данных, артефакты машинного обучения и т. д. нужно отслеживать. Эти метаданные можно поместить в Git вместо больших файлов. Теперь вы можете использовать DVC для создания моментальных снимков данных, восстановления предыдущих версий, воспроизведения экспериментов, записи меняющихся показателей и многого другого.