Airflow 中的传感器- 是一种特定类型的操作员,它将一直运行直到满足特定标准,但它们会占用一个完整的工作槽。好奇人们是否能够可靠地使用更有效的方法来实现这一点。
我脑海中的一些想法
- 使用池来限制分配给传感器的工作槽数量
- 跳过下游的所有任务,然后通过外部触发器清除和恢复
- 暂停 DAG 的运行并通过外部触发器再次恢复
其他相关链接:
Airflow 中的传感器- 是一种特定类型的操作员,它将一直运行直到满足特定标准,但它们会占用一个完整的工作槽。好奇人们是否能够可靠地使用更有效的方法来实现这一点。
我脑海中的一些想法
其他相关链接:
Airflow 的新版本,即 1.10.2 为传感器提供了新的选项,我认为可以解决您的问题:
mode (str) – 传感器如何工作。选项是:{戳| 重新安排},默认是戳。当设置为 poke 时,传感器在其整个执行时间内占用一个工作槽,并在 poke 之间休眠。如果传感器的预期运行时间很短或需要较短的戳间隔,请使用此模式。当设置为重新安排时,传感器任务在尚未满足条件时释放工作槽,并在稍后重新安排。如果满足条件的预期时间是,请使用此模式。戳间隔应超过一分钟,以防止调度程序负载过多。
这是文档的链接。
我认为您需要退后一步,质疑为什么传感器占用一个完整的工作槽是一个问题。
Airflow 是一个调度器,而不是一个资源分配器。使用工作并发、池和队列,您可以限制资源使用,但只能非常粗略。最后,Airflow 天真地假设传感器将在工作节点上使用与产生多进程基因组测序实用程序的 BashOperator 相同的资源。但是传感器很便宜,而且 99.9% 的时间都在睡觉,所以这是一个糟糕的假设。
因此,如果您想解决传感器占用所有工作槽的问题,只需提高工作器的并发性即可。您应该能够在单个工作人员上同时运行数百个传感器。
如果您在集群节点和具有危险的高系统负载的节点上遇到工作负载分布非常不均匀的问题,您可以使用以下任一方法限制昂贵作业的数量:
airflow worker --queues my_expensive_queue
)并且具有低并发设置。这会创建每个节点的限制。如果您有比这更复杂的要求,请考虑将所有重要的计算作业发送到专用资源分配器,例如Apache Mesos,您可以在其中指定确切的 CPU、内存和其他要求,以确保更有效地分配集群负载在每个节点上,Airflow 将永远无法做到。
根据此文档,跨 DAG 依赖项是可行的
可以在单独的 DAG 中将条件指定为单独的任务,以便在给定日期满足该条件时,允许运行子任务。