Введение

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

При наличии вычислительных заданий на таких движках, как Spark, Hive, Trino, и большого количества кода Python для обработки данных и платформ машинного обучения оркестровка рабочего процесса превращается в сложную задачу. Оркестрация — это механизм, который объединяет вычислительные задачи и выполняет их как конвейер данных, где конвейер данных обычно выглядит как граф.

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

Исторически Lyft использовала два механизма оркестровки: Apache Airflow и Flyte. Flyte, созданный Lyft с открытым исходным кодом, теперь является проектом Linux Foundation высшего уровня.

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

И Flyte, и Airflow являются важными элементами инфраструктуры Lyft и имеют много общего:

  • поддержка Python для написания рабочих процессов
  • запускать рабочие процессы по расписанию или ad-hoc
  • обеспечить интеграцию с вычислительными движками
  • хорошо работают для пакетной обработки и не подходят для потоковой обработки

Мы поделились своим опытом использования Airflow и Flyte в предыдущих постах. В этом посте мы сосредоточимся на сравнении их реализации в Lyft. Сначала мы углубимся в архитектуру и суммируем ее преимущества и недостатки. Затем мы расскажем, почему Lyft решила создать Flyte, уже внедрив Airflow. В конце мы делимся своими мыслями о паттернах и антипаттернах каждого движка и приводим примеры использования.

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

Расход воздуха

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

Основные проблемы, которые Airflow решает в Lyft, — это организация ETL путем маршалинга SQL-запросов для вычислительных механизмов, таких как Hive и Trino.

Концепции воздушного потока

Для лучшего контекста, вот несколько ключевых концепций Airflow:

  • Задача: единица вычисления. Задачи внутри одной DAG могут выполняться последовательно или параллельно.
  • DAG: направленный ациклический граф — рабочий процесс, состоящий из задач и зависимостей между ними.
  • Оператор: архетип задачи; например, выполнение Python/Bash или интеграция с вычислительным движком, таким как Hive или Trino.
  • Sensor: подкласс оператора, ответственного за опрос источника данных и запуск выполнения DAG. Самый популярный датчик в Lyft — датчик разделов, который опрашивает таблицы Hive и срабатывает при добавлении нового раздела данных.

Датчик раздела постоянно опрашивает таблицу «event_rides» и срабатывает, когда появляются поездки предыдущего дня. Затем рассчитывается статистика поездок и сохраняется в таблице STAGE. После проверки правильности результатов данные меняются местами с предыдущей таблицей PROD.

Пожалуйста, обратитесь к документации для получения более подробной информации об Airflow и полного списка операторов.

Архитектура воздушного потока в Lyft

Как показано на приведенной выше диаграмме, основными компонентами архитектуры являются:

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

В Lyft мы используем Apache Airflow 1.10 с исполнителем на основе распределенной очереди задач сельдерей. Это централизованный монолитный пакетный планировщик с количеством рабочих процессов, которые можно масштабировать по горизонтали. На всех машинах должен быть одинаковый набор библиотек с похожими версиями. Важно отметить, что рабочие процессы выполняют задачи как отдельные процессы на одних и тех же машинах. В этой статье мы делимся нашим опытом, связанным с версией 1.10 Airflow, поскольку мы все еще находимся в процессе перехода на версию 2.0+.

Преимущества воздушного потока

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

Недостатки воздушного потока

Ниже вы можете найти недостатки Airflow, которые мы сочли наиболее существенными для нас.

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

Кроме того, стоит упомянуть о некоторых нюансах:

  • В Lyft все группы обеспечения доступности баз данных относятся к одному и тому же экземпляру Airflow, а логическое рабочее пространство используется всеми командами. Есть команды, которые работают с конфиденциальными данными и предъявляют особые требования к безопасности. Разделение границ безопасности возможно только при поддержке отдельного набора воркеров с разными ролями IAM. Постоянное выделение отдельных рабочих процессов усложняет поддержание более детальной изоляции разрешений для каждого варианта использования.
  • Airflow не управляет потоком данных между задачами, последовательность задач должна быть определена явно. Поскольку Airflow не поддерживает данные, сложно реализовать кэширование, поскольку оно не поддерживается. Наконец, Airflow предназначен только для Python и не позволяет писать рабочие процессы на других языках.

