Airflow任务状态为null

Question

我在EC2上的24xlarge机器上运行Airflow时遇到了问题。

我必须注意并行级别为256。

有几天dagrun以“失败”的状态结束，原因不明：

1. 一些任务的状态为“upstream_failed”，但实际上这不是真的，因为我们可以清楚地看到所有先前的步骤都成功了。 2. 其他任务的状态不是“null”，它们还没有开始，但它们导致dagrun失败。 我必须注意这两个任务的日志为空。

这些案例的测试实例详情如下：

请问有什么解决方案吗？

- I.Chorfi

---

运算符也是空的吗？ - mad_

是的，它总是为空。 - I.Chorfi

Answer 1

我曾经遇到过第二个条件（"其他任务的状态不为'null'"）的另一种情况，就是当任务实例发生变化，并且特别是变成了不同的运算符类型时。

我希望你已经得到答案或者成功解决了问题。在过去的一个月中，我也遇到了这个问题几次，因此我决定记录下我最终采取的解决方法。

---

示例：

• 任务实例最初是子Dag运算符的一个实例
• 要求将运算符类型从子Dag运算符更改为Python运算符
• 更改后，Python运算符的状态设置为空（NULL）

---

我尽力推断出正在发生的事情如下：

• Airflow正在检查与每个任务相关联的运算符
• 每个任务实例都记录在数据库表格task_instance中
  • 该表具有名为operator的属性
• 当调度器重新检查代码时，它会查找具有正确运算符类型的task_instance；如果没有找到，它会将相关的数据库记录更新为状态=“removed”
• 当DAG随后进行调度时，airflow

您可以使用以下查询查看受此过程影响的任务：

SELECT *
FROM task_instance
WHERE state = 'removed'

看起来airflow 1.10已经对此问题进行了修复：

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

话虽如此，根据我找到的提交记录，我不能百分之百确定这个修复措施可以解决这个问题。似乎整体哲学仍然是“当DAG发生变化时，您应该增加/更改DAG名称”。

我不太喜欢这种解决方案，因为它使基本上是一个流水线的迭代变得困难。我使用的替代方法部分地遵循Astronomer的建议，“展开”DAG历史记录。要做到这一点，您需要：

• 停止调度程序
• 删除DAG的历史记录
  • 这应该导致DAG完全从Web UI中消失
  • 如果它没有完全消失，则调度程序仍在某个地方运行
• 重新启动调度程序
  • 注意：如果您按计划运行DAG，请准备好进行补偿/追赶/运行其最新计划，因为您已经删除了历史记录
  • 如果不想这样做，则可以应用Astronomer的“快进DAG”建议

- Adam Bethke

Answer 2

这种情况可能发生在任务状态被手动更改（很可能是通过“标记成功”选项），或者被强制进入某个状态（如upstream_failed），并且任务记录上从未收到hostname值，因此不会有任何日志或PID。

- joebeeson

---

这很奇怪，因为没有手动干预发生过。 - I.Chorfi

“upstream_failed”状态适用于由于依赖项失败而无法运行的任务。 - joebeeson