【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
在Flink中管理大量的状态--增量式的检查点的介绍
本文由Flink 博客 翻译而来，为了叙述的可读性和流畅性，笔者做了少量的修改。
Apache Flink是为了“有状态”的处理流式数据建立的。那么，在流式计算程序中，状态的含义是什么？ 我在前面的博客中做了“状态”以及 “有状态的流式处理”的定义。这里回顾一下，状态指的是，在程序中，Operator将过去处理过的event信息保存在内存中， 这样可以在之后的处理中使用。
“状态”是一个基础的功能，使得在流式计算中复杂的用户使用场景成为可能。在Flink 文档中列举 了一些例子。
- 程序需要查找某些固定的模式的事件，“状态”保存了至今接收到的事件流。
- 程序需要每分钟做聚合操作，“状态”缓存等待聚合的数据
- 程序需要基于流式的数据进行模型训练，“状态”保存当前版本的模型参数。
但是，只有“状态”拥有容错能力，这样才能在生产环境使用。“容错性”意味着，即使有软件或者机器的故障，最终的计算结果也是精确的，没有数据丢失也没有重复处理。
Flink的容错特性非常强大，它不仅对软件和机器的负载很小，并且也提供了“端到端仅一次”的消息传递保证。
Flink程序容错机制的核心是检查点。Flink的检查点是一个全局的、异步的程序快照，它周期性的生成并送到持久化存储（一般使用分布式系统）。 当发生故障时，Flink使用最新的检查点进行重启。一些Flink的用户在程序“状态”中保存了GB甚至TB的数据。这些用户反馈在大量 的状态下，创建检查点通常很慢并且耗资源，这也是为什么Flink在 1.3版本开始引入“增量式的检查点”。
在引入“增量式的检查点”之前，每一个Flink的检查点都保存了程序完整的状态。后来我们意识到在大部分情况下这是不必要的，因为上一次和这次的检查点之前 ，状态发生了很大的变化，所以我们创建了“增量式的检查点”。增量式的检查点仅保存过去和现在状态的差异部分。
增量式的检查点可以为拥有大量状态的程序带来很大的提升。在早期的测试中，一个拥有TB级别“状态”程序将生成检查点的耗时从3分钟以上降低 到了30秒左右。因为增量式的检查点不需要每次把完整的状态发送到存储中。
如何使用
现在只能通过RocksDB state back-end来获取增量式检查点的功能，Flink使用RocksDB内置的备份机制来合并检查点数据。这样， Flink 增量式检查点的数据不会无限制的增大，它会自动合并老的检查点数据并清理掉。
想要在程序中使用增量式的检查点，我建议详细的阅读Flink 检查点的官方文档 总的来说，要启用这个机制，可以如下设置：
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); env.setStateBackend(new RocksDBStateBackend(filebackend, true));//第二个参数为true
默认的，Flink保留一个完整的检查点，如果你需要保留更多，可以通过如下的配置设置:
state.checkpoints.num-retained
它是怎么工作的
Flink 增量式的检查点以“RocksDB”为基础，RocksDB是一个基于 LSM树的KV存储，新的数据保存在内存中，称为memtable。如果Key相同，后到的数据将覆盖之前的数据，一旦memtable写满了，RocksDB将数据压缩并写入到磁盘。memtable的数据持久化到磁盘后，他们就变成了不可变的sstable。
RocksDB会在后台执行compaction，合并sstable并删除其中重复的数据。之后RocksDB删除原来的sstable，替换成新合成的ssttable，这个sstable包含了之前的sstable中的信息。
在这个基础之上，Flink跟踪前一个checkpoint创建和删除的RocksDB sstable文件，因为sstable是不可变的，Flink可以因此计算出 状态有哪些改变。为了达到这个目标，Flink在RocksDB上触发了一个刷新操作，强制将memtable刷新到磁盘上。这个操作在Flink中是同步的，其他的操作是异步的，不会阻塞数据处理。
Flink 的checkpoint会将新的sstable发送到持久化存储（例如HDFS，S3）中，同时保留引用。Flink不会发送所有的sstable， 一些数据在之前的checkpoint存在并且写入到持久化存储中了，这样只需要增加引用次数就可以了。因为compaction的作用，一些sstable会合并成一个sstable并删除这些sstable，这也是为什么Flink可以减少checkpoint的历史文件。
为了分析checkpoint的数据变更，而上传整理过的sstable是多余的（下文会有描述，这里的意思是之前已经上传过的，不需要再次上传）。Flink处理这种情况，仅带来一点点开销。这个过程很重要，因为在任务需要重启的时候，Flink只需要保留较少的历史文件。
假设有一个子任务，拥有一个keyed state的operator，checkpoint最多保留2个。上面的图片描述了每个checkpoint对应的RocksDB 的状态，它引用到的文件，以及在checkpoint完成后共享状态中的count值。
checkpoint ‘CP2’，本地的RocksDB目录有两个sstable文件，这些文件是新生成的，于是Flink将它们传到了checkpoint 对应的存储目录。当checkpoint完成后，Flink在共享状态中创建两个实体，并将count设为1。在这个共享状态中，这个key 由operator、subtask，原始的sstable名字组成，value为sstable实际存储目录。
checkpoint‘CP2’,RocksDB有2个老的sstable文件,又创建了2个新的sstable文件。Flink将这两个新的sstable传到 持久化存储中，然后引用他们。当checkpoint完成后，Flink将所有的引用的相应计数加1。
checkpoint‘CP3’,RocksDB的compaction将sstable-(1), sstable-(2), sstable-(3) 合并成 sstable-(1,2,3)，然后删除 原始的sstable。这个合并后的文件包含了和之前源文件一样的信息，并且清理掉了重复的部分。sstable-(4)还保留着，然后有一个 新生成的sstable-(5)。Flink将新的 sstable-(1,2,3)以及 sstable-(5)传到持久化存储中， sstable-(4)仍被‘CP2’引用，所以 将计数增加1。现在有了3个checkpoint，'CP1','CP2','CP3',超过了预设的保留数目2，所以CP1被删除。作为删除的一部分， CP1对应的文件（sstable-(1)、sstable-(2)） 的引用计数减1。
checkpoint‘CP4’，RocksDB将sstable-(4), sstable-(5), 新的 sstable-(6) 合并成 sstable-(4,5,6)。Flink将新合并 的 sstable-(4,5,6)发送到持久化存储中，sstable-(1,2,3)、sstable-(4,5,6) 的引用计数增加1。由于再次到达了checkpoint的 保留数目，‘CP2’将被删除，‘CP2’对应的文件（sstable-(1)、sstable-(2)、sstable(3) ）的引用计数减1。由于‘CP2’对应 的文件的引用计数达到0，这些文件将被删除。
竞态条件和并发的checkpoint
由于Flink可以并行的执行多个checkpoint，有时候前面的checkpoint还没有完成，后面的新的checkpoint就启动了。因此，在 使用增量式的checkpoint的时候，你需要考虑使用哪一个checkpoint启动。Flink在使用checkpoint之前需要checkpoint协调器的确认， 所以不会使用那些被删除的checkpoint。
通过checkpoint恢复状态，以及性能的注意事项
如果使用增量式的checkpoint，那么在错误恢复的时候，不需要考虑很多的配置项。一旦发生了错误，Flink的JobManager会告诉 task需要从最新的checkpoint中恢复，它可以是全量的或者是增量的。之后TaskManager从分布式系统中下载checkpoint文件， 然后从中恢复状态。
增量式的checkpoint能为拥有大量状态的程序带来较大的提升，但还有一些trade-off需要考虑。总的来说，增量式减少了checkpoint操作的时间，但是相对的，从checkpoint中恢复可能更耗时，具体情况需要根据应用程序包含的状态大小而定。相对的，如果程序只是部分失败，Flink TaskManager需要从多个checkpoint中读取数据，这时候使用全量的checkpoint来恢复数据可能更加耗时。同时，由于新的checkpoint可能引用到老的checkpoint，这样老的checkpoint就不能被删除，这样下去，历史的版本数据会越来越大。需要考虑使用分布式来存储checkpoint，另外还需要考虑读取带来的带宽消耗。
还有一些便利性和性能的trade-off，可以通过阅读Flink 文档 了解更多。
来源：oschina
链接：https://my.oschina.net/u/992559/blog/2873828