Flink的状态持久化和状态后端

状态持久化

        检查点的保存离不开 JobManager 和 TaskManager,以及外部存储系统的协调。在应用进行检查点保存时,首先会由 JobManager 向所有 TaskManager 发出触发检查点的命令;TaskManger 收到之后,将当前任务的所有状态进行快照保存,持久化到远程的存储介质中;完成之后向JobManager 返回确认信息。这个过程是分布式的,当 JobManger 收到所有TaskManager 的返回信息后,就会确认当前检查点成功保存,而这一切工作的协调,就需要一个“专职人员”状态后端来完成。

Flink的状态持久化和状态后端_第1张图片

检查点(Checkpoint)

        有状态流应用中的检查点(checkpoint),其实就是所有任务的状态在某个时间点的一个快 照(一份拷贝)。简单来讲,就是一次“存盘”,让我们之前处理数据的进度不要丢掉。在一个 流应用程序运行时,Flink 会定期保存检查点,在检查点中会记录每个算子的 id 和状态;如果 发生故障,Flink 就会用最近一次成功保存的检查点来恢复应用的状态,重新启动处理流程, 就如同“读档”一样。

        默认情况下,检查点是被禁用的,需要在代码中手动开启
// 启用检查点,间隔时间 1 秒
env.enableCheckpointing(1000);
CheckpointConfig checkpointConfig = env.getCheckpointConfig();
// 设置精确一次模式
checkpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
// 最小间隔时间 500 毫秒
checkpointConfig.setMinPauseBetweenCheckpoints(500);
// 超时时间 1 分钟
checkpointConfig.setCheckpointTimeout(60000);
// 同时只能有一个检查点
checkpointConfig.setMaxConcurrentCheckpoints(1);
// 开启检查点的外部持久化保存,作业取消后依然保留
checkpointConfig.enableExternalizedCheckpoints(
 ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);
// 启用不对齐的检查点保存方式
checkpointConfig.enableUnalignedCheckpoints();
291
// 设置检查点存储,可以直接传入一个 String,指定文件系统的路径
checkpointConfig.setCheckpointStorage("hdfs://my/checkpoint/dir")

保存点(savepoint)

存点在原理和形式上跟检查点完全一样,也是状态持久化保存的一个快照;区别在于,保存点是自定义的镜像保存,所以不会由 Flink 自动创建,而需要用户手动触发。这在有计划地停止、重启应用时非常有用。

https://blog.csdn.net/qq_42456324/article/details/128043395?csdn_share_tail=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22128043395%22%2C%22source%22%3A%22qq_42456324%22%7D

状态后端

        在 Flink 中,状态的存储、访问以及维护,都是由一个可插拔的组件决定的,这个组件就 叫作状态后端(state backend)。状态后端主要负责两件事:一是本地的状态管理,二是将检查点(checkpoint)写入远程的持久化存储。
         状态后端是一个“开箱即用”的组件,可以在不改变应用程序逻辑的情况下独立配置。 Flink 中提供了两类不同的状态后端,一种是“哈希表状态后端”(HashMapStateBackend),另 一种是“内嵌 RocksDB 状态后端”(EmbeddedRocksDBStateBackend)。如果没有特别配置, 系统默认的状态后端是 HashMapStateBackend。

哈希表状态后端(HashMapStateBackend)

         这种方式就是我们之前所说的,把状态存放在内存里。具体实现上,哈希表状态后端在内
部会直接把状态当作对象(objects),保存在 Taskmanager 的 JVM 堆(heap)上。普通的状态, 以及窗口中收集的数据和触发器(triggers),都会以键值对(key-value)的形式存储起来,所 以底层是一个哈希表(HashMap),这种状态后端也因此得名。
         HashMapStateBackend 是将本地状态全部放入内存的,这样可以获得最快的读写速度,使
计算性能达到最佳,代价则是内存的占用

内嵌 RocksDB 状态后端(EmbeddedRocksDBStateBackend)

         RocksDB 是一种内嵌的 key-value 存储介质,可以把数据持久化到本地硬盘。配置 EmbeddedRocksDBStateBackend 后,会将处理中的数据全部放入 RocksDB 数据库中RocksDB
默认存储在 TaskManager 的本地数据目录里。数据被存储为序列化的字节数组(Byte Arrays),读写操作需要序列化/反序列化,因此状态的访问性能要差一些
        由于它会把状态数据落盘,而且支持增量化的检查点,所以在状态非常大、窗口非常长、
键/值状态很大的应用场景中是一个好选择,同样对所有高可用性设置有效。
状态后端的配置
  1. flink-conf.yaml 中,可以使用 state.backend 来配置默认状态后端。
  2. 每个作业独立的状态后端,可以在代码中,基于作业的执行环境直接设置。

你可能感兴趣的:(flink,flink,数据库,大数据)