Разделяй и властвуй: управление зависимыми DAG в Apache AirFlow

Автор Категория ,
Разделяй и властвуй: управление зависимыми DAG в Apache AirFlow

Чтобы сделать обучение дата-инженеров еще более полезным, сегодня мы рассмотрим проблему управления взаимозависимыми цепочками задач в Apache AirFlow. Читайте далее, как бразильская ИТ-компания QuintoAndar разработала промежуточный компонент Mediator на базе одноименного шаблона архитектурного проектирования ПО, чтобы облегчить взаимодействие между разными DAG’ами в конвейерах обработки больших данных.

Проблема взаимозависимых DAG’ов в Apache AirFlow

Основной сущностью конвейера обработки данных (data pipeline) в Apache Airflow является DAG (Directed Acyclic Graph) – цепочка задач для запланированного запуска по расписанию в виде направленного ациклического графа. По мере роста объема данных и усложнения конвейеров их обработки таких цепочек, каждая из которых состоит их нескольких задач, становится много и они зависят друг от друга. Соответственно, возрастает сложность управления связанными DAG’ами, включая обеспечение их согласованности и возможности повторного использования.

Разбиение конвейеров обработки данных на множество модулей ответственности в виде DAG повышает их ремонтопригодность и улучшает понимание процессов перемещения данных. Однако управление взаимосвязями между разными DAG’ами по умолчанию не поддерживается в Apache Airflow. Поэтому дата-инженеры бразильской ИТ-компании QuintoAndar решили создать компонент, который позволит сохранить целостность потока работ в конвейере данных и гарантировать бесперебойное выполнение DAG’а даже при изменении связанных с ним цепочек [1].

Прежде чем разрабатывать собственное решение, следует рассмотреть существующие альтернативы, предоставляемые встроенными возможностями самого фреймворка [2]:

  • ручное управление расписаниями DAG;
  • создание комплексного DAG, аккумулирующего все существующие цепочки задач, чтобы управлять зависимостями между ними через технологию XCom (cross-communication), о которой мы рассказывали здесь;
  • использование операторов ExternalTaskSensor и ExternalTaskMarker, чтобы установить зависимости между разными DAG’ами и выполнять очистку зависимых задач;
  • применение триггера TriggerDagRunOperator, который позволяет пользователям получать доступ к DAG, запускаемому задачей [3].

Все эти подходы не соответствуют современному взгляду на программную инженерию, когда система строится в соответствии с принципами масштабируемости, модульности и удобства использования. В частности, при использовании настраиваемого триггера для запуска зависимого DAG необходимо определить, какая из зависимостей будет отвечать за запуск конкретной цепочки задач. Поэтому специалисты QuintoAndar начали разработку собственного решения, которое будет надежным, масштабируемым, отказоустойчивым и сможет успешно работать самостоятельно, без ручного вмешательства дата-инженеров. Для этого они обратились к основам архитектурного проектирования программных систем, выбрав из множества классических Design Patterns шаблон «Посредник» (Mediator). Что он представляет собой и как реализуется в рамках Apache AirFlow, мы рассмотрим далее.

Посредник для связанных цепочек задач – плагин от QuintoAndar

Напомним, посредник в архитектурном проектировании ПО — это поведенческий шаблон, обеспечивающий взаимодействие множества объектов, который формирует слабую связанность и избавляет объекты от необходимости явно ссылаться друг на друга [4]. Mediator в Airflow отвечает поиск успешно выполненных DAG, которые являются результатом других цепочек. То есть, если один DAG зависит от другого, посредник сам заботится о проверке и запуске необходимых объектов для продолжения конвейера обработки данных. Таким образом, вместо прямой связи между разными DAG’ами можно реализовать взаимодействие между ними через независимый компонент-посредник, который отвечает за обработку зависимостей и их запуск цепочек задач в нужное время. Сам DAG посредника состоит из двух наборов задач [1]:

  • проверка зависимостей, которая идентифицирует зависимости каждого DAG’а и оценивает его статус;
  • зависимых триггеров, которые отвечают за запуск соответствующих DAG’ов.

Каждый зависимый DAG, обрабатываемый посредником, имеет набор зависимостей из набора других DAG или определенных задач. При запуске Mediator DAG, средство проверки зависимостей анализирует статус каждой зависимости, проверяя успешность его завершения. Если какая-то зависимость из набора DAG завершилась неудачно, посредник не запустит эту цепочку задач, пометив красным цветом соответствующую задачу триггера. А если зависимый DAG не нужно запускать, триггер будет просто пропущен (отмечен розовым).

AirFlow, DAG, курсы дата-инженеров
Управление зависимыми DAG’ами в Apache AirFlow

Чтобы поделиться с сообществом своим решением, дата-инженеры QuintoAndar упаковали его как внешний плагин с двумя пользовательскими операторами, которые отвечают за механизм посредничества [1]:

  • QuintoAndarShortCircuitExternalOperator – отвечает за логику оценки зависимостей, получая словарь зависимостей для распознавания DAG’ов и их зависимостей, хранящихся файле сопоставления;
  • QuintoAndarCustomTriggerDagOperator – запускает каждый DAG из словаря зависимостей, предварительно определяя дату выполнения DAG на основе метаданных, совместно используемых предыдущей задачей через XC

Таким образом, предложенный QuintoAndar компонент Mediator для Apache AirFlow обеспечивает распараллеливание конвейера обработки данных, т.к. DAG выполняются не в фиксированное время, а по требованию. Кроме того, data pipeline теперь гибко масштабируется, позволяя добавлять больше DAG, поддерживать которые стало проще благодаря модульности и вынесению ответственности за взаимную зависимость в область посредника. Наконец, увеличилась скорость и производительности конвейерной обработки, т.к. каждый DAG запускается как можно раньше, оперативно доставляя нужные данные без ручного вмешательства. Интересно, что в марте 2021 года популярная платформа онлайн-образования в области Machine Learning и других методов ИИ, компания DataCamp предложила свой вариант инструмента для решения проблемы управления кросс-зависимыми задачами и DAG’ами в AirFlow, выпустив фреймворк Viewflow, о котором мы рассказываем здесь. Читайте в нашей следующей статье для дата-инженеров про инфраструктурные среды для развертывания и поддержки этого ETL-фреймворка в крупных production-проектах. А какие еще практики разработки ПО полезны дата-инженеру, рассматривается в этом материале.

Узнайте больше про применение Apache AirFlow для разработки сложных конвейеров аналитики больших данных с Hadoop и Spark на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Источники

  1. https://medium.com/quintoandar-tech-blog/effective-cross-dags-dependency-in-apache-airflow-1885dc7ece9f
  2. https://airflow.apache.org/docs/apache-airflow/stable/howto/operator/external_task_sensor.html
  3. https://airflow.apache.org/docs/apache-airflow/stable/_api/airflow/operators/trigger_dagrun/index.html
  4. https://en.wikipedia.org/wiki/Mediator_pattern