6. CheckPoint

一、CheckPoint 是什么

​ Flink 实现容错的核心就是使用流重播和检查点。检查点就是在某个时间点所有任务的状态的一份快照，如果发生故障，Flink 将会使用最近的检查点来一致恢复应用程序的状态，并重新启动处理流程。

二、实现

​ 实现检查点的一种简单的思路是暂停应用，然后对当前流程的状态做快照，但是这样会极大的影响刘处理的性能。Flink 采用了基于 Chandy-Lamport 算法的分布式快照，将检查点的保存和数据处理分离开，不暂停整个应用。实现的方式就是使用 barrier。

2.1 barrier

​ barrier 是一种特殊形式的数据（自己不携带任何数据），每个 barrier 都会有自己的 id，用来把一条流的数据分开。barrier n 之前到来的数据导致的状态更改，都会被包含在当前 barrier 所属的检查点中；而基于 barrier 之后的数据导致的更改，都会被包含在之后的检查点中。

​ barrier 是从 source 开始注入的，当数据源发出 barrier n 后，就向 checkpoint coordinator（Job Manager） 通知。

​ 当一个中间算子收到它所有输入的 barrier n 之后，它将进行 snapshot n，然后将向下游发送 barrier n。

​ 当一个 sink 算子收到它所有输入的 barrier n 后，同样会进行 snapshot n，然后向 checkpoint coordinator 通知。当 checkpoint coordinator 收到所有 sink 的通知之后，就认为 snapshot n 已经完成。

​ 当 snapshot n 完成之后，job 将不再向 source 请求 n 之前的数据。

2.1.1 align checkpoint

2.1.1.1 基本流程

​ 在默认情况下，Flink 使用的是 align checkpoint，即一个算子 operator 有多个输入流时，则必须等到所有输入的 barrier n 到齐了之后才能继续处理，如果有一个输入流 input1 的 barrier n 到了，但是其他的没有到，则 input1 暂停处理，将输入数据放入到 input buffer，先处理其他的 input；当其他 input 的 barrier n 到来之后，operator 就进行 snapshot n 的快照，并且发送 barrier n 到下游；之后处理数据时优先处理 input buffer 中的数据。

​ 优点align 的:方式可以避免将属于 snapshot n 的数据与 snapshot n + 1 的数据混到一起。

​ **缺点：**1. 增加数据的延迟；

​ 2. 当作业出现反压时，这种方式会加剧反压。

首先， Chandy-Lamport 分布式快照的结束依赖于 Marker 的流动，而反压则会限制 Marker 的流动，导致快照的完成时间变长甚至超时。无论是哪种情况，都会导致 Checkpoint 的时间点落后于实际数据流较多。这时作业的计算进度是没有被持久化的，处于一个比较脆弱的状态，如果作业出于异常被动重启或者被用户主动重启，作业会回滚丢失一定的进度。如果 Checkpoint 连续超时且没有很好的监控，回滚丢失的进度可能高达一天以上，对于实时业务这通常是不可接受的。更糟糕的是，回滚后的作业落后的 Lag 更大，通常带来更大的反压，形成一个恶性循环。

其次，Barrier 对齐本身可能成为一个反压的源头，影响上游算子的效率，而这在某些情况下是不必要的。比如典型的情况是一个的作业读取多个 Source，分别进行不同的聚合计算，然后将计算完的结果分别写入不同的 Sink。通常来说，这些不同的 Sink 会复用公共的算子以减少重复计算，但并不希望不同 Source 间相互影响。

https://cloud.tencent.com/developer/article/1663055

2.1.2 unaligned checkpoint

2.1.2.1 基本流程

​ 为了解决 align checkpoint 带来的问题，Flink 提出了 unaligned checkpoint。

​ unaligned checkpoint 的基本流程：

​ 1. 当第一个 barrier 到达它所在的缓冲区时，operator 就做出反应

​ 2. operator 将 barrier 进行 “插队处理”，将其传送到输出缓冲区的末尾

​ 3. operator 异步将 “插队” 掠过的元素保存下来，知道其他的 barrier 到达，保存的元素会作为 operator 的 checkpoint 的一部分。

2.1.2.2 举例：

​ 如上图，我们对数据进行 equal-join 的操作，我们称上面的输入为 input1，下面的输入为 input2，输出为 output

