如何通过 pub/sub 将旧数据重播到数据流中并保持正确的事件时间逻辑？

Question

我们正在尝试使用数据流的处理时间独立性来启动一个新的流作业并通过 Pub/Sub 将我们的所有数据重播到其中，但遇到了以下问题：

管道的第一阶段是对事务 id 的 groupby，会话窗口为 10 秒，丢弃已触发的窗格，并且不允许延迟。因此，如果我们没有指定重播 pub/sub 主题的 timestampLabel，那么当我们重播到 pub/sub 时，所有事件时间戳都是相同的，并且 groupby 会尝试将我们所有的存档数据一直分组到事务 id 中。不好。

如果我们将 timestampLabel 设置为存档数据中的实际事件时间戳，并在 pub/sub 主题中一次重播 1d 次，那么它适用于第一天的事件，但只要这些是已用尽重播发布/订阅的数据水印会以某种方式向前跳转到当前时间，并且所有后续重播天数都将作为延迟数据丢弃。我真的不明白为什么会这样，因为它似乎违反了数据流逻辑独立于处理时间的想法。

如果我们将 timestampLabel 设置为存档数据中的实际事件时间戳，并将其全部重播到 pub/sub 主题中，然后启动流式作业来消费它，数据水印似乎永远不会前进，并且groupby 似乎没有任何结果。我也不太明白这是怎么回事。

Answer 1

您的方法 #2 和 #3 存在不同的问题：

方法 #3（写入所有数据，然后开始消费）：由于数据是乱序写入 pubsub 主题的，因此在所有（或大部分）数据被消费之前，水印确实无法前进 - 因为水印是一个软保证“您收到的其他项目不太可能有晚于此的事件时间”，但由于无序发布，发布时间和事件时间之间没有任何对应关系。因此，您的管道实际上会卡住，直到它处理完所有这些数据。

方法 #2：从技术上讲，它在每一天都会遇到同样的问题，但我想 1 天内的数据量并没有那么大，所以管道能够处理它。但是，在那之后，pubsub 频道会长时间保持空白，在这种情况下，PubsubIO 的当前实现会将水印提前到实时，这就是为什么更多天的数据被声明为延迟的原因。 The documentation 对此进行了更多解释。

一般来说，快速赶上大量积压，例如通过使用历史数据来“播种”管道，然后继续流入新数据，这是我们目前不能很好地支持的一个重要用例。

同时我有几个建议给你：

• （更好）使用方法 #2 的变体，但尝试根据流管道对其进行计时，这样 pubsub 通道就不会保持为空。
• 使用方法 #3，但需要更多工作人员和每个工作人员更多的磁盘（您当前的工作似乎是使用最多 8 个工作人员的自动缩放 - 尝试更大的东西，比如 100 个？它赶上后会缩小规模）