我们使用kafka流的sessionwindows来聚合相关事件的到达。在聚合的同时，我们还使用 until() 应用程序编程接口。流信息：
会话窗口（非活动时间）为1分钟，保留时间传递给 until() 是2分钟。我们使用定制的 TimestampExtractor Map事件的时间。
例子：
事件：e1；活动时间：上午10:00:00；应收账rivaltime:2pm（当天）
事件：e2；活动时间：上午10:00:30；到达时间下午2:10（同一天）
第二个事件的到达时间是e1到达后10分钟，超过保留时间+不活动时间。但旧事件e1仍然是聚合的一部分，尽管保留时间为2分钟。
问题：
1） kafka streams如何使用 until() 应用程序编程接口？由于作为参数指定的保留值是“窗口将被保持多长时间的下限”，因此该窗口究竟何时被清除？
2） 是否有定期清理状态存储的后台线程？如果是，那么是否有方法确定清除窗口的实际时间。
3） 在保留时间之后清除窗口数据的任何流配置。
1条答案
按热度按时间uqdfh47h1#
在我回答您的具体问题之前：请注意，保留时间不是基于系统时间，而是基于“流时间”“流时间”是基于
TimestampExtractor返回。不需要太多细节：对于您有2条记录的示例，当第二条记录到达时，“流时间”将提前30秒，因此保留时间还没有过去。还请注意，如果没有新数据到达（对于至少一个分区），“流时间”不会提前。这适用于Kafka0.11.0及更高版本，但在将来的版本中可能会有所改变。
更新：kafka2.1改变了流时间的计算，即使一个分区不传送数据，流时间也可能提前。有关详细信息，请参阅kip-353：改进kafka流时间戳同步
对于您的问题：
（1） kafka streams将所有存储更新写入changelog主题和本地rocksdb存储。两者都被划分成具有一定大小的所谓片段。如果新数据到达（即“流时间”进行），将创建新的段。如果发生这种情况，如果旧段中的所有记录都早于保留时间（即，记录时间戳小于“流时间”减去保留时间），则删除旧段。
（2） 因此，没有后台线程，但清理是常规处理的一部分，
（3）没有强制清除旧记录/窗口的配置。
如果所有记录都已过期，则会删除整个段，因此段中较旧的记录（很可能具有较小/较旧的时间戳）的维护时间长于保留时间。这种设计背后的动机是性能：以每个记录为基础过期将过于昂贵。