Apache Airflow¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Область версий: Apache Airflow 3.1.0, Python3.12; SDK imports/новый backfill CLI. Проверка источников: 2026-11-02; это не рекомендация latest release.

Архитектура и роль¶

FACT. Orchestration control plane: DAG processor разбирает Python и сериализует definitions, scheduler планирует task instances, executor распределяет работу, metadata database хранит состояние, triggerer обслуживает deferrable waiting. Airflow3.1 использует Task SDK/Execution API; примеры Airflow2 imports/CLI не переносим автоматически.

Внутренние механизмы и движение данных¶

Scheduled DAG run получает logical date/data interval по timetable; для @daily запуск обычно следует после конца интервала. Это диапазон данных, а не время фактического старта task. catchup создаёт пропущенные scheduled intervals согласно настройке; backfill в3.1 управляется scheduler и имеет отдельный CLI/API.

Dynamic Task Mapping расширяет task instances по runtime metadata через expand, а не генерирует DAG произвольным запросом к БД при каждом parse. XCom передаёт небольшие manifest URIs/counts, не DataFrame/полный финансовый dataset. Top-level Python должен быть дешёвым и не выполнять бизнес-IO при import.

flowchart TB
  DAG[Versioned DAG definition] --> Scheduler[Scheduler and metadata DB]
  Scheduler --> Map[Runtime manifest mapping]
  Map --> Workers[Bounded extraction tasks]
  Workers --> Objects[Immutable generation outputs]
  Objects --> Checks[Reconciliation and publish barrier]

Ordering и guarantees¶

Task retry/clear/backfill могут повторить внешние effects; successful task status не образует общую distributed transaction. Каждая task должна иметь idempotent output identity (interval, source version, generation), публикация report — отдельный commit/barrier. Dependencies обеспечивают порядок задач, а не row-level consistency источников.

Документированный contract и версия.

Масштабирование и backpressure¶

Pools, executor capacity, task concurrency, max_active_runs и mapping cardinality ограничивают нагрузку. Тысячи mapped tasks увеличивают metadata/scheduler overhead. Long sensor занимает worker при неподходящем режиме; deferrable operator уменьшает ожидание worker resources, но требует triggerer/correct operator.

Failure / recovery / replay¶

Scheduler/worker crash восстанавливается из metadata и executor state, но task может быть запущена снова после уже совершённого effect. Backfill пишет отдельную generation; live report pointer переключается после reconciliation. Код DAG, dependencies и source manifests должны быть версионированы, иначе повтор того же интервала даст иной результат.

Документированный contract и версия.

Эксплуатация и мониторинг¶

Наблюдать scheduler heartbeat, DAG import errors, queued/running age, retry counts, pool pressure, triggerer health, interval completeness и report publication. Мониторить metadata DB, logs, secrets и executor. Состояние success не доказывает row counts/amount totals; DQ/reconciliation — отдельные tasks и alert.

Ограничения и критерии выбора¶

Не streaming engine и не место для хранения stream offsets/state windows. Выбирать для bounded jobs с dependencies/backfill и наблюдаемым lifecycle. Не использовать XCom как транспорт большого dataset. SQL source cutoff/consistent extraction остаётся задачей data job.

FinTech / iGaming и реальные источники¶

FACT: Flutter UKI/AWS описывают MWAA pipeline orchestration. Это vendor/customer case с ограничениями и более ранней версией; из него не выводится Airflow3.1 contract. G04. Учебный daily reporting — HYPOTHETICAL.

Практический пример¶

Mapped DAG и backfill CLI3.1. Import/AST check не считается DagBag/scheduler execution; Windows-host runtime не предполагается.

Типичные ошибки проектирования¶

data interval=текущее now(); large XCom; side effects в DAG import; backfill пишет в live aggregates без generation; catchup путают с retry.

Вопросы на собеседовании¶

catchup и retry одно? Нет, scheduled intervals и повтор task instance решают разные задачи.

Зачем manifest вместо XCom dataset? Bounded metadata уменьшает сериализацию/metadata DB pressure.

Успешный DAG доказывает финансовую полноту? Нет, нужны согласованный cutoff и reconciliation.

Практические упражнения¶

Сделайте backfill пропущенного интервала в отдельную generation, затем сравните counts/keys/currency totals и только после проверки предложите pointer switch.