RocksDB 具有 append-only 特性,Flink 利用这一特性将两次 checkpoint 之间 SST 文件列表的差异作为状态增量上传到分布式文件系统上,并通过 JobMaster 中的SharedStateRegistry 进行状态的注册和过期。 如上图所示,Task 进行了 3 次快照(假设作业设置保留最近 2 次 Checkpoint): CP-1:RocksDB 产生 sst-1 和 sst-...
现在 Flink 中 Checkpoint 有两种模式，全量 Checkpoint 和 增量 Checkpoint，其中全量 Checkpoint 会把当前的 state 全部备份一次到持久化存储，而增量 Checkpoint，则只备份上一次 Checkpoint 中不存在的 state，因此增量 Checkpoint 每次上传的内容会相对更好，在速度上会有更大的优势。现在 Flink 中仅在 RocksDBState...
RocksDBStateBackend会将状态数据先写入RocksDB,然后异步的将状态数据写入文件系统,其是目前唯一支持incremental的checkpoints的策略,适用于非常大的状态、长窗口、大的KV状态及增量ck。 1. 引子 处在运行状态中的Flink任务,State状态存储方式为RocksDBStateBackend,随着时间的推移,ck在hdfs上所占用的空间及文件越来越多...
RocksDBStateBackend 最适合用于处理大状态,长窗口,或大键值状态的有状态处理任务。 RocksDBStateBackend 非常适合用于高可用方案。 RocksDBStateBackend 是目前唯一支持增量 checkpoint 的后端。增量 checkpoint 非常使用于超大状态的场景。 当使用 RocksDB 时,状态大小只受限于磁盘可用空间的大小。这也使得 RocksDBStateB...
在Flink CDC中,即使开启了RocksDB全量checkpoint的TTL,checkpoint文件大小仍然可能会持续增大。以下是一些可能的原因: 写入放大:RocksDB的写放大是指每次写入操作导致的磁盘写入量大于实际数据量的现象。这可能会导致checkpoint文件大小的增加。为了减小写放大的影响,可以适当调整compaction参数。 Flush速度慢:当所有的memtable...
此外,需要注意的是,RocksDBStateBackend 是唯一支持增量快照的状态后端。 Checkpoints(检查点) Flink中基于异步轻量级的分布式快照技术提供了Checkpoints容错机制,Checkpoints可以将同一时间点作业/算子的状态数据全局统一快照处理,包括前面提到的算子状态和键值分区状态。当发生了故障后,Flink会将所有任务的状态恢复至最后一次...
图3:RocksDB 增量 Checkpoint 的 RocksDB 状态存储上传过程 通用增量 Checkpoint 可以有效降低作业的 CPU 和网络流量的消耗,提升 Checkpoint 稳定性,平滑集群 CPU 和网络资源使用。一方面,通用增量 Checkpoint 通过将增量状态变化日志(State Changelog)持续上传到远端持久化存储,可以将网络流量的消耗均摊在整个 Checkpoint ...
当你使用RocksDB作为Flink的状态后端并开启了增量检查点，关闭增量检查点可能会导致一些问题。增量检查点是...
有了上面的铺垫,下面通过例子来解释增量检查点的过程。 From https://flink.apache.org/features/2018/01/30/incremental-checkpointing.html 上图示出一个有状态的算子的4个检查点,其ID为2,并且state.checkpoints.num-retained参数设为2,表示保留2个检查点。表格中的4列分别表示RocksDB中的sstable文件,sstable文件...
Flink 增量 Checkpoint 以 RocksDB 的 Checkpoint 为基础。RocksDB 是一种基于日志结构合并树(LSM)的 KV 存储,把所有的修改保存在内存的可变缓存中(称为 memtable)。所有对 memtable 中 key 的修改,会覆盖之前的 value,当 memtable 写满之后,RocksDB 会将其写入磁盘,按 Key 排序并进行轻度压缩。一旦 RocksDB...