Flink之状态管理--容错--检查点

有状态的分布式流式处理

流式处理

流式处理简单地说就是一个无穷尽的数据源在持续的收数据，以代码作为数据处理的基础逻辑，然后输出，这就是流式处理的基本原理。

分布式流式处理

Stream需要做分区，设置相同的Key，并让同样的Key流到一个computition instance做相同的运算。

有状态分布式流式处理

代码中定义了变量X，X在数据处理过程会进行读写操作，变量X会影响最后的结果输出。比如计算每个使用者出现的次数，次数即所谓的状态。

Checkpointing

作为有状态分布式流式处理引擎，我们会考虑到容灾问题，而且希望是精确一次的状态容错保证，因为如果修改超过了一次就意味着数据引擎产生的结果是不可靠的。于是我们开始思考以下几点问题：

• 怎么确保状态拥有精确一次（Exactly-once guarantee）的容错保证？
• 在分布式场景下怎么为拥有多个本地状态的operator产生痊愈一致性快照（grobal consistent snapshot）？
• 最重要的是，怎么在不中断的前提下持续不断地产生快照呢？

简单场景的精确一次容错

我们可以考虑最简单的使用场景，比如是在单一的Flink Process中进行运算，我们想到可以用“笨方法”，每处理完一笔计算就累计一次状态，进行一次快照，就能确保精确一次。

分布式的精确一次容错

假设在分布式场景下，进行多个本地状态的运算。现在我们引入一个Checkpoint的概念，将每个Opeartor的状态保存在Checkpoint中，并且将Checkpoint传入共享的DFS中。如果任何一个Process挂掉，就可以从三个完整的Checkpoint将所有运算值得状态恢复。Checkpoint的存在使整个Process能够实现在分布式环境中的Exactly-once。

Barriers

分布式不中断的全域一致性快照

关于 Flink 如何在不中断运算的状况下持续产生 Global consistent snapshot？引入Checkpoint barrier N 的概念， Flink首先会在job manager触发Checkpoint，Checkpoint触发后会在 Datastream 中会安插 Checkpoint barrier N。

当数据源收到 Checkpoint barrier N 后会将自已的状态保存好，Checkpoint barrier N 跟着数据流动到 Opeartor1 之后，Opeartor1 将数据记录在状态中，同样当 Checkpoint barrier N 流到 Opeartor2，Opeartor2 也会将数据反映到状态上。以上可以看到 Checkpoint barrier N 完成了一个完整的表格，这个表格叫做Distributed Snapshots，即分布式快照。

Flink job manager 可以触发其他的Checkpoint，比如 Checkpoint N + 1，Checkpoint N + 2,等也可以同步进行。正是利用这种机制，可以在不阻挡运算的状况下持续的产生Checkpoint。

Flink 容错机制的核心就是持续创建有状态的分布式数据流的全局一致性快照。这些快照在系统遇到故障时，充当可以回退的一致性Checkpoint。

Savepoint

流式处理应用无时无刻不在运行，所以在运维上有几个考量：变更底层代码逻辑、修 bug 或是升级 Flink 版本，重新定义应用、计算的平行化程度等，我们该怎么保存状态进行数据迁移。

Checkpoint 完美符合以上需求，不过 Flink 中还有另外一个名词叫做Savepoint。Savepoint 产生的原理是在 Checkpoint barrier 流动到所有的 Pipeline 中手动插入从而产生分布式快照，这些分布式快照点即 Savepoint。Savepoint 跟 Checkpoint 的差别在于，检查点是 Flink 在运行中利用分布式快照持续周期性的产生 Checkpoint，而 Savepoint 则是手动产生的 Checkpoint。

当完成变更时，可以直接从 Savepoint 恢复、执行。当执行恢复时需要注意：在变更应用的过程中流仍在持续运行，如 Kafka 在持续收集资料，所以当从 Savepoint 恢复时，Savepoint 保存着那一时刻Checkpoint 产生的时间以及 Kafka 当时所对应的位置。所以它需要恢复到最新的数据，但无论是任何运算，Event Time 都可以确保最后产生的结果完全一致。

Exactly Once vs. At Least Once

1.什么是barrier不对齐？
当还有其他输入流的barrier还没有到达时，会把已到达的barrier之后的数据1、2、3搁置在缓冲区，等待其他流的barrier到达后才能处理。barrier不对齐就是指当还有其他流的barrier还没到达时，为了不影响性能，也不用理会，直接处理barrier之后的数据。等到所有流的barrier的都到达后，就可以对该Operator做CheckPoint了。
2.为什么要进行barrier对齐？不对齐到底行不行？
Exactly Once时必须barrier对齐，如果barrier不对齐就变成了At Least Once。

CheckPoint的目的就是为了保存快照，如果不对齐，那么在checkpoint-100快照之前，已经处理了一些checkpoint-100 对应的offset之后的数据，当程序从checkpoint-100恢复任务时，checkpoint-100对应的offset之后的数据还会被处理一次，所以就出现了重复消费。