Question

问题：

在使用Cloud Dataflow时，我们展示了2个指标（请参见this page）：

系统延迟
数据新鲜度

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

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

data_watermark_age：管道已完全处理的最新数据项的寿命（自事件时间戳记以来的时间）。

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

“等待处理”是什么意思？一条消息在pubsub中等待多长时间？还是在管道中等待的总时间？
“最大持续时间”：在处理了最大数量的项目之后，指标会被调整吗？
“自事件时间戳记以来的时间”是否表示如果我的事件在时间戳记t1放入pubsub中，并且在时间戳记t2流出管道的一端，则管道在t1？我想我可以假设，如果度量标准为t1，则可以假定t1之前的所有内容都已处理。

问题：

由于这些指标与Apache Beam的语义相吻合，我希望看到一些示例，或者至少更清晰地定义这些指标以使它们可用。

Answer 1

这些度量标准非常棘手。在this talk by a member of the Beam / Dataflow team中可以深入了解它们的工作原理。

管道在内存中进行一系列计算，这些计算需要将数据序列化到某种数据存储中。例如，考虑以下管道：

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中看到的水印是来自管道中任何来源的最大水印。

-

回答您的问题：

正在等待什么？

答案

元素在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分钟。

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

答案

是的。例如，再次考虑上一个管道：BQ死了5分钟。 BQ回来后，可能会向其中写入大量项目，并从PubSub中确认为已读。这样可以将系统延迟（和数据新鲜度）大大降低到几秒钟。

自事件时间戳记以来几点？

答案

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

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

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

-

我建议您检查talk by Slava。它涵盖了所有这些概念。

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

1 个答案: