Sensor 是做什么的
Sensor 是一类「等到条件成立才继续」的任务：等文件出现、等上游分区可查、等到某个时间点。它的关键配置是运行模式：poke 模式会按间隔反复检查，期间一直占着执行槽位；reschedule 模式则在两次检查之间释放槽位，由调度器到点再唤醒。等待时间长的场景如果不改成 reschedule，几个 Sensor 就能把 worker 槽位占满，让其他任务排队。
基本信息
| 常见 Sensor | FileSensor / ExternalTaskSensor / 各系统分区 Sensor |
|---|---|
| poke 模式 | 按 poke_interval 轮询并占住槽位 |
| reschedule 模式 | 轮询间释放槽位，由调度器再唤醒 |
| 超时控制 | timeout 到点任务失败 |
| 其他参数 | mode、poke_interval、soft_fail、deferrable |
| 替代方案 | 数据集/事件触发机制，避免轮询 |
reschedule 用法
reschedule 用法
from airflow.sensors.filesystem import FileSensor
wait_file = FileSensor(
task_id="wait_file",
filepath="/data/in/{{ ds }}.done",
poke_interval=60, # 每 60 秒检查一次
timeout=60 * 60 * 6, # 最多等 6 小时
mode="reschedule", # 等待期间释放执行槽位
)典型使用场景
- 等待上游文件：对方系统落 _SUCCESS 文件后再开始加工
- 等待分区就绪：轮询目标分区是否存在且有数据
- 跨 DAG 等待：等另一个 DAG 的同周期任务完成
- 等待外部系统：确认接口可用或第三方数据到达
- 限时人工确认：等待人工放行按钮，超时后失败并告警
- 环境探测：等依赖服务健康检查通过再提交下游任务
两种模式对比
| 模式 | 占槽位 | 适用 |
|---|---|---|
| poke | 一直占用 | 等待时间短（分钟级） |
| reschedule | 轮询间释放 | 等待时间长（小时级） |
| deferrable | 交给触发器进程 | 需要更细粒度资源控制时 |
| 超时后行为 | 任务失败并告警 | soft_fail 可改为跳过 |
大量 Sensor 用 poke 模式会把执行槽位占满，导致其它任务排队——长等待统一改 reschedule。
轮询间隔不是越小越好：间隔过密会给元数据库或被检查的外部系统带来持续压力，通常按上游实际产出节奏来设。
Sensor 的超时时间要和上游的承诺产出时间对齐：承诺 03:00 出数，超时就不该设成 02:30，否则每天都会失败告警造成告警疲劳。