Airflow sensor ждёт файл: когда ожидание должно стать ошибкой

Отчёт должен быть готов к 09:00. Его DAG ждёт файл от поставщика, который обещан к 07:00. Sensor честно продолжает ждать до полудня, а команда получает зелёный отчёт слишком поздно для утреннего решения. Техническое ожидание файла и бизнес-дедлайн — разные вещи; второе нужно задать явно.

Sensor в Airflow периодически проверяет условие. Когда файл появился, задача завершается успешно и запускает последующие задачи. Если условие не выполнено до timeout, sensor переходит в ошибку и обычные механизмы мониторинга могут оповестить команду. Для источника с обещанием к 07:00 задайте конечный срок так, чтобы оставалось время на загрузку и проверки до 09:00.

Частота проверки не равна дедлайну

poke_interval задаёт паузу между проверками, а timeout — максимальное время ожидания с первой попытки. Если проверять каждые пять минут, файл может быть замечен с задержкой до следующей проверки. Увеличение интервала снижает число обращений к внешнему хранилищу, но может отодвинуть старт отчёта.

В режиме poke sensor держит worker slot во время всего ожидания. В режиме reschedule освобождает slot между проверками. Если одновременно ждут сотни ежедневных файлов по часу, второй режим снижает нагрузку на workers. Но он не делает файл доступным раньше и не исправляет слишком щедрый timeout.

Допустим, проверка начинается в 06:30, файл обещан к 07:00, обработка занимает 45 минут, а отчёт нужен к 09:00. Ожидание до 08:15 оставляет ровно 45 минут без запаса на проверку качества. Практичнее поставить дедлайн раньше, исходя из измеренного времени обработки и резерва на сбой. Такой расчёт полезнее настройки sensor по умолчанию.

Как не принять чужой файл

Проверяйте не просто существование orders.csv, а файл или маркер для конкретного data interval: например orders/2026-04-01/_SUCCESS. Иначе вчерашний файл может удовлетворить sensor сегодня. Маркер должен появляться только после полной выгрузки; появление незаконченного файла не означает готовности данных.

Если источник опоздал, не превращайте ошибку sensor в успешный пустой отчёт. Покажите в мониторинге, какой интервал не готов, когда источник должен был прийти и какой downstream заблокирован. Дальше оператор решит, ждать, использовать утверждённый резервный источник или перенести отчёт. Для каждого выбора важно сохранить историю принятого решения.

Для проверки настройки достаточно разложить путь до отчёта по времени. Sensor ждёт до 07:30; загрузка занимает обычно 20 минут, проверка качества 10, расчёт витрины 15. Теоретический результат готов к 08:15, но если 95-й процентиль общей обработки равен 70 минутам, запас до 09:00 составляет лишь 20 минут. Выбирайте timeout по наблюдаемым длительностям, а не по среднему удачному дню.

Состояние skipped тоже требует внимания. Параметр soft_fail может заменить ошибку ожидания пропуском. Это удобно для необязательного источника, но для обязательных заказов пропуск может привести к формально успешному DAG с неполными данными, в зависимости от зависимостей и правил запуска downstream. Определите, какие источники блокируют отчёт и какие разрешено пропускать, до настройки sensor.

Если источник публикует несколько файлов за день, маркер готовности должен означать полноту набора, а не только существование первого файла. Например, upstream сначала пишет временные имена, затем атомарно публикует манифест с ожидаемым количеством файлов. Sensor ждёт манифест, задача загрузки проверяет перечисленные объекты. Тогда задержка источника становится явным состоянием, а не случайным несовпадением числа строк в готовом отчёте.

На курсе Data Engineering Fast‑Track Airflow управляет зависимостями загрузки, проверками и downstream-расчётами. Изучите программу, чтобы связать ожидание внешнего источника с реальным временем готовности витрины.

Для корректной даты файла полезно отдельно понять интервал Airflow при повторном запуске.