​ unaligned checkpoint 的状态变化：

​ 图a：input1 存在 3 个元素，其中 2 在 barrier 前面；input2 存在 4 个元素，其中 2、9、7 在 barrier 前面；

​ 图b：operator 优先处理 input1 的 barrier，开始本地快照自己的状态，并将 barrier 插到 output 的末尾；

​ 图c：operator 继续正常处理两个 input 的输入，输出 2、9。同时，operator 会将 barrier 越过的数据（即 input1 的 2 和 output 的 1）写入 checkpoint，并将 input2 后续早于 barrier 的数据（即 2、9、7）持续写入 checkpoint。

比起 align checkpoint 中不同 checkpoint 周期的数据以算子快照为界限分割得很清晰，unaligned checkpoint 进行快照和输出 barrier 时，部分本属于当前 checkpoint 的输入数据还未计算（因此未反应到下游 operator 的状态中），而部分属于当前 checkpoint 的数据却落到 barrier 之后（因此未反应到下游 operator 的状态中）。这也正是 unaligned 的含义：不同 checkpoint 周期的数据没有对齐，包括不同 input 之间的不对齐，以及输入和输出间的不对齐。而这部分不对齐的数据会被快照记录下来，以在恢复是重放。换句话说，从 checkpoint 恢复时，不对齐的数据并不能由 source 端重放的数据计算得出，同时也没有反应到算子的状态中，但因为它们会被 checkpoint 恢复到对应的 channel 中，所以依然可以提供 exactly-once 的准确结果

https://cloud.tencent.com/developer/article/1663055

2.1.2.3 unaligned checkpoint 当前的问题：

1. 由于要持久化缓存数据，State Size 会有比较大的增长，磁盘负载会加重。所以 unaligned checkpoint 不适合 I/O 为瓶颈的场景。
2. 无法通过 unaligned checkpoint 缩放或者更改 job graph。在缩放或者更改前，必须保存 savepoint。
3. flink 目前不支持并行的 unaligned checkpoint，当然，因为 unaligned checkpoint 的速度很快，我们也不需要并行。但是，保存点也不能并行发生在 unaligned checkpoint 上，因此，将花费更长的时间。

2.1.2.4 如何选取

​ 目前看来，Unaligned Checkpoint 更适合容易产生高反压同时又比较重要的复杂作业。对于像数据 ETL 同步等简单作业，更轻量级的 Aligned Checkpoint 显然是更好的选择。

三、CheckPoint 使用

import org.apache.flink.runtime.state.filesystem.FsStateBackend
import org.apache.flink.streaming.api.CheckpointingMode
import org.apache.flink.streaming.api.scala.{StreamExecutionEnvironment, createTypeInformation}
import org.apache.flink.streaming.api.windowing.assigners.TumblingProcessingTimeWindows
import org.apache.flink.streaming.api.windowing.time.Time

object WordCount {

  def main(args: Array[String]): Unit = {
    val env = StreamExecutionEnvironment.getExecutionEnvironment
    env.enableCheckpointing(1000)

    // set mode to exactly-once (this is the default)
    env.getCheckpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE)

    // make sure 500 ms of progress happen between checkpoints
    env.getCheckpointConfig.setMinPauseBetweenCheckpoints(500)

    // checkpoints have to complete within one minute, or are discarded
    env.getCheckpointConfig.setCheckpointTimeout(60000)

    // prevent the tasks from failing if an error happens in their checkpointing, the checkpoint will just be declined.
    env.getCheckpointConfig.setFailOnCheckpointingErrors(false)

    // allow only one checkpoint to be in progress at the same time
    env.getCheckpointConfig.setMaxConcurrentCheckpoints(1)

    // enables the experimental unaligned checkpoints
    env.getCheckpointConfig.enableUnalignedCheckpoints()

    // 设置状态后端为本地文件系统
    env.setStateBackend(new FsStateBackend("file:Users/IdeaProjects/flinkl-study/src/main/scala/checkpoint", false))

    val text = env.socketTextStream("localhost", 9999)

    val counts = text.flatMap{ _.toLowerCase.split("\\W+") filter {_.nonEmpty}}
      .map{ (_, 1) }
      .keyBy(_._1)
      .window(TumblingProcessingTimeWindows.of(Time.seconds(5)))
      .sum(1)

    counts.print

    env.execute()

  }
}