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

Posted 2023-03-31

【中文标题】GCP 数据流：从 Pub/Sub IO 流式传输的系统滞后

【英文标题】：GCP Dataflow: System Lag for streaming from Pub/Sub IO

【发布时间】：2017-07-21 09:51:49

【问题描述】：

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

1) 系统滞后究竟是什么意思？

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

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

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

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

3) 系统滞后如何影响接收器

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

【参考方案1】：

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

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

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

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

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

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