Рабочие процессы MLOps в Azure Databricks

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

Дополнительные сведения см . в статье "Большая книга MLOps".

Что собой представляет MLOps?

MLOps — это набор процессов и автоматизированных шагов по управлению кодом, данными и моделями. Он объединяет DevOps, DataOps и ModelOps.

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

Общие рекомендации по работе с MLOps

В этом разделе содержатся некоторые общие рекомендации по использованию MLOps в Databricks со ссылками на дополнительные сведения.

Создание отдельной среды для каждого этапа

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

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

• Разработка
• Промежуточное хранение
• Рабочая среда

Другие конфигурации также можно использовать для удовлетворения конкретных потребностей вашей организации.

Управление доступом и управление версиями

Управление доступом и управление версиями — это ключевые аспекты любого процесса, связанного с выполнением операций с программным обеспечением. В Databricks рекомендуется следующее:

• Использовать Git для управления версиями. Конвейеры и код должны храниться в Git для управления версиями. Перемещение логики ML между этапами можно интерпретировать как перемещение кода из ветви разработки в промежуточную ветвь и в ветвь выпуска. Используйте папки Databricks Git для интеграции с поставщиком Git и синхронизации записных книжек и исходного кода с рабочими областями Databricks. Databricks также предоставляет дополнительные средства для интеграции Git и управления версиями; см. статью Средства разработчика и инструкции.
• Храните данные в архитектуре lakehouse с помощью таблиц Delta. Данные должны храниться в архитектуре Lakehouse в облачной учетной записи. Как необработанные данные, так и таблицы признаков должны храниться в виде таблиц Delta с возможностью управления доступом, чтобы можно было определить, кто может их читать и изменять.
• Управление разработкой моделей с помощью MLflow. Вы можете использовать MLflow для отслеживания процесса разработки модели и сохранения моментальных снимков кода, параметров модели, метрик и других метаданных.
• Используйте модели в каталоге Unity для управления жизненным циклом модели. Используйте модели в каталоге Unity для управления управлением версиями моделей, управлением и состоянием развертывания.

Развертывание кода, а не моделей

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

Рекомендуемый рабочий процесс MLOps

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

В этом разделе термины "специалист по обработке и анализу данных" и "инженер ML" используются как архетипические персонажи; конкретные роли и обязанности в рабочем процессе MLOps будут отличаться в разных командах и организациях.

Этап разработки

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

Пронумерованные шаги соответствуют числам, указанным на схеме.

1. Источники данных

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

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

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

2ю Разведочный анализ данных

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

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

3. Код

Репозиторий кода содержит все конвейеры, модули и другие файлы проекта для проекта машинного обучения. Специалисты по обработке и анализу данных создают новые или обновленные конвейеры в ветви разработки (dev) репозитория проекта. Начиная с EDA и начальных этапов проекта, специалисты по обработке и анализу данных должны работать в репозитории для совместного использования кода и отслеживания изменений.

4. Обучение модели (разработка)

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

Этот конвейер включает две задачи:

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

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

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

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

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

Рекомендуемая архитектура позволяет развернуть рабочий процесс с несколькими задачами Databricks, в котором первая задача — конвейер обучения модели, а затем задачи проверки и развертывания моделей. Задача обучения модели дает универсальный код ресурса (URI) модели, который может использовать задача проверки модели. Значения задач можно использовать для передачи этого URI модели.

5. Проверка и развертывание модели (разработка)

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

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

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

  Основная функция конвейера проверки модели — определить, должна ли модель перейти к шагу развертывания. Если модель проходит предварительное развертывание проверка, его можно назначить псевдоним Challenger в каталоге Unity. Если проверка завершается ошибкой, процесс завершается. Рабочий процесс можно настроить для уведомления пользователей о сбое проверки. См. статью "Добавление уведомлений по электронной почте и системе" для событий задания.

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

6. Код фиксации

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

Промежуточный этап

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

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

1. Данные

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

2. Код слияния

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

• Запрос на вытягивание. Процесс развертывания начинается при создании запроса на вытягивание в главной ветви проекта в системе управления версиями.

• Модульные тесты (CI). Запрос на вытягивание автоматически создает исходный код и запускает модульные тесты. Если модульные тесты завершаются ошибкой, запрос на вытягивание отклоняется.

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

3. Интеграционные тесты (CI)

Затем процесс CI выполняет интеграционные тесты. Тесты интеграции выполняют все конвейеры (включая проектирование признаков, обучение моделей, вывод и мониторинг), чтобы обеспечить правильную работу вместе. Промежуточная среда должна максимально точно соответствовать рабочей среде.

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

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

4. Слияние в промежуточную ветвь

Если все тесты проходят, новый код объединяется в основную ветвь проекта. Если тесты завершаются сбоем, система CI/CD должна уведомлять пользователей и публиковать результаты в запросе на вытягивание.

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

5. Создание ветви выпуска

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

Рабочая среда

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

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

Пронумерованные шаги соответствуют числам, указанным на схеме.

1. Обучение модели

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

• Обучение и настройка. Во время обучения журналы записываются на сервер отслеживания MLflow рабочей среды. Эти журналы включают метрики модели, параметры, теги и саму модель. Если вы используете таблицы компонентов, модель регистрируется в MLflow с помощью клиента Databricks Feature Store, который упаковает модель с сведениями о подстановке признаков, используемыми во время вывода.

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

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

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

• Регистрация модели. После завершения обучения модели артефакт модели сохраняется в качестве зарегистрированной версии модели по указанному пути модели в рабочем каталоге в каталоге Unity. Задача обучения модели дает универсальный код ресурса (URI) модели, который может использовать задача проверки модели. Значения задач можно использовать для передачи этого URI модели.

2. Проверка модели

