Flink的checkpoint解读_flank checkpoint
赞
踩
欢迎关注今日头条号、微信公众号、知乎号：仰望夜空一万次
随意聊聊并记录从小城市到上海工作生活的所思所想。
不去记录，有些事情都好像没有发生过。
Flink 中的每个方法或算子都能够是有状态的。为了让状态容错，Flink 需要为状态添加 checkpoint（检查点）。
Flink 的 checkpoint 机制前提条件：
- 一个能够回放一段时间内数据的持久化数据源
- 存放状态的持久化存储
什么是 Checkpoint
Checkpoint 是从 source 触发到下游所有节点完成的一次全局操作。
什么是 State
State 其实就是 Checkpoint 所做的主要持久化备份的主要数据
State分类
keyed state
对于 keyed state，有两个特点：
- 只能应用于 KeyedStream 的函数与操作中，例如 Keyed UDF, window state
- keyed state 是已经分区 / 划分好的，每一个 key 只能属于某一个 keyed state
operator state
- 又称为 non-keyed state，每一个 operator state 都仅与一个 operator 的实例绑定。
- 常见的 operator state 是 source state，例如记录当前 source 的 offset
- 运算符状态（或非键控状态）是绑定到一个并行运算符实例的状态。 Kafka连接器是在Flink中使用运算符状态的一个很好的例子。Kafka消费者的每个并行实例都维护一个主题分区和偏移量的映射作为其运算符状态。
数据结构对不同State的支持
- ListState<T>和BroadcastState<K,V>支持operator state
- ValueState<T>,MapState<K,V>,ListState<T>,ReducingState<T>,AggregatingState<IN,OUT>支持Keyed State.
Statebackend 的分类
下图阐释了目前 Flink 内置的三类 state backend，其中MemoryStateBackend和FsStateBackend在运行时都是存储在 java heap 中的，只有在执行 Checkpoint 时，FsStateBackend才会将数据以文件格式持久化到远程存储上。而RocksDBStateBackend则借用了 RocksDB（内存磁盘混合的 LSM DB）对 state 进行存储。
默认情况下，状态是保持在 TaskManagers 的内存中，checkpoint 保存在 JobManager 的内存中。为了合适地持久化大体量状态， Flink 支持各种各样的途径去存储 checkpoint 状态到其他的 state backends 上。通过 StreamExecutionEnvironment.setStateBackend(…) 来配置所选的 state backends。
官网WordCount例子中，对状态的操作
env.fromElements(String ...) 其中使用FromElementsFunction类,作为SourceFunction，FromElementsFunction类同时实现了CheckpointedFunction接口，其中使用类型为ListState的Operaor state。
- @Public
- public interface CheckpointedFunction {
- void snapshotState(FunctionSnapshotContext context) throws Exception;
-
-
- void initializeState(FunctionInitializationContext context) throws Exception;
- }
word count 的 sum 函数调用StreamGroupedReduce类操作 keyed state ，数据结构为ValueState。
参考
