【flink】状态清理策略(TTL)

flink的keyed state是有有效期(TTL)的,使用和说明在官网描述的篇幅也比较多,对于三种清理策略没有进行横向对比得很清晰。

  • 全量快照清理(FULL_STATE_SCAN_SNAPSHOT)
  • 增量清理(INCREMENTAL_CLEANUP)
  • rocksdb压缩清理(ROCKSDB_COMPACTION_FILTER)

注意,三种状态清理策略不是互斥的,并不是三选一的问题 ,一般是全量快照清理配合另两个其中的一个来使用(需要根据不同的state backend),可以看到StateTtlConfig.CleanupStrategies.strategies是一个集合来的。

全量快照清理

只发生在全量checkpoint的时候,把过期的元素过滤掉,以减少远程端checkpoint storage的大小(如hdfs),无论状态后端是hashmap还是rocksdb都支持,官网用了另一种相同意思描述:在 RocksDBStateBackend 的增量 checkpoint 模式下无效(当前hashmap不支持增量checkpoint)

  • 开启方式

    复制代码
      StateTtlConfig ttlConfig = StateTtlConfig .newBuilder(Time.seconds(1))
          .cleanupFullSnapshot()   //只要有这行即可
          .build();

    // 只有开启了全量快照清理才会触发transform(过滤)
    private StateSnapshotTransformFactory<?> getSnapshotTransformFactory() {
    if (!ttlConfig.getCleanupStrategies().inFullSnapshot()) {
    return StateSnapshotTransformFactory.noTransform();
    } else {
    return new TtlStateSnapshotTransformer.Factory<>(timeProvider, ttl);
    }
    }

当进行全量快照是会遍历状态中每个元素(TtlValue),过滤掉那些已经过期的TtlStateSnapshotTransformer.expired()

增量清理

在状态访问、增加、修改、删除时都会触发,主要是为了减少状态后端中的大小,当前仅状态后端为hashmap才支持增量清理

这里的增量 有点难理解,实际它的含义是:对于一个keyed stated,状态是按key被分区成若干部分的,每次只取cleanupSize个key的状态(StateEntry)进行清理 ,对于大状态这是必须的,因为这会增加状态算子处理数据的时间。对于rocksdb,由于提供不了全局的StateEntry访问器,所以它不支持增量清理AbstractRocksDBState.getStateIncrementalVisitor

判断是否满足增量清理:TtlStateFactory.registerTtlIncrementalCleanupCallback

清理逻辑:TtlIncrementalCleanup.runCleanup

启用方式:这玩意在hashmap状态后端中是默认开启的!!!

复制代码
        public IncrementalCleanupStrategy getIncrementalCleanupStrategy() {
            IncrementalCleanupStrategy defaultStrategy =
                    isCleanupInBackground ? DEFAULT_INCREMENTAL_CLEANUP_STRATEGY : null;
            return (IncrementalCleanupStrategy)
                    strategies.getOrDefault(Strategies.INCREMENTAL_CLEANUP, defaultStrategy);
        }

只要isCleanupInBackground=true,就算没显式调用cleanupIncrementally(),它依然会给你生成一个默认的增量清理策略。所以在上述全量快照清理的启用示例中同时也开启了增量清理。如果需要禁止,需要显式调disableCleanupInBackground()

rocksdb压缩清理

flink 提供的 rocksdb 压缩过滤器(FlinkCompactionFilter)会在压缩时过滤掉已经过期的状态数据,最终调用到C++的nactive方法,减少sst文件的大小。应该与增量/全量checkpoint方式无关。

相关推荐
武子康1 天前
大数据-241 离线数仓 - 实战:电商核心交易数据模型与 MySQL 源表设计(订单/商品/品类/店铺/支付)
大数据·后端·mysql
IvanCodes1 天前
一、消息队列理论基础与Kafka架构价值解析
大数据·后端·kafka
武子康2 天前
大数据-240 离线数仓 - 广告业务 Hive ADS 实战:DataX 将 HDFS 分区表导出到 MySQL
大数据·后端·apache hive
字节跳动数据平台3 天前
5000 字技术向拆解 | 火山引擎多模态数据湖如何释放模思智能的算法生产力
大数据
武子康3 天前
大数据-239 离线数仓 - 广告业务实战:Flume 导入日志到 HDFS,并完成 Hive ODS/DWD 分层加载
大数据·后端·apache hive
字节跳动数据平台4 天前
代码量减少 70%、GPU 利用率达 95%:火山引擎多模态数据湖如何释放模思智能的算法生产力
大数据
得物技术4 天前
深入剖析Spark UI界面:参数与界面详解|得物技术
大数据·后端·spark
大大大大晴天4 天前
Flink生产问题排障-HBase NotServingRegionException
flink·hbase
武子康4 天前
大数据-238 离线数仓 - 广告业务 Hive分析实战:ADS 点击率、购买率与 Top100 排名避坑
大数据·后端·apache hive
武子康5 天前
大数据-237 离线数仓 - Hive 广告业务实战:ODS→DWD 事件解析、广告明细与转化分析落地
大数据·后端·apache hive