Хабрахабр

Data Version Control (DVC): версионирование данных и воспроизводимость экспериментов

Эта статья — своеобразный мастер-класс «DVC для автоматизации ML экспериментов и версионирования данных», который прошел 18 июня на митапе ML REPA (Machine Learning REPA:
Reproducibility, Experiments and Pipelines Automation) на площадке нашего банка.

Тут я расскажу об особенностях внутренней работы DVC и способах применения его в проектах.

Код тестировался на MacOS и Linux (Ubuntu). Примеры кода, используемые в статье доступны здесь.

Содержание

Часть 1
Часть 2

Настройка DVC

Data Version Control — это инструмент, который создан для управления версиями моделей и данных в ML-проектах. Он полезен как на этапе экспериментов, так и для развертывания ваших моделей в эксплуатацию.

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

Для этого будет использовать известный датасет Iris Data Set . Давайте рассмотрим работу DVC на примере задачи классификации цветов ириса. Остальные примеры работы с DVC показаны Jupyter Notebook.

Что нужно сделать:

Итак, клонируем репозиторий, создаем виртуальное окружение и устанавливаем нужные пакеты. Инструкции по установке и запуску есть в README репозитория.

Clone this repository 1.

git clone https://gitlab.com/7labs.ru/tutorials-dvc/dvc-1-get-started.git
cd dvc-1-get-started

2. Create and activate virtual environment

pip install virtualenv
virtualenv venv
source venv/bin/activate

3. Install python libraries (including dvc)

pip install -r requirements.txt

Для установки DVC воспользуемся командой pip install dvc. После установки необходимо инициализировать DVC в папке проекта dvc init, которая сгенерирует набор папок для дальнейшей работы DVC.

checkout new branch in demo repository (to not wipe content of master branch) 4.

git checkout -b dvc-tutorial

5. Initialize DVC

dvc init
commit dvc init
git commit -m "Initialize DVC"

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

В вашем репозитории появится папка .dvc, в которой будут лежать cache и config.

Содержимое .dvc будет выглядеть так:

./ ../ .gitignore cache/ config

Config — это конфигурация DVC, а cache — это системная папка, в которую DVC будет складывать все данные и модели, которые вы будете версионировать.

Когда вы передаете DVC какой-либо файл для версионирования в Git, будут сохраняться версии и метаданные, а сам файл будет храниться в cache. Также DVC создаст файл .gitignore, в который будет записывать те файлы и папки, которые не нужно коммитить в репозиторий.

И загрузить датасет Iris.
Теперь нужно установить все зависимости, а потом сделать checkout в новую ветку dvc-tutorial, в которой мы будем работать.

Get data

wget -P data/ https://raw.githubusercontent.com/uiuc-cse/data-fa14/gh-pages/data/iris.csv

Возможности DVC

Версионирование моделей и данных

Источник тут.

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

DVC создаст метафайл iris.csv с расширением .dvc, а информацию о нём запишет в папку cache. Введём команду dvc add и укажем путь к файлу, который нам нужно версионировать. Закоммитим эти изменения, чтобы в Git-истории появилась информация о начале версионирования.

dvc add data/iris.csv

Внутри сгенерированного dvc-файла хранится его хэш со стандартными параметрами.

Система берет данные, кладет в cache и создаёт в рабочей директории ссылку на это кэш. Output — путь к файлу в папке dvc, который мы добавили под контроль DVC. Управление самими данными берет на себя DVC. Этот файл можно добавить в Git-историю и таким образом версионировать его. Первые два символа хэша используются в качестве папки внутри cache, а остальные символы используются в качестве названия создаваемого файла.

Автоматизация ML пайплайнов

Вот стандартный пайплайн обучения и оценки классификатора: Помимо контроля версий данных мы можем создавать пайплайны (pipeline) — цепочки вычислений, между которыми задаются зависимости.

