apache-flink - Apache Flink : Why to choose the MemoryStateBackend over the FsStateBackend?

Question

Flink 有一个 MemoryStateBackend和一个 FsStateBackend (和 RocksDBStateBackend )。两者似乎都扩展了HeapKeyedStateBackend ，即存储当前工作状态的机制完全相同。

此 SO answer说主要区别在于MemoryStateBackend在 JobManagers 内存中保留检查点的副本。 (我无法从源代码中收集到任何证据。)MemoryStateBackend还限制每个子任务的最大状态大小。

现在我想知道:你为什么要使用 MemoryStateBackend ?

Answer 1

正如你所说，两者都是MemoryStateBackend和 FSStateBackend均基于 HeapKeyedStateBackend .这意味着，两个状态后端都将操作符的状态作为 TaskManager 的 JVM 堆上的常规对象进行维护，即状态始终在内存中访问。

后端的不同之处在于它们如何为检查点保留状态。检查点是存储在某处的应用程序的所有运算符(operator)的状态的副本。如果出现故障，应用程序将重新启动，并且运算符(operator)的状态从检查点初始化。
FSStateBackend将检查点存储在文件系统中，通常是 HDFS、S3 或挂载在所有工作节点上的 NFS。 MemoryStateBackend将状态存储在 JobManager 的 JVM 中。这有以下优点和缺点:

优点:

无需设置(分布式)文件系统。

无需配置存储位置。

缺点:

如果 JobManager 进程终止，状态就会丢失。

状态大小受 JobManager 内存大小的限制。

由于如果 JM 宕机，检查点将丢失， MemoryStateBackend不适合大多数生产用例。它对于开发和测试有状态应用程序非常有用，因为它不需要配置或设置。