Airflow 中“Last Run Time”与实际执行时间不一致的原因解析

花韻仙語 2026-01-06 00:00:00 次阅读

airflow web ui 显示的“last run time”实际指任务数据区间（data interval）的起始时间，而非任务真正触发或完成的时间点；日志和 dag 详情页中显示的时间则对应数据区间的结束时间，二者天然相差一个调度周期（如 hourly dag 相差 1 小时）。

在 Apache Airflow 中，“Last Run Time”这一字段常被误解为 DAG 最近一次实际执行开始或完成的时间，但其真实含义是该次调度所对应 data interval 的起始时间（data_interval_start）。而你在 DAG 详情页、任务日志及运行记录中看到的时间戳（例如 2025-05-01T09:00:00+00:00），绝大多数情况下反映的是 data_interval_end —— 即该次调度所处理的数据时间窗口的结束时刻。

以一个 schedule_interval='@hourly' 的 DAG 为例：

它会在 2025-05-01T09:00:00 触发一次运行，
但这次运行处理的是 [2025-05-01T08:00:00, 2025-05-01T09:00:00) 区间的数据，
因此：
- data_interval_start = 2025-05-01T08:00:00 → 显示为 “Last Run Time”（UI 摘要页）
- data_interval_end = 2025-05-01T09:00:00 → 显示为任务实例时间、日志时间、DAG 运行时间戳

这是 Airflow 的核心设计原则，并非 Bug，而是为了明确区分「处理哪段数据」与「何时处理这段数据」。自 Airflow 2.2 起，UI 已逐步强化对 data_interval_start / data_interval_end 的显式标注（如 DAG Run 页面顶部时间栏会同时显示两者）。

✅ 验证方式（在 DAG 中打印上下文）：

def print_interval(**context):
    print("Data Interval Start:", context["data_interval_start"])
    print("Data Interval End:  ", context["data_interval_end"])
    print("Execution Date (deprecated):", context["execution_date"])  # 已弃用，等价于 data_interval_start

task = PythonOperator(
    task_id="debug_interval",
    python_callable=print_interval,
    dag=dag
)

⚠️ 注意事项：

execution_date 在 Airflow 2.2+ 中已被标记为 deprecated，应统一使用 data_interval_start；
所有调度逻辑（如 {{ ds }}, {{ ts }}, {{ next_ds }} 等 Jinja 模板变量）均基于 data_interval 计算，而非系统当前时间；
若需获取任务实际触发时间，请使用 context['dag_run'].start_date（即 DAG Run 创建时间），但它可能因调度延迟而晚于 data_interval_end。

简言之：“Last Run Time”不是“最后跑的时间”，而是“最后跑的那个数据窗口从什么时候开始”。 理解 data interval 是掌握 Airflow 时间语义的关键起点。