Мы уже рассказывали про основные достоинства и недостатки Apache Airflow, с которыми чаще всего можно столкнуться при практическом использовании этого оркестратора конвейеров обработки больших данных (Big Data). Сегодня рассмотрим некоторые специфические ограничения, характерные для этой open-source платформы и способы решения этих проблем на реальных примерах.
Все по плану: 5 особенностей Scheduler’а
Планировщик (Scheduler), который отслеживает все задачи и все группы DAG, запуская экземпляры Task, считается самым интересным, но и самым слабым местом Apache Airflow [1]. Он разработан для работы в качестве постоянной службы в production-среде и использует конфигурацию, указанную в конфигурационном файле airflow.cfg. Примечательно, что планировщик не запустит задачи до тех пор, пока не закончится установленный период, который он охватывает. Например, задание с параметром schedule_interval, установленным как @daily, запустится после окончания дня. С одной стороны, это гарантирует, что все необходимые данные, будут полностью доступны до выполнения DAG. Однако, в пользовательском интерфейсе кажется, что Airflow выполняет задачи на день позже. В частности, при запуске DAG с интервалом schedule_interval в один день, execute_date запустится после 23:59 этой даты. Таким образом, планировщик запускает задание через один schedule_interval ПОСЛЕ даты начала, в КОНЦЕ установленного периода [2].
Код курса
ADH-AIR
Ближайшая дата курса
по запросу
Продолжительность
ак.часов
Стоимость обучения
0 руб.
Еще одним важным ограничением Airflow является его строгая привязка к UTC – поэтому при запуске задач по расписанию следует помнить про разницу вашего часового пояса с этой временной зоной. В версии 1.10.10 появилась возможность менять таймзону в веб-GUI, но DAG’и все равно будут запускаться по UTC [1]. Также одним из самых значимых параметров любого DAG’а, связанного со временем, является start_date. Планировщик запускает задачу после того, как наступит время (start_date + schedule_interval). По умолчанию schedule_interval составляет один день (datetime.timedelta (1)) [3].
Интересно, что при изменении schedule_interval или start_date следует менять dag_id, т.к. во внутренней базе метаданных Airflow уже есть запись о времени запуска этого DAG’а. Поэтому при изменении расписания в таблицу DAGS добавляется еще одна строчка, т.е. получается две одинаковых задачи с разным расписанием. Если не требуется запускать pipeline для каждого интервала от start_date до текущей даты, а нужен только один запуск за последний доступный интервал, следует установить параметр catchup=False в DAG или catchup_by_default=False в конфигурационном файле [4].
Кроме того, в один момент времени может работать только один инстанс Scheduler’a, что означает отсутствие работы в режиме высокой доступности (High Availability). Также стоит помнить, что не стоит задавать слишком частый интервал запуска (раз в пару минут) data pipeline’ов, т.к. при одновременном запуске нескольких DAG’ов их фактический старт может откладываться [1].
Airflow в production: еще 5 рекомендаций
По умолчанию Airflow поставляется с серверной частью СУБД SQLite, которая позволяет пользователю запускать систему без внешней базы данных, а также отлично подходит для обучения и тестирования. Однако, в production это может привести к потере данных в нескольких сценариях. Поэтому в производственной среде следует настроить серверную часть как внешнюю СУБД, например, PostgreSQL. После этого Airflow создаст все таблицы, необходимые для работы. Не рекомендуется использовать airflow initdb, т.к. это генерирует множество соединений по умолчанию, диаграмм и прочих настроек, которые не нужны в production.
По умолчанию Airflow использует airflow.executors.sequential_executor.SequentialExecutor, который приостанавливает работу планировщика при выполнении задачи, поэтому не рекомендуется в производственной среде. Следует использовать локальный исполнитель для одной машины. А в случае многоузловой настройки целесообразно работать с исполнителем Kubernetes или Celery. После настройки исполнителя необходимо убедиться, что каждый узел в кластере содержит одинаковую конфигурацию и теги. Airflow отправляет только простые инструкции, такие как «выполнить задачу X для dag Y», но не отправляет никаких файлов DAG или конфигурации. Можно использовать простое задание cron или любой другой механизм для синхронизации DAG’ов и конфигураций между узлами, например, извлекать задачи из репозитория git каждые 5 минут на всех узлах.
Data Pipeline на Apache Airflow
Код курса
AIRF
Ближайшая дата курса
27 ноября, 2024
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
При запуске в production стоит убедиться, что DAG параметризован для изменения переменных, в частности, пути вывода операции S3 или СУБД для чтения конфигурации. Не следует жестко задавать значения внутри группы DAG, а затем изменять их вручную в соответствии со средой. При одноразовых узлах в кластереAirflow следует настроить хранилище журналов как распределенную файловую систему или внешний сервис, такой как Elasticsearch или Amazon CloudWatch. Таким образом, журналы будут доступны если узел выйдет из строя или будет заменен. Рекомендуется использовать переменные среды для конфигураций, которые меняются в зависимости от развертывания, например, БД метаданных, пароль и прочие важные настройки [5].
Больше подробностей по администрированию и эксплуатации Apache Airflow в production на реальных проектах цифровизации частного бизнеса, а также государственных и муниципальных предприятий, вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
