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

Что такое Airflow Executor

Есть много исполнителей Airflow, чтобы выбрать, давайте оставим этот выбор и сначала сосредоточимся на том, что делают исполнители Airflow в экосистеме Airflow. Дисциплина «Исполнитель», соответственно, является механизмом, позволяющим выполнять задачи. Рабочий - это узел или процессор, который выполняет фактические задачи. Планировщик Airflow не запускает никаких задач, а передает их исполнителю. Исполнитель действует как посредник, отвечающий за использование ресурсов и лучший способ распределения работы.

Хотя задание Airflow организовано на уровне DAG, этап выполнения задания более детализирован, и Executor выполняется на уровне задачи. Как показано на изображениях ниже, если группа DAG завершает работу с шестью задачами, планировщик Airflow назначит каждую задачу отдельно исполнителю. Независимо от того, выполняются ли эти задачи параллельно или последовательно, это определяется типом исполнителя.

Какая часть исполнителя задействована в жизненном цикле воздушного потока?

На данный момент Airflow (версия 1.10.10) представляет собой систему единого планировщика. В этом случае все задачи планируются только одним планировщиком. Планировщик контролирует, когда задачи будут отправлены исполнителю, и отслеживает состояние задач от исполнителей.

Жизненный цикл задачи от планировщика до исполнителя включает следующие шаги:

  1. Перед тем, как планировщик отправит команду, на которой задача Executor будет запускаться, в зависимости от типов исполнителей, ресурс самих исполнителей остается бездействующим или недоступным.
  2. Как только наступает запланированное время, планировщик Airflow отправляет команду Executor.
  3. После получения сигналов от планировщика Executor начинает выделять ресурсы и ставить задачи в очередь. Когда работа будет доступна, она заберет задачи из очереди для ее выполнения. Между тем, планировщик периодически выполняет задачи (это называется тактовым импульсом), чтобы получить текущее состояние задачи, а затем обновлять его состояние в бэкэнд-БД.
  4. Как только задачи завершились и планировщик получил состояние Завершено от Executor, ресурс, выделенный для выполнения задачи, был очищен.

Почему у Airflow разные типы исполнителей?

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

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

Airflow является расширяемым, поддерживает различных исполнителей. Изначально в Airflow доступны только SequentialExecutor, LocalExecutor, CeleryExecutor и MesosExecutor. За последние два года, начиная с Airflow 1.9.0, Airflow привлекает больше внимания, и в сообщество было добавлено больше исполнителей, в число которых входят DaskExecutor, KubernetesExecutor, DebugExecutor.

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

  • SequentialExecutor - это стандартный исполнитель по умолчанию. Как следует из названия, задачи будут выполняться последовательно. Даже у вас есть оператор ветки, и задачи все равно будут выполняться одна за другой в порядке ’branch_a’, ‘branch_b’, ‘branch_c’, ‘branch_d’
  • LocalExecutor отлично подходит для параллельного тестирования нескольких заданий Airflow, выполняя задачи для небольшой производственной среды. LocalExecutor запускает задачу на том же узле, что и планировщик Airflow, но на разных процессорах. Есть и другие исполнители, которые используют этот тип при распределении фактической работы; например, KubernetesExecutor будет использовать LocalExecutor в каждом модуле для выполнения задачи.
  • CeleryExecutor - наиболее зрелый вариант для Airflow, так как большинство первых пользователей Airflow используют CeleryExecutor. Для этого требуется поддержка инфраструктуры - дополнительно бэкэнд Celery и Celery (Redis или RabbitMQ). Тем не менее, вам было бы намного лучше помочь с этим вариантом со стороны сообщества Airflow, поскольку многие компании работают с этим вариантом.
  • MesosExecutor - один из первых разработчиков сообщества. Однако, поскольку Kubernetes получил более широкое распространение, чем Mesos, сообщество Airflow также обсуждает прекращение использования MesosExecutor. Если ваша компания не использует Mesos, и вы не увидите миграции на Kubernetes в ближайшие несколько лет, и вы хотите использовать Mesos для управления своим ресурсом-исполнителем Airflow, вы можете выбрать этот вариант. В противном случае вы можете не выбирать MesosExecutor.
  • Dask.org вдохновляет DaskExecutor. Также обсуждается удаление DaskExecutor из-за отсутствия использования, которое DaskExecutor терпит неудачу на мастере Airflow в течение нескольких месяцев, но никто этого не заметил. Мне лично нравится Даск; к сожалению, меньше используется с Airflow и Dask. К сожалению, из-за меньшего использования и поддержки вы можете не выбирать DaskExecutor.
  • KubernetesExecutor был представлен в версии 1.10.0 и предоставлен Bloomberg. Этот вклад устанавливает веху для интеграции Airflow с экосистемой Kubernetes. Хотя первые несколько минорных версий содержат ошибки, последние более стабильны. Если ваша компания широко использует Kubernetes, KubernetesExecutor может быть лучшим выбором для исполнителя Airflow. Еще одна прекрасная особенность KubernetesExecutor заключается в том, что вы можете готовить различные образы докеров для своих задач, и это дает вам больше гибкости здесь.
  • DebugExecutor был представлен в 1.10.8. Его нельзя классифицировать как исполнителя; цель этого DebugExecutor - работать с IDE. Он похож на SequentialExecutor для запуска одной задачи за раз и поддерживает работу с датчиками.

