Apache Flink状态管理和容错机制介绍

1、有状态的流数据处理

一、什么是有状态的计算

计算任务的结果不只仅依赖于输入，还依赖于它的当前状态，其实大多数的计算都是有状态的计算。

好比wordcount,给一些word,其计算它的count,这是一个很常见的业务场景。count作为输出，在计算的过程当中要不断的把输入累加到count上去，那么count就是一个state。

二、传统的流计算系统缺乏对于程序状态的有效支持

• 状态数据的存储和访问；
• 状态数据的备份和恢复；
• 状态数据的划分和动态扩容。

在传统的批处理中，数据是划分为块分片去完成的，而后每个Task去处理一个分片。当分片执行完成后，把输出聚合起来就是最终的结果。在这个过程中，对于state的需求仍是比较小的。

对于流计算而言，对State有很是高的要求，由于在流系统中输入是一个无限制的流，会运行很长一段时间，甚至运行几天或者几个月都不会停机。在这个过程中，就须要将状态数据很好的管理起来。很不幸的是，在传统的流计算系统中，对状态管理支持并非很完善。好比storm,没有任何程序状态的支持，一种可选的方案是storm+hbase这样的方式去实现，把这状态数据存放在Hbase中，计算的时候再次从Hbase读取状态数据，作更新在写入进去。这样就会有以下几个问题

• 流计算系统的任务和Hbase的数据存储有可能不在同一台机器上，致使性能会不好。这样常常会作远端的访问，走网络和存储；
• 备份和恢复是比较困难，由于Hbase是没有回滚的，要作到Exactly onces 很困难。在分布式环境下，若是程序出现故障，只能重启Storm，那么Hbase的数据也就没法回滚到以前的状态。
  好比广告计费的这种场景，Storm+Hbase是是行不通的，出现的问题是钱可能就会多算，解决以上的办法是Storm+mysql，经过mysql的回滚解决一致性的问题。可是架构会变得很是复杂。性能也会不好，要commit确保数据的一致性。
• 对于storm而言状态数据的划分和动态扩容也是很是难作。
  一个很严重的问题是全部用户都会在strom上重复的作这些工做，好比搜索，广告都要在作一遍，由此限制了部门的业务发展。

三、Flink丰富的状态访问和高效的容错机制

Flink在最先设计的时候就意识到了这个问题，并提供了丰富的状态访问和容错机制。以下图所示：

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

Flink而且提供了丰富的状态访问和高效的容错机制

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

2、Flink中的状态管理

按照数据的划分和扩张方式，Flink中大体分为2类：

• Keyed States
• Operator States

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

一、Keyed States

Keyed States的使用

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

Flink也提供了Keyed States多种数据结构类型

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

Keyed States的动态扩容

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

二、Operator State

Operator States的使用

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

Operator States的数据结构不像Keyed States丰富，如今只支持List

Operator States多种扩展方式

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

Operator States的动态扩展是很是灵活的，现提供了3种扩展，下面分别介绍：

• ListState:并发度在改变的时候，会将并发上的每一个List都取出，而后把这些List合并到一个新的List,而后根据元素的个数在均匀分配给新的Task;
• UnionListState:相比于ListState更加灵活，把划分的方式交给用户去作，当改变并发的时候，会将原来的List拼接起来。而后不作划分，直接交给用户；
• BroadcastState:如大表和小表作Join时，小表能够直接广播给大表的分区，在每一个并发上的数据都是彻底一致的。作的更新也相同，当改变并发的时候，把这些数据COPY到新的Task便可

以上是Flink Operator States提供的3种扩展方式，用户能够根据本身的需求作选择。

使用Checkpoint提升程序的可靠性

用户能够根据的程序里面的配置将checkpoint打开，给定一个时间间隔后，框架会按照时间间隔给程序的状态进行备份。当发生故障时，Flink会将全部Task的状态一块儿恢复到Checkpoint的状态。从哪一个位置开始从新执行。
Flink也提供了多种正确性的保障，包括：

• AT LEAST ONCE;
• Exactly once;

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

备份为保存在State中的程序状态数据
Flink也提供了一套机制，容许把这些状态放到内存当中。作Checkpoint的时候，由Flink去完成恢复。

从已中止做业的运行状态中恢复
当组件升级的时候，须要中止当前做业。这个时候须要从以前中止的做业当中恢复，Flink提供了2种机制恢复做业:

• Savepoint:是一种特殊的checkpoint，只不过不像checkpoint按期的从系统中去触发的，它是用户经过命令触发，存储格式和checkpoint
  也是不相同的，会将数据按照一个标准的格式存储，无论配置什么样，Flink都会从这个checkpoint恢复，是用来作版本升级一个很是好的工具；
• External Checkpoint：对已有checkpoint的一种扩展，就是说作完一次内部的一次Checkpoint后，还会在用户给定的一个目录中，多存储一份checkpoint的数据；

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

3、状态管理和容错机制实现

下面介绍一下状态管理和容错机制实现方式，Flink提供了3种不一样的StateBackend,

• MemoryStateBackend
• FsStateBackend
• RockDBStateBackend

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

用户能够根据本身的需求选择，若是数据量较小，能够存放到MemoryStateBackend和FsStateBackend中，若是数据量较大，能够放到RockDB中。

下面介绍HeapKeyedStateBackend和RockDBKeyedStateBackend

第一，HeapKeyedStateBackend

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

第二，RockDBKeyedStateBackend

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

Checkpoint的执行流程
Checkpoint的执行流程是按照Chandy-Lamport算法实现的。

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

Checkpoint Barrier的对齐

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

全量Checkpoint
全量Checkpoint会在每一个节点作备份数据时，只须要将数据都便利一遍，而后写到外部存储中，这种状况会影响备份性能。在此基础上作了优化。

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

RockDB的增量Checkpoint

RockDB的数据会更新到内存，当内存满时，会写入到磁盘中。增量的机制会将新产生的文件COPY持久化中，而以前产生的文件就不须要COPY到持久化中去了。经过这种方式减小COPY的数据量，并提升性能。

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

4、阿里相关工做介绍

Flink在阿里的成长路线
阿里是从2015年开始调研Flink,2015年10月启动Blink项目，并完善Flink在大规模生产下的一些优化和改进。2016年双11采用了Blink系统，为搜索，推荐，广告业务提供服务。2017年5月Blink已成为阿里的实时计算引擎。

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

阿里在状态管理和容错相关的工做

若是想及时了解Spark、Hadoop或者Hbase相关的文章，欢迎关注微信公共账号：iteblog_hadoop

正在作的工做，基于State重构Window方面的一些优化，阿里也正在将功能作完善。后续将包括asynchronous Checkpoint的功能完善，并和社区进一步沟通和合做。帮助Flink社区完善相关方面的工做。

5、本文 PPT 下载

本文的 PPT 能够到 《Flink China社区线下 Meetup·北京站 PPT 资料分享》 里面进行下载。