我有一个管道,该管道产生的数据流图(序列化的JSON表示形式)超过了API的允许限制,因此无法像通常那样通过apache beam的数据流运行器启动。而且,使用指示的参数--experiments=upload_graph
运行数据流运行程序将无法正常工作,并且无法显示未指定任何步骤。
通过错误通知此尺寸问题时,将提供以下信息:
the size of the serialized JSON representation of the pipeline exceeds the allowable limit for the API.
Use experiment 'upload_graph' (--experiments=upload_graph)
to direct the runner to upload the JSON to your
GCS staging bucket instead of embedding in the API request.
现在使用此参数,确实确实会导致数据流运行程序将一个额外的dataflow_graph.pb
文件上载到通常pipeline.pb文件旁边的登台位置。我确认的事实确实存在于gcp存储中。
但是,gcp数据流中的作业在启动后立即失败,并显示以下错误:
Runnable workflow has no steps specified.
我已经尝试过使用各种管道(甚至是Apache Beam示例管道)使用该标志并看到相同的行为。
这可以通过使用单词计数示例来重现:
mvn archetype:generate \
-DarchetypeGroupId=org.apache.beam \
-DarchetypeArtifactId=beam-sdks-java-maven-archetypes-examples \
-DarchetypeVersion=2.11.0 \
-DgroupId=org.example \
-DartifactId=word-count-beam \
-Dversion="0.1" \
-Dpackage=org.apache.beam.examples \
-DinteractiveMode=false
cd word-count-beam/
不使用experiments=upload_graph
参数运行它即可:
(请确保指定您的项目,如果要运行它,请指定存储桶)
mvn compile exec:java -Dexec.mainClass=org.apache.beam.examples.WordCount \
-Dexec.args="--runner=DataflowRunner --project=<your-gcp-project> \
--gcpTempLocation=gs://<your-gcs-bucket>/tmp \
--inputFile=gs://apache-beam-samples/shakespeare/* --output=gs://<your-gcs-bucket>/counts" \
-Pdataflow-runner
使用experiments=upload_graph
运行它会导致管道失败,并显示消息workflow has no steps specified
mvn compile exec:java -Dexec.mainClass=org.apache.beam.examples.WordCount \
-Dexec.args="--runner=DataflowRunner --project=<your-gcp-project> \
--gcpTempLocation=gs://<your-gcs-bucket>/tmp \
--experiments=upload_graph \
--inputFile=gs://apache-beam-samples/shakespeare/* --output=gs://<your-gcs-bucket>/counts" \
-Pdataflow-runner
现在,我希望数据流运行程序将引导gcp数据流从指定的存储桶中读取步骤,如源代码所示:
但是事实并非如此。有没有人使它起作用,或者找到了一些有关此功能的文档,可以为我指明正确的方向?
答案 0 :(得分:0)
此后,实验已还原,并将在Beam 2.13.0中更正消息传递
还原PR
答案 1 :(得分:0)
我最近遇到了这个问题,解决方案非常愚蠢。我开发了一个非常复杂的数据流流作业,并且工作正常,第二天就停止工作,并出现错误“可运行工作流未指定任何步骤”。就我而言,有人在创建选项后两次指定了pipeline().run().waitUntilFinish()
,由于这个原因,我遇到了这个错误。删除重复的管道运行可解决此问题。我仍然认为在这种情况下,beam / dataflowrunner应该存在一些有用的错误跟踪。