Этот пайплайн можно разбить на отдельные кусочки. На входе у нас есть данные, которые нужно предварительно обработать, разделить на train и test, рассчитать признаки и уже потом обучить модель и оценить её. д., и соединить эти цепочки между собой. Например, выделить этап загрузки и предобработки данных, разбиение данных, оценку и т.

Для этого в DVC есть замечательная команда dvc run, в которой мы передаем определённые параметры и указываем Python-модуль, который нам нужно запустить.

Сначала посмотрим содержимое модуля featureization.py: Теперь — к примеру запуска этапа расчёта признаков.

import pandas as pd def get_features(dataset): features = dataset.copy() # uncomment for step 5.2 Add features # features['sepal_length_to_sepal_width'] = features['sepal_length'] / features['sepal_width'] # features['petal_length_to_petal_width'] = features['petal_length'] / features['petal_width'] return features if __name__ == '__main__': dataset = pd.read_csv('data/iris.csv') features = get_features(dataset) features.to_csv('data/iris_featurized.csv', index=False)

Этот код берёт датасет, рассчитывает признаки и сохраняет их в iris_featurized.csv. Расчёт дополнительных признаков мы оставили на следующий этап.

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

Через аргумент -d укажем необходимые зависимости: модуль featureization.py и файл с данными iris.csv. Сначала в команде dvc run укажем название метафайла stage_feature_extraction.dvc, в который DVC запишет необходимые метаданные о этапе вычислений. Также укажем файл iris_featurized.csv, в который сохраняются признаки, и саму команду запуска python src/featurization.py.

dvc run -f stage_feature_extraction.dvc \ -d src/featurization.py \ -d data/iris.csv \ -o data/iris_featurized.csv \ python src/featurization.py

DVC создаст метафайл и будет отслеживать изменения в питоновском модуле и файле iris.csv.
Если в них произойдут изменения, то DVC перезапустит этот этап расчёта в пайплайне.

Получившийся файл stage_feature_extraction.dvc будет содержать свой хэш, команду запуска, зависимости и выходные данные (для них есть дополнительные параметры, которые можно посмотреть в метаданных).

Таким образом, мы можем создать новую ветку и запушить её в Git-репозиторий. Теперь необходимо сохранить этот файл в историю Git коммитов. Можно коммитить в Git-историю либо создание каждого этапа в отдельности, либо всех этапов сразу.

Хэши выходных данных одного этапа идут на входы другого. Когда мы выстраиваем такую цепочку для всего нашего эксперимента, DVC выстраивает граф вычислений (DAG), по которым может запускать либо пересчёт всего пайплайна, либо какой-то части. Если вы поменяли код где-то в split_dataset.py, то DVC не будет загружать данные и, возможно, пересчитывать признаки, а перезапустит этот этап и следующие за ним этапы обучения и оценки. По ним DVC отслеживает зависимости и выстраивает граф вычислений.

Отслеживание метрик

А если передадим параметр -a, то DVC покажет все метрики, которые есть в Git-истории. С помощью команды dvc metrics show можно вывести метрики текущего запуска, той ветки, в которой мы находимся. В этот файл модуль evaluate.py записывает метрики, в данном случае f1 и confusion metrics. Чтобы DVC начал отслеживать метрики, мы при создании этапа evaluate передаем параметр -m через data/eval.txt. То есть команда dvc metrics show выведет в консоль содержимое файла eval.txt. В папке output в dvc-файле этого этапа для cache и metrics заданы значения true. Также с помощью аргументов этой команды можно показать только f1_score или только confusion_matrix.

В этом примере у нас получились вот такие результаты:

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

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

Система отслеживает историю данных и модель, может перезапускать себя целиком или по частям, может показывать метрики. Теперь у нас есть пайплайн, созданный с помощью DVC. Мы выполнили всю необходимую автоматизацию.

Мы хотим её улучшать, меняя какие-то параметры. У нас была модель с f1 = 0,78. Кроме того, если вы работаете в команде, вы можете захотеть передать модель и код коллегам, чтобы они могли продолжить работу над ними. Для этого нужно перезапустить весь пайплайн, в идеале, какой-то одной командой.

