从 Composer 触发时，DataFlow 作业启动时间过长

Question

赏金将在 6 天后到期。 此问题的答案有资格获得+50声望赏金。 Aaron Gonzalez希望引起对这个问题的更多关注。

我有一个具有以下架构的 static 管道：

 main.py
 setup.py
 requirements.txt
 module 1
   __init__.py
   functions.py
 module 2
   __init__.py
   functions.py
 dist
   setup_tarball

setup.py 和 requirements.txt 包含将由 Dataflow 工作节点使用的非本机 PyPI 和本地函数。 数据流选项编写如下：

import apache_beam as beam
from apache_beam.io import ReadFromText, WriteToText
from apache_beam.options.pipeline_options import PipelineOptions
from module2.functions import function_to_use

dataflow_options = ['--extra_package=./dist/setup_tarball','temp_location=<gcs_temp_location>', '--runner=DataflowRunner', '--region=us-central1', '--requirements_file=./requirements.txt]

那么管道将运行如下所示：

options = PipelineOptions(dataflow_options)
p = beam.Pipeline(options=options)
transform = (p | ReadFromText(gcs_url) | beam.Map(function_to_use) | WriteToText(gcs_output_url)) 

在本地运行此程序大约需要 6 分钟才能完成 Dataflow，其中大部分时间用于工作人员启动。 我尝试使用 Composer 自动化此代码并重新安排架构如下：我的主要（dag）function 在 dags 文件夹中，模块在插件中，setup_tarball 和 requirements.txt 在数据文件夹中......所以唯一真正的参数改变的是：

'--extra_package=/home/airflow/gcs/data/setup_tarball'
'--requirements_file=/home/airflow/gcs/data/requirements.txt'

当我尝试在 Composer 中运行这个修改后的代码时，它会工作......但它会花费更多、更长的时间......一旦工作人员启动，实际运行管道之前需要 20-30 分钟（其中只需几秒钟）.. 这比从我的本地代码触发数据流要长得多，后者只需要 6 分钟即可完成。 我意识到这个问题很笼统，但由于代码有效，我认为它与 Airflow 任务本身无关。 从哪里开始寻找解决此问题的合理位置？ 在Airflow级别，可以修改什么？ Composer (Airflow) 如何与 Dataflow 交互，什么可能导致这个瓶颈？

Answer 1

事实证明，这个问题与 Composer 本身有关。 解决方法是增加 Composer 的容量，即增加 vCPU。 不知道为什么会这样，所以如果有人知道这个问题背后的基础，你的意见将不胜感激！