我们正在使用Kafka流的SessionWindows来汇总相关事件的到来。与聚合一起，我们使用Num API指定窗口的保留时间。
信息流：
会话窗口（不活动时间）为1分钟，传递给Double的保留时间为2分钟。
我们使用自定义的Fractional来映射活动的时间。
例：
事件：e1; eventTime：上午10:00:00;到达时间：下午2点（当天）
事件：e2; eventTime：上午10:00:30;到达时间下午2:10（当天）
第二次活动的到达时间是e1到达后10分钟，超过了保留时间+不活动时间。但是旧的事件e1仍然是聚合的一部分，尽管保留时间为2分钟。
问题：
1）kafka如何使用until() API清理状态存储？由于指定为参数的保留值是＆＃34;窗口维持多长时间的下限。＆＃34;什么时候清除窗户？
2）是否有后台线程定期清理状态存储？如果是，那么有没有办法确定窗口被清除的实际时间。
3）在保留时间之后清除窗口数据的任何流配置。
答案 0 :(得分：8)
在回答您的具体问题之前：请注意，保留时间不是基于系统时间，而是基于“流时间”。 “流时间”是基于TimestampExtractor返回的内部跟踪时间进度。没有太多细节：对于你的2条记录的例子，当第二条记录到达时，“流时间”将提前30秒，因此保留时间尚未过去。
另请注意，如果没有新数据到达（至少一个分区），“流时间”不会提前。 这适用于Kafka 0.11.0及更早版本，但在将来的版本中可能会更改。
更新：在Kafka 2.1中更改了流时间的计算，即使一个分区不提供数据，流时间也可能会提前。有关详细信息，请参阅KIP-353: Improve Kafka Streams Timestamp Synchronization
问题：
（1）Kafka Streams将所有商店更新写入changelog主题和本地RocksDB商店。两者都分为具有一定大小的所谓段。如果新数据到达（即“流时间”进展），则创建新段。如果发生这种情况，如果旧段中的所有记录都早于保留时间（即记录时间戳小于“流时间”减去保留时间），则会删除旧段。
（2）因此，没有后台线程，但清理是常规处理的一部分，
和（3）没有强制清除旧记录/窗口的配置。
如果所有记录都已过期，则会删除整个细分受众群，细分受众群中的旧记录（很可能是较小/较旧的时间戳）的维护时间会长于保留时间。这种设计背后的动机是性能：在每个记录的基础上到期会太昂贵。