Всем доброго времени суток! Меня зовут Никифоров Сергей, я ML-инженер из команды рекомендательных систем в компании ТехВилл.

Сегодня хочу рассказать вам, как мы переходили от одной системы управления данными и вычислениями к другой такой системе. А именно, сравню Data Version Control (DVC) и оркестратор Airflow.

Эта статья не претендует на полный разбор двух инструментов, её цель — показать, как переход на Airflow был устроен у нас в команде, предостеречь от ошибок.

Статья предназначена для ML-разработчиков, которые хотят выбрать для себя, какой инструмент использовать. Поэтому для начала дам базовую информацию о каждом инструменте, а затем расскажу, как переезд был устроен в нашем случае.

Ну что же, приступим!

2. Немного о DVC

DVC расшифровывается как Data Version Control, но несмотря на название, это больше чем система контроля версий для данных, это ещё и инструмент для построения ML пайплайнов.

В основе DVC лежит возможность версионировать данные, используя гит репозиторий как хранилище метаданных. При этом сами файлы можно хранить по-разному, например, использовать локальные папки, S3-хранилища. Можно переключаться между ветками Git и автоматически получать разное состояние данных.

Вторая, очень важная, возможность — это отслеживание зависимостей и умение строить последовательности расчётов. Пример описания стадий можно увидеть ниже.

stages:
  preprocess:
    cmd: python preprocess.py data/raw.csv data/processed.csv
    deps:
      - preprocess.py
      - data/raw.csv
    outs:
      - data/processed.csv
 
train:
    cmd: python train.py data/processed.csv model.pkl
    deps:
      - train.py
      - data/processed.csv
    outs:
      - model.pkl

Два важных ключевых понятия для DVC отражены в конфиге — это deps, то, от чего зависит расчёт, и outs -- выход расчёта. При запуске основной команды dvc repro вычисляется хеш всех зависимостей и если хеш зависимости не изменился, то этот этап расчёта будет пропущен.

Таким образом, DVC позволяет зафиксировать

  1. данные

  2. параметры

  3. команды

  4. модели

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

git clone
dcv pull
dvc repro

С другой стороны, для полноценного запуска ML сервиса не хватает ещё одной очень важной детали: нужен регулярный запуск расчётов и доставка расчётов до продакшен-сервисов. И с этой задачей как раз хорошо справляется Airflow, пришло время поговорить и о нём.

3. Немного об Airflow

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

Основная сущность в Apache Airflow — это Directed Acyclic Graph (DAG), представляющий собой направленный ациклический граф задач. DAG определяет порядок выполнения задач, их зависимости и расписание (частоту запусков).

Структура DAG’ов такая: они состоят из узлов (задач) и рёбер (зависимостей), указывающих направление выполнения.

Картинка взята отсюда
Картинка взята отсюда

Также для использования Airflow удобно использовать Docker-контейнеры. Docker — это тема для отдельной статьи, здесь же дадим только небольшую справку.

Если упрощённо, то Docker-контейнеры — это изолированная легковесная среда выполнения, содержащая всё необходимое для работы приложения: код, библиотеки, зависимости и настройки. Он работает поверх ядра операционной системы. Позволяет запускать небольшие задачи, не мучаясь с настройками зависимостей на машине-хосте.

4. Как мы переходили с dvc на airflow

Развернуть airflow-сервер было достаточно легко: по сути, всё сводится к поднятию docker-контейнера, внутри которого запускается три сервиса: база данных, веб-сервер Airflow и планировщик заданий (tasks).

Запуск расчётов на удалённых машинах происходил также через docker-контейнеры. При запуске дага последовательно клонируется репозиторий с кодом, из этого репозитория формируется контейнер, внутри которого производятся все расчёты.

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

Если упрощённо, то рекомендательная система состоит из трёх больших этапов. Первый — обработка данных, второй — формирование товаров‑кандидатов, которые послужат основой для рекомендаций пользователя. И третий — переранжирование кандидатов какой‑либо ранжирующей моделью, например catboost.

Вернёмся к обсуждению airflow. Все пайплайны построены по принципу зависимости друг от друга и, как правило, содержат три основных этапа: первый даг производит предобработку входных данных, затем по триггеру запускается следующий даг, внутри которого рассчитываются модели, делается инференс, получаем на выходе набор товаров-кандидатов. Третий шаг — даг ранжирования, формирующий непосредственно «полку», так у нас называются рекомендательные поверхности: ленты, виджеты, всё, где используются рекомендации.

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

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

5. Заключение: что мы получили от перехода на airflow

Приведу здесь три основных преимущества, которые мы получили при переходе на airflow.

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

Второе преимущество — нам удалось отделить данные от самих расчётов, что в DVC было проблематично.

Третье преимущество — упростилась работа, стало проще передавать пайплайны друг другу.

Спасибо, что уделили внимание статье! Добро пожаловать в комментарии: любые замечания приветствуются.