换后端类型，开启增量ck——该回答整理自钉群“【③群】Apache Flink China社区”
一个使用FlinkSQL开发的生产线上任务, 使用Tumble Window做聚和统计,并且配置table.exec.state.ttl为7200000,设置checkpoint周期为5分钟,使用rocksdb的增量模式。 正常情况下,任务运行一段时间以后,新增和过期的状态达到动态的平衡,随着RocksDB的compaction,checkpoint的大小会在小范围内上下起伏。 实际观察到,checkpoint大...
如果不能有效快速地完成Checkpoint,将会导致系统Checkpoint频次越来越低,当系统出现问题时,没有及时对状态数据有效地持久化,可能会导致系统丢失数据。因此,对于非常大的状态数据而言,应该对Checkpoint过程进行优化和调整,例如采用增量Checkpoint的方法等。 用户也可以通过配置CheckpointConfig中setMaxConcurrentCheckpoints()方法...
我们之前有同事用operator state存储某个业务的id-mapping数据，结果这个id-mapping数据的规模越来越大，后面导致一开始执行checkpoint, job manager就会因为收到task返回的超大的offset数组导致占用内存量越来越大，无法正常相应甚至OOM。■ 正确使用 UnionListState union list state 目前被广泛使用在 kafka connector 中，...
查看两张图的checkpointed data size,可以发现,第一次任务(第一张图)checkpoint时是全量备份,所以状态是越来越大的,从1m+增加到了3m+, 而第二次任务它每次checkpoint的状态大小是有大有小的,范围在200kb-1.2m之间 再查看End to End Duration,第一次任务的状态后端是内存存储,而时间却略大于第二次任务,说明增量...
1.checkpoint状态大小比较小 是因为我开启了rocksDB的增量模式,所以UI上看到的Checkpointed Data Size官网上说明是增量的数据。 翻看hdfs路径里面的checkpoint: 我的这个任务checkpoint地址下的状态大小 (1) chk-x: 是每个checkpoint的一个元数据保存,默认配置只保存一个:state.checkpoints.num-retained =1。
当然,Unaligned Checkpoint 并不是百分百优于 Aligned Checkpoint,它会带来的已知问题就有: 由于要持久化缓存数据,State Size 会有比较大的增长,磁盘负载会加重。 随着State Size 增长,作业恢复时间可能增长,运维管理难度增加。 目前看来,Unaligned Checkpoint 更适合容易产生高反压同时又比较重要的复杂作业。对于像数据...
size=0b taskmanager.memory.framework.heap.size=134217728b taskmanager.memory.task.heap.size=838986562...
我们之前有同事用operator state存储某个业务的id-mapping数据,结果这个id-mapping数据的规模越来越大,后面导致一开始执行checkpoint, job manager就会因为收到task返回的超大的offset数组导致占用内存量越来越大,无法正常相应甚至OOM。 ■ 正确使用 UnionListState...