от Джош Баер и Сэмюэл Нгахане

Когда Spotify был запущен в 2008 году в Швеции и в 2011 году в США, люди были поражены тем, что они могли мгновенно получить доступ почти ко всему музыкальному каталогу мира. Это было похоже на волшебство, и в результате любители музыки закопались и организовали этот контент в миллионы уникальных плейлистов. Сначала наши пользователи полагались на плейлисты и элементарные функции рекомендаций, такие как функция связанных исполнителей, для поиска новой музыки. Со временем Spotify стал более продвинутым в наших рекомендациях, а любимые пользователями функции, такие как Discover Weekly, начали значительно улучшать поиск новой музыки и общее впечатление от Spotify (подробнее об этом путешествии в этом выступлении). Больше пользователей и больше функций привели к появлению большего количества систем, которые полагались на машинное обучение для масштабирования выводов по растущей пользовательской базе.

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

В этом сообщении в блоге будет описан наш «извилистый» путь, в ходе которого были созданы строительные блоки для нашего платформенного опыта машинного обучения, и, в частности, то, как Spotify использует TensorFlow Extended (TFX) и Kubeflow в наших системах Paved Road для машинного обучения.

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

У Spotify были основные системы машинного обучения (такие как Discover Weekly и наша инфраструктура поиска) задолго до того, как у нас появилась команда, занимающаяся созданием инструментов для команд машинного обучения. Из-за этого мы не хотели переворачивать таблицы, сообщая существующим системам, что им придется переписывать свои задания, потому что в городе появился новый шериф по инструментам. Мы решили встретиться с нашими командами там, где они были, создав коннекторы среди самых популярных активно используемых платформ машинного обучения, вместо того, чтобы диктовать командам, какую платформу использовать.

В то время наши инструменты обработки данных активно использовали язык Scala — особенно Scio (предыдущий пост в блоге), нашу библиотеку обработки данных с открытым исходным кодом, созданную на основе Apache Beam. Чтобы поддержать переход от разработки данных к машинному обучению, мы создали такие библиотеки, как Featran для разработки функций, Noether для оценки моделей и библиотеку Zoltar для подключения обученных моделей к нашей библиотеке на основе JVM Apollo, которая используется почти исключительно в производственных услугах Spotify.

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

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

Вторая итерация: стандартизация Tensorflow Extended (TFX)

Одна важная вещь, которую мы сделали во время первой итерации, — это создание чего-то, что мы назвали «Мощеная дорога для машинного обучения в Spotify». Концепция проста: продуманный набор продуктов и конфигураций для развертывания комплексного решения для машинного обучения с использованием рекомендованной нами инфраструктуры, предназначенного для команд, начинающих свой путь в области машинного обучения. По мере того, как мы развивали наши инфраструктурные решения и продукты, дорога с твердым покрытием будет развиваться и всегда будет отражать новейшее состояние.

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

  • Было сложно переключаться между Python и Scala.
  • Scala было трудно использовать специалистам по данным, которые использовали Python на протяжении большей части своей карьеры.
  • Было сложно обеспечить правильное объединение версий функций, конфигураций и моделей в единое целое.

В то время мы знали о документе TFX Google и были впечатлены решениями и их влиянием. Хотя большая часть инструментов TFX еще не была доступна за пределами Google, некоторые важные основополагающие элементы, такие как TFRecord и tf.Example, были доступны. Короче говоря, они обеспечивают хранилище данных и формат сообщений, предназначенный для рабочих нагрузок машинного обучения. Пытаясь постепенно перенаправить инженеров Spotify ML на меньший набор дорог для ML, мы подумали, что хорошим первым шагом будет стандартизация формата хранения между этапами рабочего процесса ML — по сути, согласование интерфейса между этапами, чтобы что мы могли бы создавать соединители / мосты для общих инструментов, используемых различными рабочими нагрузками Spotify.

