我正在尝试优化从PubSubIO提取消息并将这些消息发送到第三方API的管道。我有一个有趣的发现,就是如果在GroupBy
之后放置PubSubIO.read
和“ Degroup”转换,则管道的吞吐量会大大增加。我添加了GroupBy
只是为了防止融合优化,现在我想知道转换是如何在给定管道中准确合并的。
找出融合后管道的外观的最佳方法是什么?
答案 0 :(得分:5)
您可以通过调用project.locations.jobs.get或通过运行以下命令通过gcloud来访问优化的图形和融合阶段:
gcloud dataflow jobs describe --full $JOB_ID --format json
根据响应的输出,将在ExecutionStageSummary数组内的ComponentTransform对象下描述融合阶段。以下是Cloud Pub/Sub to BigQuery Google提供的模板的输出示例。在这种情况下,我们可以看到图形被分为3个步骤,这些步骤主要由BigQueryIO接收器中的Reshuffle
步骤划定:
Reshuffle
和WriteSuccessfulRecords
WriteFailedRecords
之前的所有转换
Reshuffle
中的WriteSuccessfulRecords
之后的所有转换
Reshuffle
中的WriteFailedRecords
之后的所有转换
由于工作描述非常冗长,因此您可以考虑将输出传递到jq
以便在诸如以下的单行命令中轻松提取相关位:
gcloud dataflow jobs describe --full $JOB_ID --format json | jq '.pipelineDescription.executionPipelineStage[] | {"stage_id": .id, "stage_name": .name, "fused_steps": .componentTransform }'