一文读懂之flink分布式快照checkpoint

Flink checkpoint
什么是Flink?
Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams. Flink has been designed to run in all common cluster environments, perform computations at in-memory speed and at any scale.
今天主要讨论下"状态计算"和checkpoint

Flink流式计算特征
流式数据连续不断地到来，所以流处理程序也是持续运行的，并没有一个明确的结束退出时间。机器运行程序希望“永远运行”也是 不切实际的。因为各种硬件软件的原因，运行一段时间后程序可能异常退出、机器可能宕机， 如果我们只依赖一台机器来运行，就会使得任务的处理被迫中断。
解决方案：多台机器构建集群，以"分布式架构"来运行程序。这样不仅扩展了系 统的并行处理能力，而且可以解决单点故障的问题，从而大大提高系统的稳定性和可用性。
在分布式架构中，当某个节点出现故障，其他节点基本不受影响。这时只需要重启应用， 恢复之前某个时间点的状态继续处理就可以了。在实时流处理中“恢复之前某个时间点的状态”需要考虑到：
1、保证故障后能够重启继续运行
2、保证结果的正确性
3、故障恢复的速度
4、处理性能的影响
flink中有一套完整机制来保障这些，其中最重要的就是checkpoint

checkpoint
在流处理中，把之前的计算结果做个保存，这样重启之后就可以继续处理新数据、而不需要重新计算了。进一步地，我们知道在有状态的流处理中，任务继续处理新数据，并不需要“之前的计算结果”，而是需要任务“之前的状态”。所以我们 最终的选择，就是将之前某个时间点所有的状态保存下来，这份“存档”就是所谓的“检查点”(checkpoint)。
遇到故障重启的时候，我们可以从检查点中“读档”，恢复出之前的状态，这样就可以回到当时保存的一刻接着处理数据了。故障恢复之后继续处理的结果，应该与发生故障前完全一致，我们需要“检查”结果的正确性。所以，有时又会把 checkpoint 叫作“一致性检查点”。

状态管理
大多数流应用程序都是有状态的。许多算子会不断地读取和更新状态，例如在窗口中收集的数据、读取输入源的位置，或者像机器学习模型那样的用户定制化的算子状态。 Flink用同样的方式处理所有的状态，无论是内置的还是用户自定义的算子。本节我们将会讨论Flink支持的不同类型的状态，并解释“状态后端”是如何存储和维护状态的。
一般来说，由一个任务维护，并且用来计算某个结果的所有数据，都属于这个任务的状态。你可以认为状态就是一个本地变量，可以被任务的业务逻辑访问。如图显示了任务与其状态之间的交互。

任务会接收一些数据，处理数据时可以读取和更新状态数据。
应用程序里读取和写入有效可靠的状态管理会复杂一些。其中包括处理很大的状态——可能会超过内存，并且保证在发生故障时不会丢失任何状态。Flink会帮我们处理这相关的所有问题，包括状态一致性、故障处理以及高效存储和访问，以便开发人员可以专注于应用程序的逻辑。
在Flink中，状态始终与特定算子相关联。为了使运行时的Flink了解算子的状态，算子需要预先注册其状态。总的说来，有两种类型的状态：算子状态（operator state/Non-Keyed State）和键控状态（keyed state），它们有着不同的范围访问。
Non-Keyed State：

keyed state：

常见的状态：

• ValueState
• ListState
• ReducingState
• MapState<UK, UV>
• AggregatingState<IN, OUT>
• FoldingState<T, ACC>

状态后端
每传入一条数据，有状态的算子任务都会读取和更新状态。由于有效的状态访问对于处理数据的低延迟至关重要，因此每个并行任务都会在本地维护其状态，以确保快速的状态访问。状态到底是如何被存储、访问以及维护的？这件事由一个可插入的组件决定，这个组件就叫做状态后端（state backend）。状态后端主要负责两件事：本地的状态管理，以及将检查点（checkpoint）状态写入远程存储。
对于本地状态管理，状态后端会存储所有键控状态，并确保所有的访问都被正确地限定在当前键范围。 Flink提供了默认的状态后端，会将键控状态作为内存中的对象进行管理，将它们存储在JVM堆上。另一种状态后端则会把状态对象进行序列化，并将它们放入RocksDB中，然后写入本地硬盘。第一种方式可以提供非常快速的状态访问，但它受内存大小的限制；而访问RocksDB状态后端存储的状态速度会较慢，但其状态可以增长到非常大。

