云数据流新鲜度和延迟的确切定义是什么？

Question

问题：

使用云数据流时，我们得到了2个指标（请参见本页）：

1. 系统延迟

Stackdriver中也提供了以下名称（摘自此处）：

system\u lag：数据项等待处理的当前最长持续时间，以秒为单位。

data\u watermark\u age：管道已完全处理的最新数据项的期限（自事件时间戳起的时间）。

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

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

问题：

由于这些指标与Apache Beam的语义学一致，我很想看到一些示例，或者至少更清楚地定义这些指标以使它们可用。

Answer 1

这些指标是出了名的棘手。Beam/数据流团队的一位成员在本次演讲中可以看到对它们工作方式的深入探讨。

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

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。在这种情况下，数据是从“源”读取的。

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

--

回答您的问题：

1. 等待处理的是什么？

答复

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

考虑一个更简单的管道：

<代码>ReadFromPubSub-

此管道对每个项目执行以下操作：从PubSub读取项目-

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

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

答复

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

答复

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

每个阶段都有一个输出数据水印。输出数据水印为T表示计算已处理事件时间早于T的所有元素。输出数据水印可以是其所有上游计算的最早输入水印。但是，如果有一些输入数据尚未处理，则输出水印可能会被保留。

当然，这个指标是启发性的。如果某个数据点很晚才到达，那么数据的新鲜度将被延迟。

--

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