Dagster или Airflow: что выбрать для оркестрации в DWH-проектах?

Перед аналитикой данные из корпоративных систем необходимо превратить в информацию, пригодную для бизнес-анализа:

• Извлечь из разрозненных источников 
• Трансформировать – фильтровать, группировать, структурировать, агрегировать в датасет
• Загрузить в целевую систему – DWH, BI, Data Lake, СУБД, облако и т.д.

Вместе эти три процесса называются ETL (Extract, Transform, Load).

Для реализации ETL-процессов на рынке существует готовое ПО, однако оно не всегда может отвечать потребностям проекта.

При проектировании масштабных решений, например, корпоративных хранилищ данных, а также при необходимости встроить аналитические инструменты в имеющуюся сложную инфраструктуру Big Data, дата-инженеры обычно создают собственные конвейеры обработки данных - пайплайны.

Пайплайн может включать десятки шагов: извлечение данных из источников, очистку, трансформации, загрузку, агрегации, построение витрин. Он может выполняться раз в час, в конце дня, по триггеру, например, при поступлении нового файла.

Вручную управлять всеми этими условиями и настройками трудоемко.

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

Когда речь заходит об оркестрации данных, почти всегда упоминаются два инструмента: Apache Airflow и Dagster. Оба стали своего рода стандартами в своей категории, но при этом отражают разные подходы к построению пайплайнов данных.

В статье рассказываем, какие задачи решают оркестраторы в проектах внедрения корпоративных хранилищ данных. Выясняем, в чём разница между инструментами, и почему Dagster становится всё популярнее в DWH-проектах, чем Airflow.

Корпоративное хранилище данных (DWH, Data Warehouse) – централизованная система, в которой хранятся и обрабатываются бизнес-данные из разных источников. Эти данные используются для аналитики и принятия управленческих решений. 
Основная задача организации хранилищ данных в компании – создание хорошо спроектированного, централизованного и масштабируемого банка данных.

Зачем бизнесу нужны хранилища данных?

Для этой цели недостаточно использовать простую базу данных, так как в отличие от БД корпоративные хранилища:

• Предназначены для интерактивного глубокого анализа

Cохраняют исторические данные в хронологическом порядке и агрегированные значения, в отличие от БД, которые подходят только для обработки транзакций

• Предметно-ориентированные

Данные в них хранятся в соответствии с описываемыми областями, а не используемыми приложениями

• Интегрированные

Объединяют данные различной природы, форматов, типов, являющиеся аспектами предметной области, а не отдельных функций

• Неизменчивы/некорректируемые

Для обеспечения единой версии правды и корректности аналитики данные в хранилище не создаются и не удаляются, изменения можно произвести только в источнике


Транзакционные базы данных и OLTP- системы (системы оперативной обработки данных), к которым относятся ERP, SCADA, банковские системы и т.д., являются основным источником данных для хранилищ.

Также данные в хранилище поступают из любых других источников структурированных данных: Excel, текстовых файлов с разделителями TXT, CSV, учетных систем 1С, API и прочих.

Перенос данных из источников в хранилище и их предварительная обработка реализованы с помощью ETL/ELT-процессов. 

В хранилище данные распределяются на слои:

• Стейджинг (операционный слой первичных данных, Primary Data Layer, Raw-слой) – слой сырых данных, отделенных от физического устройства источников данных
• Ядро хранилища (Core Data Layer) – слой, в котором сырые данные приводятся к единым структурам и ключам
• Слой детальных данных (DDS, Detail Data Store) - слой, в котором сохраняются детальные, неагрегированные данные из различных источников в едином стандартизированном формате
• Слой витрин данных (Data Mart Layer) – слой, содержащий структурированные данные в таблицах, разделенные в зависимости от бизнес-задач и готовые для визуализации
• Сервисный слой (Service Layer), который не содержит данные, а состоит из инструментов для управления, мониторинга и устранения ошибок в перечисленных выше слоях

Готовые для анализа данные поступают во внешние инструменты отчетности и визуализации, BI-платформы, аналитические системы.

Оркестраторы занимают центральное место в архитектуре хранилищ данных, обеспечивая управление и координацию всех процессов перемещения, обработки и загрузки данных.

Оркестратор управляет полным циклом процессов:

• Extract - извлечение данных из источников (ERP, CRM, API, Excel и др.)
• Transform - запуск скриптов преобразования, очистки, обогащения, агрегации (SQL, Python, Spark)
• Load - загрузка данных в промежуточные зоны хранения или витрины хранилищ (Data Lake, DWH)

