Apache Flink 1.15：cleanupInRocksdbCompactFilter参数及测试咨询

1. 压缩过滤器何时处理状态条目？ #

RocksDB的TTL压缩过滤器会在RocksDB执行后台压缩操作时处理状态条目，触发压缩的常见场景包括：

• 当某一层级的SST文件大小、数量达到RocksDB预设阈值时，自动启动后台压缩；
• 内存中的MemTable写满并转存为SST文件后，触发层级间的压缩合并；
• 用户手动调用RocksDB的compactRange接口触发压缩。

在压缩过程中，RocksDB会读取待压缩的旧SST文件中的所有状态条目，逐个交给Flink的TTL压缩过滤器处理——过滤器会用当前时间戳判断条目是否过期，过期条目会被直接丢弃，不会写入新生成的SST文件。

2. 如何测试该清理策略的运行效果？ #

可以通过以下步骤验证：

• 构造测试场景：创建带TTL配置的状态（比如ValueState或MapState），开启cleanupInRocksdbCompactFilter并设置目标queryTimeAfterNumEntries值。写入一批状态数据，其中一部分设置为已过期（比如TTL设为10秒，写入后等待15秒再触发压缩），另一部分保持有效。
• 主动触发压缩：为快速看到效果，可调整RocksDB压缩参数（比如减小level0_file_num_compaction_trigger阈值，让压缩更早触发）；或在测试代码中通过StateBackend获取RocksDB实例，调用compactRange()方法手动触发全量压缩。
• 验证清理结果：
  • 直接读取状态，统计剩余有效条目数，确认过期条目是否被清理；
  • 查看Flink作业的metrics指标：关注state.num-entries（状态条目数）、state.size（状态占用空间）的变化，压缩后这两个指标应对应下降；
  • 查看RocksDB自身的压缩指标：比如compaction.keys.dropped（压缩过程中丢弃的条目数），若有过期条目被清理，该数值会增加；
  • 对比不同参数的性能差异：分别设置大、小两种queryTimeAfterNumEntries值，记录压缩耗时、作业吞吐量，验证时间戳更新频率对性能的影响——值越小，时间戳更新越频繁，清理越及时，但压缩耗时可能会增加。

内容的提问来源于stack exchange，提问作者Marco