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

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;
                    @Override
                    public 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);
                    }
                    @Override
                    public String map(String key) throws Exception {
                        map.put(key, key + "值值值值值值值值值值值值值值值值值");
                        return key;
                    }
                }).print();

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

原因分析

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

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

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效果正常。

总结
  1. rocksdb的压缩与sst文件数量和大小有关,所以猜测全量快照大小到达一个比较大的值后应该不会继续增长
  2. 可以调整rocksdb的压缩策略,使压缩变得更"积极",但是肯定会消耗更多资源
  3. rocksdb + MapState + TTL组合使用,建议使用增量快照方式
相关推荐
阿里云大数据AI技术1 天前
官宣|Apache Fluss 毕业成为顶级项目,湖流一体开启 Agentic Lake 全面实时化时代
人工智能·flink
Blossom i1 天前
分布式编程实验二:Flink安装与编程实践(头歌云客)
大数据·分布式·flink
渣渣盟2 天前
当反压问题解决后,如何进一步优化 Flink 作业的 Checkpoint 性能,让大状态作业也能稳定运行?
大数据·flink
渣渣盟2 天前
当 Redis 写入不再是瓶颈后,Flink 任务的反压可能来自哪里?如何系统性地定位和解决 Flink 反压问题?
数据库·redis·flink
渣渣盟2 天前
当 Redis 集群发生主从切换(Failover)时,Flink 任务会崩溃吗?如何利用 Sentinel 实现高可用?
redis·flink·sentinel
渣渣盟2 天前
当 Checkpoint 稳定运行后,如何进一步优化 Flink 作业的启动和恢复速度,让大状态作业的扩缩容从“小时级”降到“分钟级”?
大数据·flink
ZCBUS实时计算3 天前
金融证券实时数仓建设实践:轻量化实时计算平台落地,实现交易数据端到端秒级处理
大数据·数据库·数据仓库·金融·flink·dba·etl
让头发掉下来4 天前
Flink SQL 中两个频繁变化 Topic 的 Join 行为分析
大数据·数据库·sql·flink
头茬韭菜4 天前
Apache Fluss 项目深度分析与技术文档系列计划
flink·spark·realtime·fluss
渣渣盟5 天前
Flink 单流转换算子深度解析:从 Map 到 Reduce 的流式处理基石
大数据·flink