Оркестратор запускает все эти задачи строго в нужной последовательности, с учётом зависимостей и установленного расписания.

В слоеной структуре хранилища LSA оркестраторы отвечают за перемещение данных между слоями Raw / Staging, Core / ODS, Data Marts, отслеживая, какие таблицы пересчитываются, и в каком порядке

Оркестраторы могут отвечать за:

• Логирование результатов выполнения каждой задачи
• Отправку алертов при сбоях
• Сохранение статуса пайплайна и формирование lineage - истории происхождения данных

Оркестраторы запускают и управляют ETL- процессами, которые формируют витрины данных для BI-дашбордов, запускают проверки качества данных, тесты и оповещают о нарушениях.
Также оркестраторы управляют последовательностью до- и пост-обработок, обучением моделей, оценкой, бенчмарками, запускают процессы переобучения при расхождении данных, управляют деплоем моделей.

Основная сущность Airflow - DAG (Directed Acyclic Graph) - направленный ациклический граф - набор задач, упорядоченных по зависимостям, где каждая задача может быть выполнена только после того, как завершатся все необходимые предыдущие.

«Направленный» (directed) означает, что зависимости имеют чёткое направление (одна задача идет после другой), а «ацикличный» (acyclic) — что в графе нет циклов: одна и та же задача не может зависеть от самой себя, даже косвенно.

DAG представляет собой Python-скрипт, который состоит из:

• Операторов (Operator) – классов-шаблонов, задающих тип работы, которую можно выполнить, например: запуск Python-функции, выполнение SQL-запроса, копирование данных и т. д. Делятся на функциональные категории:

1. Сенсоры — специальные операторы, которые ожидают наступления определенного события
2. Обработчики (например, PythonOperator, BashOperator) — запускают код, SQL, shell-команды и API
3. Трансферы (например, S3ToRedshiftOperator) — копируют или перемещают данные из одного источника в другой, работают как коннекторы между системами

Airflow предлагает как широкий выбор встроенных операторов, так и возможность добавления пользовательских.
Начиная с версии 2.0. наряду с операторами можно использовать TaskFlow API, который упрощает создание пайплайнов. Вместо описания тасков через PythonOperator, вы описываете бизнес-логику как чистые функции. Airflow автоматически превращает эти функции в задачи DAG’а, отслеживает зависимости и обрабатывает обмен данными между ними через механизм XCom.

• Задач (Task) – конкретных экземпляров операторов, которые создаются при запуске DAG и выполняют определенную работу в рамках процесса (worker) – загружают записи, очищают данные, запускают другие системы и т. д.

• Зависимостей (Dependencies) – связей между задачами, определяющих порядок их выполнения (task1>> task2)

• Пользователь вручную создает DAG. DAG-файл определяет идентификатор DAG’а (dag_id), расписание (schedule), набор задач (tasks) и зависимости между ними, параметры запуска и поведения (retries, SLA, timeout и др.)

• Компонент Airflow Планировщик (Scheduler) определяет, в какое время должна быть запущена конкретная задача

• Как только наступает время очередного запуска, планировщик создает новый DAG Run — конкретный экземпляр запуска DAG’а. Каждая задача в этом DAG будет иметь свой TaskInstance – экземпляр задачи, который отслеживает состояние выполнения этой конкретной задачи в реальном времени

• Компонент Executor отправляет задачи на исполнение. Каждая задача имеет свой жизненный цикл и переходит в состояния:

none – зависимости задачи еще не выполнены
scheduled — планировщик определил, что зависимости задачи выполнены, и задача должна быть запущена
queued — задача назначена исполнителю и ожидает worker
running — задача выполняется на worker или на локальном исполнителе
success — задача выполнена без ошибок
restarting — задача была перезапущена извне во время ее выполнения
failed — задачу не удалось запустить, во время выполнения произошла ошибка
skipped — задача была пропущена из-за ветвления, LatestOnly и других факторов
upstream_failed – не удалось выполнить задачу, которая нужна согласно правилу триггера
up_for_retry – задача не выполнена, но есть попытки повторного выполнения, и она будет перенесена
up_for_reschedule – задача - сенсор, находящийся в режиме перепланирования
deferred – задача отложена до триггера
removed — задача удалена из DAG с момента старта выполнения

• С помощью веб-интерфейса пользователь может отследить статус задач и ошибки их выполнения, перезапустить DAG’и, настраивать переменные и подключения

