Airflow 2 中 prev_execution_date 的替代方案详解

在 airflow 2 迁移中,已弃用的 `{{ prev_execution_date }}` 模板变量需通过 `taskinstance.previous_ti.execution_date` 或 `dagrun.get_previous_dagrun()` 获取前次执行时间,而非依赖过时的模板变量。

Airflow 2 对调度语义进行了重构,明确区分了 逻辑时间(logical date)数据区间(data interval)执行上下文时间(execution time)。因此,旧版模板变量如 prev_execution_date 已被移除——它曾模糊地表示“上一次任务实例的 execution_date”,但该值在 Airflow 2 的 DAG 运行模型中不再具备明确定义(尤其在回填、手动触发或非标准调度场景下易引发歧义)。

✅ 正确替代方式有两种,适用于不同场景:

WebShop开源网上购物系统

WebShop网上商店系统专注中小企业、个人的网上购物电子商务解决方案,淘宝商城系统用户/个人首选开店的购物系统!综合5500多用户的意见或建议,从功能上,界面美观上,安全性,易用性上等对网店系统进行了深度的优化,功能更加强大,界面模板可直接后台选择。WebShop网上商店系统特点:1 对于中小企业、个体、个人、店主和淘宝易趣等卖家,可利用WebShop快速建立购物网。2 源代码开放,利用WebS

  1. 获取前一个成功任务实例的执行时间(推荐用于任务级依赖判断)
    使用 TaskInstance.previous_ti 属性(仅当存在且成功完成时可用):

    def my_task(ti: TaskInstance, **kwargs):
        if ti.previous_ti and ti.previous_ti.state == "success":
            prev_exec_time = ti.previous_ti.execution_date
            print(f"Previous successful task ran at: {prev_exec_time}")
        else:
            print("No previous successful task instance found")
  2. 获取前一个 DAG 运行的执行时间(适用于 DAG 级调度逻辑)
    使用 DagRun.get_previous_dagrun() 方法(返回前一个 DagRun 对象,含 execution_date):

    from airflow.models import DagRun
    
    def my_task(ti: TaskInstance, **kwargs):
        prev_dag_run = DagRun.get_previous_dagrun(dag_run=ti.dag_run)
        if prev_dag_run:
            print(f"Previous DAG run started at: {prev_dag_run.execution_date}")
        else:
            print("No previous DAG run exists")

⚠️ 注意事项:

  • prev_data_interval_start_success 和 prev_data_interval_end_success 并非 prev_execution_date 的直接替代项——它们对应的是前一个成功运行所覆盖的数据区间端点(即 data interval),而 execution_date 在 Airflow 2 中已统一映射为 logical_date(即数据区间的起始时间)。二者语义不同,不可混用。
  • ti.previous_ti 仅在当前任务有前置同名任务实例且其状态为 success 时才有效;若需容错(如跳过失败),应结合 state 判断。
  • DagRun.get_previous_dagrun() 不校验状态,仅按 execution_date 降序查找最近的 DagRun,适合做调度链路判断,但不保证成功。

? 总结:
放弃模板变量思维,转向面向对象的上下文访问是 Airflow 2 的最佳实践。优先使用 ti.previous_ti.execution_date(任务粒度)或 DagRun.get_previous_dagrun().execution_date(DAG 粒度),并始终添加空值与状态校验,确保逻辑健壮性。

相关推荐:

Python 3.12下的异步ORM方案该如何选择?

encode/orm是Python3.12下最平衡易落地的异步ORM,因其整合SQLAlchemyCore、databases和typesystem,原生适配3.12事件循环策略,无协程泄漏与版本锁问题,安装即用且错误堆栈清晰。 直接说结论:在Python3.12下,encode/orm是目前最平衡...

如何实现Django项目的分表分库方案_利用Python中间件动态切换库

分库分表前须确认三件事:Django版本≥4.2、主键含路由信息(如user_id)、已弃用syncdb类命令;中间件动态切库需安全重绑connections;using()优先级最高,路由器次之,中间件仅预热连接;分表逻辑应收口至Manager层,但需防范并发表名错乱。 分库分表前必须确认的三件事...

为什么Python中NumPy的运算速度比原生List快_详解向量化计算与C底层原理

NumPy运算更快的关键在于绕过Python解释器开销、使用连续内存与向量化指令,而非单纯“用了C”;小数组易受缓存未命中和初始化开销影响,需保持数据连续、类型单一、操作可并行。 NumPy运算比Python原生list快,不是因为“它用了C”,而是因为它绕过了Python解释器的运行时开销,并把计...

Python子类如何调用父类方法_详解super函数在多重继承中的应用

super()是Python多重继承中确保MRO正确执行的必需机制,所有参与类必须统一使用,否则链式调用会静默中断;其三种写法各适配不同上下文,而显式父类调用仅适用于绕过MRO的特定场景。 super()是Python中调用父类方法的推荐方式,尤其在多重继承场景下,它能避免重复调用、保证方法解析顺序...

PyTube 400 Bad Request 错误的根源分析与稳定替代方案

pytube因youtube后端接口变更频繁触发http400错误,根本原因在于其请求结构已过时;升级至最新版可临时缓解,但长期推荐迁移到维护更活跃、兼容性更强的yt-dlp或pytubefix。 pytube因youtube后端接口变更频繁触发http400错误,根本原因在于其请求结构已过时;升级...

Python如何实时监控文件夹变动_基于watchdog库的监听方案

watchdog监听器启动后没反应,需检查事件处理器是否注册及主线程是否被阻塞;必须显式调用observer.join()或time.sleep()维持进程存活,否则程序退出导致监听终止。 watchdog监听器启动后没反应?检查事件循环和阻塞点 watchdog本身不自动运行事件循环,Observ...