Первая часть — здесь.

Data lineage

Этот подход обеспечивает прослеживание связей в данных и клиентов, которые используют данные, от источника, включая промежуточные стадии, до момента потребления этих данных. Данные может потреблять сервисы, какие-то BI-системы, на которых построены дашборды, эксплуатировать данные могут люди, дата аналитики, которым это необходимо в рабочих процессах. Data lineage позволяет прозрачно взглянуть на эти вещи и отследить момент получения предагрегатов до момента эксплуатации этих данных клиентами.

Нам важен разрез, когда клиентами или целевыми заказчиками данных являются ML-модели.

Справа на схеме вы видите модельки, а слева - витрины данных, на которых эти модели построены, и зависимости между ними. В идеале прослеживать весь цикл, то есть от источника до витрины, но на этом слайде мы ограничились только одним уровнем зависимостей. Мы нашли решение этой задачи в таком решении как Open Meta Data - это data catalog инструмент.

Пришли мы к этому в 2021 году, тогда мы стояли перед выбором внедрения data catalog инструмент.

Картина была примерно следующая — был ряд инструментов. Какие-то нас удовлетворяли больше, какие-то в меньшей степени. OMD подходил нам по тем критичным параметрам, которые мы перед собой ставили. Однако был небольшой нюанс: в тот момент OMD был только зарелизен. Первая версия Open Meta Data выкатилась во втором квартале 2021 года. Это был серьезный фактор, но ребята из OMD были крайне убедительными, и мы пошли по пути внедрения Open Meta Data.

Что из себя представляет Open Meta Data? Как и все data catalog инструменты, это инструмент по аккумуляции метаданных, информации о тех данных, которые эксплуатируются в компании. При этом Open Meta Data может собирать информацию о различных базах данных, о схемах и витринах, которые в них расположены.

OMD может собирать информацию о дашбордах из различных BI-систем, таких как PowerBI, Superset, Qlik Sense и других. Кроме того, OMD позволяет внедрять элементы Data Governance, например, можно чекать data quality с помощью OMD и отрисовывать ETL-пайплайны. Под капотом пять основных компонентов: UI, API, которая позволяет делать все то, что есть в UI и даже больше, Elasticsearch, Postgres и Airflow для того, чтобы регулярно загружать метаинформацию.

Основными источниками данных в OMD являются Hive-витрины (основная хранилка витрин в билайне), реляционные базы данных такие как Postgres или MySQL, дашборды, мы используем в основном BI-инструмент Qlik Sense, некоторые команды используют Superset. В DS-задачах мы используем MLflow для трекинга экспериментов и для хранения моделей, а информация из instance MLflow попадает в Open Meta Data.

Давайте на примере MLflow поговорим о том, как происходит подключение новых источников в Open Meta Data. Это можно сделать несколькими способами. Первый из них — подключить новый источник через UI. В этом случае необходимо завести подключение Ingestion и в рамках него выбрать один из нужных коннекторов, сейчас в OMD более тридцати коннекторов по различным хранилищам данных и около пяти различных BI-систем.

Выбираем, вводим параметры, ставим на расписании как нам часто необходимо производить загрузку метаданных, и все полетело. То же самое можно сделать с помощью командной строки и с помощью API. Под капотом происходит формирование DAG в AirFlow, который выполняет эту загрузку.

Вот пример того, как все выглядит. В нашей дирекции несколько продуктовых команд. Мы можем в одном окне видеть instance’ы MLflow, которые данные команды эксплуатируют.

Важной фичей в OMD является lineage, для нас это была киллер-фича. Lineage можно отрисовывать с помощью UI. Очевидно, что этот способ немасштабируем, то есть команды могут так делать, но внедрять это в 200+ продуктовых команд было бы сложно, поэтому в OMD есть другие подходы.

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

Действительно, OMD, анализируя запросы к базам, строит lineage, но есть ограниченное количество хранилищ, в которые OMD может так делать. Это несколько хранилищ - есть ClickHouse и Postgres, но нет, например, Hive, который нам очень важен. Lineage можно отрисовывать с помощью API, так мы это и делаем. Важно отметить, что с помощью API можно отрисовывать его на уровне столбцов, в то время, как на UI можно отрисовывать только на уровне витрин.

Нам было очень важно встроить lineage в процесс появления связей в OMD между моделями и фичами безболезненно для Data Scientist’ов, то есть это не их задача, но было бы здорово, чтобы они ее делали. Нам это удалось сделать с ремаркой почти. Напомним workflow работы Data Scientist. Они работают в JupyterHub, они анализируют Hive-таблицы, которые построены, как правило, на Spark. Код хранят в унифицированном GitLab-репозитории, у нас есть некоторый шаблон, который Data Scientist при разработке новой модели себе копирует, ведет в нем разработку и складывает артефакты в определенные директории этого репозитория. Информация об экспериментах попадает в MLflow, эксперименты трекаются, там хранятся модельки.

