一文了解Flink State Backends

State Backends

MemoryStateBackend
FsStateBackend
RocksDBStateBackend

MemoryStateBackend

顾名思义，MemoryStateBackend状态后端是将状态数据以Object的形式存放于Java Heap中。

当执行检查点时，MemoryStateBackend会为当前的状态生成snapshot，然后将快照信息作为检查点ack消息的一部分发送给JobManager（master节点），JobManager会将收到的快照数据存放于自己的堆内存中。

MemoryStateBackend默认采用异步snapshots的方式来避免数据流管道阻塞，这是一种比较推荐的方式。当然，我们也可以通过配置来禁用这种方式。

new MemoryStateBackend(MAX_MEM_STATE_SIZE, false); // MAX_MEM_STATE_SIZE表示最大允许的状态容量

MemoryStateBackend的使用限制

每个状态的大小默认限制为5MB，可以通过构造函数设置状态大小
不管如何配置最大状态大小，都不能超过akka帧大小
聚合状态大小必须合乎JobManager的内存大小

基于以上这些限制，我们通常建议在如下场景中使用MemoryStateBackend：

本地开发调试
无状态作业或者保存少量状态的作业

此外，官方建议将托管内存（Managed Memory）设置为0，这样可以确保为JVM上的用户程序分配最大的内存。

FsStateBackend

FsStateBackend需要配置一个文件系统URL，如：“hdfs://namenode:40010/flink/checkpoints” or “file:///data/flink/checkpoints”。
FsStateBackend将作业执行过程中的动态数据存放在TaskManager的内存当中，当执行检查点时，状态快照数据会被存储在配置的文件系统目录中，还有一部分metadata数据会被存储在JobManager的内存当中。

同样的，FsStateBackend也是默认采用异步snapshot的方式。我们可以通过实例化FsStateBackend来更改快照生成方式。

 new FsStateBackend(path, false);

官方建议在以下场景中使用FsStateBackend：

作业中包含大状态、长窗口以及大键值状态
高可用应用场景

同样官方建议将托管内存（Managed Memory）设置为0，这样可以确保为JVM上的用户程序分配最大的内存。

RocksDBStateBackend

RocksDBStateBackend同样需要配置一个文件系统URL：“hdfs://namenode:40010/flink/checkpoints” or “file:///data/flink/checkpoints”。

RocksDBStateBackend将作业执行过程中的动态数据存放在RocksDB数据库中，RocksDB数据库默认存储在TaskManager的数据目录下。当执行检查点时，整个RocksDB数据库会被存档到配置的文件系统目录下。只有少量的metadata数据存储在JobManager的内存当中。

同样地，RocksDBStateBackend通常也采用异步snapshot的方式。

使用上的一些限制：

由于RocksDB的JNI bridge API是基于byte[]的，因此可支持的最大key值大小是2^31 byte。这个限制一般情况下不会有问题，但当作业中的状态是基于不断地merge操作生成时，很容易超过这个大小限制，这个时候就会出现检索失败的错误。

官方建议在以下场景中使用RocksDBStateBackend：

作业中包含大状态、长窗口以及大键值状态
高可用应用场景

乍一看，好像跟FsStateBackend没啥区别？其实不是，这里需要注意的是，当我们使用RocksDBStateBackend作为状态存储时，可以维护的状态大小仅仅受限于程序可访问的磁盘空间大小。这就使得我们可以维护比FsStateBackend更大的作业状态。

当然，这也带来一个问题：由于与状态后端之间的所有读写操作都要经过de-/serialization，因此这种方式牺牲了一定的吞吐量。

总结

MemoryStateBackend、FsStateBackend都是基于堆的状态存储
RocksDBStateBackend是目前唯一的一种支持增量checkpoint的状态后端

MindForward