【Flink】状态后端State Backends

在启动 CheckPoint 机制时，状态会随着 CheckPoint 而持久化，以防止数据丢失、保障恢复时的一致性。

状态内部的存储格式、状态在 CheckPoint 时如何持久化以及持久化在哪里均取决于选择的 State Backend。

Flink 1.13之后	Flink 1.13之前
HashMapStateBackend（默认）	MemoryStateBackend
EmbeddedRocksDBStateBackend	FsStateBackend
	RocksDBStateBackend

HashMapStateBackend

1、HashMapStateBackend会把状态当成对象，并保存到TaskManager的JVM堆上

2、Key/value 形式的状态、触发器等会以key-value的形式存储

3、检查点通常持久化到分布式文件系统中

4、因状态存储到内存，读写速度快，性能最佳

5、缺点是占用内存

适用范围：

• 有较大 state，较长 window 和较大 key/value 状态的 Job。

• 所有的高可用场景。

EmbeddedRocksDBStateBackend

1、状态存放在RocksDB，RocksDB 默认存储在TaskManager的本地数据目录里

2、不同于 HashMapStateBackend中的 java 对象，数据会存储为序列化的字节数组

3、检查点通常持久化到分布式文件系统中

4、因数据会被存储为序列化的字节数组，故读写操作需要进行序列化和反序列化操作，访问性能较差

5、 key 之间的比较是以字节序的形式进行而不是使用 Java 的hashCode或 equals()方法

6、采用异步快照，不会因为保存检查点而阻塞数据的处理

7、每个 key 和 value 最大支持 2^31 字节

适用范围：

• 状态非常大、窗口非常长、key/value 状态非常大的 Job。

• 所有高可用的场景。

如何选择？

        HashMap和 RocksDB两种状态后端最大的区别，就在于本地状态存放在哪里：前者是内
存，后者是 RocksDB。
        HashMapStateBackend是内存计算，读写速度非常快；但是，状态的大小会受到集群可用
内存的限制，如果应用的状态随着时间不停地增长，就会耗尽内存资源。
        RocksDB是硬盘存储，所以可以根据可用的磁盘空间进行扩展，而且是唯一支持增量检查点的状态后端，所以它非常适合于超级海量状态的存储。不过由于每个状态的读写都需要做序列化 /反序列化，而且可能需要直接从磁盘读取数据，这就会导致性能的降低，平均读写性能要比 HashMapStateBackend慢一个数量级。

配置

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
env.setStateBackend(new HashMapStateBackend());

MemoryStateBackend

旧版本的 MemoryStateBackend 等价于使用 HashMapStateBackend 和 JobManagerCheckpointStorage。

FsStateBackend 

旧版本的 FsStateBackend 等价于使用 HashMapStateBackend 和 FileSystemCheckpointStorage

RocksDBStateBackend

旧版本的 RocksDBStateBackend 等价于使用 EmbeddedRocksDBStateBackend 和 FileSystemCheckpointStorage