streaming - GCP 数据流 : System Lag for streaming from Pub/Sub IO

Question

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

1) 系统滞后到底是什么意思？

The maximum time that an item of data has been awaiting processing

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

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

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

3)系统滞后如何影响汇

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

Answer 1

根据正在执行的管道，元素可能在许多地方排队等待处理。这通常是在机器之间传递元素时，例如在 GroupByKey 中。 ，尽管 PubSub 源也反射(reflect)了最旧的未确认元素。

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

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

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

元素到达管道的速率限制了输入水印前进的速率。

窗口和触发器的配置会影响管道在发出给定窗口之前必须等待的时间。

系统滞后是衡量流水线中执行的代码当前引入了多少附加延迟的指标。

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