checkpoint的保存
1、周期性触发保存
理想情况是每一条数据都做保存，如果每处理一条数据 就进行检查点的保存，当大量数据同时到来时，就会耗费很多资源来频繁做检查点，数据处理 的速度就会受到影响。所以更好的方式是，每隔一段时间去做一次存档，这样既不会影响数据 的正常处理，也不会有太大的延迟——毕竟故障恢复的情况不是随时发生的。
2、触发保存的时间点
当所有任务都恰好处理完一个相同的输入数据的时候，将它们的 状态保存下来。首先，这样避免了除状态之外其他额外信息的存储，提高了检查点保存的效率。 其次，一个数据要么就是被所有任务完整地处理完，状态得到了保存;要么就是没处理完，状 态全部没保存:这就相当于构建了一个“事务”(transaction)。如果出现故障，我们恢复到之 前保存的状态，故障时正在处理的所有数据都需要重新处理;所以我们只需要让源(source) 任务向数据源重新提交偏移量、请求重放数据就可以了

checkpoint，状态恢复
Flink是一个分布式数据处理系统，因此必须有一套机制处理各种故障，比如被杀掉的进程，故障的机器和中断的网络连接。任务都是在本地维护状态的，所以Flink必须确保状态不会丢失，并且在发生故障时能够保持一致。

Flink的检查点（checkpoint）和恢复机制，这保证了“精确一次”（exactly-once）的状态一致性。

一致的检查点
Flink的恢复机制的核心，就是应用状态的一致检查点。有状态流应用的一致检查点，其实就是所有任务状态在某个时间点的一份拷贝，而这个时间点应该是所有任务都恰好处理完一个相同的输入数据的时候。

上面的应用程序中具有单一的输入源（source）任务，输入数据就是一组不断增长的数字的流——1,2,3等。数字流被划分为偶数流和奇数流。求和算子（sum）的两个任务会分别实时计算当前所有偶数和奇数的总和。源任务会将其输入流的当前偏移量存储为状态，而求和任务则将当前的总和值存储为状态。在图中，Flink在输入偏移量为5时，将检查点写入了远程存储，当前的总和为6和9。

从一致检查点中恢复状态：

这种检查点的保存和恢复机制可以为应用程序状态提供“精确一次”（exactly-once）的一致性。至于数据源是否可以重置它的输入流，这取决于其实现方式和消费流数据的外部接口。像Apache Kafka这样的事件日志系统可以提供流上之前偏移位置的数据重置，套接字（socket）消费数据的流就不能被重置了。

Flink的检查点算法

流应用中创建检查点的简单方法——先暂停应用，保存检查点，然后再恢复应用程序，这种方法很好理解，但它的理念是“停止一切”，这对于即使是中等延迟要求的应用程序而言也是不实用的。在是基于Chandy-Lamport算法实现了分布式快照的检查点保存。该算法并不会暂停整个应用程序，而是将检查点的保存与数据处理分离，这样就可以实现在其它任务做检查点状态保存状态时，让某些任务继续进行而不受影响。

Flink的检查点算法用到了一种称为“检查点分界线”（checkpoint barrier）的特殊数据形式。与水位线（watermark）类似，检查点分界线由source算子注入到常规的数据流中，它的位置是限定好的，不能超过其他数据，也不能被后面的数据超过。检查点分界线带有检查点ID，用来标识它所属的检查点；这样，这个分界线就将一条流逻辑上分成了两部分。分界线之前到来的数据导致的状态更改，都会被包含在当前分界线所属的检查点中；而基于分界线之后的数据导致的所有更改，就会被包含在之后的检查点中。

用一个简单的流应用程序作示例，来一步一步解释这个算法。该应用程序有两个源（source）任务，每个任务都消费一个增长的数字流。源任务的输出被划分为两部分：偶数和奇数的流。每个分区由一个任务处理，该任务计算所有收到的数字的总和，并将更新的总和转发给输出（sink）任务。

1. 作业管理器会向每个数据源（source）任务发送一条带有新检查点ID的消息，通过这种方式来启动检查点：

2. 当source任务收到消息时，它会暂停发出新的数据，在状态后端触发本地状态的检查点保存，并向所有传出的流分区广播带着检查点ID的分界线（barriers）。状态后端在状态检查点完成后会通知任务，而任务会向作业管理器确认检查点完成。在发出所有分界线后，source任务就可以继续常规操作，发出新的数据了。通过将分界线注入到输出流中，源函数（source function）定义了检查点在流中所处的位置。如图显示了两个源任务将本地状态保存到检查点，并发出检查点分界线之后的流应用程序。

