Question

我有一个涉及SubDagOperator的许多实例的工作流，其中的任务是在循环中生成的。该模式由以下玩具dag文件说明：

from datetime import datetime, timedelta
from airflow.models import DAG
from airflow.operators.dummy_operator import DummyOperator
from airflow.operators.subdag_operator import SubDagOperator

dag = DAG(
    'subdaggy-2',
    schedule_interval=None,
    start_date=datetime(2017,1,1)
)

def make_sub_dag(parent_dag, N):
    dag = DAG(
        '%s.task_%d' % (parent_dag.dag_id, N),
        schedule_interval=parent_dag.schedule_interval,
        start_date=parent_dag.start_date
        )
    DummyOperator(task_id='task1', dag=dag) >> DummyOperator(task_id='task2', dag=dag)
    return dag

downstream_task = DummyOperator(task_id='downstream', dag=dag)
for N in range(20):
    SubDagOperator(
        dag=dag,
        task_id='task_%d' % N,
        subdag=make_sub_dag(dag, N)
        ) >> downstream_task

我发现这是一种组织任务的便捷方式，特别是因为它有助于保持顶级DAG整洁，特别是如果子标本身包含更多任务（即数十个，而不仅仅是一对）。

问题是，这种方法不能很好地扩展，因为子标记的数量（示例中的20）增加了。我发现，当整个工作流程中创建的DAG对象总数超过大约200（生产工作流程很容易发生，特别是如果该模式多次出现）时，事情就会停滞不前。

所以问题是：有没有办法以这种方式组织任务（许多类似的子标签），可以扩展到数百或数千个子标记？一些分析表明该过程在DAG对象构造函数中花费了大量时间。也许有办法避免为每个SubDagOperators实例化一个新的DAG对象？

Answer 1

嗯，似乎这个问题的至少很大一部分确实是由于DAG构造函数的成本，而这在很大程度上是由于inspect.stack()的成本。我提出了一个简单的patch来用更便宜的方法替换它，并且确实看起来确实有所改进 - 以前无法为我加载的数千个子标记的流现在加载。我们会看看这是否随处可见。

具有许多子标记的工作流是否可以执行？

1 个答案: