Google Cloud Dataflow Pub/Sub to BigQuery 模板 WriteSuccessfulRecords wall time
Posted
技术标签:
【中文标题】Google Cloud Dataflow Pub/Sub to BigQuery 模板 WriteSuccessfulRecords wall time【英文标题】:Google Cloud Dataflow Pub/Sub to BigQuery template WriteSuccessfulRecords wall time 【发布时间】:2018-08-16 21:43:06 【问题描述】:目前使用标准pubsub_to_bigquery
模板获得天文挂钟时间。仅解析大约 10 个键。 WriteSuccessfulRecords
显示超过 11 小时!
当我发现这个问题时,我发现StreamingWrite
是罪魁祸首,但是我可以立即在BigQuery
中看到数据。
这只是一个缓冲问题(即保持缓冲区可用/长时间打开)还是我应该担心?
【问题讨论】:
你能粘贴一些代码吗? 被解析到输入数据流的 pub/sub 的数据是简单的键/值:"keyA":"valueA","keyB":"valueB","keyC":"valueC" ,"keyD":"valueD" 然后插入到 bigquery 中 您运行管道多久了,您向管道发布了多少条记录? @RyanMcDowell 管道已运行 9 天,每分钟持续接收 23 条记录(物联网数据传入) 我不想真正看到数据 - 我想看看为您提供这些结果的管道是如何精确配置的。 【参考方案1】:在流模式下,由于输入是无限的,因此步骤的挂墙时间将永远累积。您看到如此高的挂墙时间的原因是因为管道已经运行了 9 天,因此积累越来越大。挂壁时间定义为:
在此步骤中在所有工作人员的所有线程中初始化、处理数据、混洗数据和终止所花费的大约时间。对于复合步骤,在组件步骤中花费的时间总和。
由于StreamingWrite 转换对 BigQuery 服务进行 API 调用,这可能是管道中最昂贵的步骤(如果没有自定义转换),因为 API 调用离开了工作线程。
在您的情况下,每小时的挂钟秒数可以计算为
(((((11*60) + 16) * 60) + 31) / 9) / 24 = 187.92
。这意味着该步骤每小时花费超过 3 分钟的时间写出该步骤中的插入。该步骤看起来很昂贵,因为它运行的时间量(以及累积的挂墙时间),但它实际上只是按预期工作。
【讨论】:
感谢瑞恩的回复。有没有办法确定该步骤处理每条消息的平均时间? 您将无法编辑核心转换来执行此操作,但您可以在自己的自定义 ParDo 中执行此操作,并使用带有分布度量 (beam.apache.org/documentation/sdks/javadoc/2.6.0/org/apache/…) 的 Metrics API 进行转换。您可以在 Metrics API (github.com/apache/beam/blob/master/sdks/java/core/src/test/java/…) 的单元测试中看到此功能的一些示例代码 @RyanMcDowell 您的计算中/ 9
和/ 24
是从哪里来的?是否有任何其他文档资源实际指定了“Wall time”?
@Cristian -- 等式的第一部分将StreamingWrite
步骤的挂墙时间以秒为单位。 11 hours * 60 minutes in an hour
获取会议记录。然后我们将步骤的16 minutes
添加到该结果中。然后我们再次乘以60
并加上31
得到总时间(以秒为单位)。然后,由于管道一直在为9 days
运行,我们除以9
,然后除以24
以得到以小时为单位的细分。运行 Dataflow 作业时,侧边栏上有一个帮助工具提示,用于解释挂起时间。
我看过它,它准确地说明了您在回答中引用的内容。但这不是很容易理解,而且它对wall time的定义与传统的定义不同en.wikipedia.org/wiki/Elapsed_real_time虽然感谢分解!以上是关于Google Cloud Dataflow Pub/Sub to BigQuery 模板 WriteSuccessfulRecords wall time的主要内容,如果未能解决你的问题,请参考以下文章
如何使用 DataFlow 和 Cloud Pub Sub 确保幂等性?
Google Cloud Dataflow 和 Google Cloud Dataproc 有啥区别?
在 google-cloud-dataflow 中使用文件模式匹配时如何获取文件名