Флайт

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

Apache Airflow — хороший инструмент для ETL, и не было никаких причин изобретать его заново. Целью Flyte было не заменить Airflow, а дополнить экосистему инструментов компании. Были классы проблем, в которых мы были ограничены при использовании Airflow:

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

В Lyft Flyte используется для задач, требующих пользовательских библиотек и изоляции вычислений, таких как ресурсоемкий Python, задания Spark и ML-фреймворки.

Концепты Flyte

Для лучшего контекста, вот несколько ключевых концепций Flyte:

  • Задача: исполнительный модуль с изолированной средой с библиотеками и пакетами. Задачи могут быть кодом Python, распределенными заданиями Spark, вызовами вычислительного механизма, такого как Trino или Hive, или выполнением любого контейнера Docker.
  • Рабочий процесс: набор задач и зависимостей между ними.
  • Проект: набор рабочих процессов.
  • Домен: логическое разделение рабочих процессов в проекте: разработка, подготовка, производство.
  • План запуска: экземпляр рабочего процесса, который может быть привязан к cron и может использовать предварительно настроенные входные данные.

Пример рабочего процесса, состоящего из двух задач Spark («агрегирование поездок» и «агрегирование телеметрии»), объединяет данные и создает выходные данные для обучения модели. Задача обучения модели содержит пользовательский код Python и библиотеку XGBoost, упакованную в виде образа Docker. Конечным результатом является артефакт модели.

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

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

Архитектура Flyte в Lyft

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

Архитектура Flyte основана на операторах Kubernetes и настраиваемых определениях ресурсов (CRD). Хороший пример — Spark на Kubernetes.

Как показано на диаграмме выше, основными компонентами архитектуры являются:

  • Flyte admin: служба, которая регистрирует и сохраняет рабочие процессы в базе данных метаданных. При запуске выполнения он создает ресурсы рабочего процесса Flyte (определения пользовательских ресурсов, CRD) в кластере Kubernetes и записывает историю выполнения.
  • Пропеллер Flyte: оператор Kubernetes, который опрашивает API Kubernetes в поисках недавно созданных ресурсов рабочего процесса Flyte (CRD) и запускает модули или другие операторы, такие как Spark. Он также обрабатывает сбои и повторные попытки, а также выполняет регулирование и постановку в очередь, если в кластере Kubernetes не хватает ресурсов.
  • Панель инструментов Flyte: веб-интерфейс, который позволяет запускать рабочие процессы и просматривать состояние выполнения.
  • Облачное хранилище BLOB-объектов: хранит входные и выходные данные задач, а также определения схем. В отличие от Airflow, Flyte не использует для этой цели реляционную базу данных, чтобы избежать узких мест. В Lyft мы используем AWS S3.

В Lyft мы используем несколько кластеров Kubernetes для изоляции отказоустойчивых доменов и масштабирования. Flyte Admin поддерживает этот режим из коробки.

Преимущества Flyte

Основной движущей силой внедрения Flyte было устранение некоторых фундаментальных пробелов в Airflow, которые были важны для нас.

Самым значительным преимуществом Flyte является изоляция среды и зависимостей. Код и библиотеки упакованы в образ Docker. Такой подход позволяет иметь разные библиотеки с разными версиями для каждой команды или даже делать это под конкретную задачу. Проект логически разбит на домены: разработка, постановка и производство. Домены позволяют продвигать код в производство шаг за шагом, следуя таким методам разработки, как CI/CD, модульное/интеграционное тестирование и проверка кода.

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

Привлекательной особенностью Flyte является управление версиями рабочего процесса: мы создаем новый образ Docker с новой версией кода и библиотек и регистрируем новую версию рабочего процесса. Мы можем запускать любую версию в любое время: это дает нам огромное преимущество при устранении неполадок, откате изменений и сравнении выходных данных между разными версиями (выполнение A-B-тестирования). Возможность использовать домены и управление версиями рабочего процесса делает Flyte хорошим выбором для критически важных приложений, где изменения должны быть протестированы и развернуты независимо от выполняемых в данный момент рабочих процессов.

В настоящее время для написания рабочих процессов доступны пакеты SDK для Python и Java. Тем не менее, интересно, что Flyte компилирует рабочие процессы и сохраняет их в независимом от языка представлении, что позволяет нам внести новый SDK и потенциально добавить поддержку любого языка через сырые контейнеры. Flyte идеально подходит для разнородных рабочих процессов: мы можем упаковать любой двоичный исполняемый файл в образ Docker и сделать его задачей, которая дает нам возможность выбирать любой язык для разработки или любые библиотеки/фреймворки.

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

Недостатки флайта

Наиболее существенные недостатки Flyte связаны со стоимостью:

  • Среда Flyte и изоляция зависимостей требуют затрат: командам необходимо поддерживать репозиторий, образы Docker и обновлять библиотеки. Некоторые команды могут не прилагать к этому усилий и считают Airflow более простым в использовании.
  • Flyte создает эфемерную инфраструктуру в Kubernetes. Изолированная эфемерная инфраструктура по требованию приводит к дополнительным временным затратам на развертывание новых модулей и является чрезмерной для небольших задач или заданий. Это компромисс: стоимость создания эфемерного кластера по сравнению с поддержанием автономного кластера. Это не похоже на проблему Flyte, а скорее на антипаттерн. Кстати, сообщество Flyte работает над обновлением, которое позволит повторно использовать модули в разных задачах и рабочих процессах. Это позволит нам запускать небольшие рабочие нагрузки с меньшими задержками.

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

Airflow против Flyte: выбор правильного инструмента для вашего случая использования

Lyft активно использует Airflow и Flyte: в настоящее время у нас более десяти тысяч уникальных рабочих процессов и около миллиона исполнений в месяц. Мы предоставляем руководства и призываем команды использовать рекомендуемый инструмент на основе характеристик их вариантов использования. У нас в Lyft нет строгих правил в отношении того, когда использовать Airflow или Flyte, поскольку решения команды могут быть вызваны многими другими причинами, такими как историческое использование или опыт работы с конкретным инструментом.

Когда использовать воздушный поток

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

Однако рассмотрите возможность использования Airflow, если ваш рабочий процесс содержит какой-либо из описанных ниже анти-шаблонов:

  • Зависимости с блокировкой версии: Airflow не подходит, если вам нужны настраиваемые зависимости или библиотеки. Все DAG в Airflow имеют общие библиотеки. Все должны придерживаться версий этих зависимостей. Трудно изолировать зависимости между различными DAG.
  • Ресурсоемкие задачи. В Airflow есть фиксированное количество рабочих, которые выполняют несколько задач в любой момент. Задачи обычно передают вычисления внешним системам, таким как Trino, но операторы Python или Bash выполняются локально. Ресурсоемкие задачи могут перегружать рабочие узлы и дестабилизировать Airflow.
  • Конвейеры с динамическими задачами. Airflow не подходит для динамических конвейеров, которые изменяют форму DAG во время выполнения, используя входные или выходные данные предыдущих шагов обработки.
  • Высокочастотные конвейеры. Airflow предназначен для повторяющихся пакетных рабочих процессов. Следует избегать частот менее нескольких минут.

Когда использовать Флайт

Flyte — хороший инструмент для ресурсоемких задач, требующих настраиваемых зависимостей, изолированной среды и инфраструктуры.

