От платформы для данных до платформы для машинного обучения

От эволюции платформы данных до передовой платформы машинного обучения

Как платформы Data/ML развиваются и поддерживают сложные практики MLOps

Data/ML является самой популярной темой в нашей технологической среде. Я хочу поделиться своим пониманием платформы Data/ML и тем, как эти платформы развиваются от простых до сложных. В конце, я постараюсь рассказать о MLOps, принципе управления проектами машинного обучения.

Что касается информации обо мне, вот моя страница LinkedIn.

Начало путешествия: Онлайн-сервис + OLTP + OLAP

В начале инфраструктура данных может быть довольно простой. Аналитические запросы могут быть отправлены на реплику онлайн-базы данных OLTP или создан OLAP-сервер в качестве хранилища данных.

Вот, как может выглядеть инфраструктура:

• Краткое пояснение энтропийного регуляризированного обучения с подкреплением
• Топ-9 инструментов управления данными, которые будут использоваться в 2023 году
• Поиск изображений за 5 минут

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

На этом этапе существует несколько способов анализа данных:

1. Просто отправить запросы на реплику базы данных OLTP (не рекомендуется).
2. Активировать CDC (Change Data Capture) базы данных OLTP и загрузить эти данные в OLAP-базу данных. Для выбора службы загрузки для журналов CDC вы можете выбрать в зависимости от выбранной вами OLAP-базы данных. Например, потоковая передача данных Flink с помощью коннекторов CDC – это способ справиться с этой задачей. Многие предприятия предлагают свое рекомендуемое решение, например, Snowpipe для Snowflake. Также рекомендуется загружать данные с реплики на основной узел для сохранения производительности ЦП/ввода-вывода основного узла при онлайн-трафике.

На этом этапе рабочая нагрузка МО может выполняться в вашей локальной среде. Вы можете настроить локальную среду Jupyter и загрузить структурированные данные из OLAP-базы данных, а затем обучить модель МО локально.

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

• Трудность работы с неструктурированными или полуструктурированными данными в OLAP-базе данных.
• Ухудшение производительности OLAP при обработке больших объемов данных (более нескольких терабайтов, необходимых для одной задачи ETL).
• Отсутствие поддержки различных вычислительных движков, таких как Spark или Presto. Большинство вычислительных движков поддерживают подключение к OLAP через точку доступа JDBC, но параллельная обработка будет сильно ограничена узким местом ввода-вывода точки доступа JDBC.
• Стоимость хранения больших объемов данных в OLAP-базе данных высока.

Вы, возможно, уже знаете направление для решения этой проблемы. Постройте Data Lake! Внедрение Data Lake не обязательно означает полное прекращение использования OLAP-базы данных. Вполне обычно видеть, что компании используют оба системы параллельно для разных целей.

Data Lake: Хранение и отделение компьютеризации + Схема при записи

Data Lake позволяет сохранять неструктурированные и полуструктурированные данные, а также выполнять схему при записи. Он позволяет снизить затраты, храня большие объемы данных с использованием специализированного хранилища и запуская вычислительные кластеры в зависимости от вашего спроса. Благодаря этому вы легко можете управлять набором данных в терабайтах/петабайтах, масштабируя вычислительные кластеры.

Вот, как может выглядеть ваша инфраструктура:

Это действительно упрощенная схема. Фактическая реализация Data Lake может быть гораздо более сложной.

Многие провайдеры облачных услуг уже имеют отработанные решения для хранилища данных, такие как AWS S3 и Azure ADLS. Тем не менее, над этими решениями все еще нужно выполнять множество задач. Например, должен быть Hive метастор для управления метаданными таблиц, а также Datahub для обеспечения видимости данных. Также существуют сложные вопросы, такие как управление правами на данные в озере данных и анализ линейности данных (например, spline).

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

Общие рекомендации:

• Избегайте маленьких файлов: маленькие файлы являются одной из основных причин высоких затрат на хранение и плохой производительности в озере данных.
• Найти баланс между задержкой, коэффициентом сжатия и производительностью: таблица с низкой задержкой в озере данных с форматом файла, например, Hudi, может не дать вам наилучший коэффициент сжатия, и большие ORC-файлы с высоким коэффициентом сжатия могут причинять кошмарную производительность. Вы должны выбирать формат файла обдуманно на основе шаблона использования таблицы, требований к задержке и размеров таблицы.

Существуют некоторые установленные SaaS/PaaS-провайдеры, такие как Databricks, которые предоставляют неплохое решение для озера данных (или уже LakeHouse). Вы также можете изучить ByteHouse, чтобы иметь единый опыт обработки больших объемов данных.

В области машинного обучения команда может начать изучать хорошо зарекомендовавшие себя фреймворки машинного обучения, такие как Tensenflow и Pytorch, в удаленной среде. Более того, обученные модели машинного обучения могут быть развернуты в производственной среде для вычисления модели в реальном времени. И TensorFlow, и Pytorch поставляются с решением для обслуживания моделей, например TensorFlow Serving и Pytorch Serving.

Однако наш путь не остановится здесь. У нас могут возникнуть следующие проблемы:

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

Поднимем свою игру на новый уровень.

Реальное время/Инфраструктура МЛ: Data River + Data Streaming + Feature Store + Metric Server

Обычно построение инфраструктуры для передачи данных в режиме реального времени является совместным усилием нескольких отделов компании. Изначальная цель построения Data River, как правило, не в системе данных/машинного обучения, а в обеспечении возможности масштабирования микросервисов путем удаления синхронизированного вызова. Вместо этого микросервисы обеспечивают эффективность путем взаимодействия с посредником сообщений, таким как Kafka (за счет снижения уровня согласованности).

Общая архитектура может выглядеть следующим образом.

Используя данные, доступные в Data River (например, Kafka), мы можем создать конвейер обработки данных в реальном времени. Эти данные могут использоваться непосредственно в онлайн магазине характеристик или синхронизироваться с сервером метрик, таким как Pinot. Сервер метрик может дополнительно обрабатывать/агрегировать эти точки метрик для создания более полезных метрик производительности модели и бизнес-метрик. Вы также можете использовать потоковые базы данных, такие как RisingWave, которые могут объединять/агрегировать потоковые данные с помощью синтаксиса SQL.

Для создания потоковой обработки данных очень популярен Flink. Вы также можете использовать Flink с коннектором CDC для извлечения данных из базы данных OLTP и отправки данных в брокеры сообщений и озеро данных.

Должен быть интернет-магазин с функцией хранения, поддерживаемый базой данных ключ-значение, такой как ScyllaDB или AWS Dynamo DB. Интернет-магазин может помочь вам обогатить отправленный запрос в сервис моделирования с вектором характеристик, связанных с определенным идентификатором ссылки (идентификатор пользователя, UUID продукта). Это может значительно разъединить зависимость между командой службы бэкэнда, которая создает микросервисы, и командой инженеров машинного обучения, которая создает модели машинного обучения. Это позволяет инженерам машинного обучения внедрять новые функции машинного обучения с новой моделью машинного обучения независимо (сигнатура вашего API моделирования, предоставленная микросервисам, остается неизменной при обновлении вектора характеристик).

В книге “Проектирование систем машинного обучения” рассказывается о стэкинге моделей (Jen Wadkin’s VoAGI post о стэкинге моделей). Также очень распространено использование стэкинга моделей для обслуживания моделей. Для объединения разнообразных моделей требуется оркестратор, например, сочетание моделей pytorch и tensorflow. Вы также можете усложнить своего оркестратора, динамически устанавливая веса на основе производительности моделей при маршрутизации запросов к разным моделям.

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

• Долг системы будет резко возрастать, если ее оставить незащищенной.
• Машинным обучением инженерам будет трудно справиться с высокой нагрузкой.

Вот когда вам, вероятно, понадобится задуматься о том, как MLOps может вам помочь.

MLOps: Абстракция, наблюдаемость и масштабируемость

MLOps никогда не является конкретным решением. Это больше похоже на набор принципов управления системами машинного обучения. В отличие от типичного программного проекта, системы машинного обучения сильно зависят от изменения данных, и управление зависимостями данных не является простой задачей. В статье “Скрытый технический долг в системах машинного обучения” подробно описаны эти вызовы. Поэтому MLOps-ориентированная платформа машинного обучения должна быть способна:

• Мониторить изменение данных и качество данных.
• Управлять особенностями ML в офлайн и онлайн среде.
• Конструировать воспроизводимую ML пайплайн, обеспечивающую экспериментально-операционную симметрию.
• Иметь лаконичную конфигурацию ML пайплайна, которая может абстрагировать детали инфраструктуры.

В статье “MLOps: Непрерывная доставка и автоматизация пайплайнов в машинном обучении” подчеркивается важность экспериментально-операционной симметрии. Он также описывает уровни автоматизации MLOps от уровня 0, уровня 1 до уровня 2. Мне очень нравится график из этого документа, и я позаимствую его, чтобы объяснить, как выглядит MLOps уровня 1.

Чтобы масштабировать такую ​​практику MLOps в вашей организации, вам необходимо предоставить лаконичную конфигурацию ML пайплайна, которая может абстрагировать детали реализации инфраструктуры от инженеров машинного обучения. Сделав это, инженеры платформы также получают гибкость для обновления платформы машинного обучения без существенных нарушений для пользователей платформы. Вы можете рассмотреть вариант использования файлов конфигурации (например, YAML) для описания ML пайплайнов и полагаться на контроллеры ML Pipeline для трансляции их в фактическую рабочую нагрузку.

Итак, давайте организуем реальные данные/инфраструктуры машинного обучения с помощью следующего графика, чтобы подчеркнуть, как MLOps формирует наши платформы.

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

Kubernetes является популярным решением для оркестрации рабочих нагрузок машинного обучения (или, возможно, всех рабочих нагрузок в наши дни). Вы можете использовать CRDs, чтобы предоставить компактные интерфейсы между пользователями и платформами. В статье Мое мышление о Kubebuilder, я поделился некоторыми своими мыслями при построении CRD с помощью Kubebuilder.

Конечно, я не охватил многие важные подтемы, включая, но не ограничиваясь:

• Оптимизация гиперпараметров
• Архитектура распределенного обучения

Что дальше

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

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

• Безсерверность: Мы слишком сильно отодвигаем ценность машинного обучения из-за того, что фундаментом платформы ML обычно является платформа для работы с данными. Это похоже на то, как заставляем пользователей покупать вычислительные мощности для использования социальных медиа-платформ, когда мы уже в эпоху мобильных устройств. Серверные службы обработки данных и вычислительные кластеры решают эту проблему. Многие поставщики услуг исследуют свои собственные решения для платформы “без сервера”, например, Databricks, Snowflake, Bytehouse. Компании могут начать создание своих продуктов в области машинного обучения после создания своих хранилищ данных или озер данных.
• Искусственный интеллект для создания признаков: Хорошо, искусственный интеллект теперь может делать все, не так ли?
• Тренды в предоставлении моделей в виде сервиса: Появятся более мощные модели в виде “Модель-как-сервис”. Компании могут непосредственно использовать мощности машинного обучения, даже не создавая свою собственную службу машинного обучения, чтобы получить преимущество в своем бизнесе.

Как мы все заметили, область машинного обучения развивается настолько быстро. В этот самый момент, когда я пишу это, эта статья может уже устареть. Больше идей уже возникло и были превращены в реальность. Пожалуйста, дайте мне знать, что вы думаете об MLOps или о том, где мне следует продолжить свое обучение. Давайте держать темп вместе!