Airflow 动态 DAG 中的竞争条件
Race condition in Airflow dynamic DAG
我有一个看起来像这样的 Airflow DAG (Airflow 1.10.15)：
立方体类型：
- lvl0_parser：Kuberenetes 运算符
- get_rawdata_tables: Python 运算符
- end_of_data_collectors：虚拟运算符
- 其余所有（蓝色立方体）也是 Python 运算符。
我遇到了一个在极少数情况下发生的问题（我仍然无法弄清楚），即“end_of_data_collectors”多维数据集 (DummyOperator) 在前一个多维数据集完成之前启动。
一个重要的细节是多维数据集“get_rawdata_tables”创建了一个 JSON 文件，该文件描述了应该打开的下一个多维数据集（“get_rawdata_tables”和“end_of_data_collectors”之间的多维数据集）然后我们在 运行 时间打开它们 - DAG 不是静态的（我知道官方不支持或推荐它，但它可以工作 - 大多数时候）。所有触发规则都设置为默认的“成功时”
我怀疑是动态cube多的情况下DAG解析时间长的问题，但我不确定。
我的问题是：
- 如果我将 Airflow 调度程序配置为每分钟 运行，当每个多维数据集完成以验证下一个依赖项时，是否也会 运行ning？或者只是每一分钟，不管 DAG 中发生了什么。
- 我已经这样工作了 3.5 年，只有在将“end_of_data_collectors”更改为 DummyOperator（之前是 Kubernetes Operator）之后，我才在几个用例中发生过这种情况 - 你认为它可以吗有理由吗？此运算符中的某些行为有所不同，因此可以解释此问题？
- 你认为我关于调度程序和 DAG 解析之间竞争条件的理论有意义吗？
谢谢
我能弄明白，看起来 Airflow 调度程序忽略了 Dummy Operator 多维数据集（“end_of_data_collectors”），跳过它并将其标记为“成功完成”然后继续。
我还在 Airflow 代码中找到了这种行为的证据：
看起来在动态用例中使用 Dummy Operator 不是一个好主意。
我有一个看起来像这样的 Airflow DAG (Airflow 1.10.15)：
立方体类型：
- lvl0_parser：Kuberenetes 运算符
- get_rawdata_tables: Python 运算符
- end_of_data_collectors：虚拟运算符
- 其余所有（蓝色立方体）也是 Python 运算符。
我遇到了一个在极少数情况下发生的问题（我仍然无法弄清楚），即“end_of_data_collectors”多维数据集 (DummyOperator) 在前一个多维数据集完成之前启动。 一个重要的细节是多维数据集“get_rawdata_tables”创建了一个 JSON 文件，该文件描述了应该打开的下一个多维数据集（“get_rawdata_tables”和“end_of_data_collectors”之间的多维数据集）然后我们在 运行 时间打开它们 - DAG 不是静态的（我知道官方不支持或推荐它，但它可以工作 - 大多数时候）。所有触发规则都设置为默认的“成功时”
我怀疑是动态cube多的情况下DAG解析时间长的问题，但我不确定。
我的问题是：
- 如果我将 Airflow 调度程序配置为每分钟 运行，当每个多维数据集完成以验证下一个依赖项时，是否也会 运行ning？或者只是每一分钟，不管 DAG 中发生了什么。
- 我已经这样工作了 3.5 年，只有在将“end_of_data_collectors”更改为 DummyOperator（之前是 Kubernetes Operator）之后，我才在几个用例中发生过这种情况 - 你认为它可以吗有理由吗？此运算符中的某些行为有所不同，因此可以解释此问题？
- 你认为我关于调度程序和 DAG 解析之间竞争条件的理论有意义吗？
谢谢
我能弄明白，看起来 Airflow 调度程序忽略了 Dummy Operator 多维数据集（“end_of_data_collectors”），跳过它并将其标记为“成功完成”然后继续。
我还在 Airflow 代码中找到了这种行为的证据：
看起来在动态用例中使用 Dummy Operator 不是一个好主意。