源是我们的光束管道的 kafka。即使任何分区空闲，Apache beam 的 kafka IO 连接器也支持移动水印（在 flink runner 的情况下）。想要根据包含在有效负载中的数据包的时间戳来处理数据包的应用程序会想要使用“CustomTimestampPolicyWithLimitedDelay”。我们使用 FIXED WINDOWS 一分钟进行聚合，这取决于时间的概念。因此，如果时间没有正确推进，则不会调用聚合函数并且会丢失数据。
此 API 存在功能问题。因此，当应用程序初始化时，让我们以 Topic a 为例，它被用作具有三个分区的源。采取了这些步骤来重现该问题：
- 仅以任意 x 秒的频率将数据泵入一个分区，观察结果是聚合函数即使在几分钟后也不会被调用。
- 现在将数据泵送到所有分区，观察结果是按预期在每分钟结束时调用聚合函数。
- 现在只将数据泵送到一个分区，并且直到在那之前的一分钟结束，这样我们就可以生成一个空闲的分区场景并观察它现在是否按预期工作。
所以总结是这个api有一个初始化问题，它没有提前时间，但在第2步之后它稳定并按预期工作。
这很容易重现，并且会要求 apache beam 来解决这个问题。
到目前为止，我们采用的临时修复方法是使用 LogAppendTime，它可以完美运行，但由于各种应用程序需要，我们不想在代理时间处理数据包。