Airflow本地运行BigQueryOperator任务处于REMOVED状态未执行排查

我来帮你排查这个BigQueryOperator在UI触发时一直卡REMOVED状态的问题——毕竟你用airflow test能正常跑，说明任务本身逻辑没问题，大概率是调度或执行上下文的坑，下面是几个常见的排查方向：

• 检查DAG的调度配置与执行日期范围
  airflow test是指定执行日期强制运行，而UI触发会遵循DAG的默认调度逻辑。如果你的DAG配置有问题，Airflow可能认为没有需要执行的任务实例，直接标记为REMOVED：

  • 确认start_date是固定的过去时间（比如datetime(2024, 5, 1)），绝对不要用datetime.now()——每次DAG解析都会刷新这个时间，导致调度器无法识别有效执行窗口。
  • 如果是手动触发的DAG，建议把schedule_interval设为None或@once，避免自动调度逻辑干扰。
  • 在UI的DAG详情页，手动触发时指定一个明确的执行日期（选一个在start_date之后的时间），看看任务是否能正常进入队列。

• 检查任务的模板变量与上下文依赖
  airflow test是本地直接执行，不会完全模拟调度器的上下文环境，有些依赖模板变量的配置在UI触发时可能出问题：

  • 查看BigQueryOperator中是否使用了{{ ds }}、{{ execution_date }}这类模板变量，到UI的任务实例页面查看「Rendered Template」，确认SQL或参数是否被正确渲染。
  • 如果任务依赖上游任务的XCom输出，确认上游任务是否已经成功执行，或者手动触发时勾选了「Trigger DAG w/ config」并包含必要的上下文参数。

• 检查调度器与执行器的状态
  虽然BashOperator能正常运行，但调度器可能没正确处理BigQueryOperator的任务，或者执行器资源不足：

  • 查看调度器日志（airflow scheduler logs），搜索你的任务ID，看看有没有类似「Task not scheduled」的报错，或者权限、资源相关的提示。
  • 确认执行器配置（比如SequentialExecutor、LocalExecutor）是否符合你的需求：如果用SequentialExecutor，确保没有其他长运行任务占用执行资源。
  • 可以直接查看Airflow元数据库的task_instance表，看看该任务实例的state和error字段有没有具体信息。

• 检查BigQuery连接与worker权限
  airflow test用的是你本地用户的权限，而UI触发时用的是Airflow worker进程的身份，两者可能存在权限差异：

  • 确认Airflow连接中配置的BigQuery连接是否正确，worker进程能否访问到服务账号密钥文件（如果用的是服务账号认证）。
  • 检查worker进程的用户是否有BigQuery项目的访问权限，比如能否读取源表、写入目标表。
  • 查看worker的日志，搜索BigQuery相关的错误，比如认证失败、权限不足等。

• 检查DAG的并发限制配置
  如果DAG的并发参数设置得太低，新任务可能被直接移除：

  • 查看DAG定义中的concurrency（单DAG并发任务数）和max_active_runs（单DAG最大活跃运行数），建议暂时设为较大的值（比如10）测试。
  • 在UI的DAG设置页面，确认这两个参数的配置是否和代码一致。

如果以上排查都没问题，可以尝试重启Airflow调度器和worker——有时候缓存的状态异常会导致任务无法正常调度。

内容的提问来源于stack exchange，提问作者Tomas Jansson