Airflow — самый распространённый оркестратор, но не единственный. В последние годы появилось несколько новых инструментов, которые предлагают другие подходы. Этот урок — обзор главных альтернатив и контекста, в котором каждая из них имеет смысл. Понимание ландшафта поможет тебе осознанно выбирать инструмент на новом проекте и ориентироваться в чужих стеках.

Краткое сравнение

Dagster: assets вместо tasks

Dagster — относительно новый оркестратор (Elementl, 2018). Главная идея — переключить фокус с tasks на assets. В Airflow ты пишешь: «выполни эту задачу, потом эту, потом эту». В Dagster ты пишешь: «вот данные customers, они производятся из raw.customers через эту функцию» — и Dagster сам определит порядок выполнения по графу зависимостей данных.

# Dagster style: декларация assets
from dagster import asset

@asset
def raw_orders():
    return fetch_orders_from_api()

@asset
def cleaned_orders(raw_orders):  # параметр = upstream asset
    return raw_orders.dropna().dropDuplicates()

@asset
def daily_revenue(cleaned_orders):
    return cleaned_orders.groupBy("date").agg(...)

Dagster читает граф: daily_revenue зависит от cleaned_orders, который зависит от raw_orders. Это и есть DAG, но выраженный через данные, а не через задачи.

Преимущества:

• Типизация и контракты. Можно явно описать типы asset, и Dagster проверит на этапе компиляции.
• Sensors и schedules для assets, а не задач — более естественно для DE.
• Lineage из коробки. Граф ассетов автоматически.
• Software-defined assets — концепция, что данные есть результат выполнения кода с дефинитивной связью.

Недостатки:

• Меньше зрелость. Меньше battle-tested сценариев, меньше готовых operators.
• Меньше экосистема. Provider-ы для всех нужных систем есть, но их меньше.
• Команда должна купить asset-mental-model. Многим DE привычнее tasks.

Dagster выигрывает в командах с сильной dbt-практикой, где данные — first-class citizens.

Prefect: Pythonic flows

Prefect — оркестратор от Jeremiah Lowin (бывший Airflow core contributor). Появился в 2018 как «Airflow done right». Главная идея — описывать пайплайны как обычные Python-функции с декораторами, без специального API.

from prefect import flow, task

@task
def extract():
    return fetch_data()

@task
def transform(data):
    return data.transform()

@task
def load(data):
    save(data)

@flow
def daily_pipeline():
    data = extract()
    transformed = transform(data)
    load(transformed)

Это обычный Python с двумя декораторами. Зависимости выводятся из вызовов функций. DAG строится динамически в момент выполнения, не статически как в Airflow.

Преимущества:

• Pythonic. Любой Python-разработчик сразу понимает.
• Dynamic DAG. Можно строить разные структуры в зависимости от данных (в Airflow это сложнее).
• Hybrid mode. Prefect Cloud координирует, а сами задачи запускаются на твоих агентах в твоей инфраструктуре. Это удобная модель для security.
• Богатая retry/timeout/state-машина из коробки.

Недостатки:

• Меньше operators. Для специфичных систем (Snowflake-Postgres-Slack) часто пишешь сам.
• Менее зрелый ecosystem. Книг, статей, stackoverflow ответов сильно меньше Airflow.
• Hybrid Cloud — это business-модель. Полный open-source self-hosted вариант менее проработан.

Prefect выигрывает в маленьких командах, где хочется минимум boilerplate.

Argo Workflows: Kubernetes-native

Argo Workflows — это не специализированный DE-инструмент, а универсальный оркестратор workflows в Kubernetes. Часть проекта Argo (вместе с Argo CD для GitOps).

В Argo Workflows DAG задаётся в YAML, каждая задача — это Kubernetes pod. Идеально вписывается в K8s-native стек.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: daily-etl-
spec:
  entrypoint: main
  templates:
  - name: main
    dag:
      tasks:
      - name: extract
        template: extract-task
      - name: transform
        dependencies: [extract]
        template: transform-task
  - name: extract-task
    container:
      image: my-org/etl:1.0
      command: [python, /app/extract.py]

Преимущества:

