Google Cloud Dataflow Pub/Sub to BigQuery 模板 WriteSuccessfulRecords wall time答案

【问题标题】：Google Cloud Dataflow Pub/Sub to BigQuery template WriteSuccessfulRecords wall timeGoogle Cloud Dataflow Pub/Sub to BigQuery 模板 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 条记录（物联网数据传入）
我不想真正看到数据 - 我想看看为您提供这些结果的管道是如何精确配置的。

标签： google-bigquery google-cloud-dataflow

【解决方案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虽然感谢分解！