Мониторинг и обзор инструментов

Финальный урок: как следить за пайплайнами в проде и куда расти дальше.

Мониторинг пайплайнов — отслеживание успешности, длительности и свежести данных конвейеров с автоматическими оповещениями о сбоях.

За чем следить

Запущенный в прод конвейер живёт сам по себе, и единственный способ узнать о проблеме раньше аналитика — мониторинг. Следят за тремя вещами: успешностью (задача упала?), длительностью (стала работать вдвое дольше — что-то не так) и свежестью данных (витрина обновилась сегодня?).

Отдельно стоит понятие SLA (Service Level Agreement) — обещание, что данные будут готовы к определённому времени. Например, «отчёт за вчера готов до 9 утра». Если конвейер не уложился, мониторинг сигналит независимо от того, упал он или просто затянулся. Для бизнеса срыв SLA часто важнее технического сбоя: аналитик, пришедший в 9 утра к пустому дашборду, не разбирается, почему — ему просто нечем работать.

Сигнал	О чём говорит
Задача FAILED	сбой — нужен разбор и перезапуск
Срыв SLA по времени	конвейер не успел к дедлайну
Долгая задача	деградация, рост данных, проблема в источнике
Старая партиция	данные не обновились — витрина устарела

Как работает под капотом

Airflow умеет слать алерты при падении задачи и проверять SLA. Простой мониторинг можно представить как проверку метрик и решение «слать ли алерт». На чистом Python:

runs = [
    {"day": "2026-06-20", "status": "success", "minutes": 12},
    {"day": "2026-06-21", "status": "failed", "minutes": 3},
    {"day": "2026-06-22", "status": "success", "minutes": 40},
]
SLA_MIN = 30
for r in runs:
    if r["status"] == "failed":
        print(f"{r['day']}: ALERT — задача упала")
    elif r["minutes"] > SLA_MIN:
        print(f"{r['day']}: ALERT — превышен SLA ({r['minutes']} мин)")
    else:
        print(f"{r['day']}: OK")

Вывод:

2026-06-20: OK
2026-06-21: ALERT — задача упала
2026-06-22: ALERT — превышен SLA (40 мин)

Экосистема: куда расти

Airflow дирижирует, но тяжёлую работу часто делают специализированные инструменты. Коротко о трёх главных:

dbt — фреймворк для шага Transform в ELT: преобразования пишутся как SQL-модели с тестами и документацией прямо в хранилище. Airflow обычно запускает dbt по расписанию.
Apache Spark — движок распределённой обработки больших данных. Когда данные не помещаются на одной машине, Transform выносят в Spark. Глубже — в нашем курсе PySpark.
Apache Kafka — распределённая очередь событий, основа streaming-конвейеров: источники пишут события в Kafka, потребители читают их в реальном времени.

Для подготовки данных перед загрузкой и быстрых преобразований в Python пригодятся наши курсы Pandas и NumPy — они отлично дополняют инженерный стек этого курса.

Частые ошибки

Полагаться на «само заметим». Без алертов о сбое узнают по жалобе на неверный отчёт — это поздно и бьёт по доверию.
Мониторить только падения. Задача может «успешно» отработать, но загрузить ноль строк; нужен контроль свежести и объёма.
Тащить Spark и Kafka в каждый проект. Это тяжёлые инструменты; пока данные помещаются на одной машине и хватает batch — они избыточны.

Итог

Мониторят успешность, длительность и свежесть данных, шлют алерты при сбоях.
Успешный запуск ≠ корректные данные: следят и за объёмом, и за свежестью.
dbt отвечает за Transform в ELT, Spark — за большие данные, Kafka — за streaming.