Flink State Checkpoint和并行重分布

目录

一、状态类型

1.基本类型划分

2.组织形式划分

3. 举例：托管的Keyed State

二、State checkpoint  

1.Filesystem State Backend

2.RocksDB State Backend

3.Queryable State

三、State 并行重分配

1. Operator State

2. Keyed State

四、State 结合 Process Function使用

---

 

---

 

为什么需要State

与批计算相比，State是流计算特有的，批计算没有failover机制，要么成功，要么重新计算。流计算在 大多数场景 下是增量计算，数据逐条处理（大多数场景)，每次计算是在上一次计算结果之上进行处理的，这样的机制势必要将上一次的计算结果进行存储（生产模式要持久化），另外由于 机器，网络，脏数据等原因导致的程序错误，在重启job时候需要从成功的检查点(checkpoint，后面篇章会专门介绍)进行state的恢复。增量计算，Failover这些机制都需要state的支撑。

 

State 实现

Apache Flink内部有四种state的存储实现，具体如下：

• 基于内存的HeapStateBackend - 在debug模式使用，不 建议在生产模式下应用；
• 基于HDFS的FsStateBackend - 分布式文件持久化，每次读写都产生网络IO，整体性能不佳；
• 基于RocksDB的RocksDBStateBackend - 本地文件+异步HDFS持久化；
• 还有一个是基于Niagara(Alibaba内部实现)NiagaraStateBackend - 分布式持久化- 在Alibaba生产环境应用；

 

一、状态类型

 

1.基本类型划分

在Flink中，按照基本类型，对State做了以下两类的划分：

a.Keyed State，和Key有关的状态类型，它只能被基于KeyedStream之上的操作，方法所使用。我们可以从逻辑上理解这种状态是一个并行度操作实例和一种Key的对应， <parallel-operator-instance, key>。
b.Operator State（或者non-keyed state），它是和Key无关的一种状态类型。相应地我们从逻辑上去理解这个概念，它相当于一个并行度实例，对应一份状态数据。因为这里没有涉及Key的概念，所以在并行度（扩/缩容）发生变化的时候，这里会有状态数据的重分布的处理。

2.组织形式划分

但是在这里还有一种按照组织形式的划分，也可以理解为按照runtime层面的划分，又可以分为一下两类：

a.Managed State，这类State的内部结构完全由Flink runtime内部来控制，包括如何将它们编码写入到checkpoint中等等。
b.Raw State，这类State就比较显得灵活一些，它们被保留在操作运行实例内部的数据结构中。从Flink系统角度来观察，在checkpoint时，它只知道的是这些状态数据是以连续字节的形式被写入checkpoint中。等待进行状态恢复时，又从字节数据反序列化为状态对象。
Managed State可以在所有的data stream相关方法中被使用，官方也是推荐优先使用这类State，因为它能被Flink runtime内部做自动重分布而且能被更好地进行内存管理。

3. 举例：托管的Keyed State

• ValueState<T> getState(ValueStateDescriptor<T>)
• ReducingState<T> getReducingState(ReducingStateDescriptor<T>)
• ListState<T> getListState(ListStateDescriptor<T>)
• AggregatingState<IN, OUT> getAggregatingState(AggregatingState<IN, OUT>)
• FoldingState<T, ACC> getFoldingState(FoldingStateDescriptor<T, ACC>)
• MapState<UK, UV> getMapState(MapStateDescriptor<UK, UV>)

 

 

二、State checkpoint  

State操作都是在内存中，如果遇到错误，会导致数据丢失，任务失败，可以通过代码或者配置文件的方