Таким образом, CeleryExecutor и KubernetesExecutor будут отличным выбором для вашей производственной среды. LocalExecutor также является предпочтительным вариантом для производственной среды. Если у вас небольшая рабочая нагрузка или большинство задач выполняется в облачных службах, таких как AWS или служба Azure, Airflow Executor выступает в роли посредника, который общается с различными службами, не выполняя их на самом деле, LocalExecutor также является жизнеспособным выбором. SequentialExecutor и DebugExecutor предназначены для локального тестирования. Вы, вероятно, пропустили бы их на производстве. MesosExecutor и DaskExecutor, возможно, вы захотите избежать их из-за неоднозначности их будущей дорожной карты в экосистеме Airflow.

Как настроить Airflow Executor?

Большинство конфигураций Airflow Executor контролируются файлом airflow.cfg. В различных функциональных разделах файл заключен в квадратные скобки. Для выбора исполнителя, который вы увидите в разделе ядра, по умолчанию выбран SequentialExecutor. Это позволяет запускать Airflow без установки слишком большого количества зависимостей. SequentialExecutor может работать напрямую с SQLite, который должен быть установлен вместе с установкой Python. Как мы обсуждали выше, вы можете выбрать разные типы исполнителей, но для каждого из них требуется дополнительная настройка в файле AirflowAirflow .cfg.

[core]
executor = SequentialExecutor

LocalExecutor также легко настроить, и он требует, чтобы база данных метаданных была MySQL или PostgreSQL вместо SQLite. После настройки LocalExecutor раскрывается 90% функциональных возможностей исполнителя Airflow. Остальные 10% функциональности Executor - это распределенный запуск Airflow.

В CeleryExecutor есть раздел конфигурации - [celery]. Есть два основных компонента: бэкэнд для сельдерея и сельдерея. Сельдерей - это асинхронная очередь задач. С помощью Celery Airflow может масштабировать свои задачи для нескольких сотрудников, чтобы выполнять их быстрее. Дополнительные настройки можно найти на странице Airflow Celery.

KubernetesExecutor - любимый ребенок в Airflow из-за популярности Kubernetes. Если у вас есть Kubernetes в вашей среде, настройка KubernetesExecutor в Airflow не составит большого труда, я рассмотрел базовую настройку в своей предыдущей статье: Изучите Airflow KubernetesExecutor на AWS и kops.

Последние мысли

Для инфраструктуры Airflow настройка правильного Executor является критическим шагом. Если вы хотите, чтобы Airflow обрабатывал не только часть планирования, но и запускал задачи на вашем рабочем узле, исполнитель Airflow предоставляет здесь больше дополнительных возможностей благодаря своим распределенным возможностям. Я надеюсь, что эта статья может дать вам некоторые основные идеи по Airflow Executor. Ваше здоровье!