Команде нужно каждый день в 7:00 обновлять три зависимых друг от друга SQL-модели и отправлять уведомление в Slack при ошибке. Почему для этого обычно выбирают Airflow, а не просто cron-задачи?

Короткий ответ

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

Как это работает подробнее

• Как это работает: в Airflow пайплайн описывается как DAG (direct acyclic graph) — набор задач (task) с явными зависимостями (task_a >> task_b >> task_c); планировщик следит, что задача B запустится только после успешного завершения A, а веб-интерфейс показывает статус и логи каждого запуска.

Пример кода

daily_pipeline.pyКопировать

from airflow import DAG
from airflow.operators.empty import EmptyOperator
from datetime import datetime
with DAG("daily_sales_pipeline", start_date=datetime(2024, 1, 1), schedule="0 7 * * *", catchup=False) as dag:
    extract = EmptyOperator(task_id="extract")
    transform = EmptyOperator(task_id="transform")
    report = EmptyOperator(task_id="report")
    extract >> transform >> report

Что использовать на практике

• На практике: при трёх зависимых моделях cron потребовал бы либо запускать их одной задачей с ручной обработкой ошибок на каждом шаге, либо сильно разносить время запуска «на глаз», рискуя, что модель B стартует раньше, чем реально готова A; в Airflow достаточно описать зависимость явно, настроить retry с задержкой и алерт в Slack при падении задачи через on_failure_callback.
• Пример и проверка. Проверка: в интерфейсе Airflow (Graph View) видно, что run_marts не стартует, пока run_staging не завершится успешно, а при искусственном падении run_staging (например, временно сломав SQL) приходит уведомление в Slack без ручного вмешательства.

Подводные камни

• Частые ошибки: использовать Airflow только как «cron с красивым интерфейсом», не используя зависимости между задачами (все задачи независимы и просто запущены по расписанию) — тогда теряется основной смысл инструмента; не делать задачи идемпотентными (при повторном запуске данные задваиваются), из-за чего retry Airflow приносит больше вреда, чем пользы.