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

Question

我们使用“System Lag”来检查我们Dataflow作业的健康状况。例如，如果我们看到系统滞后时间的增加，我们将尝试看看如何降低这个指标。有关这一指标的问题很少。

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

数据的项目一直在等待处理

上面的最大时间是我们在GCP控制台看到，当我们打到信息图标。在这种情况下，数据项意味着什么？流处理具有窗口的概念，事件时间与处理时间，水印等的概念。什么时候被考虑等待处理的项目？例如，简单地说，当消息到达时，无论其状态如何？

• 2）该度量的最佳阈值是多少？

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

• 3）如何系统的滞后拖累汇

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

Answer 1

根据正在执行的管道，有一些地方可能会排队等待处理的元素。这通常是在机器之间传递元素时，例如在GroupByKey之间传递，尽管PubSub源也反映了最老的未包含元素。

对于给定的步骤（包含接收器）“系统滞后时间”度量该步骤最近输入队列中最老元素的年龄。

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

水槽的延迟取决于几个因素：

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

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