我们正在尝试使用数据流的处理时间独立性来启动新的流媒体作业，并通过Pub / Sub将所有数据重播到其中但遇到以下问题：
管道的第一个阶段是一个关于事务ID的groupby，其会话窗口为10秒，丢弃已触发的窗格且不允许延迟。因此，如果我们没有指定重播pub / sub主题的timestampLabel，那么当我们重播到pub / sub时，所有事件时间戳都是相同的，groupby会尝试将我们的所有存档数据分组到事务ID＆＃39 ; s一直以来。不好。
如果我们将timestampLabel设置为归档数据的实际事件时间戳，并且每次重播说明1d到pub / sub主题，则它适用于第一天的事件，但是当那些用尽时，重播pub / sub的数据水印以某种方式跳转到当前时间，并且随后的所有重播日都作为延迟数据被丢弃。我真的不明白为什么会这样，因为它似乎违反了数据流逻辑独立于处理时间的想法。
如果我们将timestampLabel设置为归档数据的实际事件时间戳，并将其全部重放到pub / sub主题中，然后启动流式传输作业来使用它，那么数据水印似乎永远不会推进，并且似乎没有任何东西出现在群体中。我也不太了解这是怎么回事。
答案 0 :(得分：1)
您的方法＃2和＃3遇到了不同的问题：
方法＃3（写入所有数据，然后开始消费）：由于数据被无序写入pubsub主题，水印实际上无法前进，直到所有（或大部分）数据被消耗 - 因为水印是一个软保证“你收到的其他项目不太可能有比这更晚的活动时间”，但由于无序发布，发布时间和活动时间之间没有任何对应关系。因此，您的管道有效地停留，直到它完成处理所有这些数据。
方法＃2：从技术上讲，它在每个特定的日子里都遇到了同样的问题，但我认为1天内的数据量并不大，所以管道能够处理它。然而，在此之后，pubsub通道长时间保持空白，在这种情况下，PubsubIO的当前实现将水印提前到实时，这就是为什么更多天的数据被宣布延迟的原因。 The documentation更多地解释了这一点。
一般情况下，快速赶上大量的积压工作，例如通过使用历史数据“播种”管道然后继续传输新数据，这是一个我们目前不支持的重要用例。
与此同时，我有几条建议：