3

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

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

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

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

4

1 回答 1

2

您的方法 #2 和 #3 遇到不同的问题：

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

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

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

同时我有几个建议给你：

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