• Все состояния DAG Run’ов, задач, логов, XCom-сообщений, подключений и расписаний хранятся в базе метаданных (обычно PostgreSQL или MySQL)

• Поддержка разных интеграций

Платформу легко встроить в любую корпоративную экосистему, так как Airflow поставляется с сотнями готовых операторов для интеграции с базами данных, облаками, API и BI-инструментами

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

С помощью инструмента можно реализовать практически любую логику исполнения задач, включая динамические DAG’и (автоматически созданные из одинакового Python-кода) и кастомные плагины

• Удобство для пользователей

В основе Airflow – код на Python, который по умолчанию считается стандартом для дата-специалистов. Графическое отображение DAG’ов и простой интерфейс платформы будут понятны любому пользователю.

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

Airflow имеет модульную архитектуру, поэтому легко масштабируется, подходит для работы с большими объемами данных и тысячами задач

• Активное сообщество 

За более чем 10 лет существования сформировалось большое сообщество разработчиков, которые развивают платформу. Airflow имеет хорошо описанную документацию на разных языках

• Высокая нагрузка на разработчика

Императивный подход дает гибкость и полный контроль, но с ростом числа задач и усложнением логики требует все больше усилий на поддержку, особенно при отладке или повторном запуске частей пайплайна. При изменении порядка шагов в процессе нужно переписывать связи между задачами, инкрементальное обновление тоже требует ручной реализации.

• DAG строится вокруг задач, а не таблиц

Airflow оперирует задачами, а не данными или артефактами (таблицами, витринами, представлениями). DAG представляет собой структуру выполнения шагов, но не описывает, какие именно данные или структуры эти шаги создают. Это делает невозможным автоматическое определение какие таблицы зависят друг от друга, какие нужно пересчитать, и какие из них устарели.

• Неоптимально работает с большим количеством мелких задач

Каждая задача в Airflow создается как отдельный TaskInstance, требует коммуникации между scheduler, executor, worker и использует базу метаданных для контроля состояний. При большом количестве задач и DAG’ов возникает нагрузка на базу метаданных. В распределенных системах это приводит к задержкам в планировании, перегрузке Scheduler'а и формирует накладные расходы, особенно при частом запуске или необходимости обработки событий в режиме реального времени (меньше 1 секунды на событие).

• Не подходит для потоковой обработки данных (streaming)

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

• Ограниченный контроль за состоянием и качеством данных

Airflow не имеет встроенной поддержки data lineage, версионирования данных, контроля целостности таблиц. Нет декларативного описания, какие именно данные производятся и от чего они зависят, что усложняет трассировку и контроль качества данных для DWH-проектов


Apache Airflow остается мощным и гибким инструментом для оркестрации, но его архитектура и принципы проектирования ориентированы на опытных инженеров и зрелые инфраструктуры.

Airflow не имеет встроенной модели data-lineage; для автоматического отслеживания зависимостей таблиц требуются дополнительные механизмы и интеграции. Такой подход становится ограничением для data-проектов, особенно внедрения DWH, где важно отслеживать происхождение, состояние и зависимости данных, поддерживать сценарии с высокой частотой событий или real-time обработкой.

Основной архитектурный подход Dagster — это декларативное описание таблиц, моделей, отчетов. В отличие от императивного подхода Airflow, вы описываете, что должно получиться, а не как этого достичь. 

В Dagster пайплайны описываются как граф зависимых данных и состоит из компонентов:

• Assets — сущности данных (например, таблицы, модели, отчеты), которые Dagster отслеживает
• Ops — вычисления (шаги), преобразующие данные
• Job —объект, который определяет какие шаги (ops) нужно выполнить и как они связаны
• Executor - отвечает за запуск операций (локально, через Celery, Kubernetes и др.)
• IOManager - управляет сохранением/загрузкой артефактов (в базу, в файл, в DWH и т.д.)
• Schedule/Sensor - механизмы автоматического запуска
• Metadata Store - хранит историю, версии, события

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

• Встроенная модель активов Software-defined assets (SDA)

Dagster позволяет описывать данные как активы (@asset), что позволяет поддерживать декларативную структуру пайплайна, основанную на данных, а не на задачах, автоматически строить граф зависимостей и отслеживать состояния и повторный запуск только устаревших активов

• Встроенное отслеживание происхождения данных (Data Lineage)

