GCP数据流：用于从Pub / Sub IO流式传输的系统延迟

Question

我们使用“系统延迟”来检查Dataflow作业的运行状况。例如，如果我们看到系统延迟增加，我们将尝试了解如何降低此指标。有关此指标的问题很少。

• 1）系统滞后究竟意味着什么？

  

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

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

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

我们尽量保持这个指标尽可能低，但我们没有任何建议我们应该保持多低。例如，我们是否有一些建议，例如保持系统滞后在20到30秒之间是最佳的。

• 3）系统滞后如何暗示汇？

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

Answer 1

根据正在执行的管道，有许多元素可能排队等待处理。这通常是在机器之间传递元素时，例如在GroupByKey内，尽管PubSub源也反映了最旧的未应用元素。

对于给定步骤（包括接收器），“系统延迟”测量到该步骤的最近输入队列中最旧元素的年龄。

在这种情况下出现尖峰并不罕见 - 元素在处理后被拉出队列，因此如果传递了许多新元素，则队列恢复到可管理的大小可能需要一段时间。重要的是系统滞后在这些峰值之后会回落。

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

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

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