Google cloud dataflow 在GCD上运行PubsubIO的水印启发是什么？

嗨，我正在尝试运行一个管道，在这个管道中，我正在计算以30秒心跳*发布到pubsub的消息之间的差异（10K流，每30秒心跳一次）。我不关心100%的数据完整性，但我想了解什么是PubsubIO的水印启发（如果我可以调整它），以确定是否可以以足够低的损失忽略延迟数据

*注意，pubsub主题提供了[可能值得几天]的持久性，以防我们必须关闭管道，因此启发式方法在积压订阅中工作良好是很重要的

---

有人能解释一下水印是如何计算的（假设使用了timestamplabel（）），以及如何调整水印的吗？

下面是我们如何计算PubSub水印的简要说明：

我们的目标是为通过PubSub发送到流媒体管道的数据构建合理的启发式水印。我们对向PubSub发送数据的源进行了一些假设。具体地说，我们假设原始数据的时间戳“表现良好”，换句话说，在发送到PubSub之前，我们期望源数据上有一定数量的顺序时间戳。任何发送的时间戳超出允许的无序界限的数据都将被视为延迟数据。在我们当前的实现中，这个界限是10秒，这意味着在发送到pubsub之前10秒内重新排序时间戳将不会创建延迟数据。我们称这个值为估计带。然后，构建PubSub水印的问题减少到确保没有额外的数据由于通过PubSub传输而延迟

我们面临的挑战是什么？由于pubsub不能保证排序，我们必须有一些额外的元数据来充分了解积压工作。幸运的是，PubSub根据“最早的未确认发布时间戳”提供了一个后日志度量。这与消息的事件时间戳不同，因为PubSub与通过它发送的应用程序级元数据无关，而是PubSub接收消息的时间戳

虽然这种测量听起来类似于水印，但它并不相同。我们不能简单地使用最早的未确认发布时间戳作为水印。这些时间戳不等于事件时间戳，并且在发送历史（过去）数据的情况下，它可能任意远离。这些时间戳上的顺序也可能不同，因为如上所述，我们允许有限数量的重新排序。然而，我们可以使用它作为积压工作的度量，以了解积压工作中存在的事件时间戳的足够信息，以便我们可以建立一个合理的水印，如下所示

我们将数据到达的订阅称为基本订阅。看看我们的基本订阅，我们发现消息可能会无序到达。我们用它的pubsub发布时间戳“pt”和事件时间戳“et”标记每条消息。请注意，这两个时域可以是不相关的

基本订阅上的某些消息未确认，形成积压。这可能是由于它们尚未交付，或者它们可能已经交付，但尚未处理。还请记住，来自此订阅的请求分布在多个碎片上。因此，仅仅通过查看基本订阅就不可能说出我们的水印应该是什么

我们继续创建第二个仅元数据跟踪订阅，该订阅用于有效检查基本订阅的积压，并获取积压中的最小事件时间戳。通过在跟踪订阅上保持很少或没有积压，我们可以在基本订阅的最早未确认之前检查消息

通过确保从该订阅中提取数据在计算上是便宜的，我们可以继续跟踪订阅。相反，如果我们在跟踪订阅方面落后了很多，我们将停止推进水印。为此，我们确保至少满足以下条件之一：

• 跟踪订阅足够超前于基本订阅，足够超前意味着跟踪订阅至少超前于估计频带。这确保了考虑到估计频带内的任何有界重序
• 跟踪订阅足够接近实时。换句话说，跟踪订阅没有积压工作

一旦我们持久保存了关于消息的发布和事件时间戳的元数据，我们将尽快确认跟踪订阅上的消息。我们以稀疏直方图格式存储此元数据，以最小化使用的空间量和持久写入的大小

最后，我们确保有足够的数据来进行合理的水印估计。我们获取一组事件时间戳，其中发布时间戳在范围内

 [ min ( base sub oldest unack'd, tracking sub oldest unack'd - 10 sec) , 
         tracking sub oldest unack'd ]

这确保我们考虑积压中的所有事件时间戳，或者如果积压很小，最新的估计带，进行水印估计。

最后，水印值被计算为频带中的最小事件时间

还要注意，此方法是正确的，但会生成过于保守的水印。由于我们认为所有的消息都在跟踪订阅的基础订阅最老的unk上，所以我们可以在已经被确认的消息中包含水印时间戳中的事件时间戳。p> 此外，还有一些启发式方法可以确保进度。上述方法适用于密集、频繁到达的数据。对于稀疏或不频繁的数据，可能没有足够的最新消息来建立合理的估计。如果我们没有看到订阅的数据