状态为空的气流任务

Question

在EC2的24倍大型计算机上运行时，气流出现问题。

我必须注意，并行度为256。

有几天，达格伦以“失败”状态结束，原因有两个未定：

1. 某些任务的状态为“ upstream_failed”，这是不正确的，因为我们可以清楚地看到前面的所有步骤都成功。

2. 其他任务的状态不是“ null”，它们尚未启动，并且会导致dagrun失败。

我必须注意，这两个任务的日志都是空的

这是这些情况下的tast实例详细信息：

请问有什么解决方案吗？

Answer 1

我遇到第二种情况（“其他任务的状态不为'null'”）的另一种情况是任务实例发生了更改，特别是更改了操作员类型。

我希望你已经得到了答案/能够继续前进。上个月，我在这个问题上被困了几次，所以我想我要记录一下我最终为解决该问题所做的事情。

---

示例：

• 任务实例最初是SubDag运算符的实例
• 要求导致运算符的类型从SubDag运算符更改为Python运算符
• 更改后，Python运算符设置为NULL

---

尽我所能拼凑，正在发生的事情是：

• 气流正在反思与每个任务相关的操作员
• 每个任务实例都登录到数据库表task_instance中
  • 此表的属性为operator
• 当调度程序重新检查代码时，它将寻找具有正确运算符类型的task_instance；没有看到它，它将状态（状态）=“已删除”更新关联的数据库记录
• DAG随后进行调度时，气流

通过查询，您可以看到受此过程影响的任务：

SELECT *
FROM task_instance
WHERE state = 'removed'

似乎在气流1.10的此问题上已有工作：

• https://github.com/apache/airflow/pull/3137/commits/db29af4ffb3d120ad55cd089a44b99feb7b8bf38

话虽这么说，但我不确定100％的提交是否可以解决此问题。似乎一般的哲学仍然是"when a DAG changes, you should increment / change the DAG name"。

我不喜欢这种解决方案，因为它很难迭代根本上是一个管道的内容。我使用的替代方法是（部分）遵循recommendations from Astronomer并“淘汰” DAG历史。为此，您需要：

• 停止调度程序
• Delete the history from the dag
  • 这应导致DAG从Web UI完全消失
  • 如果它没有完全消失，则表明调度程序仍在运行
• 重新启动调度程序
  • 注意：如果您按计划运行DAG，请准备好回填/追赶/运行最新的DAG，因为您已经删除了历史记录
  • 如果您不希望这样做，可以应用Astronomer的“快速转发DAG”建议

Answer 2

当手动更改任务状态（可能通过“标记成功”选项）或强制进入状态（如upstream_failed）并且任务从不接收hostname值时，可能会发生这种情况记录中，并且没有任何日志或PID