Data Orchestration Service в Spotify
В этой статье поговорим про то, как устроена оркестрация данных в Spotify.
В Spotify запускают 20,000 batch data пайплайнов в более чем 1000 репозиториях, которые поддерживает 300+ команд ежедневно.
Большинство пайплайнов ранилось на 2х тулах: Luigi (для Python сервисов) и Flo (для Java сервисов). В 2019 data orchestration команда в спотифай решила уйти от этих тулов. В этой статье рассмотрим почему команда ушла от них и что в итоге выбрала как альтернативу.
Какой был стек оркестрации
Вместе с Luigi и Flo дефайнились workflows как рекурсивно зависимые задачи. Все различные задачи, библиотеки и логика упаковываются в образ Docker, который деплоился в Styx с точкой входа в root таску. Styx занимается планированием и выполнением, поэтому, когда нужно, он запустит образ Docker в нашем кластере GKE.
Во время выполнения обнаруживается граф зависимостей, и задачи выполняются в определенном порядке. Таски могут запускать dataflow или BigQuery джобы и паблишить данные в разных местах.
Проблемы, которые решали в Spotify
Luigi и Flo поставляются в виде библиотек, которые затем используют пользователи. Есть несколько проблем с этим подходом:
- Бремя обслуживания: нам нужно реализовать, поддерживать и обновлять функции в двух разных библиотеках, предлагающих одинаковые возможности.
- Нагрузка на поддержку: нам нужно отправлять обновления всем пользователям, но пользователи не всегда обновляются до последней версии. Это затрудняет апдейты, так как для команды платформы, деплой фиксов и новых инструментов для всего "парка" из более чем 1000 репозиториев, а также для растущего числа репозиториев.
- Отсутствие insights: workflow container — это черный ящик для платформы, и собирать информацию можно только по инсайтам. Это приводит к значительным накладным расходам, поскольку часть времени кластера GKE тратится на пуллинг отсутствующих зависимостей.
Приоритетными целями для оркестровки следующего поколения в спотифай были и остаются:
- Делать апгрейды максимально простыми. Передавать максимально функционал платформ командам , это позволяет тимам отвечающим за платформу овнить большинство функционала. Это позволяет автоматически добавлять функции и фиксы всем сервисам.
- Функций автоматизации платформы. Пример таких задач: downstream backfill triggering, уведомление downstream консюмеров про фейлы и делеи в вокрфлоу
Как искали подходящее решение в Spotify?
При ресерче учитывали следующие факты:
- Нужно ли временные затраты на миграцию существующих вокфлоу
- Сколько нужно времени, чтобы уйти в прод (time to market)
- Время на обслуживание, например cloud based решение или что-то self-managed.
- Возможность расширения решения
- Поддержка нескольких языков программирования.
Flyte: решение, которое Spotify выбрал
Spotify пришел к выводу, что Flyte был лучшим вариантом из-за его расширяемости для интеграции инструментов Spotify, поддержки нескольких языков и масштабируемости.
Причины по которым был выбран Flyte:
- Имеет ту же модель сущностей, что и Luigi и Flo, что упрощает миграцию.
- Позволяет совместное повторное использование тасок и workflow.
- Есть SDK для тонкого клиента, перемещая больше функционала на серверную часть: это делает обслуживание всей платформы намного проще, чем существующее предложение с двумя библиотеками (Python, Java), обе из которых содержат логику.
- Можно расширить, чтобы предоставить больше пакетов SDK для оркестровки.
- Имеет расширяемый бэкэнд для поддержки различных типов задач.
- Это существующий инструмент с платформенным подходом, поэтому нам не нужно разрабатывать сервис самостоятельно.
- Масштабируется и "закален в боях".
- Проект с открытым исходным кодом.
Диаграмма как Flyte интегрируется в экосистему Spotify
Экшины описанные в вокфлоу видны для команды платформы, так же их можно зарегистрировать в Flyte Admin и в системе Спотифай Styx. Что позволило сделать миграцию плавной.
