Почему зелёный DAG не всегда означает, что данные свежие: разбор инцидента

Airflow отмечает DAG как успешный, но аналитики видят в витрине данные за предыдущий день. Ниже — разбор типового сценария для Apache Airflow 2.10.x и хранилища с таблицами, разбитыми по датам. Это реконструкция, а не описание подтверждённого инцидента конкретной компании: численные замеры и таймлайн нужно строить по данным вашей системы.

Инцидент: запуск успешен, а данные отстают

Представим конвейер: задача забирает данные из источника, следующая преобразует их, последняя публикует партицию в хранилище. Утренний запуск завершился без ошибки. При этом часть исходных записей пришла позже обычного, уже после того, как задача чтения проверила источник. Витрина получила неполный срез, а повторного запуска не было: технически все задачи выполнились успешно.

Проблема не в том, что оркестратор «не заметил падение». Он сообщил состояние задач, а не подтвердил, что в итоговой таблице есть полный набор данных за нужный период. Это разные гарантии. Успешный DAG означает, что запланированные задачи дошли до успешного состояния; само по себе это не доказывает свежесть или полноту результата.

Мониторинг конвейера должен отвечать не только на вопрос «задача закончилась?», но и на вопрос «какие данные она опубликовала и за какой период?»

Водяной знак (watermark) — отметка о том, до какого момента времени источник или конвейер считает данные обработанными. Это может быть время события, время загрузки или номер последнего обработанного пакета. Важно заранее определить, какое именно значение используется: смешение этих времён создаёт ложное ощущение свежести.

Как локализовать разрыв

Начинайте не с перезапуска всего DAG, а с последнего периода, который бизнес считает неполным. Сопоставьте его с логами задач и фактическим содержимым целевой таблицы. В Airflow 2.10.x история запусков и состояния задач помогают увидеть, где остановилась или задержалась обработка; для конкретных метрик и настройки экспорта сверяйтесь с документацией именно этой версии.

1. Зафиксируйте ожидание. Уточните, за какую дату и к какому сроку витрина должна быть готова. Проверьте часовой пояс и границы периода: «данные за вчера» без этих уточнений может означать разные интервалы. Результат шага — однозначный целевой период.
2. Проверьте запуск и задачи. Посмотрите, когда стартовал DAG, какие задачи завершились, сколько заняли и были ли повторы. Отдельно проверьте очередь: поздний старт из-за ожидания свободного исполнителя отличается от долгой обработки. Результат — цепочка фактических событий, а не только зелёный статус.
3. Сравните источник и приёмник. Для одного и того же периода проверьте количество записей, максимальное время события или другое контрольное значение, подходящее вашей модели данных. Результат — понятно, на каком участке исчезла задержка: до чтения, при передаче или после загрузки.
4. Проверьте публикацию. Убедитесь, что витрина читает нужную партицию и что публикация не оставила старый срез доступным вместо нового. Сравните время последнего обновления с временем данных внутри таблицы. Результат — отличаете свежую загрузку от действительно свежего содержания.
5. Восстановите и перепроверьте. Запустите безопасное дозаполнение или пересчёт по затронутому периоду, если это допускает логика конвейера. После завершения повторите проверки полноты и свежести, а не ограничивайтесь зелёным статусом. Результат — есть подтверждение, что нужный период восстановлен.

Какие сигналы разделяют похожие сбои

Один сигнал редко даёт диагноз. Например, задержка запуска, медленная обработка и поздняя доставка источника могут одинаково выглядеть для пользователя: «отчёт устарел». Поэтому связывайте статус оркестратора с показателями данных и временем прохождения этапов.

Для каждого показателя задайте владельца и действие при срабатывании. Например, сигнал о старой витрине должен вести не просто в общий канал уведомлений, а к проверке конкретного периода и ответственного этапа. Порог выбирайте из договорённого срока доступности данных и обычного разброса длительности запусков. Здесь нет универсального числа: его нужно получить из истории именно вашего конвейера.

Почему обычная проверка статуса не спасает

Статус задачи отвечает на вопрос, выполнился ли её код без зарегистрированной ошибки. Он не проверяет автоматически, что источник уже выдал все события, что фильтр не отбросил часть строк или что downstream-таблица обновилась для нужного бизнес-периода. Даже проверка количества строк может обмануть: объём иногда меняется естественно, а повторная загрузка может создать дубли.

Подберите контроль к смыслу данных. Для одних таблиц важны уникальность ключей и отсутствие пропусков; для других — временная свежесть, допустимый диапазон объёма или сверка с системой-источником. Условия должны учитывать пустые периоды: ноль строк иногда означает сбой, а иногда — корректный результат. Зафиксируйте это правило вместе с владельцем данных.

Где такая схема ломается

• Поздние события. Если источник присылает данные задним числом, проверка свежести по времени загрузки может пропустить неполноту. Отслеживайте время самого события, когда оно доступно, и предусмотрите обработку опоздавших данных.
• Повторный запуск. Повтор может исправить пропуск, но при неидемпотентной загрузке добавить дубликаты. До автоматического повтора проверьте, можно ли безопасно пересчитать период.
• Бэкфилл. Массовая обработка истории увеличит длительности и очередь. Не сравнивайте её напрямую с обычными ежедневными запусками и не поднимайте тревогу только из-за ожидаемого изменения времени.
• Часовые пояса и переходы времени. Если источник, планировщик и хранилище по-разному трактуют границы суток, контроль свежести будет срабатывать не в тот момент. Зафиксируйте временную зону и способ расчёта периода.
• Здоровый DAG, сломанный контракт. Задачи могут завершиться, даже если схема источника изменилась и поле стало пустым. Добавьте проверки критичных полей и отдельно оповещайте об изменении структуры.

Не маскируйте сигнал постоянными повторами. Если задача регулярно завершается только после нескольких попыток, это не «самоисцеление», а наблюдаемый симптом. Разделите временные ошибки зависимости и ошибки данных: для первых может помочь повтор, для вторых нужен разбор причины и явная проверка результата.

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

Универсальные цифры здесь были бы выдумкой: без характеристик источника, объёма данных, расписания и ресурсов нельзя честно обещать, что новый контроль сократит задержку на конкретный процент. Вместо этого сравните до и после на одинаковых типах запусков: фактическую свежесть витрины, задержку старта, длительность каждого этапа, долю повторов и число пропущенных или повторно загруженных записей.

Проверяйте период, когда источник задерживается, и период обычной работы. Если система поддерживает безопасный тестовый прогон, воспроизведите опоздание входных данных отдельно от сбоя вычислителя. Фиксируйте условия: объём выборки, параллельность, расписание и состав этапов. Иначе сравнение покажет только то, что два запуска были разными.

Что делать дальше

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

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