Flink（四）Flink的State

精选原创

移望yuan 2021-01-05 18:40:34 博主文章分类：Flink ©著作权

文章标签 Flink的state Flink的状态 Flink的checkpoint 有状态计算 文章分类 大数据

©著作权归作者所有：来自51CTO博客作者移望yuan的原创作品，请联系作者获取转载授权，否则将追究法律责任

一、State概述

Flink里面有state的概念 State:一般指一个具体的task/operator的状态。State可以被记录，在失败的情况下数据还可以恢复，Flink中有两种基本类型的State：Keyed State，Operator State，他们两种都可以以两种形式存在：原始状态(raw state)和托管状态(managed state) **托管状态：**由Flink框架管理的状态，我们通常使用的就是这种。 **原始状态：**由用户自行管理状态具体的数据结构，框架在做checkpoint的时候，使用byte[]来读写状态内容，对其内部数据结构一无所知。通常在DataStream上的状态推荐使用托管的状态，当实现一个用户自定义的operator时，会使用到原始状态。但是我们工作中一般不常用，所以我们不考虑他。

二、State类型

1、Operator State类型

里面没有shuffle的操作，或者说里面没有key by的操作。

（1）operator state是task级别的state，说白了就是每个task对应一个state

（2）Kafka Connector source中的每个分区（task）都需要记录消费的topic的partition和offset等信息。（3）operator state 只有一种托管状态：ValueState （4）operator state可以定义为source和sink的状态进行管理

2、Keyed State类型

（1）keyed state记录的是每个key的状态（2）Keyed state托管状态有六种类型

  （2.1）ValueState
			 /**
			 *  ValueState<T> ：这个状态为每一个 key 保存一个值
			 *      value() 获取状态值
			 *      update() 更新状态值
			 *      clear() 清除状态
			 */
     （2.2）ListState
			 /**
			 *  ListState<T> ：这个状态为每一个 key 保存集合的值
			 *      get() 获取状态值
			 *      add() / addAll() 更新状态值，将数据放到状态中
			 *      clear() 清除状态
			 */
     （2.3）MapState
			 /**
			 *  MapState<K, V> ：这个状态为每一个 key 保存一个 Map 集合
			 *      put() 将对应的 key 的键值对放到状态中
			 *      values() 拿到 MapState 中所有的 value
			 *      clear() 清除状态
			 */
     （2.4）ReducingState
			/**
			 *  ReducingState<T> ：这个状态为每一个 key 保存一个聚合之后的值
			 *      get() 获取状态值
			 *      add()  更新状态值，将数据放到状态中
			 *      clear() 清除状态
			 */
     （2.5）AggregatingState
	       
	    (2.6)FoldingState
(3) flink的keyed的state通过继承RichFlatMapFunction，重写open和flatMap，定义状态，实现状态的管理和自定义

三、State backend

1、概述

Flink支持的StateBackend: MemoryStateBackend FsStateBackend RocksDBStateBackend

（1）、MemoryStateBackend

默认情况下，状态信息是存储在 TaskManager 的堆内存中的，checkpoint 的时候将状态保存到JobManager 的堆内存中。缺点：只能保存数据量小的状态状态数据有可能会丢失优点：开发测试很方便

（2）、 FSStateBackend

状态信息存储在TaskManager 的堆内存中的，checkpoint 的时候将状态保存到指定的文件中 (HDFS等文件系统) 缺点：状态大小受TaskManager内存限制(默认支持5M) 优点：状态访问速度很快状态信息不会丢失用于：生产，也可存储状态数据量大的情况

（3）、 RocksDBStateBackend

状态信息存储在 RocksDB 数据库 (key-value 的数据存储服务)，最终保存在本地文件中 checkpoint 的时候将状态保存到指定的文件中 (HDFS 等文件系统) 缺点：状态访问速度有所下降优点：可以存储超大量的状态信息状态信息不会丢失用于：生产，可以存储超大量的状态信息

2、 StateBackend配置方式

（1）单任务调整

修改当前任务代码 env.setStateBackend(new FsStateBackend("hdfs://namenode:9000/flink/checkpoints")); 或者new MemoryStateBackend() 或者new RocksDBStateBackend(filebackend, true);【需要添加第三方依赖】

（2）全局调整

修改flink-conf.yaml state.backend: filesystem state.checkpoints.dir: hdfs://namenode:9000/flink/checkpoints 注意：state.backend的值可以是下面几种：jobmanager(MemoryStateBackend), filesystem(FsStateBackend), rocksdb(RocksDBStateBackend)

四、checkpoint(容错)

1、checkpoint概述

（1）为了保证state的容错性，Flink需要对state进行checkpoint。（2）Checkpoint是Flink实现容错机制最核心的功能，它能够根据配置周期性地基于Stream中各个 Operator/task的状态来生成快照，从而将这些状态数据定期持久化存储下来，当Flink程序一旦意外崩溃时，重新运行程序时可以有选择地从这些快照进行恢复，从而修正因为故障带来的程序数据异常（3）Flink的checkpoint机制可以与(stream和state)的持久化存储交互的前提：持久化的source，它需要支持在一定时间内重放事件。这种sources的典型例子是持久化的消息队列（比如Apache Kafka，RabbitMQ等）或文件系统（比如HDFS，S3，GFS等）用于state的持久化存储，例如分布式文件系统（比如HDFS，S3，GFS等）生成快照：5秒

恢复快照：

2、checkpoint配置

默认checkpoint功能是disabled的，想要使用的时候需要先启用，checkpoint开启之后， checkPointMode有两种，Exactly-once和At-least-once，默认的checkPointMode是Exactly-once， Exactly-once对于大多数应用来说是最合适的。At-least-once可能用在某些延迟超低的应用程序（始终延迟为几毫秒）。

默认checkpoint功能是disabled的，想要使用的时候需要先启用
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); 
// 每隔1000 ms进行启动一个检查点【设置checkpoint的周期】 
env.enableCheckpointing(1000); 
// 高级选项： 
// 设置模式为exactly-once （这是默认值） 
env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE); 
// 确保检查点之间有至少500 ms的间隔【checkpoint最小间隔】 
env.getCheckpointConfig().setMinPauseBetweenCheckpoints(500); 
// 检查点必须在一分钟内完成，或者被丢弃【checkpoint的超时时间】 
env.getCheckpointConfig().setCheckpointTimeout(60000); 
// 同一时间只允许进行一个检查点 
env.getCheckpointConfig().setMaxConcurrentCheckpoints(1); 
// 表示一旦Flink处理程序被cancel后，会保留Checkpoint数据，以便根据实际需要恢复到指定的 Checkpoint【详细解释见备注】 
env.getCheckpointConfig().enableExternalizedCheckpoints(ExternalizedCheckpointCl 
eanup.RETAIN_ON_CANCELLATION);

3、恢复数据(容错)

（1）重启策略概述

Flink支持不同的重启策略，以在故障发生时控制作业如何重启，集群在启动时会伴随一个默认的重启策略，在没有定义具体重启策略时会使用该默认策略。如果在工作提交时指定了一个重启策略，该策略会覆盖集群的默认策略，默认的重启策略可以通过 Flink 的配置文件 flink-conf.yaml 指定。配置参数restart-strategy 定义了哪个策略被使用。常用的重启策略（1.1）固定间隔 (Fixed delay) （1.2）失败率 (Failure rate) （1.3）无重启 (No restart) 如果没有启用 checkpointing，则使用无重启 (no restart) 策略。如果启用了 checkpointing，但没有配置重启策略，则使用固定间隔 (fixed-delay) 策略，尝试重启次数默认值是：Integer.MAX_VALUE，重启策略可以在flink-conf.yaml中配置，表示全局的配置。也可以在应用代码中动态指定，会覆盖全局配置。

（2）重启策略

（2.1）固定间隔 (Fixed delay)

第一种：全局配置 flink-conf.yaml 
restart-strategy: fixed-delay 
restart-strategy.fixed-delay.attempts: 3 
restart-strategy.fixed-delay.delay: 10 s 
第二种：应用代码设置 
env.setRestartStrategy(RestartStrategies.fixedDelayRestart( 3, // 尝试重启的次数
Time.of(10, TimeUnit.SECONDS) // 间隔 ));

（2.2）失败率 (Failure rate)

第一种：全局配置 flink-conf.yaml 
restart-strategy: failure-rate 
restart-strategy.failure-rate.max-failures-per-interval: 3 
restart-strategy.failure-rate.failure-rate-interval: 5 min 
restart-strategy.failure-rate.delay: 10 s 
第二种：应用代码设置 
env.setRestartStrategy(RestartStrategies.failureRateRestart( 3, // 一个时间段内的最大失败次数 
Time.of(5, TimeUnit.MINUTES), // 衡量失败次数的是时间段 
Time.of(10, TimeUnit.SECONDS) // 间隔 ));

（2..3）无重启 (No restart)

第一种：全局配置 flink-conf.yaml 
restart-strategy: none 第二种：应用代码设置
env.setRestartStrategy(RestartStrategies.noRestart());

4、多checkpoint

默认情况下，如果设置了Checkpoint选项，则Flink只保留最近成功生成的1个Checkpoint，而当Flink程序失败时，可以从最近的这个Checkpoint来进行恢复。但是，如果我们希望保留多个Checkpoint，并能够根据实际需要选择其中一个进行恢复，这样会更加灵活，比如，我们发现最近4个小时数据记录处理有问题，希望将整个状态还原到4小时之前Flink可以支持保留多个Checkpoint，需要在Flink的配置文件conf/flink-conf.yaml中，添加如下配置，指定最多需要保存Checkpoint的个数：

state.checkpoints.num-retained: 20

这样设置以后就查看对应的Checkpoint在HDFS上存储的文件目录 hdfs dfs -ls hdfs://namenode:9000/flink/checkpoints 如果希望回退到某个Checkpoint点，只需要指定对应的某个Checkpoint路径即可实现

5、从checkpoint恢复数据

如果Flink程序异常失败，或者最近一段时间内数据处理错误，我们可以将程序从某一个Checkpoint点进行恢复

bin/flink run -s hdfs://namenode:9000/flink/checkpoints/467e17d2cc343e6c56255d222bae3421/chk- 56/_metadata flink-job.jar
### ```

-----


程序正常运行后，还会按照Checkpoint配置进行运行，继续生成Checkpoint数据。
当然恢复数据的方式还可以在自己的代码里面指定checkpoint目录，这样下一次启动的时候即使代码发生了改变就自动恢复数据了。