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

    状态持久化

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

    在这里插入图片描述

    检查点（Checkpoint）

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

            默认情况下，检查点是被禁用的，需要在代码中手动开启。 
    1. // 启用检查点，间隔时间 1 秒
    2. env.enableCheckpointing(1000);
    3. CheckpointConfig checkpointConfig = env.getCheckpointConfig();
    4. // 设置精确一次模式
    5. checkpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
    6. // 最小间隔时间 500 毫秒
    7. checkpointConfig.setMinPauseBetweenCheckpoints(500);
    8. // 超时时间 1 分钟
    9. checkpointConfig.setCheckpointTimeout(60000);
    10. // 同时只能有一个检查点
    11. checkpointConfig.setMaxConcurrentCheckpoints(1);
    12. // 开启检查点的外部持久化保存，作业取消后依然保留
    13. checkpointConfig.enableExternalizedCheckpoints(
    14.  ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);
    15. // 启用不对齐的检查点保存方式
    16. checkpointConfig.enableUnalignedCheckpoints();
    17. 291
    18. // 设置检查点存储，可以直接传入一个 String，指定文件系统的路径
    19. 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. 每个作业独立的状态后端，可以在代码中，基于作业的执行环境直接设置。
  • 相关阅读:
    A-Level经济真题（12）
    Vue中巧用computed配合watch实现监听多个属性的变化
    代码随想录算法训练营第四十八天| LeetCode198. 打家劫舍、LeetCode213. 打家劫舍 II、LeetCode337. 打家劫舍 III
    Three.js——基础材质、深度材质、法向材质、面材质、朗伯材质、Phong材质、着色器材质、直线和虚线、联合材质
    window系统安装 NodeJS
    ubuntu 修改nginx端口
    设计模式——代理模式
    透视投影时相机的参数设置
    MCU编译时间模板 永久适用
    PyTorch深度学习实战（15）——迁移学习
  • 原文地址：https://blog.csdn.net/qq_42456324/article/details/128015314