【发布时间】:2022-12-24 14:58:51
【问题描述】:
我有一个在 Apache Beam 中定义的数据流作业,它正常工作但当我尝试将所有自定义命令行选项包含在我传递给 beam.Pipeline(options=pipeline_options) 的 PipelineOptions 中时中断。它在构建图之后,但在第一步开始之前失败,因为工作人员在启动后变得无响应,最终作业超时,没有有用的日志。
我想传递我的自定义选项,因为只有直接传递给管道的选项才会显示在 Dataflow 控制台 UI 的右侧,并且能够非常方便地查看它们。
全broken example is here。有效的旧版本看起来或多或少像这样
def run():
parser = argparse.ArgumentParser()
# Many parser.add_argument lines
known_args, pipeline_args = parser.parse_known_args()
pipeline_options = PipelineOptions(pipeline_args)
pipeline_options.view_as(SetupOptions).save_main_session = True
with beam.Pipeline(options=pipeline_options) as p:
# Pipeline definition
不起作用的代码看起来像这样
class CustomOptions(PipelineOptions):
@classmethod
def _add_argparse_args(cls, parser):
# same lines of parser.add_argument
def run():
pipeline_options = CustomOptions()
pipeline_options.view_as(SetupOptions).save_main_session = True
with beam.Pipeline(options=pipeline_options) as p:
# Same pipeline definition
这是我最终传递给 PipelineOptions 对象的额外键。
api_key
dataset_id
date_column
date_grouping_frequency
input_bigquery_sql
input_mode
org_id
output
output_executable_path # This one isn't really me, it just ends up in there
撇开 argparse/PipelineOptions API 似乎完全基于副作用不谈,我无法理解为什么这会导致作业无法启动。我最好的猜测是我正在通过的选项之一是覆盖/对工作人员产生一些意想不到的副作用,但我以前做过这种事情所以我知道通常可以通过这样的选项和让管道工作。
有人可以发现可能导致第一个工作人员反应迟钝的问题吗?我传递选项的方式似乎是问题所在。
【问题讨论】:
标签: google-cloud-dataflow apache-beam