Команда dvc repro позволяет перезапускать пайплайны или отдельные этапы (в этом случае нужно после команды указать воспроизводимый этап).

Но если мы это сделаем в текущем состоянии, то DVC не увидит никаких изменений и перезапускать не станет. Выполнив команду dvc repro stage_evaluate, этап попробует перезапустить весь пайплайн. А если мы что-то изменим, он сам найдёт изменение и перезапустит пайплайн с этого момента.

$ dvc repro stage_evaluate.dvc Stage 'data/iris.csv.dvc' didn't change.
Stage 'stage_feature_extraction.dvc' didn't change.
Stage 'stage_split_dataset.dvc' didn't change.
Stage 'stage_train.dvc' didn't change.
Stage 'stage_evaluate.dvc' didn't change.
Pipeline is up to date. Nothing to reproduce.

В данном случае DVC не увидел изменений в зависимостях этапа stage_evaluate и отказался перезапускать. А если мы укажем параметр -f, тогда он перезапустит все предварительные этапы и покажет предупреждение о том, что удаляет предыдущие версии данных, которые от отслеживал. Каждый раз, когда DVC перезапускает этап, он удаляет предыдущий кэш, фактически перезаписывает его, чтобы не дублировать данные. В момент запуска файла DVC проверят его хэш, и если он изменился, пайплайн перезапускается и затирает все output, которые у этого пайплайна есть. Если вы хотите этого избежать, то нужно предварительно запушить конкретную версию данных в какой-то удалённый репозиторий.

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

DVC увидит эти изменения и перезапустит весь пайплайн. Например, можно изменить признаки (‘раскомментить’ строки расчёта признаков в featurization.py).

Сохранение данных в удаленном репозитории

Если выполнить команду dvc push, то DVC отправит текущую версию модели и данных в предварительно настроенное удаленное хранилище репозиторий. DVC может работать не только с локальными хранением версий. Главное, чтобы у всех был доступ к этому репозиторию. Если потом ваш коллега сделает git clone вашего репозитория и выполнит dvc pull, он получит ту версию данных и моделей, которая предназначена для этой ветки.

Примерно таким же образом создается удалённое хранилище и в облаке. В данном случае мы имитируем «удалённое» хранилище в папке temp/dvc. Теперь мы можем выполнить dvc push для отправки данных в это хранилище, а ваш коллега, чтобы получить их, просто выполняет dvc pull. Коммитим это изменение, чтобы оно осталось в Git-истории.

Итак, мы рассмотрели три ситуации, в которых полезен DVC и основной функционал:

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

Часть 2

Как внедрить DVC в ваших проектах?

Для обеспечения воспроизводимости проекта необходимо соблюдать определённые требования.
Вот основные из них:

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

Если всё это сделано, то проект с большей вероятностью будет воспроизводимым. DVC позволяет выполнить 3 первых требования в этом списке.

У нас есть Jupyter Notebook». Пытаясь внедрить в своей компании DVC, вы можете столкнуться с нежеланием: «Зачем нам это надо? В таком случае можно пойти путем пошагового внедрения. Возможно, некоторые ваши коллеги работают только с Jupyter Notebook, и им гораздо сложнее писать такие пайплайны и код в IDE.

  1. Проще всего начать с версионирования кода и моделей.
    И затем перейти к автоматизации пайплайнов.
  2. Сначала автоматизировать этапы, которые часто перезапускают и изменяются,
    а затем весь пайплайн.

Если у вас есть новый проект и пара энтузиастов в команде, то лучше сразу использовать DVC. Так, например, получилось у нас в команде! При запуске нового проекта меня поддержали мои коллеги, и мы самостоятельно начали использовать DVC. Потом стали делиться с другими коллегами и командами. Кто-то подхватил наше начинание. Сегодня DVC пока не является общепринятым инструментом в нашем банке, однако он используется в нескольких проектах.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть