GCP数据流：从发布/订阅IO流式传输的系统延迟

Question

我们使用“系统延迟”来检查我们的数据流作业的运行状况。例如，如果看到系统延迟增加，我们将尝试查看如何降低该指标。关于该指标几乎没有疑问。

• 1）系统滞后到底意味着什么？

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

以上是我们点击信息图标后在GCP控制台中看到的内容。在这种情况下，数据项是什么意思？流处理具有“窗口化”，事件时间与处理时间，水印等概念。什么时候考虑将某个项目等待处理？例如，仅仅是消息何时到达而不论其状态如何？

• 2）此指标的最佳阈值是多少？

我们试图将这一指标保持在尽可能低的水平，但是对于将其保持在最低水平我们没有任何建议。例如，我们是否有一些建议，例如将系统延迟保持在20s到30s之间是最佳的。

• 3）系统滞后如何影响汇

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

Answer 1

根据正在执行的流水线，元素可能在许多地方排队等待处理。通常，这是在元素之间在机器之间传递时（例如在内）GroupByKey，尽管PubSub源也反映了最早的未确认元素。

对于给定的步骤（包括接收器），“系统滞后”测量最接近该步骤的输入队列中最旧的元素的寿命。

这种措施经常会出现峰值-处理完元素后将其从队列中拉出，因此，如果交付了许多新元素，则可能需要一段时间才能将队列恢复到可管理的大小。重要的是在这些峰值之后，系统滞后时间会回落。

接收器的延迟取决于几个因素：

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

查看接收器的“数据水印”可能更容易，该“数据水印”报告处理接收器的（事件）时间的哪一点。