Вопрос проверяет понимание того, как сенсоры проверяют условия и почему это может быть дорого с точки зрения ресурсов.
Polling — это периодическая проверка условия через заданный интервал времени. Сенсор «просыпается», проверяет условие и, если оно не выполнено, снова засыпает. Интервал задаётся параметром poke_interval. Такой подход прост, но может потреблять ресурсы, если сенсоров много. Поэтому polling нужно использовать аккуратно.
Polling — базовый механизм работы классических сенсоров в Airflow. Он прост в реализации, но имеет свои ограничения.
Polling — это регулярная проверка состояния внешнего ресурса через фиксированные интервалы времени.
Работа сенсора выглядит так:
Сенсор запускается.
Проверяет условие (poke).
Если условие ложно — ждёт poke_interval.
Повторяет шаги до успеха или таймаута.
Пример логики:
while not condition():
sleep(poke_interval)
Основные настройки сенсора:
poke_intervalинтервал между проверками;
слишком маленький → высокая нагрузка;
слишком большой → высокая задержка.
timeoutмаксимальное время ожидания;
по истечении сенсор падает с ошибкой.
Классические сенсоры:
занимают worker на всё время ожидания;
блокируют слот executor-а.
Это основной источник проблем при масштабировании.
Если:
много DAG;
много сенсоров;
длинные таймауты.
То:
воркеры простаивают;
задачи ждут своей очереди;
падает общая пропускная способность.
Polling — простой и понятный механизм ожидания, но он плохо масштабируется. Его стоит использовать только для коротких и редких ожиданий или заменять deferrable-сенсорами.