Право на инфраструктуру для внедрения решений MLOps

В моем предыдущем посте я обсудил три ключевых компонента для создания комплексного решения MLOps, а именно конвейеры разработки данных и функций, обучение модели ML и переобучение модели конвейера ML, обслуживающей конвейеры. Вы можете найти статью здесь: Изучите ядро ​​MLOPS — Построение конвейеров машинного обучения. В конце моего последнего сообщения я кратко рассказал о том, что сложность решений MLOps может значительно различаться от одного к другому, в зависимости от характера проекта машинного обучения и, что более важно, от требуемой базовой инфраструктуры.

Поэтому в сегодняшнем посте я объясню, как требуются разные уровни инфраструктуры, определяю сложность решений MLOps, а также распределяю решения MLOPS по разным уровням.

Что еще более важно, на мой взгляд, категоризация MLOps по разным уровням упрощает внедрение MLOps для организаций любого размера. Причина в том, что не для каждого уровня MLOps требуется крупномасштабная инфраструктура онлайн-вывода, такая как Kubernetes, параллельные и распределенные платформы обработки данных, такие как Apache Spark, а также решения для потоковой передачи данных с малой задержкой, такие как Structured Streaming и Apache Flink. Следовательно, организациям с небольшими наборами данных и проектами пакетного вывода ML не нужно нанимать людей с этими специализированными навыками и настраивать сложную базовую инфраструктуру хранения и вычислений, но они все же могут правильно выполнять MLOps с существующими наборами навыков и значительно упрощенной инфраструктурой.

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

Во-первых, давайте поговорим об инфраструктуре, необходимой для запуска комплексного решения MLOps, для каждого из трех ключевых компонентов:

  • Конвейер проектирования данных и функций;
  • Конвейер обучения модели машинного обучения;
  • конвейер вывода модели машинного обучения;

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

Инфраструктура, необходимая для конвейеров проектирования данных и функций

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

  • Уровень 1. Когда объем данных может обрабатываться одной машиной, а задержка данных соответствует частоте пакетов, необходимая инфраструктура может быть такой простой, как локальный ноутбук или виртуальная машина в общедоступном облаке. Кроме того, вы можете использовать предложения облачной платформы как услуги (PaaS), такие как AWS Batch, AWS Lambda или Azure Functions, чтобы еще больше упростить управление инфраструктурой;
  • Уровень 2. Когда объемы данных не могут быть обработаны одной машиной и требуется параллельная и распределенная обработка данных, но задержка данных все еще может оставаться на частоте пакетной обработки, необходимая инфраструктура должна будет выходить за пределы одной машины, чтобы быть вычислительным кластером. , для установки распределенных вычислительных сред, таких как Apache Spark, и управления ими. Apache Spark — это решение с открытым исходным кодом. Организации могут запускать свои собственные вычислительные кластеры и использовать Spark с открытым исходным кодом для управления своими конвейерами разработки данных и функций. Тем не менее, большинство по-прежнему выбирают управляемую службу, такую ​​как Databricks, в качестве базовой инфраструктуры данных для крупномасштабных данных и рабочих нагрузок проектирования функций. Поставщики общедоступных облаков также предлагают сервисы для Spark, такие как AWS EMR и GCP Data Proc.
  • Уровень 3. В первых двух сценариях задержка данных остается на уровне пакетов. Однако, когда задержка данных должна быть очень низкой, требуются совсем другие наборы инфраструктуры. Требуются как минимум управляемая событиями очередь сообщений и механизм потоковой передачи. Чтобы добиться гораздо меньшей задержки, обычно требуется служба очереди сообщений для захвата потоковых данных на лету вместо сохранения данных в системе хранения. Для служб очередей сообщений существуют решения с открытым исходным кодом, такие как Apache Kafka; Существуют также коммерческие управляемые сервисы, такие как Azure Event Hub, AWS Kinesis Data Stream и Confluent. Помимо службы очереди сообщений, также очень необходим надежный механизм потоковой передачи, чтобы добиться низкой частоты потребления данных в нисходящем направлении. Механизмы потоковой передачи с открытым исходным кодом включают структурированную потоковую передачу Apache Spark и Apache Flink, а также Apache Beam. Конечно, существуют и коммерческие предложения для потокового движка, такие как Databricks, AWS Kinesis Data Analytics, а также GCP Dataflow.

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

Инфраструктура, необходимая для конвейеров обучения модели машинного обучения

В зависимости от размера обучающих данных и требуемого времени (SLA) для подготовки обучаемого режима к использованию в производственной среде инфраструктура для обучения модели может быть разделена следующим образом:

  • Уровень 1. Когда объем обучающих данных подходит для памяти одной машины, а общее время обучения не превышает SLA, требуемого для производственной среды, достаточно иметь одну машину для обучения модели. В зависимости от формата обучающих данных может потребоваться машина с графическим процессором. Например, если ваши тренировочные данные структурированы и имеют числовой характер, обычно достаточно компьютера с процессором. Однако если данные обучения неструктурированы, например изображения, предпочтительной инфраструктурой обучения будет машина с графическим процессором.
  • Уровень 2 – когда обучающие данные слишком велики, чтобы поместиться в память одной машины, или даже если размер обучающих данных может поместиться в памяти одной машины, но это занимает больше времени, чем требуется SLA. чтобы завершить работу по обучению, это время, когда компаниям необходимо развернуть учебные кластеры для параллельного и распределенного обучения модели машинного обучения на нескольких узлах. Однако выполнение распределенного обучения модели машинного обучения на нескольких узлах создает множество новых сложностей, таких как планирование задач на нескольких компьютерах, эффективная передача данных и восстановление после сбоев компьютеров. К счастью, существует несколько библиотек с открытым исходным кодом для решения этих дополнительных сложностей, возникающих при обучении на нескольких узлах, и обеспечения относительной простоты учебных заданий для специалистов по данным, даже когда им необходимо распределять задания. Эти библиотеки с открытым исходным кодом включают Ray для масштабирования рабочих нагрузок Python ML, Horovod для распределенной обучающей среды глубокого обучения для TensorFlow, Keras, PyTorch и Apache MXNet и Dask для масштабирования библиотек Python, включая библиотеки Python ML.

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

