Как использовать Airflow для оркестрации ETL-процессов

Что проверяют

Понимаете ли вы, что Airflow это оркестратор, а не движок обработки данных, и умеете ли строить DAG, который можно безопасно перезапустить. Следом почти всегда спрашивают: что будет, если задача упала посреди загрузки и её запустили повторно.

Как отвечать

Опишите, из чего собирается пайплайн и на что опирается надёжность:

• DAG и задачи: граф зависимостей в Python-файле. Сейчас удобнее TaskFlow API с декораторами @dag и @task, расписание задаётся параметром schedule, cron-строкой или по событию;
• операторы и провайдеры: готовые операторы для баз, S3, Spark, dbt приходят из provider-пакетов. Тяжёлая трансформация выполняется в хранилище, Spark или dbt, а Airflow только запускает её и ждёт результат;
• интервал данных: каждый запуск обрабатывает свой интервал (data_interval_start, data_interval_end, шаблон {{ ds }}), а не «данные на сейчас». Это основа для backfill и перезапусков;
• идемпотентность: задача перезаписывает партицию за свой интервал (DELETE + INSERT или MERGE), а не дописывает строки, поэтому повторный запуск не плодит дубли;
• надёжность: retries и retry_delay на задачах, алерты через on_failure_callback, пулы для ограничения нагрузки на источник, сенсоры в режиме reschedule или deferrable-операторы, чтобы не держать слот воркера;
• зависимости между DAG: data-aware scheduling через Assets (в ранних версиях Datasets) вместо сенсоров, ждущих чужой DAG.

Упомяните исполнитель: LocalExecutor для небольших установок, CeleryExecutor или KubernetesExecutor для масштаба.

Где спотыкаются

Гоняют сами данные через XCom. XCom хранится в метабазе и рассчитан на метаданные: путь к файлу, число строк, id партиции.

Пишут тяжёлый код на верхнем уровне файла DAG: запросы к базе, чтение API. Файлы DAG регулярно перечитываются, и такой код выполняется при каждом разборе, а не при запуске.

Берут datetime.now() внутри задачи вместо интервала запуска. Тогда backfill за прошлую неделю загрузит сегодняшние данные.