Автор Джулиан де Рюйтер, инженер по машинному обучению

В этой записи блога вы узнаете, как мы спроектировали и создали платформу машинного обучения (ML) на Google Cloud Platform (GCP), чтобы дать возможность специалистам по обработке и анализу данных Adevinta быстро и независимо разрабатывать комплексные решения для обработки данных. Мы пройдем различные этапы этого путешествия, от того, как мы спроектировали платформу, с глубоким погружением в получившуюся архитектуру, до того, как платформа используется на практике.

Расширение возможностей науки о данных с помощью новой платформы

Прежде чем стать частью Adevinta, eBay Classifieds Group (eCG) использовала устаревший локальный стек Hadoop для разработки решений для обработки данных. Работа над наукой о данных поверх этого стека часто была медленным и разочаровывающим процессом из-за негибкой рабочей среды и отсутствия современных технических средств (например, для организации обучения моделей, отслеживания версий моделей).

Чтобы решить эту проблему, мы использовали миграцию GCP для всей eCG, чтобы создать современную платформу самообслуживания, которую мы могли бы предоставить в качестве вспомогательной услуги другим командам внутри компании. Цель этой платформы заключалась в том, чтобы предоставить специалистам по данным (DS) и инженерам по машинному обучению (MLE) возможность независимо разрабатывать продукты для обработки данных на протяжении всего жизненного цикла разработки (показано ниже), повышая их владение продуктом и сокращая время, затрачиваемое на ожидание других команд во время разработки. циклы.

Планирование процесса науки о данных

Чтобы разработать платформу, соответствующую требованиям наших внутренних команд, мы сначала собрали отзывы об их существующих процессах и о том, какие компоненты потребуются для поддержки их (предполагаемого) рабочего процесса. Затем мы сопоставили эти процессы с упрощенной версией рабочего процесса обработки данных от AI Infrastructure Alliance (AIIA), чтобы создать общее представление о процессе обработки данных (и вспомогательных компонентах) для разных команд:

Это представление определило три различных этапа, необходимых для большинства продуктов науки о данных:

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

Каждый из этих этапов, как правило, различался инструментами (например, Spark для этапа данных, Python с Tensorflow для этапа обучения) и техническими требованиями, такими как базы данных или распределенные кластеры для обработки данных, большие виртуальные машины (ВМ) для обучения. Модели машинного обучения и сетевые конечные точки для развертывания моделей в качестве API.

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

  • Среды исследования и разработки для DS и MLE, которые можно использовать для исследования данных и разработки программного обеспечения для своих продуктов обработки данных.
  • Конвейеры машинного обучения и обработки данных для координации работы, выполняемой на разных этапах.
  • Хранилище метаданных для отслеживания происхождения созданных артефактов (например, наборов данных, моделей, показателей), чтобы мы всегда знали, как была обучена данная модель и какова ее производительность.
  • Возможности мониторинга, чтобы мы могли отслеживать производительность наших продуктов и конвейеров, чтобы быстро выявлять любые проблемы, которые могут возникнуть.
  • Возможности хранения для хранения данных и артефактов моделей.

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

