Google Cloud Dataflow：使用 argparse 时 DirectRunner 与 DataFlowRunner 的不同行为答案

【问题标题】：Google Cloud Dataflow: Different behavior for DirectRunner versus DataFlowRunner when using argparseGoogle Cloud Dataflow：使用 argparse 时 DirectRunner 与 DataFlowRunner 的不同行为
【发布时间】：2018-01-26 15:18:16
【问题描述】：

我正在构建一个谷歌云数据流管道来处理视频。我很难调试管道，因为 DirectRunner 和 DataflowRunner 上的环境行为似乎不同。

我的视频处理工具（下面称为 DeepMeerkat）接收来自 argparse 的参数。我打电话给管道：

python run_clouddataflow.py \
    --runner DataFlowRunner \
    --project $PROJECT \
    --staging_location $BUCKET/staging \
    --temp_location $BUCKET/temp \
    --job_name $PROJECT-deepmeerkat \
    --setup_file ./setup.py \
    --maxNumWorkers 3 \
    --tensorflow \
    --training

其中最后两个参数 tensorflow 和 training 都用于我的管道，其余的用于 clouddataflow。

我解析 args 并将 argv 传递给管道

beam.Pipeline(argv=pipeline_args)

然后在 DeepMeerkat 的 argparse 中，只解析已知的 args。

args,_=parser.parse_known_args()

这在本地完美运行，关闭 tensorflow（默认开启）并开启训练（默认开启）。打印 args 确认该行为。但随后它无法解析云数据流，tensorflow 保持打开状态，并且训练关闭。

DirectRunner：

DeepMeerkat args: Namespace(tensorflow=False, training=True)

来自 DataFlowRunner 的日志记录：

DeepMeerkat args: Namespace(tensorflow=True, training=False)

对这里发生的事情有任何想法吗？相同的命令，相同的代码，只是将 DirectRunner 更改为 DataFlowRunner。

我宁愿不走passing custom arguments to pipeline options 的道路，因为我需要以某种方式将它们分配到下游，如果已经有一个解析参数的工具，这似乎是一个更直接的解决方案，只要有数据流工作者并没有什么特别之处。

【问题讨论】：

标签： argparse google-cloud-dataflow

【解决方案1】：

我对此有错误的概念模型。在本地，每个“worker”仍然可以访问 sys args，因此并不是 runner 的行为不同，而是“worker”正在绕过云管道并获取新的 args 进行解析。在 DataFlowRunner 中执行此操作的方法是使用

将管道参数显式传递给您的 DoFN 函数

__init__(self,args)

。然后在光束管道内部解析这些参数，就好像它们来自字符串一样。

【讨论】：