Этот конвейер использует универсальный код ресурса (URI) модели из шага 1 и загружает модель из каталога Unity. Затем он выполняет ряд проверка проверки. Эти проверка зависят от вашей организации и варианта использования, а также могут включать такие функции, как основные проверки формата и метаданные, оценки производительности на выбранных срезах данных и соответствие требованиям организации, таким как проверка соответствия тегам или документации.

Если модель успешно проходит все проверка проверки, можно назначить псевдоним "Challenger" версии модели в каталоге Unity. Если модель не проходит все проверка проверки, процесс завершается и пользователи могут автоматически получать уведомления. Теги можно использовать для добавления атрибутов значения ключа в зависимости от результата этих проверка проверки. Например, можно создать тег "model_validation_status" и задать значение "ОЖИДАНИЕ" в качестве выполнения тестов, а затем обновить его до "PASSED" или "FAILED" после завершения конвейера.

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

3. Развертывание модели

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

• Сравните "CHALLENGER" с моделью CHAMPION. Вы можете выполнить это сравнение в автономном режиме или в сети. Автономное сравнение вычисляет обе модели по заданному набору данных и отслеживает результаты с помощью сервера отслеживания MLflow. Для обслуживания модели в режиме реального времени может потребоваться выполнить более длительные онлайн-сравнения, такие как тесты A/B или постепенное развертывание новой модели. Если версия модели "Challenger" лучше работает в сравнении, она заменяет текущий псевдоним "Чемпион".

  Databricks Model Serving and Databricks Lakehouse Monitoring позволяют автоматически собирать и отслеживать таблицы вывода, содержащие данные запроса и ответа для конечной точки.

  Если нет существующей модели "Чемпион", можно сравнить модель "Challenger" с бизнес-эвристики или другого порога в качестве базового значения.

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

• Развертывание модели. Конвейеры вывода пакетной или потоковой передачи можно настроить для использования модели с псевдонимом "Чемпион". Для вариантов использования в режиме реального времени необходимо настроить инфраструктуру для развертывания модели в качестве конечной точки REST API. Эту конечную точку можно создать и управлять ими с помощью службы моделей Databricks. Если конечная точка уже используется для текущей модели, можно обновить конечную точку с помощью новой модели. Служба моделей Databricks выполняет обновление без простоя, сохраняя существующую конфигурацию до тех пор, пока новая не будет готова.

4. Обслуживание моделей

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

Вы можете создать одну конечную точку с несколькими моделями и указать трафик конечной точки, разделенный между этими моделями, что позволяет проводить онлайн-сравнения "Чемпион" и "Challenger".

5. Вывод: пакетная или потоковая передача

Конвейер вывода считывает последние данные из рабочего каталога, выполняет функции для вычисления функций по запросу, загружает модель "Чемпион", оценивает данные и возвращает прогнозы. Пакетный или потоковый вывод, как правило, является наиболее экономичным вариантом для случаев использования с более высокой пропускной способностью и более высокой задержкой. В сценариях, где требуются прогнозы с низкой задержкой, но прогнозы могут быть вычислены в автономном режиме, эти пакетные прогнозы можно опубликовать в хранилище значений ключей в Интернете, например DynamoDB или Cosmos DB.

Зарегистрированная модель в каталоге Unity ссылается на ее псевдоним. Конвейер вывода настроен для загрузки и применения версии модели "Чемпион". Если версия "Чемпион" обновляется до новой версии модели, конвейер вывода автоматически использует новую версию для следующего выполнения. Таким образом шаг развертывания модели отделяется от конвейеров вывода.

Пакетные задания обычно публикуют прогнозы в таблицах в рабочем каталоге, в неструктурированные файлы или через подключение JDBC. Задания потоковой передачи обычно публикуют прогнозы в таблицах каталога Unity или в очереди сообщений, такие как Apache Kafka.

6. Мониторинг Lakehouse

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

• Прием данных. Этот конвейер считывает журналы из пакетного, потокового или интерактивного вывода.
• Проверка точности и смещения данных. Конвейер вычисляет метрики входных данных, прогнозов модели и производительности инфраструктуры. Специалисты по обработке и анализу данных указывают метрики данных и моделей во время разработки, а инженеры ML определяют метрики инфраструктуры. Вы также можете определить пользовательские метрики с помощью Lakehouse Monitoring.
• Публикация метрик и настройка оповещений. Конвейер записывает в таблицы в каталоге рабочей среды для анализа и создания отчетов. Эти таблицы следует настроить для чтения из среды разработки, чтобы специалисты по обработке и анализу имели доступ. Вы можете использовать Databricks SQL для создания панелей мониторинга для отслеживания производительности модели, а также настроить задание мониторинга или средство панели мониторинга для отправки уведомления, когда метрика превышает указанный порог.
• Переобучение модели триггера. Если метрики мониторинга указывают на проблемы с производительностью или изменения входных данных, специалист по обработке и анализу данных может потребоваться разработать новую версию модели. Вы можете настроить оповещения SQL, чтобы уведомить специалистов по обработке и анализу данных, когда это произойдет.

7. Переобучение

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

• Запланированный. Если новые данные доступны регулярно, можно создать запланированное задание для запуска кода обучения модели на основе последних доступных данных.
• Активируемые. Если конвейер мониторинга может выявлять проблемы с производительностью модели и отправлять оповещения, он также может активировать переобучение. Например, если распределение входящих данных значительно изменяется или если производительность модели снижается, автоматическое переобучение и повторное развертывание могут повысить производительность модели с минимальным вмешательством человека. Это можно сделать с помощью оповещения SQL, чтобы проверка, является ли метрика аномальной (например, проверка смещение или качество модели по пороговому значению). Оповещение можно настроить для использования назначения веб-перехватчика, который впоследствии может активировать рабочий процесс обучения.

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