Dagster автоматически строит граф зависимостей между активами, включая входы и выходы каждой функции, цепочки зависимости таблиц и моделей, визуализацию data lineage в интерфейсе Dagit. Происхождение данных сохраняется для каждого запуска и доступно через API и UI, что особенно важно в проектах DWH, где нужно понимать, откуда берутся бизнес-метрики и какие данные устарели

• Встроенные проверки качества данных (Data Validation / Expectations)

Dagster поддерживает собственные механизмы валидации на уровне @asset или @op, интеграцию с Dagster expectations, где можно задавать условия, которые должны выполняться (например, «таблица не пуста», «все значения > 0»), нативную интеграцию с Great Expectations, если требуется расширенная валидация. Результаты проверок логируются, визуализируются и могут влиять на состояние активов (например, актив может отмечаться как невалидный).

• Полноценная интеграция с dbt

Dagster имеет официальный интеграционный модуль для dbt, который автоматически импортирует dbt-модели как активы Dagster, отслеживает статус каждой модели, позволяет запускать только те модели, которые требуют обновления. Модуль работает как с dbt CLI, так и с dbt Cloud. 

• Наблюдаемость и детализация всех компонентов

Dagster предлагает структурированный журнал событий для мониторинга, графов, логов, артефактов и истории запусков, встроенную визуализацию зависимостей между ops, assets, partitions, легкий просмотр всех ресурсов, подключений, конфигураций. Архитектура Dagster построена так, что все вычисления прозрачны, и можно отследить, какие данные созданы, кем и когда. 

• Поддержка версионирования и воспроизводимости (Versioning)

Dagster позволяет назначать версию активам и ops (на основе кода и входных данных), отслеживать изменения кода, влияющие на выходы, пересчитывать только те части пайплайна, где изменилась логика и повторно выполнять исторические пайплайны с теми же параметрами и окружением.

• Инфраструктурная гибкость и Dev-friendly среда

Решение поддерживает local, Celery, Kubernetes, Docker, Dask executors, а также конфиги и шаблоны для среды исполнения (@config, RunConfig). Механизм IOManager позволяет управлять сохранением артефактов из хранилищ (S3, DB, файловая система и т.д.)

• Меньше готовых интеграций, чем у Airflow

Dagster предлагает IOManager, resources и hooks для написания интеграций вручную, но это требует больше усилий, чем использование готового BashOperator, S3ToRedshiftOperator или BigQueryOperator в Airflow.

• Меньшая зрелость и распространенность на рынке

Dagster — сравнительно новая платформа, поэтому примеров в продакшене, комьюнити, материалов гораздо меньше, чем у Airflow. К тому же Dagster использует декларативный подход: пользователи описывают не порядок задач, а структуру данных и зависимостей между активами. Для команд, привыкших к классическому императивному мышлению (как в Airflow, Prefect 1.x или Luigi), потребуется понимание дополнительных абстракций

• Рекомендованная архитектура требует переосмысления подходов к управлению данными

Dagster предлагает использовать assets, IOManager, resource-абстракции и графы зависимостей на уровне данных. Такой подход требует перестроить пайплайны, отказаться от чисто скриптовой логики, внедрить управление данными как системой, что может быть затруднительно в имеющихся проектах, особенно если архитектура построена вокруг Airflow или кастомных ETL-фреймворков.

Dagster предлагает более логичный и удобный подход оркестрации для проектов, где присутствуют сложные зависимости между таблицами, модели данных, автоматические пересчеты при обновлении источников. Его модель ориентирована на данные, а не только на исполнение задач, что делает пайплайны проще для поддержки и визуализации.

Dagster подойдет для проектирования DWH с нуля и обеспечит прозрачность, отслеживание data lineage, версионность и структурное управление данными.

С другой стороны, если в проекте уже используется Airflow, построена инфраструктура и накоплен опыт команды, миграция на Dagster может быть затратной и трудной для специалистов. Airflow все еще остается лидером в зрелых средах и крупных компаниях с комплексной архитектурой данных и множеством нестандартных интеграций.

В проектах внедрения DWH Qlever Solutions ориентируется на уникальные особенности, возможности и опыт клиента. При проектировании хранилища с нуля мы выбираем более современные, управляемые и функциональные инструменты, такие как Dagster. В ситуациях, когда команда клиента имеет накопленную экспертизу в Airflow, или по результатам оценки работ миграция потребует больших временных и финансовых затрат, мы стремимся оптимизировать текущие решения и сохранить привычный для клиента стек