GCP Dataflow：从Pub/Sub IO流式传输的系统延迟

Question

我们使用“系统延迟”来检查我们的Dataflow作业的健康状况。例如，如果我们看到系统延迟增加，我们会尝试找出如何降低此指标。关于这个度量标准有一些问题。

1）什么是系统延迟的确切含义？

答：数据项等待处理的最长时间。

以上是我们在GCP控制台上点击信息图标时看到的内容。在这种情况下，“数据项”是什么意思？流处理有窗口化、事件时间与处理时间、水印等概念。何时将数据项视为等待处理？例如，是否只是消息到达时就立即等待处理？

2）这个指标的最佳阈值是多少？

答：我们尽可能将此指标保持在最低水平，但我们没有任何建议，关于应该将其保持多低的建议，例如保持系统延迟在20秒至30秒之间是最佳的建议吗？

3）系统延迟如何影响接收器？

答：系统延迟如何影响事件本身的延迟？

- user_1357

Answer 1

根据正在执行的流水线，可能会有许多元素在等待处理。这通常是当元素在机器之间传递时发生的，例如在GroupByKey中，虽然PubSub源也反映了最旧的未确认元素。

对于给定的步骤（包括sink），“系统滞后”测量最接近该步骤的输入队列中最古老元素的年龄。

这种度量存在波动并不罕见--元素在处理后会从队列中取出，因此如果有很多新元素被传递，可能需要一段时间才能使队列恢复到可管理的大小。重要的是这些波动后系统滞后是否会回落。

sink的延迟取决于几个因素：

1. 元素到达管道的速率限制了输入水印前进的速率。 2. 窗口和触发器的配置影响了管道在发出特定窗口前必须等待多长时间。 3. 系统滞后是正在执行管道内部代码引入的额外延迟的度量。

查看sink的“数据水印”可能更容易，它报告了在（事件）时间上sink已经被处理到了哪个点。

- Ben Chambers