Как работает исполнитель Celery в Apache AirFlow, зачем ему очередь сообщений и каким образом это помогает масштабировать параллельное выполнение задач.
Как работает исполнитель Celery в Apache AirFlow
Именно исполнитель (Executor) в Apache Airflow отвечает за выполнение задач в рабочих процессах, определяя их локацию и последовательность, а также использование ресурсов. Хотя вариантов исполнителей есть несколько, на практике для запуска удаленных задач наиболее часто используются Celery и Kubernetes. Подробно об этом мы писали здесь.
Про промышленном развертывании Airflow, когда необходимо масштабировать нагрузку, можно использовать исполнитель Celery, который использует постоянные рабочие процессы для выполнения задач. При этом масштабирование включает выбор количества и размера рабочих процессов, доступных Airflow для одновременного выполнения задач.
Celery — это распределённая система обработки задач, которая используется для асинхронного выполнения заданий. Она написана на Python, состоит из нескольких рабочих узлов и брокеров, что обеспечивает высокую доступность и горизонтальное масштабирование. Очереди задач используются как механизм распределения работы по потокам или машинам. Входные данные очереди задач — это единица работы, называемая задачей. Выделенные рабочие процессы постоянно отслеживают очереди задач на предмет новой работы для выполнения. Celery общается посредством сообщений, обычно используя брокера в качестве посредника между клиентами и работниками. Чтобы инициировать задачу, клиент добавляет сообщение в очередь, затем брокер доставляет это сообщение рабочему процессу.
В качестве бэкенда Celery использует брокер сообщений RabbitMQ или key-value базу данных Redis, а также поддерживает SQLite для локальной разработки. Celery может работать на одной машине, на нескольких машинах или даже в разных центрах обработки данных. Когда Airflow использует Celery, он применяет его в качестве бэкэнда для распределения задач между несколькими исполнителями, чтобы масштабировать выполнение задач, распределяя нагрузку параллельно.
Планировщик Airflow (Scheduler) управляет планированием задач и определяет, когда задача должна быть выполнена. Он добавляет задачи в очередь брокера сообщений, например, RabbitMQ или Redis. Чтобы это работало, сперва нужно настроить брокер сообщений в бэкенде Celery, установить требуемые зависимости, например, библиотеки librabbitmq или redis, и изменить настройки исполнителя в конфигурационном файле airflow.cfg.
Брокер сообщений хранит задачи до тех пор, пока они не будут обработаны исполнителями. Он действует как промежуточное звено между планировщиком и исполнителями. Рабочие процессы (Workers) Celery, которые обрабатывают задачи из очереди, получают их из брокера сообщений и выполняют. После выполнения задачи, результаты могут быть сохранены в хранилище результатов (например, базе данных), что позволяет отслеживать статус и результаты выполнения.
Таким образом, очередь в Celery реализуется так, что брокер сообщений сохраняет команды для исполнения, а бэкэнд результатов сохраняет статус выполненных команд.
Взаимодействие между компонентами Airflow при использовании исполнителя Celery можно отобразить так:
- пользователь инициирует выполнение DAG, отправляя запрос к планировщику;
- планировщик проверяет статус DAG в базе данных Airflow;
- для каждой задачи планировщик публикует ее в очереди Celery;
- задача передается на исполнение рабочему процессу Celery;
- рабочий процесс выполняет задачу и обновляет её статус в базе данных;
- планировщик получает уведомление о завершении выполнения задачи;
- после завершения всех задач, планировщик сообщает пользователю об окончании выполнения DAG.
Настройки очереди Celery
Если время выполнения задачи будет превышен ее тайм-аут видимости visible_timeout, Celery переназначит задачу другому рабочему процессу, даже если исходная задача все еще успешно выполняется. Затем новый экземпляр задачи запускается одновременно с исходной задачей, а пользовательский интерфейс Airflow и логи покажут сообщение об ошибке. Если установить параметр task_acks_late в значение True, Celery будет ждать завершения задачи, прежде чем назначать новый экземпляр задачи. Это фактически переопределяет тайм-аут видимости.
По сути, тайм-аут видимости в Celery определяет, как долго сообщение может оставаться невидимым для других рабочих процессов после того, как оно было получено одним из них. Если рабочий процесс не завершает задачу в течение этого времени, сообщение становится доступным для других, чтобы они могли выполнить эту задачу.
Рекомендуется установить тайм-аут видимости, превышающий расчетное время выполнения самой длительной задачи, чтобы предотвратить дублирования работ и избежать лишней нагрузки на систему из-за постоянного переназначения задач. Можно сказать, что правильно настроенный тайм-аут видимости помогает поддерживать систему в стабильном состоянии и предотвращает лишние вычислительные затраты.
При использовании исполнителя Celery можно указать очереди, в которые отправляются задачи, используя атрибут базового оператора BaseOperator под названием queue. Любую задачу можно назначить любой очереди. Очередь по умолчанию для среды определяется в конфигурационном файле airflow.cfg. Именно в эту очередь назначаются задачи, если не указано иное. Также эту очередь прослушивают рабочие процессы Airflow. Впрочем, любой рабочий процесс может прослушивать одну или несколько очередей зада, что можно задать при его запуске. Иногда такая ручная настройка полезна, если нужны специализированные рабочие процессы, например, для легковесных и не ресурсоемких задач или специфические для какой-то среды, к примеру, внутри кластера Spark с соответствующими правами и настройками безопасности. Таким образом, управление очередями позволяет динамически масштабировать рабочие процессы и изолировать их друг от друга.
Узнайте больше про администрирование и эксплуатацию Apache AirFlow для оркестрации пакетных процессов в задачах реальной дата-инженерии на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
- https://www.astronomer.io/docs/learn/airflow-scaling-workers/
- https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/celery_executor.html
- https://docs.celeryq.dev/en/latest/getting-started/introduction.html
- https://www.restack.io/docs/airflow-knowledge-apache-airflow-queue-management
- https://www.astronomer.io/docs/astro/configure-worker-queues/