Мы быстро создали соединители из наших инструментов рабочего процесса машинного обучения и внутренних библиотек, которые поддерживали связывание этих данных и форматов сообщений с общими обучающими библиотеками, такими как XGBoost, Tensorflow и scikit-learn.

Ранним преимуществом использования TFRecord/tf.Example была простая поддержка проверки данных Tensorflow (TFDV) — одного из первых компонентов с открытым исходным кодом, предоставленных Google из их документа TFX. TFDV позволил нашим инженерам по машинному обучению лучше понимать свои данные во время разработки модели и легко обнаруживать распространенные проблемы, такие как перекосы, ошибочные значения или слишком много нулей в производственных конвейерах и сервисах.

Вскоре после этого команда TFX выпустила гораздо больше своих внутренних инструментов, включая такие компоненты, как Tensorflow Transform, Tensorflow Model Analysis и Tensorflow Serving. Оценка этих компонентов показала, что они были сопоставимы по производительности с нашими инструментами на основе Scala и предлагали привлекательные функции, которые мы еще не создали. В то время это был не полный набор инструментов, но он был многообещающим, и мы подозревали, что это еще не все — разговор с некоторыми членами команды TFX подтвердил это. Мы решили направить Spotify ML и нашу Paved Road на стандартизацию инструментов TFX.

Благодаря инструментам TFX у нас была проложенная дорога для машинного обучения! Тем не менее, в нем все еще было много пробелов:

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

Мы начали обсуждать эти пробелы с Google Cloud в начале 2018 года. Они были заинтригованы и только начали создавать продукт, который мог бы удовлетворить некоторые из этих потребностей. Этот продукт стал Kubeflow Pipelines.

Третья итерация: знакомство с конвейерами Kubeflow

Совсем недавно мы начали переключать команды на Kubeflow Pipelines (KFP), платформу с открытым исходным кодом для определения, развертывания и управления сквозными рабочими процессами машинного обучения. Он превращает компоненты рабочего процесса машинного обучения в контейнеры Docker, чтобы обеспечить переносимость и воспроизводимость при управлении ресурсами и оркестровке рабочих нагрузок через Kubernetes.

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

Во-первых, наши усилия по стандартизации TFX поддерживаются Kubeflow Pipelines. Как объяснялось выше, наши пользователи уже были знакомы с TFX и его компонентами, поэтому им не нужно было изучать еще один способ выполнения основных задач машинного обучения.

Во-вторых, KFP SDK позволяет создавать и совместно использовать компоненты: автономные наборы кода, которые выполняют один шаг в конвейере (например, предварительная обработка данных, преобразование данных, обучение модели). Команды, которым нужны настраиваемые компоненты, теперь создают их на основе общего интерфейса. Это значительно упрощает для команд совместное использование компонентов и уменьшает количество «изобретенных заново колес».

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

Чтобы поддержать использование Kubeflow и KFP в Spotify, мы развернули управляемые кластеры Kubeflow и создали пакет разработки программного обеспечения Python (SDK) и интерфейс командной строки (CLI).

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

Вот некоторые функции наших кластеров, которые мы добавили поверх стандартного развертывания Kubeflow:

  • Служба управляемой базы данных GCP Cloud SQL для хранения метаданных конвейера вместо запуска базы данных MySQL по умолчанию KFP в кластере.
  • Интеграция с общим VPC (Виртуальное частное облако), позволяющая нескольким проектам GCP взаимодействовать друг с другом через общую сеть VPC.
  • Предопределенные пулы узлов, подходящие для стандартных задач машинного обучения, задач с интенсивным использованием памяти или обучения GPU.

Для получения более подробной информации о построении и управлении нашими кластерами ознакомьтесь с презентацией, которую мы представили на KubeCon North America 2019: Создание и управление централизованной платформой Kubeflow в Spotify.