Пересмотрите использование Flyte, если ваш рабочий процесс содержит какой-либо из описанных ниже антишаблонов:

  • Небольшие пакеты: Flyte создает инфраструктуру с нуля и прекращает работу после завершения задачи. Для запуска новых модулей требуется время, что увеличивает расходы, когда мы хотим часто запускать небольшие партии. Используйте статический кластер вместо эфемерного для небольших задач. Другим вариантом может быть использование сервисно-ориентированной архитектуры, управляемой событиями. Если вы все еще хотите использовать Flyte, рассмотрите возможность использования кэширования, если это применимо.
  • Распознавание таблиц считается антипаттерном для Flyte. Вместо опроса источника данных используйте подход, управляемый событиями, и запускайте рабочие процессы Flyte, вызывая API.
  • Сложные параллельные вычисления: Flyte предоставляет картографические задачи и динамические рабочие процессы, но не подходит для сложных параллельных вычислений, когда требуется перетасовка. Используйте вычислительный движок, такой как Spark, если вам нужно секционирование данных, распределенное объединение или сложное агрегирование.

Примеры использования

Мы определили два основных класса вариантов использования в Lyft:

  • ETL, в основном SQL: большинство этих рабочих процессов организуют запросы к Hive или Trino и управляют данными в таблицах SQL с помощью операторов SQL. Может быть небольшая часть задач, не связанных с SQL, таких как выполнение скриптов Python/Bash для вывода результатов в CSV или из него на S3 или загрузка результатов в реляционную базу данных. Обычно для таких случаев мы используем Apache Airflow.
  • Вычислительные задачи, требующие пользовательских сред или библиотек: задачи Python, выполнение Spark с пользовательскими библиотеками (например, платформами для обработки пространственных данных), обработка изображений/карт, обучение модели машинного обучения и т. д. Как правило, лучше с помощью Флайта.

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

Оптимизация ценообразования для максимизации количества поездок и прибыли

Ценообразование — это невероятно мощный инструмент для достижения стратегических целей компании, будь то прибыль, рост количества клиентов, частота клиентов, увеличение плотности или некоторая комбинация всего этого. Из-за того, что Lyft приходится принимать миллионы ценовых решений в день, мы обращаемся к машинному обучению для основных частей нашей системы ценообразования. Одним из важных факторов, влияющих на ценообразование, является прогнозирование стоимости обслуживания поездки. Это делается с помощью набора моделей XGboost. Сквозной поток состоит из трех основных частей: подготовка данных для обучения, обучение модели и обслуживание модели.

Этап подготовки обучающих данных — это набор ETL, которые получают такие события, как поездки, тарифы, налоги, сборы и т. д., в качестве входных данных, выполняют набор запросов Hive/Trino и создают набор логических данных с функциями модели. ETL работают ежедневно. Мы используем Airflow, потому что это отличный инструмент для управления ETL, которые управляют внешними системами, такими как Hive/Trino.

Этап обучения модели — это набор рабочих процессов, которые обучают модели и выводят артефакты модели, такие как модель XGboost, в S3. Мы используем Flyte по следующим причинам:

  • Мы делимся пользовательским кодом Python между рабочими процессами, используя и создавая многочисленные библиотеки. Нам также нужны собственные образы Docker.
  • Мы создаем детерминированные задачи и активно используем кэширование: это делает нас более эффективными и сокращает время выполнения с нескольких часов до менее часа. В некоторых рабочих процессах может быть 20–30 задач. В случае сбоя задачи мы можем исправить проблему и перезапустить весь пайплайн: кешированные задачи быстро пройдут. Кэширование также помогает нам значительно сократить расходы.
  • Обучение моделей — это скорее разовый процесс, чем запланированный. В один день мы можем переобучить 20 моделей, а в другие дни мы не будем обучать ничего нового. Flyte упрощает вызов рабочих процессов с разными параметрами.
  • Возможность использовать отдельные среды: разработка, промежуточная подготовка, производство снижает количество ошибок, которые потенциально могут оказать существенное влияние на Lyft, если они будут обнаружены в производстве.

Выполнение этого для большого количества пользователей ETL в централизованной версии Airflow будет кошмаром и сильно замедлит нас.

