Что такое Apache Airflow

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

Airflow родился в Airbnb в 2014 году как ответ на типичную боль зрелой дата-команды: десятки пайплайнов, написанных на разных языках, запускаемых по cron, без видимости статуса, без понимания зависимостей, без единого места для отладки. К 2026 году Airflow стал стандартом отрасли — 30+ миллионов скачиваний в месяц, 80 000+ организаций, top-level проект Apache Software Foundation с 2019 года.

Что значит «оркестрация»

В русскоязычной литературе термин orchestration часто переводят как «оркестровка», что подразумевает дирижирование. И это удачная метафора: Airflow не выполняет работу сам — он управляет тем, когда, в каком порядке, с какими параметрами и на каком исполнителе запустить каждый шаг конвейера.

Различие между тремя смежными понятиями:

Айрфлоу — workflow engine. Это значит, что вы можете описать не отдельную задачу, а DAG (Directed Acyclic Graph) — направленный ациклический граф, где узлы — это задачи, а рёбра — зависимости между ними.

Простой пример DAG

Рассмотрим типичный ETL-конвейер:

На языке Airflow 2.x это описывается так (TaskFlow API):

from airflow.decorators import dag, task
from datetime import datetime

@dag(
    schedule="@daily"
    start_date=datetime(2026, 1, 1),
    catchup=False,
    tags=["etl", "orders"],
)
def orders_etl():
    @task
    def extract_orders() -> str:
        return "s3://staging/orders/2026-05-12.parquet"

    @task
    def transform_orders(staging_path: str) -> str:
        return "s3://processed/orders/2026-05-12.parquet"

    @task
    def load_to_warehouse(processed_path: str):
        pass

    @task
    def notify_team(processed_path: str):
        pass

    staging = extract_orders()
    processed = transform_orders(staging)
    load_to_warehouse(processed)
    notify_team(processed)

orders_etl()

Несколько неочевидных моментов:

• Зависимости неявные: transform_orders(staging) означает «получи результат extract_orders как вход» — Airflow сам выводит граф зависимостей.
• Расписание @daily не запускает задачу прямо сейчас. Оно создаёт DagRun за каждый интервал (data interval), начиная с start_date. Это фундаментально отличается от cron.
• catchup=False говорит Airflow не запускать пропущенные runs за прошлое — только текущий и будущие.

Что Airflow делает за вас

Когда вы описываете DAG, Airflow автоматически берёт на себя:

1. Планирование — создаёт DagRun для каждого интервала расписания и решает, когда какой task запускать.
2. Исполнение — отправляет task в executor (Local, Celery, Kubernetes), который запускает её на worker.
3. Состояние — каждый task имеет своё состояние (scheduled, queued, running, success, failed, up_for_retry, и ещё 9 других), хранящееся в metadata database.
4. Повторы — при ошибке task переходит в up_for_retry и автоматически перезапускается через retry_delay, до retries раз.
5. Триггеры зависимостей — transform_orders не запустится, пока extract_orders не достигнет success.
6. Backfill — можно прогнать DAG за прошлые даты, и Airflow создаст соответствующие DagRun с правильными data_interval.
7. Конкурентность — пять параметров одновременности (parallelism, max_active_runs_per_dag, max_active_tasks_per_dag, pool slots, executor parallelism) дают контроль над загрузкой.
8. Наблюдаемость — Web UI с graph view, gantt chart, logs, история выполнения, метрики через OTel/StatsD.

Всё это работает не «магически» — это десятки тысяч строк Python, дискриминирующая модель данных в PostgreSQL и тонко настроенный scheduler. В модулях 04 и 05 мы препарируем эту машинерию до строк кода.

Где Airflow в архитектуре дата-платформы

Airflow находится в центре дата-платформы. Он сам не обрабатывает данные — он координирует внешние системы, которые это делают:

Главная ценность Airflow здесь — единая точка управления и наблюдаемости. Без оркестратора вы получаете «зоопарк» из cron jobs, Jenkins pipelines, Lambda functions, каждый со своим логированием и retry-логикой. С Airflow — один интерфейс, один journal, одна модель зависимостей.

Когда Airflow — правильный выбор, а когда — нет

Airflow создан для определённого класса задач. Он отлично подходит для:

• Batch ETL/ELT пайплайнов, запускаемых по расписанию (час, день, неделя)
• Координации между внешними системами (Spark, dbt, Snowflake, S3)
• Долгоживущих многошаговых workflow (часы, дни — backfill за месяц истории)
• Сценариев с явными зависимостями (граф из десятков-сотен задач)
• Требований к идемпотентности и retry (failed task должен иметь возможность повторить)
• Data-aware scheduling через Datasets (с Airflow 2.4+)

Airflow — неправильный выбор для:

| CI/CD pipelines | Не предназначен для VCS-trigger | GitHub Actions, GitLab CI, Argo Workflows | | Long-running stateful services | Airflow задачи короткоживущие | Temporal, Kubernetes Operators | | Дешёвый cron на одной машине | Overhead инфраструктуры | systemd timers, cron + supervisord | | Workflow с миллионами короткоживущих задач/сек | Scheduler bottleneck | Argo Workflows (k8s-native), Prefect |

Конкуренты в 2026 году

Айрфлоу — лидер рынка, но не монополист. Ключевые альтернативы:

• Prefect 3 — динамические workflow, hybrid agents, Prefect Cloud как SaaS. Pythonic API без top-level parse quirks.
• Dagster — asset-first подход, strong typing, software-defined assets. Сильнее в analytics engineering и ML.
• Argo Workflows — Kubernetes-native через CRDs, YAML или Hera SDK. Очень быстрый для parallel fan-outs.
• Temporal — durable execution для долгоживущих бизнес-процессов. Не дата-оркестратор, но решает смежную задачу.
• Kestra — YAML/Kotlin core, declarative.

Айрфлоу выигрывает там, где нужна зрелость экосистемы (3000+ providers), смешанная нагрузка batch+data-aware, on-premise deployment и большой Python-сообщество.

Как создавался курс

Курс создан при участии Claude (Anthropic) как соавтора: ИИ помогал писать материалы, структурировать темы, генерировать примеры кода и диаграммы. Каждая глава проходила ручную сверку с первоисточниками — спецификациями, документацией, исходным кодом рассматриваемых систем — но гарантировать 100% точность невозможно.

Если вы заметили неточность, опечатку или хотите предложить улучшение — напишите в Telegram-группу курса. Это самый ценный вклад в курс, который вы можете сделать.

Углублённое изучение с Claude

Курс рассчитан на самостоятельное изучение, но любая теория быстрее ложится, если задавать вопросы. Рекомендую держать рядом браузерное расширение Claude (claude.com/download) — оно работает с контентом открытой страницы: выделяете кусок урока и спрашиваете напрямую.

Сценарии, которые особенно хорошо работают для углублённого погружения:

• «Объясни проще» / «дай ещё один пример» — когда формулировка из урока не дошла с первого раза.
• «Покажи, как это устроено на уровне кода / железа» — когда хочется спуститься на слой ниже того, что даёт урок.
• «Как это связано с [другая тема курса]» — когда нужно увязать концепцию с тем, что было раньше.
• «У меня в проекте стек X — как применить?» — когда хочется примерить материал на свой реальный кейс.

Это не замена курсу, а способ ускорить интеграцию материала в вашу картину мира. Если что-то из ответов Claude расходится с уроком — присылайте в Telegram-группу, курс будет уточнён.

Нашли ошибку?

Если заметили неточность, опечатку или хотите предложить улучшение:

Telegram-канал

Подписывайтесь, чтобы узнавать об обновлениях и новых курсах: