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

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

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

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

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

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

Этап 1 - Этап экспериментов и упаковки

Для любой проблемы науки о данных может потребоваться множество начальных экспериментов, которые необходимо провести как часть PoC (Proof of Concepts) над некоторыми начальными вариантами использования, прежде чем переходить к созданию пилотного или минимально жизнеспособного продукта (MVP) из данные. Чаще всего специалисты по обработке данных и инженеры машинного обучения используют записные книжки, чтобы начать экспериментировать с данными, исследовать их, понимать, исправлять, выяснять правильный алгоритм решения проблемы, тестировать и проверять его, а затем создавать модель машинного обучения. покончил с настройкой.

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

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

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

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

Рекомендуемые инструменты:

  • Jupyter Notebook / Jupyter Lab: он предоставляет быстрый и грязный способ опробовать различные методы и подходы, от очистки данных до создания высокопроизводительных моделей.
  • MLFlow: он обеспечивает быструю и простую интеграцию на уровне эксперимента для отслеживания различных параметров, функций, показателей, эпох / итераций и т. д., что может быть очень продуктивным на этом этапе с некоторыми классными готовыми визуализациями. а также быстро взглянуть на различные эксперименты и их результаты. Наряду со всеми этими средствами отслеживания MLFlow также обеспечивает управление версиями моделей, что мы рассмотрим на следующих этапах. Лучший способ начать работу с MLFlow - просмотреть официальную страницу документации и следовать руководству по быстрому запуску.
  • Kubeflow: в зависимости от доступности кластера Kubernetes для фазы экспериментов, Kubeflow также можно использовать как часть фазы экспериментов, поскольку конвейеры Kubeflow предоставляют функции для отслеживания каждого эксперимента и их выполнения, сравнить несколько запусков, а также предоставить инфраструктуру Kubernetes для быстрого проведения множества параллельных экспериментов с масштабированием. В целом, это в конечном итоге сводится к доступности инфраструктуры, поскольку иногда может быть немного дорого создать выделенный кластер Kubernetes только для экспериментов. В этом случае рекомендуется использовать MLFlow.

Этап 2 - Контроль версий

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

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

Рекомендуемые инструменты:

  • Git: это бесплатная распределенная система управления версиями с открытым исходным кодом, которую можно использовать для управления версиями упакованных кодов. Одними из наиболее широко используемых веб-репозиториев, которые можно использовать для размещения и поддержки резервных копий кодов, могут быть GitHub, GitLab и т. Д.

Этап 3 - CI (непрерывная интеграция)

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

Поскольку мы будем использовать конвейеры Kubeflow в качестве среды Kubernetes для обучения и развертывания наших моделей, у нас будет несколько компонентов в нашем конвейере, таких как сбор данных, предварительная обработка данных, непрерывный тренажер, тренажер моделей и т. Д. Каждый компонент конвейера Kubeflow будет контейнер, и, следовательно, нам нужны сборки образов докеров для всех этих образов контейнеров с должным управлением версиями и поддерживаемыми в каком-то репозитории, таком как AWS ECR. Теперь, чтобы создать и отправить эти образы в соответствующие репозитории, нам нужно будет включить этот шаг в наш триггер CI.

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

Ниже я упомянул некоторые инструменты, которые должны быть частью набора инструментов на этом этапе.

Рекомендуемый инструмент:

  • Jenkins: это сервер автоматизации, который можно легко использовать для надежного создания образов докеров для нашего компонента конвейера Kubeflow, а также для запуска тестов над недавно зафиксированными кодами.

Фаза 4 - CT (непрерывное обучение)

После фазы 3 у нас будут последние сборки для всех компонентов, которые будет использовать обучающий конвейер Kubeflow, поэтому на этом этапе мы кратко детализируем некоторые из наиболее распространенных компонентов, которые могут быть частью большинства данных. научная проблема и как автоматически организовать обучение модели машинного обучения в кластере Kubernetes с помощью Kubeflow Pipelines.

Давайте посмотрим на некоторые часто используемые компоненты:

  • Сбор данных: этот компонент будет получать необработанные данные, которые могут храниться на любых облачных серверах, таких как сегмент AWS S3, облачное хранилище Google, BLOB-объект Azure и т. д.
  • Препроцессор данных: этот компонент будет предварительно обрабатывать полученные данные, используя любые шаги предварительной обработки, которые могли быть разработаны как этап повторения или этап экспериментов.
  • Continuous Trainer (CT): этот компонент решает, обучать модель или нет. Поскольку Kubeflow на данный момент не поддерживает триггеры на основе событий для запуска конвейера, нам нужно будет найти обходной путь, чтобы сделать это возможным. Одним из решений может быть использование поддерживаемого в настоящее время периодического триггера для периодической проверки некоторых облачных сегментов, таких как S3, например, есть ли какие-либо билеты на обучение, которые были подняты или нет? Если да, то CT может выполнить следующий компонент тренера модели, в противном случае он может пропустить обучение на это время.
  • Model Trainer: этот компонент берет предварительно обработанные данные и выполняет обучение модели на основе этих данных. Хотя конвейеры Kubeflow действительно предоставляют нам возможность отслеживать эксперименты и их многократные запуски, а также некоторую готовую поддержку визуализаций и всего остального, мы можем использовать MLFlow здесь, чтобы отслеживать параметры, метрики, а также самые эффективные модели. с легкостью. MLFlow обеспечивает хорошую интеграцию с MinIO, с помощью которой мы можем легко версировать наши модели, а также любые другие артефакты для S3, а позже можем даже использовать это для вывода через сам MLFlow или любые другие инструменты, такие как KFServing, в любой инфраструктуре. С пользовательским интерфейсом MLFlow можно даже напрямую просматривать артефакты. Таким образом, использование MLFlow внутри этого компонента действительно обеспечивает мощный способ мониторинга и визуализации экспериментов, а также одновременного обслуживания и управления версиями артефактов, за исключением использования самого Kubeflow для этой цели. Подводя итог, этот компонент будет отвечать за обучение модели, управление версиями модели и запись обучающей информации для последующего анализа прогона.

Теперь, чтобы организовать запуск конвейера, нам нужно будет предоставить конфигурацию .yml на предметно-ориентированном языке (DSL) интерфейсу конвейера Kubeflow, чтобы создать ресурсы для каждого из компонентов по мере необходимости и организовать запуск. Чтобы создать DSL для компонентов конвейера, Kubeflow предоставляет пакет SDK для Python под названием kfp, который мы можем использовать для генерации DSL. Пожалуйста, следуйте документации Kubeflow и kfp, чтобы начать с ним работать.

Ниже я упомянул некоторые инструменты, которые должны быть частью набора инструментов на этом этапе.

Рекомендуемые инструменты:

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

Этап 5 - CD (непрерывная доставка)

Как только мы закончим фазу 4, пора наконец запустить нашу обученную модель в производство. Теперь, чтобы получить действительно готовую к производственной среде среду, нам придется управлять сложностью автомасштабирования, работы в сети, проверки работоспособности и конфигурации сервера, чтобы внедрить в наши развертывания машинного обучения передовые функции обслуживания, такие как автоматическое масштабирование графического процессора, масштабирование до нуля и канареечное развертывание. Итак, для этого мы можем использовать собственный KFServing Kubeflow. KFServing обеспечивает бессерверный логический вывод в Kubernetes и предоставляет высокопроизводительные и простые интерфейсы абстракции для распространенных фреймворков машинного обучения, таких как TensorFlow, XGBoost, scikit-learn, PyTorch и ONNX. В зависимости от того, какие варианты использования мы решаем и какие фреймворки мы используем, мы можем использовать их соответствующие интерфейсы абстракции для создания нашего компонента вывода.

Эта часть конвейера Kubeflow может состоять преимущественно из двух компонентов:

  • Непрерывная доставка: этот компонент решит, развертывать модель или нет. Поскольку Kubeflow на данный момент не поддерживает триггеры на основе событий для запуска конвейера, мы снова можем использовать ранее обсуждавшийся CT-подобный обходной путь использования периодического триггера конвейера Kubeflow для периодической проверки некоторых облачных сегментов, таких как S3, который есть ли билет на развертывание, который был поднят или нет? Если да, то CD может выполнить следующий компонент вывода модели, в противном случае он может пропустить развертывание для этого.
  • Вывод модели: как следует из названия, это создаст развертывание модели KFServing через некоторый порт для обслуживания модели. Поскольку этот порт развертывания будет доступен только для внутренней среды, поэтому ни один запрос не сможет попасть туда. Чтобы решить эту проблему, нам нужно будет настроить шлюз Ingress с использованием шлюза Istio, а также для KFServing необходимо наличие Knative Serving. Следуйте инструкциям в официальном репозитории KFServing, чтобы найти необходимые условия для работы KFServing.

Ниже я упомянул некоторые инструменты, которые должны быть частью набора инструментов на этом этапе.

Рекомендуемые инструменты:

  • Kubeflow: мы будем использовать его для развертывания конвейера вывода.
  • MLFlow (необязательно): мы также можем использовать MLFlow для логической части в любой инфраструктуре.

Этап 6 - Мониторинг

После фазы 5 это будет заключительный этап, на котором мы сможем отслеживать жизненный цикл модели в процессе производства. Мы можем хранить журналы логических выводов в реальном времени с различными деталями об оценке достоверности для некоторых прогнозов, IP-адресах клиентов, использующих сервисы, и т. Д. В некоторую базу данных временных рядов, такую ​​как база данных притока, и визуализировать ее в режиме реального времени с помощью некоторых инструментов, таких как grafana. Это может объяснить любое неожиданное поведение и помочь в смягчении последствий как можно раньше.

Ниже я упомянул некоторые инструменты, которые должны быть частью набора инструментов на этом этапе.

Рекомендуемые инструменты:

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

Заключение:

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