Предсказание времени прибытия

Цель состоит в том, чтобы предсказать время в пути из пункта А в пункт Б и показать его, когда пользователь заказывает поездку. Служба ETA использует модели GeoBoost для обеспечения точной оценки.

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

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

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

Предоставление рыночных сигналов для расчета цены

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

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

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

Управление версиями имеет важное значение, поскольку могут быть случаи, когда мы можем улучшить производительность модели, но это может не привести к аналогичному или справедливому улучшению последующих бизнес-показателей для потребителей. По сути, может одновременно работать несколько версий модели потоковой передачи, и потребители могут подписываться на события, создаваемые конкретной версией. Это позволяет взаимодействовать между командами, поскольку потребители могут оставаться на старой версии и выполнять A-B-тестирование. Каждая версия модели связана с версией рабочего процесса Flyte и помечена SHA фиксации GIT.

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

Сохранение точности и актуальности картографических данных с помощью компьютерного зрения и графического процессора

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

Процесс включает в себя сбор метаданных изображений и использование моделей компьютерного зрения ML в PyTorch. Выполнение модели требует ресурсоемких вычислений на графическом процессоре. Flyte используется для всего конвейера, поскольку он позволяет нам использовать возможности Kubernetes для маршрутизации задач на серверы GPU, когда они нам нужны. Также необходимо настроить кластер Spark с помощью библиотек для обработки пространственных данных, таких как Apache Sedona, которые мы включаем в образ Docker, поддерживаемый оператором Flyte Spark.

Заключение

В этом посте мы рассказали, как мы используем Airflow и Flyte для организации конвейеров данных. Мы рассмотрели различные аспекты темы:

  • Концепции и архитектура Airflow и Flyte в Lyft, их преимущества и недостатки
  • Ограничения Airflow, которые привели к созданию Flyte
  • Рекомендации по выбору того или иного инструмента в зависимости от класса варианта использования
  • Несколько примеров использования, иллюстрирующих использование Flyte и Airflow.

Airflow лучше подходит для ETL, где мы организуем вычисления, выполняемые во внешних системах. Поэтому нет необходимости в изоляции вычислений на стороне Airflow. Кроме того, мы используем стандартизированный набор библиотек, таких как клиент Hive/Trino, поэтому настройка библиотек не требуется. Большим плюсом Airflow является то, что его легко освоить и он обеспечивает поддержку задач распознавания стола. Многие команды используют Airflow, потому что он быстро запускается и не требует поддержки пользовательских образов или библиотек Docker.

Если вы беспокоитесь о пользовательской среде и изоляции вычислений, Flyte может быть лучшим решением. Flyte полагается на Kubernetes, который предоставляет такие возможности из коробки. Типичными вариантами использования Flyte являются задания Python или Spark, требующие пользовательских библиотек или платформ машинного обучения. Существенным преимуществом Flyte является управление версиями рабочего процесса. Стоит отметить, что настройка и изоляция имеют свою цену: командам необходимо поддерживать свои образы Docker. Эфемерная инфраструктура приносит дополнительные чрезмерные затраты на краткосрочные задачи.

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

Хотите узнать больше? Lyft набирает сотрудников — присоединяйтесь к нам!

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

Особая благодарность следующим людям, которые предоставили отзывы, идеи, представили свои варианты использования и помогли создать этот пост: Aaron TaylorMays, Anand Swaminathan, Anmol Khurana, Artem Semianenka, Arup Malakar, Bhuwan Chopra, Bill Graham, Eli Schachar, Igor Valko, Илья Зверев, Джек Чжоу, Кетан Умаре, Лев Драгунов, Мэттью Смит, Макс Пэйтон, Майкл Буриш, Майкл Сан, Николя Флакко, Нильс Бантилан, Пол Диттамо, Роберт Эверсон, Руслан Станевич, Самхита Алла, Сандра Юссеф, Сантош Кумар, Вилли Рихерт .