Если необходим деплой модели в продуктивный кластер, то это делается либо с помощью Argo, как я рассказывал выше в сценарии вычисления на кластере, либо, если необходим интерфейс доступа к модели, это делается с помощью Seldon Core.

Теперь давайте посмотрим, что же от всего этого безобразия попадает в Open Meta Data.

Туда попадает информация о таблицах Hive и попадает метаинформация из MLflow, оттуда попадает лишь название модели, ее тип и принадлежность к команде. Это попадает в автоматическом режиме, если ничего не допиливать. Нам было важно связать информацию о витрине, на которой происходит построение модели, с этой моделью в OMD так, чтобы у нас появилась связь и отрисовался lineage между ними. Это мы и допиливали. Data Scientist работает над определенной витриной в Hive, он идет в OMD и забирает оттуда ключи к витрине, на которой он работает. Соответственно, мы написали клиент к OMD и эксплуатируем его. Data Scientist после своей работы понимает, какие витрины и столбцы ему нужны, а какие не нужны.

После этого он формирует некий yaml-конфиг, где явно отражает ключи тех витрин и столбцов, которые он будет эксплуатировать в рамках этой модели. Далее этот конфиг выпадает в определенную директорию репозитория, в которой триггерится конфиг, триггерится CI pipeline и выполняется загрузка этих ключей в OMD с привязкой к той модели, в рамках которой разрабатывался этот цикл. После успешного выполнения CI job мы получаем lineage примерно таким образом.

Посмотрим, как это выглядит, небольшое демо.

Мы находимся в UI Open Meta Data, переходим в раздел ML models и видим все instance’ы MLflow, которые мы сейчас завели OMD. Погружаемся в instance отдельной команды, и нам выпадают все модели, которые были построены данной командой. Погружаемся в одну модель, так как у нас добавлены эти фичи, видим, что у модели следующие зависимости.

Отрисован lineage, справа вы видите модель машинного обучения, которая зависит от некоторых витрин. Информация о зависимости в OMD есть и на уровне раньше. Разворачиваем, видим полную картину зависимостей данных к этой модели. Можем погрузиться в отдельную витрину. В ней справа появляется меню, в котором отражены признаки, которые мы берем для этой модели из этой витрины.

Представим, что что-то пошло не так с этой фичей. Мы ее можем скопипастить, вбить в поиск, и OMD выдаст все объекты, которые так или иначе зависят от этой фичи. Среди них мы видим восемь моделей машинного обучения. То есть потенциально, если с этой фичей что-то не так, то мы влияем на восемь моделей. Важно понять, что OMD кроме точного поиска фичи ищет еще приближенные названия, что может помочь в случае, если у нас что-то пошло не так с целой витриной, а не только с одной фичей, но мы еще о витрине не знаем.

Теперь посмотрим, как внедрение этого инструмента повлияло на процесс. Пусть у нас будет две витрины, три модели машинного обучения и два домена (геомодели и модели скоринга). Сломалась опять многострадальная первая моделька. Мы смотрим в OMD, какие домены строят витрины для данной модели, это скоринг и гео. У гео все в порядке, теперь у скоринга какие-то проблемы, и ребята начинают расследовать свои инциденты.

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

Эффекты

Инциденты возникают у нас не так часто, но имеющиеся мы устраняем в четыре раза быстрее по сравнению с тем временем, когда у нас не было OMD и построенного lineage. Также есть еще одна процедура, в рамках которой нам удалось получить оптимизацию. Мы регулярно, с интервалом примерно раз в месяц, некоторые команды чаще, некоторые - реже, проверяем фичи на предмет их стабильности, качества и так далее. Эту процедуру тоже удалось снизить примерно в три раза. Сейчас мы чекаем фичи за несколько часов, раньше это занимало гораздо больше времени. Соответственно, OMD позволил нам убрать все накладные расходы, связанные с поиском и с нотификацией.

Что в планах

Планируем автоматизировать нотификацию, сейчас ребята ищут те объекты, которые могли быть затронуты, устанавливают ответственные команды (owner’ы этих объектов), и в некотором мануальном режиме их уведомляют. Мы хотим использовать OMD шире. Он предоставляет элементы data quality, хотим сделать его некоторым коммунальным инструментом по проверке качества данных. Также в разработке хотим использовать Airflow в качестве ETL-scheduler, мы хотим воспользоваться фичей, которая бы позволила нам с использованием Airflow отрисовывать зависимости в Open Meta Data из коробки.

MLOps: как не потеряться в 10 тысячах фич, часть 2