Flink状态管理、一致性检查点和保存点

概述

状态我理解为是各个算子的处理函数在处理数据过程中需要查询访问或者是要存储下来的本地/实例变量，一个处理函数中所有需要任务去维护以及用来计算结果的数据都属于任务的状态。然后说一下算子，在我们的应用最终执行时，算子处理数据其实是它的处理函数来实现的，所以我们可以将算子看成是处理函数的一个代号。

大部分的流式应用都是有状态的，因为应用中的很多算子都会不断的读取并更新该算子维护（分布式存储，每一个并行任务都会单独储存维护各自的状态）的各种状态。例如：一个窗口内收集的数据需要存储下来，等待触发执行处理操作，输入源的读取位置需要存储下来，以记录下一次读取位置。上面两个例子可以看作是Flink中的内置状态，在实际应用中我们可能会自定义各种状态。但是无论是内置状态还是用户自定义状态，Flink都会采用相同的策略对他们进行维护。接下来我会详细介绍一下Flink中支持的各种状态类型（数据类型）、如何利用状态后端（state backend）对状态进行存储和维护，以及有状态的应用如何通过状态再分配实现扩缩容。

状态管理

下图展示了一个任务和它状态之间的交互过程：任务接收数据并对他进行处理，处理过程中需要读取或更新状态，并根据状态和输入数据计算结果。

                                                      

状态根据状态类型是Flink提供还是用户自定义分为托管状态与原始状态：

1. 托管状态：是Flink管理的状态，通过Flink框架提供的接口，我们来新增、更新和管理状态的值（下面我们讲述的都是托管状态，不对原始状态进行解析）。
2. 原始状态：由用户自己实现状态的数据机构并进行管理，并且框架在做checkpoint的时候，使用byte[]来读写状态内容，对其内部数据结构一无所知，所以我们要自己实现它的序列化与反序列化。推荐在DataStream上使用托管的状态，因为使用原始状态我们要自己对它进行管理很麻烦。当实现一个用户自定义的operator时，会使用到原始状态。

状态分类

Flink中，状态都是和特定算子相关联的。为了让运行层知道算子有哪些状态，算子需要自己对其进行注册。根据作用域不同可以将状态分为两类：

1. 算子状态：算子状态跟一个特定算子的一个并发实例（一个子任务中的一个算子）进行绑定，整个算子只对应一个状态实例（也就是说一个状态实例对应多个key），每个进入到该算子实例中的记录在被处理时获取到的是同一个状态实例（同一个对象）；
2. 键值分区状态：Flink为每个key都维护了一个状态实例（也就是说对KeyedStream上的每一个key，可能都对应一个状态实例），当一个算子实例在处理一条数据时，该算子会自动把状态的访问范围限制在当前记录的键值处。

托管状态分类

作用域	数据类型
算子状态（operator state）	列表状态	联合列表状态