Flink的出现，主攻流计算场景，提供有状态的流计算，尤其是在面对大规模实时流计算上，性能值得称赞。而Flink的有状态的流计算，这个状态（State），也值得深入理解。今天的大数据开发学习分享，我们就来讲讲Flink框架的State状态。
在流计算场景中，数据会源源不断的流入Apache Flink系统，每条数据进入Apache Flink系统都会触发计算。如果我们想进行一个Count聚合计算，那么每次触发计算是将历史上所有流入的数据重新计算一次，还是每次计算都是在上一次计算结果之上进行增量计算呢?答案是肯定的，Apache Flink是基于上一次的计算结果进行增量计算的。
那么问题来了:“上一次的计算结果保存在哪里，保存在内存可以吗?”，答案是否定的，如果保存在内存，在由于网络，硬件等原因造成某个计算节点失败的情况下，上一次计算结果会丢失，在节点恢复的时候，就需要将历史上所有数据(可能十几天，上百天的数据)重新计算一次，所以为了避免这种灾难性的问题发生，Apache Flink会利用State存储计算结果。
什么是State？
在Flink里面什么是State？State是指流计算过程中计算节点的中间计算结果或元数据属性，比如在aggregation过程中要在state中记录中间聚合结果，比如Apache Kafka作为数据源时候，我们也要记录已经读取记录的offset，这些State数据在计算过程中会进行持久化(插入或更新)。所以Flink中的State就是与时间相关的，Flink任务的内部数据（计算数据和元数据属性）的快照。
为什么需要State？
与批计算相比，State是流计算特有的，批计算没有failover机制，要么成功，要么重新计算。流计算在大多数场景下是增量计算，数据逐条处理（大多数场景)，每次计算是在上一次计算结果之上进行处理的，这样的机制势必要将上一次的计算结果进行存储（生产模式要持久化），另外由于机器，网络，脏数据等原因导致的程序错误，在重启job时候需要从成功的检查点(checkpoint)进行state的恢复。增量计算，Failover这些机制都需要state的支撑。
State存储实现
Flink内部有三种state的存储实现，具体如下：
基于内存的HeapStateBackend-在debug模式使用，不建议在生产模式下应用；
基于HDFS的FsStateBackend-分布式文件持久化，每次读写都操作内存，同需考虑OOM问题；
基于RocksDB的RocksDBStateBackend-本地文件+异步HDFS持久化;
State存储的架构
Apache Flink默认是RocksDB+HDFS的方式进行State的存储，State存储分两个阶段，首先本地存储到RocksDB，然后异步的同步到远程的HDFS。这样的而设计既消除了HeapStateBackend的局限（内存大小，机器坏掉丢失等），也减少了纯分布式存储的网络IO开销。
State分类
KeyedState：
这里面的key是我们在SQL语句中对应的GroupBy/PartitioneBy里面的字段，key的值就是groupby/PartitionBy字段组成的Row的字节数组，每一个key都有一个属于自己的State，key与key之间的State是不可见的；
OperatorState：
Flink内部的Source Connector的实现中就会用OperatorState来记录source数据读取的offset。
关于大数据开发学习，Flink框架的State状态，以上就为大家做了一些简单的介绍了。Flink作为流计算场景下，热度越来越高的框架，是必学的，其中的诸多概念细节，也需要一一去理解透彻。
网友评论