我通过pub / sub将数据提取到以无限制模式运行的数据流管道。数据基本上是与跟踪设备捕获的时间戳的坐标。这些消息分批到达，每批可能是1..n消息。在某段时间内可能没有到达的消息，这些消息可能会在以后（或不是）重新发送。我们使用每个坐标的时间戳（以UTC为单位）作为pub-sub消息的属性。并通过Timestamp标签读取管道：
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没有未传递或未确认的消息。
当新的活动时间消息到达时，水印是否应该向前移动？
根据What is the watermark heuristic for PubsubIO running on GCD?，WaterMark也应该每隔2分钟向前推进一次，它不会？
[..]如果我们还没有看到有关订阅的数据 超过两分钟（并且没有积压），我们将水印推进到 接近实时。 [..]
更新以解决Bens问题：
我们可以查看一份工作ID吗？
是的我刚刚在欧洲中部时间09:52重启整个设置，时间是07:52 UTC，职位编号为2017-05-05_00_49_11-11176509843641901704。
您使用的是哪个版本的SDK？
1.9.0
您如何使用时间戳标签发布消息？
我们使用python脚本发布使用pub sub sdk的数据。 来自那里的消息可能如下：
{＆＃39;数据＆＃39;：{timestamp; lat; long; ele}，＆＃39; timestamp＆＃39;：＆＃39; 2017-05-05T07：45：51Z＆＃39;} < / p>
我们在数据流中使用timestamplabel的timestamp属性。
什么是水印？
对于这项工作，水印现在停留在09:57:35（我在10:10左右发布），尽管发送了新的数据，例如在
10:05:14
10:05:43
10:06:30
我还可以看到，我们可能会将数据发布到pub sub，延迟时间超过10秒，例如在10:07:47我们发布时间戳最高的时间为10:07:26的数据。
几个小时后，水印赶上，但我看不出为什么它在开始时被延迟/没有移动。
答案 0 :(得分：0)
为便于记录，在直接运行器上下文中，前面提到的边缘情况要考虑的另一件事是运行器的并行性。具有更高的并行度（尤其是在多核计算机上，这是默认设置）似乎需要更多的数据。就我而言，设置this有所帮助。基本上将阻塞的管道转换为可以正常工作的管道，而无需任何其他干预。