Перейти к содержанию

Компоненты Airflow (Airflow components)

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

В этом руководстве описаны основные компоненты Airflow.

Между Airflow 2 и Airflow 3 произошли существенные архитектурные изменения: улучшена безопасность и появились возможности вроде удалённого выполнения. Для авторов DAG важно: прямой доступ к метаданным БД из задач больше невозможен. Подробнее: Upgrade from Apache Airflow® 2 to 3 и Release notes.

Примечание

Необходимая база

Полезно понимать:

Основные компоненты

Основные компоненты Airflow:

  • Triggerer — отдельный процесс для выполнения асинхронных Python-функций в рамках trigger-классов. Нужен для deferrable-операторов и event-driven scheduling.
  • Метаданные (metadata database) — хранит данные, важные для работы Airflow: подключения (connections), сериализованные DAG, XCom, историю DAG run и экземпляров задач вместе с метаданными об их состояниях. Чаще всего используется PostgreSQL. См. поддерживаемые версии.
  • DAG processor — забирает и парсит файлы из расположения, заданного настроенным DAG bundle(s).
  • API server — FastAPI-сервер, который отдаёт UI Airflow и три API: API для воркеров при выполнении экземпляров задач; внутренний API для UI с обновлениями динамических элементов (состояния задач и DAG run); публичный Airflow REST API для пользователей.
  • Scheduler — ядро Airflow: следит за всеми задачами и DAG и планирует запуск экземпляров задач, как только выполнены их зависимости. При создании нового DAG run всегда выбирается последняя версия этого DAG. Когда задача готова к запуску, планировщик использует настроенный executor для запуска задачи на воркере.

При локальном запуске через Astro CLI командой astro dev start поднимается пять контейнеров — по одному на каждый из основных компонентов.

CONTAINER ID    IMAGE                [...]      PORTS       NAMES
f565...         [...]/airflow:latest [...]      >8080/tcp   [...]apiserver1
77e6…           [...]/airflow:latest [...]                  [...]dagprocessor1
88dc...         [...]/airflow:latest [...]                  [...]triggerer1
aa5a...         [...]/airflow:latest [...]                  [...]scheduler1
5f0e...         postgres:12.6        [...]      >5432/tcp   [...]postgres-1

Кроме этих компонентов могут быть запущены один или несколько воркеров. Их тип зависит от настроенного executor планировщика.

Взаимодействие компонентов

На схеме ниже показано, как основные компоненты взаимодействуют друг с другом:

Взаимодействие основных компонентов Airflow

В общих чертах при добавлении нового простого DAG происходит следующее:

  1. Планировщику нужен статус экземпляров задач в DAG, чтобы определить, какие ещё экземпляры теперь удовлетворяют зависимостям и могут быть запланированы. Пока это происходит в фоне, API server отдаёт UI данные о текущем DAG и статусах задач, которые он получает из БД метаданных Airflow.
  2. Часть этих данных (например, статус экземпляра задачи) важна для планировщика: он следит за всеми DAG и, как только зависимости выполнены, планирует запуск экземпляров задач.
  3. Воркер, взявший экземпляр задачи, выполняет его; метаданные (статус экземпляра, XCom) отправляются с воркера через API server в БД метаданных Airflow. Если задаче нужны данные (например, Airflow connection), воркер запрашивает их у API server; сервер получает их из БД метаданных и передаёт воркеру. Пока экземпляр задачи выполняется, воркер пишет логи напрямую в настроенное хранилище логов.
  4. Далее экземпляры задач планируются и попадают в очередь. Воркеры опрашивают очередь и забирают запланированные экземпляры для выполнения.
  5. Когда планировщик определяет, что DAG готов к следующему run, настроенный executor решает, как и где запустить первые экземпляры задач этого DAG run.
  6. Планировщик проверяет сериализованные DAG и определяет, какие DAG готовы к выполнению по заданному расписанию: сверка расписания с текущим временем, проверка обновлений assets и событий от AssetWatchers.
  7. DAG парсится DAG processor, который сохраняет сериализованную версию в БД метаданных Airflow.

Управление инфраструктурой Airflow

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

Полезные ресурсы:

При настройке продакшен-окружения важно учитывать масштабирование. См. Scaling out Airflow.

Высокая доступность

Airflow можно сделать высокодоступным, что подходит для крупных организаций с критичными продакшен-нагрузками. Запуск нескольких реплик Scheduler в режиме active-active повышает производительность и отказоустойчивость и устраняет единую точку отказа.

В Astro высокую доступность можно включить при создании deployment: переключатель High Availability в UI или параметр isHighAvailability со значением true в API или Terraform.

← К содержанию | Метаданные БД → | Исполнители →