任务超时的两层控制
任务超时至少有两层控制：单任务执行超时（execution_timeout）限制一个任务最多跑多久，超时会被终止；批次超时（dagrun_timeout）限制一次 DagRun 的总时长。再往上还有一层「产出新鲜度」监控——盯目标表或分区的最晚就绪时间。前两层是执行侧约束，第三层才真正回答「今天的数是否按时可用」这个业务问题。
基本信息
| 任务级 | execution_timeout：单任务最长执行时间，超时被终止 |
|---|---|
| 批次级 | dagrun_timeout：整个 DagRun 的最长运行时间 |
| 产出级 | 监控目标表或分区的最晚就绪时间 |
| 重跑前提 | 任务需支持分区覆盖或 upsert，超时后才能安全重跑 |
典型使用场景
- 长跑任务防卡死：给重任务设执行超时，避免长期占用槽位
- 日切批次兜底：给关键链路设 DagRun 总时长上限
- 月末大批次：按历史峰值耗时评估超时值，避免误杀
- 产出承诺：与合作方约定产出时间并监控就绪状态
- 故障恢复：超时后按策略重试或转人工，保证当天数据补齐
Airflow 超时设置
Airflow 超时设置
from datetime import timedelta
task = BashOperator(
task_id='load_dwd',
bash_command='spark-submit /opt/jobs/dwd.py',
execution_timeout=timedelta(hours=1), # 单任务最长 1 小时，超时终止
retries=2, # 超时终止后按重试策略再跑一次
retry_delay=timedelta(minutes=5),
dag=dag,
)
# 批次级：DAG(..., dagrun_timeout=timedelta(hours=6)) 限制整批总时长超时层次与做法
| 层次 | 控制对象 | 不控制的后果 |
|---|---|---|
| 任务级 execution_timeout | 单个任务实例 | 任务卡死长期占用槽位 |
| 批次级 dagrun_timeout | 一次 DagRun | 批次挂住不结束，需人工发现 |
| 产出级新鲜度监控 | 目标分区就绪时间 | 漏掉「成功但没数据」的情况 |
超时终止后要能安全重跑：确认任务使用分区覆盖或 upsert 写目标表，否则超时留下的半成品会和重跑结果混在一起，产生重复或残缺。
超时时间设得过短，正常的大批次（月末、大促补数）会被误杀并触发重试风暴，反而更慢；应按历史峰值耗时留出余量再定阈值。