Оркестратор Apache Airflow: что это и как используется в BI и DWH

Извлечение из источников

↓

Загрузка в DWH

↓

Очистка и трансформация

↓

Формирование витрин

↓

Визуализация в BI

• запустить Python-скрипт для получения данных через API;
• инициировать SQL-запрос в PostgreSQL, Greenplum или ClickHouse;
• запустить модель dbt;
• вызвать Spark-задачу;
• проверить успешность предыдущей операции;
• после формирования витрины запустить следующий процесс.

• Scheduler мониторит готовые к запуску задачи с учетом расписания и зависимостей.
• Executor определяет, где и как выполняются задачи. Он работает внутри Scheduler и передает задачи исполнителям — Workers.
• Metadata Database хранит состояния, историю запусков и другие служебные данные.
• Web UI / API Server позволяют отслеживать выполнение DAG, историю и ошибки, а также вручную запускать процессы.
• Triggerer обслуживает отложенные (deferrable) задачи, которые ждут внешнего события: появления файла, завершения запроса во внешней системе, ответа API. Пока задача ожидает, Worker не занят и может выполнять другие задачи.

• Задач (Tasks, тасков): отдельных шагов процесса (например, выгрузка, трансформация или отправка данных).
• Задачи могут создаваться с помощью операторов (Operators), которые определяют, какое действие необходимо выполнить: запустить Python-код, Bash-команду, SQL-запрос и т. д. Отдельный тип операторов — Sensors, которые ожидают наступления определенного события или выполнения условия, например появления файла или готовности данных.
• Зависимостей (Dependencies): правил очередности, которые показывают, какая задача должна выполниться перед другой.
• Расписания (Schedule): правила, определяющего, когда запускать DAG.

1. В Python-коде создается DAG: задаются задачи, порядок их выполнения, расписание, количество повторных попыток и другие параметры.
2. Планировщик определяет, когда должен быть запущен DAG и какие задачи готовы к выполнению с учетом их зависимостей.
3. Для каждого запуска Airflow создает DAG Run — экземпляр DAG за конкретную дату (logical date), а для каждой задачи внутри него — TaskInstance со своим состоянием.
4. Executor передает задачи на выполнение. В процессе выполнения задача меняет состояния, а при ошибке получает статус failed или может быть автоматически отправлена на повторное выполнение (up_for_retry).
5. Состояния запусков и задач сохраняются в Metadata Database, а через Web UI можно отслеживать выполнение процессов, анализировать ошибки и перезапускать необходимые задачи. Состояния задач видны в Web UI в представлении Grid: каждая клетка — это задача в конкретном запуске.

• Сбор и интеграция данных (ETL/ELT) — управляет задачами извлечения и загрузки данных из различных источников, а также процессами репликации.
• Хранение и обработка данных (DWH) — запускает очистку, трансформацию и агрегацию данных, контролирует вычисления, проверки качества и отправку алертов.
• Аналитика и отчетность (BI) — обеспечивает последовательное обновление данных от источников до витрин и отчетности.
• Data Science / MLOps — оркестрирует процессы подготовки данных, переобучения и валидации моделей, а также задачи их развертывания.

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

• Актуальность данных — отчетность обновляется по заданному расписанию.
• Быстрое устранение сбоев — техническим специалистам проще определить проблемный этап и перезапустить его, не влияя на работу пользователей.
• Меньше ошибок в данных — регулярные процессы выполняются автоматически, что сокращает влияние человеческого фактора

• Open source

• Гибкость и универсальность

• Большая экосистема интеграций

• Workflows as Code

• Масштабируемость

• Мониторинг

• Развитое сообщество и подробная документация упрощают разработку и поддержку.

• Высокий порог входа: работа с Airflow требует знания Python и компетенций Data Engineering.
• Сложность сопровождения: с ростом количества DAG, задач и зависимостей возрастают требования к разработке, тестированию и поддержке пайплайнов.
• Требования к инфраструктуре: Airflow необходимо развертывать, обновлять, резервировать и мониторить, а при росте нагрузки — масштабировать его компоненты.

• Streaming-платформы

• Инструменты обработки данных

• Инструменты управления данными

• Ориентация на Data Assets. Dagster позволяет описывать таблицы, витрины и другие объекты как активы и автоматически строить зависимости между ними.

• Data Lineage и наблюдаемость. В интерфейсе можно проследить происхождение данных, зависимости между активами и историю их обновления.

• Контроль качества данных. Встроенные Asset Checks (проверки ассетов) позволяют проверять наличие данных, дубликаты, допустимые значения и другие параметры качества непосредственно в пайплайне.

• Интеграция с dbt. Dagster представляет dbt-модели как Data Assets, отображает их зависимости и позволяет управлять их выполнением.

• Гибкое управление пересчетами. Dagster определяет, какие активы требуют обновления, и позволяет пересчитывать отдельные части пайплайна вместо запуска всей цепочки.

• Экосистема интеграций Dagster уступает Airflow, поэтому для отдельных систем может потребоваться самостоятельная разработка.
• Dagster моложе Airflow, поэтому имеет меньше примеров промышленного использования, материалов и специалистов на рынке.
• Подход Dagster строится вокруг assets и зависимостей между данными. Командам, привыкшим к управлению последовательностью задач, потребуется освоить новые абстракции и в некоторых случаях перестроить существующие пайплайны.

• Динамические workflows. Логику выполнения проще менять непосредственно во время исполнения в зависимости от результатов предыдущих шагов.

• Удобство локальной разработки. Процессы можно запускать и отлаживать как обычный Python-код, постепенно добавляя оркестрацию.

• Гибкая событийная автоматизация. Prefect хорошо подходит для процессов, которые запускаются не только по расписанию, но и в ответ на события.

• По распространенности, количеству готовых интеграций и накопленному опыту эксплуатации Prefect уступает Airflow.
• Найти инженеров с практическим опытом Prefect обычно сложнее, чем специалистов по Airflow.

• проектирование архитектуры DWH и ETL/ELT;
• развертывание и настройку Apache Airflow, разработку DAG;
• интеграцию с PostgreSQL, Greenplum, ClickHouse, API, dbt и другими системами;
• настройку мониторинга, CI/CD, обработки ошибок и повторных запусков;
• подготовку документации и передачу компетенций внутренней команде.