这篇文章我们将深入探讨有状态流处理,更确切地说是 Flink 中可用的不同状态后端。在以下部分,我们将介绍 Flink 的3个状态后端,它们的局限性以及根据具体案例需求选择最合适的状态后端。
在有状态的流处理中,当开发人员启用了 Flink 中的检查点功能时,状态会持久化存储以防止数据的丢失并确保发生故障时能够完全恢复。为应用程序选择何种状态后端,取决于状态持久化的方式和位置。
Flink 提供了三种可用的状态后端:MemoryStateBackend,FsStateBackend,和RocksDBStateBackend。
MemoryStateBackend 是将状态维护在 Java 堆上的一个内部状态后端。键值状态和窗口算子使用哈希表来存储数据值和定时器。当应用程序 checkpoint 时,状态后端会在将状态发给 JobManager 之前对状态进行快照,JobManager 会将状态存储在 Java 堆上。默认情况下,MemoryStateBackend 会配置成支持异步快照。异步快照可以避免阻塞数据流的处理,从而避免反压的发生。
使用 MemoryStateBackend 时的注意点:
什么时候使用 MemoryStateBackend:
FsStateBackend 配置需要文件系统的 URL(类型,地址,路径)等来配置。举个例子,比如可以是:
当选择 FsStateBackend 时,正在处理的数据会保存在 TaskManager 的内存中。在 checkpoint 时,状态后端会将状态快照写入配置的文件系统目录和文件中,同时会在 JobManager 或者 Zookeeper(在高可用场景下)的内存中存储极少的元数据。
默认情况下,FsStateBackend 会配置提供异步快照,以避免在写状态 checkpoint 时阻塞数据流的处理。该特性可以通过在实例化 FsStateBackend 时将布尔标志设置为 false 来禁用,例如:
new FsStateBackend(path, false);
当前的状态仍然会先存在 TaskManager 中,所以状态的大小同样不能超过 TaskManager 的内存。
什么时候使用 FsStateBackend:
RocksDBStateBackend 的配置同样需要文件系统的 URL(类型,地址,路径)等来配置,如下所示:
RocksDBStateBackend 将正在处理的数据使用 RocksDB 存储在本地磁盘上。在 checkpoint 时,整个 RocksDB 数据库会被存储到配置的文件系统中,或者在超大状态作业时可以将增量差异数据存储到配置的文件系统中。该状态后端同时也会在 JobManager 或者 Zookeeper(在高可用场景下)的内存中存储极少的元数据。。RocksDB 默认也是配置成异步快照。
使用 RocksDBStateBackend 时的注意点:
何时使用 RocksDBStateBackend:
在使用 RocksDB 时,状态大小只受限于磁盘可用空间的大小。这也使得 RocksDBStateBackend 成为管理超大状态的比较好的选择。使用 RocksDB 的权衡点在于所有状态的访问和检索都需要序列化(或反序列化)才能跨越 JNI 边界。与上面提到的堆上后端相比,这可能会影响应用程序的吞吐量。
不同的状态后端可以满足不同开发人员的需求,在开始开发应用程序之前应该仔细考虑和规划后选择。这可确保选择了正确的状态后端以最好地满足应用程序和业务需求。
英译对照: