Использование Azure Databricks для оркестрации MLOps

Azure Databricks

Идеи решения

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

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

Это решение может воспользоваться преимуществами полной автоматизации, непрерывного мониторинга и надежной совместной работы, поэтому предназначен для уровня 4 уровня зрелости MLOps. В этой архитектуре используется код повышения уровня, который создает подход модели , а не подход по повышению уровня моделей . Код повышения уровня, который создает подход модели , фокусируется на написании и управлении кодом, который создает модели машинного обучения. Рекомендации, приведенные в этой статье, включают параметры автоматизированных или ручных процессов.

Архитектура

Схема, демонстрирующая решение для использования Azure Databricks для MLOps.

На этой схеме показаны 12 шагов этого рабочего процесса. В разделе рабочих данных Lakehouse содержатся метрики модели данных, таблицы признаков и модели таблиц Lakehouse. Раздел управления версиями включает среду разработки, промежуточного хранения и выпуска. Управление версиями включает Azure DevOps и GitHub. В основной среде разработки шаг 1 анализ исследуемых данных считывает данные из таблицы данных. Шаг 2 обучения модели считывает данные из таблицы данных и таблицы признаков. Шаг 3 фиксирует код в среде разработки в системе управления версиями. Шаг 4 объединяет запрос к промежуточной среде. Промежуточная среда управления версиями активирует этап 5 модульных и CI-тестов в основной промежуточной среде, которая считывает данные из таблицы компонентов и таблицы данных. Код изменяет слияние с промежуточной средой управления версиями. Шаг 6 создает ветвь выпуска в среде выпуска. Стрелка, указывающая на среду выпуска в основную рабочую среду, говорится в развертывании заданий Databricks машинного обучения. В основной рабочей среде обновление таблицы компонентов 7 считывает данные из таблицы данных и отправляет данные в таблицу признаков. Шаг 8 обучения модели считывает данные из обнаружения смещения и переобучения модели. Шаг 8 также отправляет модель в каталог Unity. Шаг 9 оценка и повышение уровня модели загружает модель из каталога Unity для оценки. Затем она отправляет модель в промежуточный, а затем рабочую среду в каталоге Unity. Шаг 10 развертывания модели загружает модель для вывода и считывает данные из таблицы функций. Шаг 11 мониторинга считывает данные из таблицы признаков и считывает метрики модели таблиц Lakehouse. Шаг 11 также записывает данные в таблицу Lakehouse и в Azure Monitor. Шаг 12 переобучение модели указывает на шаг 8 и переобучение модели триггера со стрелками.

Скачайте файл Visio для этой архитектуры.

Рабочий процесс

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

Управление версиями: репозиторий кода этого проекта упорядочивает записные книжки, модули и конвейеры. Вы можете создавать ветви разработки для тестирования обновлений и новых моделей. Разработка кода в поддерживаемых Git записных книжках или интегрированных средах разработки (IDEs), которые интегрируются с папками Git, чтобы синхронизироваться с рабочими областями Azure Databricks. Управление версиями способствует конвейерам машинного обучения из среды разработки, тестированию в промежуточной среде и развертыванию в рабочей среде.

Производственные данные Lakehouse: как специалист по обработке и анализу данных у вас есть доступ только для чтения к рабочим данным в среде разработки. Среда разработки может иметь зеркальные данные и отредактированные конфиденциальные данные. У вас также есть доступ на чтение и запись в среде хранилища разработки для разработки и экспериментирования. Рекомендуется использовать архитектуру lakehouse для данных, в которых хранятся данные в формате Delta Lake в Azure Data Lake Storage. Lakehouse предоставляет надежное, масштабируемое и гибкое решение для управления данными. Чтобы определить элементы управления доступом, используйте сквозное руководство по учетным данным Microsoft Entra ID или элементы управления доступом к таблицам.

Следующие среды включают основной рабочий процесс.

Разработка

В среде разработки вы разрабатываете конвейеры машинного обучения.

  1. Выполните анализ аналитических данных (EDA): изучите данные в интерактивном итеративном процессе. Вы можете не развертывать эту работу в промежуточной или рабочей среде. Используйте такие средства, как Databricks SQL, команда dbutils.data.summarize и Databricks AutoML.

  2. Разработка обучения моделей и других конвейеров машинного обучения: разработка конвейеров машинного обучения модульного кода и оркестрация кода с помощью Записных книжек Databricks или проекта MLflow. В этой архитектуре конвейер обучения модели считывает данные из хранилища компонентов и других таблиц Lakehouse. Конвейер обучает и настраивает параметры модели журнала и метрики на сервер отслеживания MLflow. API хранилища функций регистрирует окончательную модель. К этим журналам относятся модель, его входные данные и код обучения.

  3. Фиксация кода: чтобы повысить рабочий процесс машинного обучения в рабочей среде, зафиксировать код для признаков, обучения и других конвейеров для управления версиями. В базе кода поместите код машинного обучения и операционный код в разные папки, чтобы участники команды могли одновременно разрабатывать код. Код машинного обучения — это код, связанный с моделью и данными. Операционный код — это код, связанный с заданиями и инфраструктурой Databricks.

Этот основной цикл действий, которые выполняются при написании и тестировании кода, называются внутренним процессом. Чтобы выполнить внутренний процесс для этапа разработки, используйте Visual Studio Code в сочетании с интерфейсом командной строки контейнера разработки и интерфейсом командной строки Databricks. Вы можете написать код и выполнить модульное тестирование локально. Вы также должны отправлять, отслеживать и анализировать конвейеры модели из локальной среды разработки.

Промежуточная

В промежуточной среде инфраструктура непрерывной интеграции (CI) проверяет изменения конвейеров машинного обучения в среде, которая имитирует рабочую среду.

  1. Слияние запроса. При отправке запроса на слияние или запроса на вытягивание в промежуточной (главной) ветви проекта в системе управления версиями средство непрерывной интеграции и непрерывной доставки (CI/CD), например Azure DevOps, выполняет тесты .

  2. Выполнение модульных тестов и тестов CI: модульные тесты выполняются в инфраструктуре CI, а тесты интеграции выполняются в комплексных рабочих процессах в Azure Databricks. Если тесты проходят, код изменяет слияние.

  3. Создайте ветвь выпуска: если вы хотите развернуть обновленные конвейеры машинного обучения в рабочей среде, можно создать новый выпуск. Конвейер развертывания в средстве CI/CD развертывает обновленные конвейеры в качестве новых рабочих процессов.

Производственный экземпляр

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

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

  2. Обучение модели. В рабочей среде можно настроить обучающий конвейер модели или переобучение конвейера для запуска на триггере или расписания обучения новой модели на основе последних рабочих данных. Модели автоматически регистрируются в каталоге Unity.

  3. Оценка модели и повышение уровня . При регистрации новой версии модели триггеры конвейера CD, выполняющие тесты, чтобы гарантировать, что модель будет хорошо работать в рабочей среде. Когда модель проходит тесты, каталог Unity отслеживает ход выполнения с помощью переходов этапа модели. К тестам относятся проверки соответствия, тесты A/B для сравнения новой модели с текущей производственной моделью и тестами инфраструктуры. Таблицы Lakehouse записывают результаты теста и метрики. Кроме того, перед переходом моделей в рабочую среду можно требовать вручную.

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

    • Оценка пакетной или потоковой передачи. Для задержки минут или длиннее пакетная и потоковая передача являются наиболее экономичными вариантами. Конвейер оценки считывает последние данные из хранилища компонентов, загружает последнюю версию рабочей модели из каталога Unity и выполняет вывод в задании Databricks. Он может публиковать прогнозы в таблицах Lakehouse, подключение к базе данных Java (JDBC), неструктурированные файлы, очереди сообщений или другие подчиненные системы.

    • Онлайн-обслуживание (REST API ): для случаев использования с низкой задержкой обычно требуется онлайн-обслуживание. MLflow может развертывать модели в мозаичных моделях ИИ, облачных системах обслуживания и других системах. Во всех случаях система обслуживания инициализируется с последней рабочей моделью из каталога Unity. Для каждого запроса он получает функции из интернет-магазина функций и делает прогнозы.

  5. Мониторинг: непрерывные или периодические рабочие процессы отслеживают входные данные и прогнозы модели для смещения, производительности и других метрик. Платформу Delta Live Tables можно использовать для автоматизации мониторинга конвейеров и хранения метрик в таблицах Lakehouse. Databricks SQL, Power BI и другие средства могут читать из этих таблиц для создания панелей мониторинга и оповещений. Чтобы отслеживать метрики, журналы и инфраструктуру приложений, можно также интегрировать Azure Monitor с Azure Databricks.

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

Компоненты

  • Архитектура озера данных объединяет элементы озер данных и хранилищ данных. Используйте lakehouse для получения возможностей управления данными и производительности, которые обычно находятся в хранилищах данных, но с низкой стоимостью гибкий объект хранит это предложение озера данных.

    • Delta Lake — это рекомендуемый формат данных с открытым исходным кодом для lakehouse. Azure Databricks хранит данные в Data Lake Storage и предоставляет подсистему высокопроизводительных запросов.
  • MLflow — это проект с открытым исходным кодом для управления комплексным жизненным циклом машинного обучения. MLflow имеет следующие компоненты:

    • Функция отслеживания отслеживает эксперименты, поэтому можно записывать и сравнивать параметры, метрики и артефакты модели.

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

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

    • Мозаичная модель ИИ, обслуживающая модели MLflow, размещает модели MLflow в качестве конечных точек REST.

  • Azure Databricks предоставляет управляемую службу MLflow с корпоративными функциями безопасности, высокой доступностью и интеграцией с другими функциями рабочей области Azure Databricks.

    • Databricks Runtime для Машинное обучение автоматизирует создание кластера, оптимизированного для машинного обучения и предустановки популярных библиотек машинного обучения, таких как TensorFlow, PyTorch и XGBoost. Он также предустановит Azure Databricks для Машинное обучение инструментов, таких как AutoML и клиенты хранилища компонентов.

    • Хранилище функций — это централизованный репозиторий функций. Используйте хранилище функций для обнаружения и совместного использования функций и предотвращения размыкания данных между обучением моделей и выводом.

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

    • Папки Git обеспечивают интеграцию с поставщиком Git в рабочей области Azure Databricks, что улучшает совместную работу с записной книжкой или кодом и интеграцию интегрированной среды разработки.

    • Рабочие процессы и задания предоставляют способ запуска неинтерактивного кода в кластере Azure Databricks. Для машинного обучения задания обеспечивают автоматизацию подготовки данных, признаков, обучения, вывода и мониторинга.

Альтернативные варианты

Это решение можно адаптировать к инфраструктуре Azure. Рассмотрим следующие настройки:

  • Используйте несколько рабочих областей разработки, которые совместно используют общую рабочую область.

  • Обмен одним или несколькими компонентами архитектуры для существующей инфраструктуры. Например, можно использовать Фабрика данных Azure для оркестрации заданий Databricks.

  • Интеграция с существующими средствами CI/CD через ИНТЕРФЕЙСы REST API Git и Azure Databricks.

  • Используйте Microsoft Fabric или Azure Synapse Analytics в качестве альтернативных служб для возможностей машинного обучения.

Подробности сценария

Это решение обеспечивает надежный процесс MLOps, использующий Azure Databricks. Вы можете заменить все элементы в архитектуре, чтобы при необходимости интегрировать другие службы Azure и партнерские службы. Эта архитектура и описание адаптированы из электронной книги Big Book mlOps. Электронная книга подробно изучает эту архитектуру.

MLOps помогает снизить риск сбоев в системах машинного обучения и искусственного интеллекта и повышает эффективность совместной работы и инструментов. Общие сведения о MLOps и обзор этой архитектуры см. в статье "Архитектор MLOps" в lakehouse.

Используйте эту архитектуру для:

  • Подключение заинтересованных лиц к бизнесу с помощью команд машинного обучения и обработки и анализа данных. Используйте эту архитектуру для включения записных книжек и идентификаторов среды разработки. Бизнес-заинтересованные лица могут просматривать метрики и панели мониторинга в Databricks SQL, все в пределах одной архитектуры Lakehouse.

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

  • Реализуйте MLOps в модулях и конвейерах. Как и в любом программном приложении, используйте модульные конвейеры и код в этой архитектуре для тестирования отдельных компонентов и снижения затрат на рефакторинг в будущем.

  • Автоматизируйте процессы MLOps по мере необходимости. В этой архитектуре можно автоматизировать шаги по повышению производительности и снижению риска человеческой ошибки, но вам не нужно автоматизировать каждый шаг. Azure Databricks позволяет обрабатывать пользовательский интерфейс и вручную в дополнение к API для автоматизации.

Потенциальные варианты использования

Эта архитектура применяется ко всем типам машинного обучения, глубокого обучения и расширенной аналитики. Распространенные методы машинного обучения и ИИ в этой архитектуре включают:

  • Классическое машинное обучение, например линейные модели, модели на основе деревьев и повышение.
  • Современное глубокое обучение, как TensorFlow и PyTorch.
  • Пользовательская аналитика, например статистика, методы Bayesian и графовая аналитика.

Архитектура поддерживает как небольшие данные (один компьютер), так и большие данные (распределенные вычисления и ускорение GPU). На каждом этапе архитектуры можно выбрать вычислительные ресурсы и библиотеки для адаптации к данным и измерениям проблем сценария.

Архитектура применяется ко всем типам отраслей и бизнес-вариантов использования. Клиенты Azure Databricks, использующие эту архитектуру, включают небольшие и крупные организации в следующих отраслях:

  • Потребительские товары и розничные услуги
  • Финансовые услуги
  • Здравоохранение и медико-биологические науки
  • Информационные технологии

Примеры см. в разделе "Клиенты Databricks".

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

  • Брэндон Ковен | Старший архитектор облачных решений
  • Prabal Deb | Главный инженер программного обеспечения

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующие шаги