• Native K8s. Если у тебя уже Kubernetes — не надо ставить отдельный оркестратор.
• Изоляция задач. Каждая задача в своём поде, никаких shared воркеров.
• GitOps friendly. Workflow как YAML в git, applied через Argo CD.

Недостатки:

• Не специализирован для DE. Нет встроенных Snowflake/dbt-operators, нет XCom-аналога (приходится через volume или storage), нет UI с метриками pipeline.
• Учитель кривой. Нужно знать Kubernetes на хорошем уровне.
• YAML вместо Python. Программирование сложной логики в YAML мучительно.

Argo выигрывает в командах, где DE-задачи — это малая часть workloads, и весь стек уже на Kubernetes.

Mage: low-code

Mage (бывший Mage AI) — новый оркестратор с фокусом на low-code опыт. UI похож на Jupyter notebook: ты пишешь блоки кода (data loader, transformer, exporter), Mage визуально показывает их связи.

Преимущества:

• Очень низкий barrier. Аналитик с базовым Python может построить пайплайн.
• Notebook-style. Интерактивная разработка, видишь результат сразу.
• Встроенные блоки для популярных источников и DWH.

Недостатки:

• Не enterprise-grade. Слабее retry, monitoring, scaling по сравнению с Airflow.
• Скрытые зависимости. GUI скрывает структуру DAG, что может быть проблемой при росте.
• Узкий ecosystem. Меньше готовых интеграций.

Mage выигрывает в командах, где много аналитиков и мало DE.

Когда что выбирать

Выбирай Airflow когда:

• Production DE-команда с опытом.
• Нужен зрелый инструмент с долгосрочной поддержкой.
• Богатый набор operators для разных систем (Snowflake, BigQuery, dbt, AWS, GCP).
• Размер команды и пайплайнов оправдывает операционную сложность.

Выбирай Dagster когда:

• Сильная практика dbt и asset-centric mindset.
• Хочется типизации и явных контрактов между моделями.
• Готовы инвестировать в новый mental-model.

Выбирай Prefect когда:

• Маленькая команда, ценит Pythonic-простоту.
• Нужны динамические пайплайны, генерирующиеся из данных.
• Готовы платить за Prefect Cloud или поднимать self-hosted core.

Выбирай Argo когда:

• Вся инфраструктура уже на Kubernetes.
• DE-workloads — малая часть общих workloads.
• Готовы жить с YAML и без DE-специфичных features.

Выбирай Mage когда:

• Команда в основном аналитики, не разработчики.
• Пайплайны простые и стабильные.
• Не критично enterprise-grade оркестрирование.

Не оркестратор: cron, GitHub Actions, AWS Step Functions

Стоит упомянуть инструменты, которые не являются оркестраторами, но иногда используются для похожих задач:

cron — для маленьких и простых сценариев. Подходит, если 1-5 job-ов без зависимостей.

GitHub Actions / GitLab CI. Хороши для CI/CD, могут запускать пайплайны по расписанию. Но без серьёзного state management, retries, UI для DE. Подходят для лёгких задач.

AWS Step Functions / Azure Logic Apps / GCP Workflows. Cloud-native serverless оркестраторы. Хорошо интегрированы с облачными сервисами своего провайдера. Менее гибкие, чем Airflow, но не требуют деплоя.

В реальной DE-практике они дополняют, а не заменяют полноценный оркестратор. Например, GitHub Actions для деплоя DAG-ов в Airflow.

Реальная картина

В крупных компаниях обычно один доминирующий оркестратор (чаще Airflow) и точечные использования других:

• Основной DE-оркестратор — Airflow или Dagster.
• CI/CD — GitHub Actions.
• Serverless ad-hoc — AWS Step Functions для триггеров.
• K8s-native workloads — Argo для ML-обучения.

Не надо стандартизироваться на одном инструменте «потому что так чище». В реальности hybrid работает лучше — каждый инструмент применяется там, где сильнее.

Попробуй сам

Зайди на сайт каждого из четырёх альтернативных инструментов (Dagster, Prefect, Argo, Mage), прочитай их quickstart. Сравни, как один и тот же простой пайплайн (load -> transform -> save) выглядит в каждом из них. Что тебе понятнее? Чей подход лучше ложится на твой mental-model? Это упражнение помогает быстро ориентироваться в выборе для нового проекта.