Airflow operators中context变量是什么？*context与**context有何区别

1. context 变量的来源、设置位置与使用说明 #

• 来源：context 是 Airflow 调度器在触发 Operator 的 execute 方法运行时，自动注入的运行时上下文对象，里面封装了当前任务执行关联的所有元数据，包括执行日期、所属 DAG 信息、上游任务执行状态、系统配置、自定义参数等内容。
• 可设置的位置：
  • 系统默认字段由 Airflow 核心自动注入，常见的默认字段有 execution_date（执行日期）、ti（TaskInstance 实例）、dag（所属 DAG 实例）、prev_execution_date（上一次调度执行日期）、next_execution_date（下一次调度执行日期）等
  • 自定义参数可通过三种方式注入 context：给单个 Operator 设置 params 参数，自定义内容会存入 context 的 params 字段；在 DAG 层面设置全局 params，会对 DAG 下所有 Operator 的 context 生效；使用 PythonOperator 时通过 op_kwargs 传递的参数也会直接合并到 context 中
• 使用时机与方法：
  • 使用时机：仅在 execute 方法的执行周期内可以拿到完整有效的 context，Operator 初始化的 __init__ 方法中无法获取，因为初始化阶段任务还未被调度，没有运行时数据。
  • 使用方法：直接从 context 字典中按键取值即可，示例如下：

    def execute(self, **context):
        # 获取执行日期
        exec_date = context["execution_date"]
        # 获取自定义参数
        my_custom_param = context["params"]["my_param"]
    

2. *context 和 **context 的区别与适用场景 #

• 语法层面差异：
  • *context 是 Python 的位置可变参数语法，会将调用函数时传入的所有未匹配位置参数打包为一个元组赋值给 context 变量
  • **context 是 Python 的关键字可变参数语法，会将调用函数时传入的所有未匹配关键字参数打包为一个字典赋值给 context 变量
• Airflow 场景下的差异：
  Airflow 调用 execute 方法时，所有上下文内容都是以关键字参数的形式传递的，因此标准写法是用 **context 接收，拿到的直接是键值对结构的上下文字典，可直接取值使用。
  少数示例中出现的 *context 写法属于不规范写法，或是兼容极老版本 Airflow 的特殊用法，实际使用时如果用 *context 接收，所有上下文参数会被打包为仅含一个字典元素的元组，需要额外取 context[0] 才能拿到实际的上下文内容，没有任何使用优势，还容易引发取值错误。
• 适用场景：
  所有当前维护的 Airflow 版本（2.x 及以上，甚至绝大多数 1.10+ 版本）开发自定义 Operator、编写 PythonOperator 回调函数时，统一使用 **context 接收上下文即可，没有需要使用 *context 的场景。

内容的提问来源于stack exchange，提问作者Alan Mil