Как известно, машинное обучение — чрезвычайно динамичная область. Чтобы выполнить задание по обучению модели, специалистам по данным необходимо установить довольно много библиотек с открытым исходным кодом, включая Pandas, Numpy, Matplotlib, Seaborn, Plotly, Scikit Learn, Tensorflow, Keras, Pytorch, mlflow и так далее. Поэтому большинство поставщиков общедоступных облаков или конкретных поставщиков данных и ИИ (например, Databricks) предоставляют предварительно настроенную среду выполнения машинного обучения, включающую все эти популярные библиотеки машинного обучения, чтобы сэкономить специалистам по данным значительное время на установку и обслуживание этих библиотек. Поэтому большинство организаций строят свою инфраструктуру обучения машинному обучению, используя облачные сервисы. Популярными сервисами машинного обучения в облаке являются AWS Sagemaker, Azure Machine Learning Workspace, GCP Vertex AI, а также среда выполнения машинного обучения Databricks.

Инфраструктура, необходимая для конвейеров вывода моделей машинного обучения

В зависимости от частоты вывода модели и объемов запросов на вывод инфраструктура, необходимая для запуска конвейеров вывода модели ML, выглядит следующим образом:

  • Уровень 1. Когда частота вывода модели является пакетной, а объемы данных для вывода модели могут обрабатываться одной машиной, обученную модель можно загрузить в одну машину для пакетных прогнозов, вызвав функцию прогнозирования данных, которая обычно хранится как фрейм данных Pandas;
  • Уровень 2 — когда частота вывода модели является пакетной, но объем данных не может управляться на одном компьютере, необходимо настроить кластер для использования сред распределенных вычислений, таких как Apache. Искра. Например, обученную модель машинного обучения можно загрузить как пользовательскую функцию Spark (UDF) и применить UDF к фрейму данных Spark для прогнозирования параллельной модели.
  • Уровень 3. Когда частота вывода модели имеет низкую задержку, а объем данных достаточно велик, становится необходимым потоковый вывод. Как и на уровне 2, требуется вычислительный кластер. Кроме того, необходимо также использовать механизм потоковой передачи для предсказания модели, чтобы удовлетворить требование низкой задержки. В этом случае используются популярные механизмы потоковой передачи — структурированная потоковая передача Apache Spark и Apache Flink.
  • Уровень 4. Когда вывод модели выполняется в режиме онлайн, что означает, что модель обычно упакована как конечные точки REST API, но объем запросов API невелик и может обрабатываться одной машиной, требуемая инфраструктура, как правило, представляет собой ЦП с одним узлом. виртуальная машина в облаке. Поставщики общедоступных облаков и поставщики данных/ИИ имеют управляемые службы для этого типа обслуживания моделей. Например, у Databricks есть бессерверная конечная точка, в которой клиентам не нужно беспокоиться о настройке обслуживающей инфраструктуры, и все, что им нужно сделать, — это создать экземпляр конечной точки модели. Другие также имеют аналогичные предложения.

Одно замечание, которое нужно сделать, прежде чем мы перейдем к уровню 5: онлайн-вывод отличается от потокового вывода, когда обученная модель машинного обучения по-прежнему загружается как функция Python, а не как конечная точка REST. Оба они имеют низкую задержку, но онлайн-вывод должен осуществляться в режиме реального времени.

  • Уровень 5 — когда вывод модели находится в режиме онлайн, а объем запросов API является большим (это означает, что количество запросов в секунду (QPS) чрезвычайно велико для одной единственной конечной точки), необходимо настроить кластерную инфраструктуру, такую ​​​​как Kubernetes. , для распределенного вывода. Обычно используемый метод заключается в том, что обученная модель упаковывается в образ контейнера и регистрируется в реестре контейнеров, таком как AWS Elastic Container Registry, Azure Container Registry или GCP Container Registry. Затем эти зарегистрированные образы обученных моделей будут загружены и развернуты в Kubernetes для крупномасштабного и распределенного вывода моделей. У каждого общедоступного облака есть свое предложение для управляемой службы Kubernetes.

Заключение

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

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

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

Если вы хотите получать больше руководств, подробных сведений и идей о современном и эффективном стеке данных и ИИ, подпишитесь на мою бесплатную рассылку — Эффективные данные и стек ИИ. , Спасибо!

Примечание: Если вы еще не стали участником Medium и хотите получить неограниченный доступ к Medium, вы можете зарегистрироваться по моей реферальной ссылке! Я получу небольшую комиссию бесплатно для вас. Большое спасибо за вашу поддержку!