В ответ на интерес, проявленный на KubeCon, мы открыли модуль Terraform для настройки наших кластеров GKE на https://github.com/spotify/terraform-gke-kubeflow-cluster. .

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

  • Компоненты KFP и TFX нельзя было смешивать и сочетать в одном конвейере.
  • HTML-артефакты из компонентов TFX, например созданные с помощью анализа моделей TensorFlow, не могли отображаться в веб-интерфейсе KFP.
  • Оркестратор KFP для TFX не поддерживает кэширование, а это означает, что конвейер необходимо будет полностью перезапустить, даже если, например, выйдет из строя только последний компонент.
  • Компонент TFX нельзя было легко расширить, а это означает, что пользователи не могли добавлять собственные зависимости времени выполнения для таких компонентов, как Trainer или Transformer.

Кроме того, мы разработали внутреннюю библиотеку Python, в значительной степени основанную на SDK TFX и KFP, чтобы устранить разрыв между ними. Он имеет следующие особенности:

  • Оба SDK унифицированы, близко соответствуют компонентам в стиле TFX и их богатой системе метаданных, обеспечивая при этом дополнительную гибкость, предлагаемую KFP.
  • Поддержка кэширования была добавлена ​​путем переработки оркестровки KFP для взаимодействия с метаданными ML (MLMD), чтобы воспользоваться преимуществами встроенного кэширования TFX.
  • Визуализации TFX, такие как статистика набора данных и показатели оценки модели, могут отображаться в пользовательском интерфейсе KFP.
  • Интеграция с существующей инфраструктурой данных, которая управляет обнаружением данных, публикацией и контролем доступа.
  • Добавление пользовательских компонентов и внешних зависимостей Python стало проще
  • Набор общих компонентов, охватывающий большинство вариантов использования наших клиентов, эффективно сокращающий шаблонный код и абстрагирующий детали от пользователя (например, обучение XGBoost, выборка данных с помощью Apache Beam).

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

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

Имея этот контролируемый слой между пользователем и Kubeflow, мы можем легко управлять обновлениями Kubeflow и TFX.

Мы запустили альфа-версию нашей платформы в августе, и на данный момент мы уже увидели около 100 пользователей в общей сложности 18 000 запусков. Инженеры по машинному обучению теперь могут сосредоточиться на разработке и анализе своих экспериментов по машинному обучению, а не на создании и обслуживании собственной инфраструктуры, что сокращает время от прототипирования до производства. На самом деле, предварительный анализ показывает, что некоторые команды уже проводят в 7 раз больше экспериментов!

Уроки выучены

Создание инфраструктуры вместе с нашими пользователями помогает нам работать быстрее

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

Эволюция инфраструктуры сказывается на ваших пользователях

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

Стоя на плечах гигантов

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

Что дальше?

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

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

Оставайтесь с нами, чтобы узнать больше о том, как мы решаем эту проблему для нашей организации! И мы хотели бы поговорить с вами (или нанять вас), если у вас есть хорошие подходы в этой области!

Благодарности

Все вышеперечисленное стало результатом многолетней совместной работы множества разных команд Spotify. Нашим самым большим достижением является то, как разные области объединились для решения проблем в целом. Мы особенно хотели бы поблагодарить команду под названием Hyperkube за создание третьей итерации и многих людей, которые направили нас на правильный путь: Эндрю Мартина, Биндию Калра, Дэмиена Тардье, Эдварда Ньюетта, Эда Моргана, Эрика Саймона, Гэндальфа Эрнандеса, Молли Холдер, Джозеф Коутеруччо, Кеши Дай, Марк Ромейн, Марк Толлин, Майя Христакева, Марк Кох, Мартин Лоран, Мэтт Браун, Рафал Войдила, Ромен Йон и Райан Клаф!

Сэмюэл Нгахане — штатный инженер, а Джош Баер — руководитель группы по платформе машинного обучения Spotify.

Первоначально опубликовано на http://labs.spotify.com 13 декабря 2019 г.