Cloud Dataflow 新鲜度和延迟的确切定义是什么？

Question

问题：

使用 Cloud Dataflow 时，我们会看到 2 个指标（请参阅此页面）：

1. 系统延迟
2. 数据新鲜度

这些在 Stackdriver 中也可用以下名称（摘自此处）：

system_lag：数据项等待处理的当前最大持续时间，以秒为单位。

data_watermark_age：管道已完全处理的最新数据项的年龄（自事件时间戳起的时间）。

但是，这些描述仍然非常模糊：

1. “等待处理”是什么意思？消息在 pubsub 中等待多长时间？或者它必须在管道内等待的总时间？
2. “最大持续时间”：在处理了最大项目后，是否会调整指标？
3. “自事件时间戳起的时间”是否意味着如果我的事件在时间戳 t1 被放入 pubsub 并且它在时间戳 t2 从管道的一端流出，管道在 t1？我想我可以假设，如果指标在 t1，则可以假设处理 t1 之前的所有内容。

题：

由于这些指标与 Apache Beam 的语义一致，我希望看到一些示例，或者至少对这些指标进行更清晰的定义以使其可用。

Answer 1

这些指标是出了名的棘手。Beam / Dataflow 团队的一名成员在本次演讲中可以深入了解它们的工作方式。

管道分为内存中发生的一系列计算，以及需要将数据序列化到某种数据存储的计算。例如，考虑以下管道：

with Pipeline() as p:
  p | beam.ReadFromPubSub(...)  \
    | beam.Map(parse_data)
    | beam.Map(into_key_value_pairs) \
    | beam.WindowInto(....) \
    | beam.GroupByKey() \
    | beam.Map(format_data) \
    | beam.WriteToBigquery(...)

这条管道将分为两个阶段。阶段是可以在内存中应用的一系列计算。

第一阶段从ReadFromPubSub到GroupByKey操作。这两个 PTransform 之间的所有内容都可以在内存中完成。要执行GroupByKey，需要将数据写入持久状态（并因此写入新源）。

第二阶段从GroupByKey到WriteToBigQuery。在这种情况下，数据是从“源”读取的。

每个来源都有自己的一组水印。您在 Dataflow UI 中看到的水印是来自管道中任何源的最大水印。

——

回答您的问题：

1. 等待处理的是什么？

回答

它是元素在 PubSub 中等待的时间。具体来说，元素在管道中的任何源内等待的时间。

考虑一个更简单的管道：

ReadFromPubSub -> Map -> WriteToBigQuery.

此管道对每个项目执行以下操作：Read an item from PubSub -> Operate on it -> Insert to BigQuery -> **Confirm to PubSub that the item has been consumed**.

现在，假设 BigQuery 服务停机 5 分钟。这意味着 PubSub 在 5 分钟内不会收到任何元素的确认。因此，这些元素会在 PubSub 中卡住一段时间。

这意味着当 BQ 写入被阻止时，系统延迟（以及数据新鲜度指标）将膨胀至 5 分钟。

2. 处理后是否调整最长持续时间？

回答

这是正确的。例如，再次考虑之前的管道：BQ 死了 5 分钟。当 BQ 返回时，可能会有大量项目写入其中，并确认为从 PubSub读取。这将大大减少系统延迟（和数据新鲜度）回到几秒钟。

3. 从事件时间戳到现在是什么时候？

回答

事件时间戳可以作为消息的属性提供给 PubSub。这是一个有点棘手的概念，但本质上：

每个阶段都有一个输出数据水印。T 的输出数据水印表示计算已经处理了事件时间在 T 之前的所有元素。最新的输出数据水印可以是其所有上游计算的最早输入水印。但是，如果有一些尚未处理的输入数据，则可以阻止输出水印。

当然，这个指标是启发式的。如果某些数据点很晚才出现，那么数据新鲜度将被阻止。

——

我建议你看看Slava的演讲。它涵盖了所有这些概念。