Google cloud dataflow 水印被卡住了

我通过pub/sub将数据摄取到以无界模式运行的数据流管道中。数据基本上与跟踪设备捕获的时间戳相协调。这些消息分批到达，其中每个批可能是1..n条消息。在一段时间内，可能没有消息到达，这可能会在以后重新发送（或不发送）。我们使用每个坐标的时间戳（UTC）作为发布子消息的属性。并通过时间戳标签读取管道：

pipeline.apply(PubsubIO.Read.topic("new").timestampLabel("timestamp")

坐标和延迟的示例如下所示：

36 points wait 0:02:24
36 points wait 0:02:55
18 points wait 0:00:45
05 points wait 0:00:01
36 points wait 0:00:33
36 points wait 0:00:43
36 points wait 0:00:34

消息可能如下所示：

2013-07-07 09:34:11；47.798766;13.050133

在第一批之后，水印是空的，在第二批之后，我可以在管道诊断中看到水印，只是它没有得到更新，尽管新消息到达。此外，根据stackdriver日志记录，PubSub没有未送达或未确认的消息

水印不应该随着具有新事件时间的消息的到达而向前移动吗

根据这一点，水印也应该每2分钟向前移动一次，而不是吗

[……]如果我们在更多的时间里没有看到有关订阅的数据 不到两分钟（而且没有积压），我们将水印提前到 接近实时。[……]

更新以解决Bens的问题：

---

我们可以看一下工作证吗

是的，我刚刚在CET时间09:52（UTC时间07:52）重新启动了整个设置，作业ID为2017-05-05_00_49_11-11176509843641901704

您使用的SDK版本是什么

1.9.0

您如何发布带有时间戳标签的消息

我们使用一个python脚本来发布数据，该脚本使用pub-sub sdk。 来自那里的消息可能如下所示：

{'data'：{timestamp；lat；long；ele}，'timestamp'：'2017-05-05T07:45:51Z'}

我们在数据流中使用timestamp属性作为timestamp标签

水印的作用是什么

对于此作业，水印现在固定在09:57:35（我在10:10左右发布此消息），尽管新数据已发送，例如

10:05:14
10:05:43
10:06:30

我还可以看到，我们可能会以超过10秒的延迟向pub-sub发布数据，例如，在10:07:47，我们发布的数据的最高时间戳为10:07:26

---

几个小时后，水印开始出现，但我不明白为什么它在开始时会延迟/不移动。

这是PubSub水印跟踪逻辑中的一种边缘情况，有两种解决方法（见下文）。基本上，如果2分钟内没有输入，则水印将前进到当前时间。但是，如果数据的到达速度超过每2分钟一次，但QPS仍然非常低，那么就没有足够的数据使估计的水印保持最新

正如我提到的，有几个解决办法：

如果处理更多数据，问题自然会得到解决

或者，如果您注入额外的消息（例如每秒2条），它将提供足够的数据，以便水印更快地前进。这些只需要有时间戳，并且可以立即从管道中过滤出来

---

为了记录在案，在direct runner上下文中，前面提到的边缘情况需要记住的另一件事是runner的并行性。具有更高的并行性（这是多核机器的默认情况）似乎需要更多的数据。在我的例子中，设置

--targetParallelism=1

有帮助。基本上，在没有任何其他干预的情况下，将卡住的管道转化为工作管道

我们可以看一下工作证吗？您使用的SDK版本是什么？您如何发布带有时间戳标签的消息？水印的作用是什么？谢谢你的回复，本。我更新了我的第一篇文章，回答了你的问题。谢谢。我在尝试管道时遇到了这个问题，必须推送虚拟消息以使水印保持最新（在prod中，当然我会有更多消息）。数据流文档应该更新，以包括除DF工程师之外没有人知道的“边缘案例”，尤其是当它们违反最小惊讶原则时。