目前正在使用标准pubsub_to_bigquery模板获得天文墙壁时间。仅解析大约 10 个键。WriteSuccessfulRecords放映时间超过 11 小时！
当我解决这个问题时，我发现这StreamingWrite是罪魁祸首，但是我可以立即在BigQuery.
这只是一个缓冲问题（即保持缓冲区可用/长时间打开）还是我应该担心？
1 回答
4
在流模式下，由于输入是无界的，因此步骤的壁时间将永远累积。您看到如此高的挂墙时间的原因是因为管道已经运行了 9 天，因此积累越来越大。壁时间定义为：
在此步骤中，在所有工作人员的所有线程中初始化、处理数据、混洗数据和终止所花费的大约时间。对于复合步骤，在组件步骤中花费的时间总和。
由于StreamingWrite转换对 BigQuery 服务进行 API 调用，这可能是管道中最昂贵的步骤（如果没有自定义转换），因为 API 调用离开了工作线程。
在您的情况下，每小时的挂钟秒数可以计算为
(((((11*60) + 16) * 60) + 31) / 9) / 24 = 187.92。这意味着该步骤每小时花费超过 3 分钟的时间写出该步骤中的插入。该步骤看起来很昂贵，因为它运行的时间量（以及累积的挂墙时间），但它实际上只是按预期工作。
于 2018-08-17T03:13:01.033 回答