这不是我的确切情况，但确实可以解释我问题的情况。
假设一个AWS S3存储桶包含未知数量的文件。我已经写了能够在单个文件上执行所需任务的运算符，而我的目标是并行化该过程。理想情况下，我想要一个从SubDagOperator继承并完成类似于以下内容的运算符：
def fn_generate_operator_for_s3_file(s3_file):
task_id = unique_task_id_for_s3_file(s3_file)
return MyS3FileActionOperator(task_id=task_id, s3_file=s3_file)
AwsS3BucketMapOperator(SubDagOperator):
def __init__(aws_s3_bucket_config, fn_generate_operator_for_s3_file, **kwargs):
# Disregard implementation, just know that it retrieves the bucket
aws_s3_bucket = get_aws_s3_bucket(aws_s3_bucket_config)
with DAG(subdag_name, ....) as subdag:
for s3_file in aws_s3_bucket:
operator_task = fn_generate_operator_for_s3_file(s3_file)
# operator_task should be added to subdag implicitly due to the `with` context manager statement
super(AwsS3BucketMapOperator, self).__init__(subdag=subdag, **kwargs)
本质上，我希望能够使用传递的一些operator_generator可调用对象，映射一个已知的能够处理S3存储桶中所有文件（或一些经过过滤的文件集）上的S3文件的任意运算符。到Map运算符，以便实际实例化subdag运算符。
注意事项：我对如何发现DAG的理解是DAG中的Operator实例的__init__方法都是在DAG本身的实际执行阶段之前运行的，并且它实际上是在连续进行发现过程。
在某些情况下，实际收集准确确定需要生成哪些subdag运算符所需的配置的过程在计算上非常昂贵。
理想情况下，我想让subdag的生成过程只运行一次，而我能看到的唯一方法是subdag的生成是否发生在Map Operator类的execute()方法中。但是，这样做会导致在DagBag中找不到subdag，从而无法运行。有没有办法解决？
如果无法在执行时以编程方式确定子数据的内容，是否有方法来限制生成子数据所需的昂贵操作的运行频率？