Всем привет! Меня зовут Дмитрий Ермилов, и сегодня я хочу рассказать про то, как мы в билайне использовали один data catalog-инструмент для того, чтобы построить прозрачные связи между моделями машинного обучения и признаками, от которых эти модели зависят, то есть от фич. Из доклада вы узнаете, зачем и кому это бывает нужно, а также один из способов решения этой задачи.
Для начала немного о себе. Я более десяти лет в разработке и анализе данных, имею научный бэкграунд, принимал участие в различных проектах от построения высоконагруженных сервисов с использованием моделей машинного обучения и глубоких нейронных сетей до построения корпоративных хранилищ данных и ETL-процессов. В настоящий момент работают в билайн, в дирекции билайн бизнес (Big Data&AI).
Департамент DS состоит из двадцати специалистов. Билайн сегодня в первую очередь — технологичная компания, мы любим говорить, что мы технологичны снаружи и технологичны внутри. У нас трудится более 3500 IT-специалистов, более 200 продуктовых команд, которые разбиты на различные сегменты (внутренние продукты, продукты B2C, B2G и B2B). Дирекция Big Data&AI сфокусирована на B2B-сегменте, у нас 13 продуктовых команд, 200 IT-специалистов, это ML, DS, дата аналитики, фронт, бек, DevOps и другие функции.
Спектр продуктов широкий - от платформы видеоаналитики и системы транскрибации и анализа речи до классических продуктов в области банковского скоринга. Мы любим машинное обучение, и это взаимно.
Сейчас у нас в кластере крутится более 150 моделей, специфика такова, что модели машинного обучения у нас зависят от большого количества фич, рекорд - модель на десять тысяч фич. Это та история, которой необходимо управлять.
Чтобы понять наши решения, давайте погрузимся в среду, в которой происходит разработка моделей машинного обучения, и поговорим про инфраструктуру в билайне Бизнес для анализа данных. Жизненным циклом данных мы управляем в Data Management Platform, сердцем которого является Hadoop-кластер. Последний насчитывает порядка 25 петабайт данных, скорость прироста данных составляет два-три петабайта в год, данные разбиты на более чем двадцать тысяч витрин.
ETL-процессы мы строим на Spark на движке Yarn, также используем Hive для построения витрин. Управляем приложениями в среде Kubernetes и строим свою DS/ML-платформу в рамках большой платформы DMP.
Важно отметить, что билайн живет в парадигме Data Mesh - это подход децентрализованного использования данных, при котором данные эксплуатируются в рамках одного домена, то есть один домен отвечает за какой-то кусок данных. При этом каждый домен может использовать данные других доменов, если это необходимо.
Приведу пример: пусть желтый прямоугольник - это геодомен, который строит в нашей компании специфичные витрины на геоданных, на GPS-перемещениях абонентов.
Бирюзовый домен - антифрод-домен, ребята в этой команде строят витрины по данным из транзакций. Красный домен - домен скоринга, ребята строят так называемые карточки абонентов с признаками клиентов компании. Стрелками я указал зависимости доменов, кто куда ходит для получения данных, чтобы строить свои продукты. У подхода Data Mesh есть плюсы и минусы. Плюс состоит в том, что не нужно держать отдельную команду, которая обслуживает другие команды по построению каких-то витрин, которые необходимы продуктам.
Однако очевидно, что кто-то это делать должен, это делают сами продукты, поэтому в каждой продуктовой команде необходимо держать функцию построения таких витрин. Нам важно, что потенциально каждый домен лучше знает свои данные, таким образом данные в витринах получаются более информативными, что положительно сказывается на качестве продуктов. Мы находим больше плюсов, чем минусов, в Data Mesh, поэтому живем именно так.
ML-решения
MLOps - это набор DevOps-практик по оптимизации подходов к созданию ML-решений. Кто строил MLOps, знает, что пару лет назад выглядело это примерно так.
Какой-то зоопарк инструментов, которые слабо между собой связаны. Попытки их связать приводили к неожиданным последствиям. Сейчас ситуация другая. Есть много зрелых инструментов: ClearML, MLFlow, KubeFlow, BentoML, Seldon Core и другие. Они зреют, появляются удобные интеграции, делать MLOps становится приятно, чем мы в билайне и занимаемся.
DS-платформа
Жизненный цикл моделей происходит в рамках эксплуатации DS-платформы. Кратко расскажу об ее структуре. Выглядит это все так.
Команда, которой нужно анализировать данные, нужно строить ML-модели, заказывает в отделе эксплуатации DS-кабинет.
Последний представляет из себя несколько интегрированных между собой сервисов, которые поднимаются в рамках отдельного namespace и предоставляются команде, все это дело поверх бесшовной Keycloak авторизации, а слой памяти представляет собой Ceph. В ряде сервисов это Jupyter Hub, это MLflow, они друг с другом интегрированы, там ничего делать разработчикам не нужно.
Это преднастроенные ноутбуки для проведения стандартных задач по построению моделей и аналитике данных. Трекаем эксперименты в MLflow, кладем модельки в MLflow Storage, и если моделька доживает до внедрения в продуктив, то в 90% случаев это сценарий вычисления score’ов модельки на кластере. Делаем мы это с помощью Argo Workflow на преднастроенных Docker-образах, и обычно это PySpark job.
Посмотрим, как парадигма Data Mesh влияет на итоговое решение, связанное с моделями машинного обучения.
Справа вы видите некоторые модели машинного обучения. Модели зависят от некоторых витрин данных, а они в свою очередь строятся на данных из определенных доменов. Так, например, первая витрина зависит от одного геодомена, вторая витрина зависит от данных из гео и скоринга и так далее. Давайте представим на секунду, что с моделью пошло что-то не так, например, мы заметили это на мониторинге, заметили деградацию модели, снижается performance, пробивает какую-то отсечку, и с этим нужно что-то делать. Начинается расследование инцидента, команда-owner этой модельки приходит к тому, что у ребят из гео что-то пошло не так, надо что-то делать.
Они начинают расследовать этот инцидент внутри своего домена и приходят к какому-то решению. Это может быть сломанный какой-то ETL-пайплайн, это может быть отвалившийся источник данных, это может быть что-то в коммунальных сервисах. Важно, что от этого домена зависят и другие клиенты - мы видим еще две модели машинного обучения, которые зависят от желтого домена.
Потенциально сейчас возникают ситуации, когда продукты, в рамках которых созданы эти модели, могут нести риски. Нам важно как можно оперативнее уведомить продукты, что у них потенциально есть риски, чтобы команды устраняли их и не подставляли своих заказчиков и клиентов.
Мы это решили с помощью подхода Data lineage. Об этом я и расскажу во второй части статьи.