Представьте простую бытовую задачу: каждую ночь нужно
1) выгрузить базу;
2) превратить её в отчёт;
3) отправить результат в S3;
Пока шагов мало, их легко раскидать по crontab. Но рано или поздно что‑нибудь пойдет медленнее обычного, соседний скрипт стартует раньше, отчёт выедет пустым — и вы начинаете расставлять костыли: sleep, «if‑else», ручные письма об ошибках. Так появляется «снежный ком» расписаний, который трудно контролировать.
Что делает Airflow по‑другому
Airflow описывает тот же процесс в виде DAG — направленного ациклического графа. Каждая задача — узел, каждая зависимость — стрелка.
Расписание теперь одно на весь процесс, а порядок шагов Airflow вычисляет сам:
from airflow import DAG
from airflow.operators.bash import BashOperator
from datetime import datetime, timedelta
with DAG(
dag_id="nightly_pipeline",
# стартуем раз в сутки
schedule_interval="0 2 * * *",
start_date=datetime(2025, 4, 1),
# не догоняем пропущенные дни
catchup=False
) as dag:
dump = BashOperator(
task_id="dump_db",
bash_command="/scripts/dump.sh",
retries=2,
retry_delay=timedelta(minutes=10),
# алёрт в чат
on_failure_callback="notify_telegram"
)
transform = BashOperator(
task_id="make_report",
bash_command="/scripts/report.sh"
)
upload = BashOperator(
task_id="upload_s3",
bash_command="/scripts/upload.sh"
)
dump >> transform >> upload
Что меняется на практике:
- Автоматические повторы — достаточно указать retries, и упавшая задача перезапустится без ваших правок в коде скрипта.
- Чёткая картинка процессов — в веб‑интерфейсе видно, что именно сейчас выполняется, что уже зелёное, а что покраснело.
- Уведомления «из коробки» — функция on_failure_callback отправит сообщение в Telegram/Slack, как только что‑то рухнет.
- Sensors и ожидание событий — вместо бесконечных while sleep 30 можно сказать: «ждать, пока файл появится в папке», и Airflow займётся этим сам.
В одном из следующих постов мы поднимем Airflow одной командой через Docker‑Compose и соберём первый «hello world» DAG.
Реальный сценарий задержки
Допустим, дамп БД обычно занимает пять минут. В одну из ночей, из‑за нагрузки, он растягивается до получаса. Если процесс управляется cron’ом, то в 02:05 по расписанию стартует следующий скрипт report.sh, тот читает ещё незаконченный дамп и отправляет пустой отчёт. Ошибку вы заметите только утром.
С Airflow всё иначе: пока задача dump_db не финишировала, зависимый make_report даже не начнётся. Когда дамп завершится успешно, DAG продолжит движение; если же он дважды упадёт подряд, Airflow пометит цепочку как failed и тут же пришлёт вам Telegram‑уведомление со ссылкой на лог.
Cron остаётся отличным будильником для одиночных задач, но когда шагов несколько и они зависят друг от друга, удобнее отдать управление оркестратору. Airflow даёт одну точку правды (DAG), автоматические ретраи, встроенное журналирование и мгновенные алёрты — и всё это пишется на чистом Python, без костылей.
LinuxCamp | Chat | #devops #bymaga