Комплектация компонентов платформы

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

  • Простота использования. Насколько легко получить доступ к сервису для пользователей? Это что-то, что они уже знают, или у этого есть крутая кривая обучения?
  • Гибкость. Можем ли мы легко внедрить поддержку новых модных (ML) платформ, которые пользователи могут захотеть использовать? Легко ли пробовать новое?
  • Масштабируемость. Хорошо ли масштабируется сервис для решения задач разного масштаба с точки зрения производительности и стоимости?
  • Удобство сопровождения. Нуждается ли сервис в значительной операционной поддержке или это делается за нас? Сколько пользовательского клея необходимо для интеграции сервиса в наш рабочий процесс?

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

  • Основа данных — GCS и BigQuery, так как обе службы предоставляют масштабируемые и доступные варианты хранения наборов данных любого размера. BigQuery предпочтительнее для структурированных наборов данных, поскольку он позволяет пользователям легко запрашивать и преобразовывать данные с помощью SQL.
  • Мониторинг — мониторинг Google Cloud, обеспечивающий надежную поддержку регистрации показателей и предупреждений с готовой интеграцией для большинства сервисов Google.
  • Этап данных — Dataproc (Spark) и BigQuery, при этом Spark используется в качестве решения по умолчанию для преобразования (больших) данных, а BigQuery SQL обеспечивает дополнительную удобную альтернативу для данных, хранящихся в BigQuery.
  • Этап обучения —обучение Vertex AI, которое предоставляет контейнерный (бессерверный) уровень вычислений для простого масштабирования учебных заданий для самых разных платформ машинного обучения.
  • Этап развертывания — Vertex AI Serving или Google Cloud Run, где Vertex AI обещает готовое развертывание моделей из популярных платформ машинного обучения в сочетании с мониторингом для обнаружения перекосов функций и дрейфа данных. Google Cloud Run предоставляет более простую, но, возможно, более экономичную альтернативу.
  • Конвейеры обработки данных — Google Composer (управляемый поток воздуха) или DBT, где Composer используется для организации рабочих процессов между различными службами, а DBT представляет собой более простую альтернативу для управления преобразованиями на основе SQL в BigQuery.
  • Конвейеры машинного обучения — Vertex AI Pipelines, который предоставляет интерфейс на основе Python (на основе Kubeflow Pipelines) для выполнения заданий обучения в воспроизводимых конвейерах машинного обучения вместе с возможностями управляемых вычислений и отслеживанием происхождения созданных артефактов.
  • Исследование и разработка —Vertex AI Workbench, поскольку он обеспечивает удобный подход к развертыванию настраиваемых виртуальных машин, к которым пользователи могут получить доступ с помощью знакомых IDE, таких как JupyterLab (для исследования) и Visual Studio Code (для разработки программного обеспечения).

В целом это дало нам следующую карту технологий для нашей платформы:

Сборка платформы

Следующим шагом после выбора нашего короткого списка технологий было объединение этих фрагментов в комплексный пользовательский интерфейс. Для этого мы сосредоточились на разработке платформы с учетом двух точек зрения: пользователя (разработчика) и модели (варианта использования):

  • С точки зрения пользователя, каждому разработчику (DS/MLE) предоставляется собственная виртуальная машина для разработки в Vertex Workbench. Эта виртуальная машина предоставляет инструменты, необходимые для изучения данных и разработки информационных продуктов, например. JupyterLab, VSCode, Python, Docker). Пользовательские файлы хранятся на диске данных виртуальной машины, и их можно опционально использовать совместно с другими пользователями через пользовательскую корзину GCS.
  • С точки зрения варианта использования каждая модель снабжена ресурсами для хранения всех наборов данных и артефактов, характерных для модели. Эти ресурсы включают сегменты GCS для ввода, вывода и промежуточных артефактов (например, промежуточных наборов данных, обученных моделей), а также дополнительный набор данных BigQuery для хранения структурированных данных.

При работе на платформе пользователям предоставляется доступ к ресурсам через служебную учетную запись пользователя, привязанную к их виртуальной машине. Это позволяет им (например) запрашивать данные из внешних наборов данных, отправлять пакеты Python и образы Docker в общий реестр артефактов и выполнять задания по обучению/выводу с использованием Vertex Pipelines.

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

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

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

Применение платформы на практике

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

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

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

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

После того, как проекты пройдут стадию идеи/исследования, пользователи могут приступить к разработке кода своей модели как части пакета Python с использованием кода Visual Studio (показан ниже), который автоматически встраивается в контейнер Docker с помощью сценариев развертывания, содержащихся в нашем шаблоне проекта. Этот переход от блокнотов к пакету имеет несколько преимуществ, в том числе упрощает отслеживание, тестирование и обслуживание кода благодаря автоматизированным проверкам качества кода.

Помимо создания пакета Python, пользователи также могут автоматизировать различные шаги, необходимые для запуска своей модели, путем создания конвейера машинного обучения с помощью SDK Kubeflow Pipeline. Этот пакет SDK позволяет пользователям определять конвейер как последовательность шагов, где каждый шаг выполняет определенную функцию, такую ​​как выборка обучающих данных из GCS/BigQuery, обучение модели и оценка производительности модели. Для обычных операций (запрос BigQuery, создание кластера Dataproc, отправка задания Spark и т. д.) шаги можно определить с помощью готовых компонентов, предоставленных нами (командой платформы). Шаги, специфичные для проекта, реализуются путем вызова контейнера Docker, созданного из пакета Python проекта.

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

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

Выводы

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

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

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