当前位置：首页 > news >正文

【flink】Rocksdb TTL状态全量快照持续递增

news 2025/8/25 23:38:04

flink作业中的MapState开启了TTL，并且使用rocksdb作为状态后端配置了全量快照方式（同时启用全量快照清理），希望能维持一个平稳的运行状态，但是经观察后发现效果不达预期，不仅checkpoint size持续缓慢递增，很长时间后还发生了物理内存溢出。

场景复现

        env.addSource(new OneRecordSource(100000000, 1)).keyBy(e -> e).map(new RichMapFunction<String, String>() {private MapState<String, String> map;@Overridepublic void open(Configuration parameters) throws Exception {super.open(parameters);StateTtlConfig ttlConfig = StateTtlConfig.newBuilder(Time.minutes(1)).cleanupFullSnapshot().build();MapStateDescriptor<String, String> lastStateDes = new MapStateDescriptor<>("lastState", String.class, String.class);lastStateDes.enableTimeToLive(ttlConfig);map = getRuntimeContext().getMapState(lastStateDes);}@Overridepublic String map(String key) throws Exception {map.put(key, key + "值值值值值值值值值值值值值值值值值");return key;}}).print();

自定义一个简单的source持续递增生成整数，作为key保存到MapState，设置了1分钟的过期时间，从web中看到，即使过了几分钟，但是checkpoint size依然是稳步增加的，说明了过期的数据并没得到清理。
在这里插入图片描述

原因分析

现象中全量checkpoint size增长，说明了两个问题

本地rocksdb持续增长，过期数据在本地状态得没得到清理
远端快照文件持续增长，过期数据在快照过程依然被保留了

rocksdb作为状态后端时依赖的是压缩时清理过期数据，具有滞后性（越久的数据处于更上层，压缩频率更小），这解释了发生问题1的原因。在启用了全量快照清理条件下，就算本地状态依然保留着过期数据，在发生全量快照的时候为什么不把过期数据过滤掉，造成checkpoint size单调递增，理想的情况是随着ttl发生周期性的增减。

在全量快照时，在RocksDBMapState.StateSnapshotTransformerWrapper.filterOrTransform中会对本地所有状态数据根据ttl配置进行过滤转换，对于已过期的key，其value设为NULL_VALUE(长度为1的byte[])，这样造成了过期的kv依然保留在远程端，只是原始的值使了统一的标识代替，但是hashmap的MapState在该环节会把过期的kv直接过滤掉。造成这种处理上的差异不知道是什么出发点，不过测试将过期的value修改为null后，在一个ttl周期后，checkpoint size趋向于固定，效果和hashmap一致。

ps：RocksDbListState效果正常。