3. 源任务发出的检查点分界线（barrier），将被传递给所连接的任务。与水位线（watermark）类似，barrier会被广播到所有连接的并行任务，以确保每个任务从它的每个输入流中都能接收到。当任务收到一个新检查点的barrier时，它会等待这个检查点的所有输入分区的barrier到达。在等待的过程中，任务并不会闲着，而是会继续处理尚未提供barrier的流分区中的数据。 对于那些barrier已经到达的分区，如果继续有新的数据到达，它们就不会被立即处理，而是先缓存起来。这个等待所有分界线到达的过程，称为“分界线对齐”（barrier alignment）

4. 当任务从所有输入分区都收到barrier时，它就会在状态后端启动一个检查点的保存，并继续向所有下游连接的任务广播检查点分界线

5. 所有的检查点barrier都发出后，任务就开始处理之前缓冲的数据。在处理并发出所有缓冲数据之后，任务就可以继续正常处理输入流了

6. 最终，检查点分界线会到达输出（sink）任务。当sink任务接收到barrier时，它也会先执行“分界线对齐”，然后将自己的状态保存到检查点，并向作业管理器确认已接收到barrier。一旦从应用程序的所有任务收到一个检查点的确认信息，作业管理器就会将这个检查点记录为已完成。如图显示了检查点算法的最后一步。这样，当发生故障时，我们就可以用已完成的检查点恢复应用程序了。

性能影响

Flink的检查点算法可以在不停止整个应用程序的情况下，生成一致的分布式检查点。但是，它可能会增加应用程序的处理延迟。所以Flink针对延迟做了一些调整：例如，文件系统（FileSystem）状态后端和RocksDB状态后端都支持了异步（asynchronous）检查点。RocksDB状态后端还实现了增量的检查点，这样可以大大减少要传输的数据量。

但是这其中会有一个阻塞的过程。在大多数情况下运行良好，然而当作业出现反压时，阻塞式的 Barrier 对齐反而会加剧作业的反压，甚至导致作业不稳定。

首先， Chandy-Lamport 分布式快照的结束依赖于 Marker 的流动，而反压则会限制 Marker 的流动，导致快照的完成时间变长甚至超时。无论是哪种情况，都会导致 Checkpoint 的时间点落后于实际数据流较多。

这时作业的计算进度是没有被持久化的，处于一个比较脆弱的状态，如果作业出于异常被动重启或者被用户主动重启，作业会回滚丢失一定的进度。如果 Checkpoint 连续超时且没有很好的监控，回滚丢失的进度可能高达一天以上，对于实时业务这通常是不可接受的。更糟糕的是，回滚后的作业落后的 Lag 更大，通常带来更大的反压，形成一个恶性循环。

所以在 Flink 1.11 版本中，引入了一个 Unaligned Checkpointing 的模块，主要功能是，在 barrier 到达之后，不必等待所有的输入流的 barrier，而是继续处理数据。
然后把第一次到达的 barrier 之后的所有数据也放到 checkpoint 里面，在下一次计算的时候，会合并上次保存的数据以及流入的数据后再计算。这样会大大加快 Barrier 流动的速度，降低 checkpoint 整体的时长。

两者的差异主要可以总结为两点:

1. 快照的触发是在接收到第一个 Barrier 时还是在接收到最后一个 Barrier 时。
2. 是否需要阻塞已经接收到 Barrier 的 Channel 的计算。

从这两点来看，新的 Unaligned Checkpoint 将快照的触发改为第一个 Barrier 且取消阻塞 Channel 的计算，算法上与 Chandy-Lamport 基本一致

比起 Aligned Checkpoint 中不同 Checkpoint 周期的数据以算子快照为界限分隔得很清晰，Unaligned Checkpoint 进行快照和输出 Barrier 时，部分本属于当前 Checkpoint 的输入数据还未计算（因此未反映到当前算子状态中），而部分属于当前 Checkpoint 的输出数据却落到 Barrier 之后（因此未反映到下游算子的状态中）。

这也正是 Unaligned 的含义: 不同 Checkpoint 周期的数据没有对齐，包括不同输入 Channel 之间的不对齐，以及输入和输出间的不对齐。而这部分不对齐的数据会被快照记录下来，以在恢复状态时重放。换句话说，从 Checkpoint 恢复时，不对齐的数据并不能由 Source 端重放的数据计算得出，同时也没有反映到算子状态中，但因为它们会被 Checkpoint 恢复到对应 Channel 中，所以依然能提供只计算一次的准确结果。

Unaligned Checkpoint和Aligned Checkpoint对比缺点：

1. 由于要持久化缓存数据，State Size 会有比较大的增长，磁盘负载会加重。
2. 随着 State Size 增长，作业恢复时间可能增长，运维管理难度增加。

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