Flink Exactly-once 实现原理解析

Exactly-once并不是代表数据只计算一次，而是数据只影响计算结果一次

背景

  通常情况下，流式计算系统都会为用户提供指定数据处理的可靠模式功能，用来表明在实际生产运行中会对数据处理做哪些保障。一般来说，流处理引擎通常为用户的应用程序提供三种数据处理语义：最多一次、至少一次和精确一次。

• 最多一次（At-most-Once）：这种语义理解起来很简单，用户的数据只会被处理一次，不管成功还是失败，不会重试也不会重发。
• 至少一次（At-least-Once）：这种语义下，系统会保证数据或事件至少被处理一次。如果中间发生错误或者丢失，那么会从源头重新发送一条然后进入处理系统，所以同一个事件或者消息会被处理多次。
• 精确一次（Exactly-Once）：表示每一条数据只会被精确地处理一次，不多也不少。
    Exactly-Once 是 Flink、Spark 等流处理系统的核心特性之一，这种语义会保证每一条消息只被流处理系统处理一次。“精确一次” 语义是 Flink 1.4.0 版本引入的一个重要特性，而且，Flink 号称支持“端到端的精确一次”语义。

  在这里我们解释一下“端到端（End to End）的精确一次”，它指的是 Flink 应用从 Source 端开始到 Sink 端结束，数据必须经过的起始点和结束点。Flink 自身是无法保证外部系统“精确一次”语义的，所以 Flink 若要实现所谓“端到端（End to End）的精确一次”的要求，那么外部系统必须支持“精确一次”语义；然后借助 Flink 提供的分布式快照和两阶段提交才能实现。
要求：

• 内部保障：checkpoint
• source：重设数据读取位置
• sink：故障恢复时不会重复写
  • 幂等写入：(e^x)N = (e^N)x ， 操作多次，但是只有第一次操作有效。
  • 事务写入：要么全成功，要么全失败。 实现方式：
    • 1、预写日志；
    • 2、两阶段提交；等checkpoint真正完成再写入sink。

实现原理

Flink的容错机制checkpoint

  Flink 提供了失败恢复的容错机制checkpoint，而这个容错机制的核心就是持续创建分布式数据流的快照（snapshot ）来实现。Flink由JobManager协调各个TaskManager进行checkpoint存储,checkpoint保存在 状态后端（StateBackend）中,默认StateBackend是内存级的,也可以改为文件级的进行持久化保存（配置即可）。
ck的核心：分布式快照机制:Barrier
  Flink 分布式快照的核心元素之一是 Barrier（数据栅栏），我们也可以把 Barrier 简单地理解成一个标记，该标记是严格有序的，并且随着数据流往下流动。每个 Barrier 都带有自己的 ID，Barrier 极其轻量，并不会干扰正常的数据处理。

1、什么时候产生Barrier

  当 checkpoint coordinator（job manager 的一部分）指示 task manager 开始 checkpoint 时，它会让所有sources 记录它们的偏移量（offset），并将编号的 checkpoint barriers 插入到它们的流中。这些 barriers 流经 job graph，标注每个 checkpoint 前后的流部分。

2、Barrier 工作流程

  如上图所示，假如我们有一个从左向右流动的数据流，Flink 会依次生成 snapshot 1、 snapshot 2、snapshot 3……Flink 中有一个专门的“协调者”负责收集每个 snapshot 的位置信息，这个“协调者”也是高可用的。
  Barrier 会随着正常数据继续往下流动，每当遇到一个算子，算子会插入一个标识，这个标识的插入时间是上游所有的输入流都接收到 snapshot n。与此同时，当我们的 sink 算子接收到所有上游流发送的 Barrier 时，那么就表明这一批数据处理完毕，Flink 会向“协调者”发送确认消息，表明当前的 snapshot n 完成了。当所有的 sink 算子都确认，这批数据成功处理后，那么本次的 snapshot 被标识为完成。
  这里就会有一个问题，因为 Flink 运行在分布式环境中，一个 operator 的上游会有很多流，每个流的 barrier n 到达的时间不一致怎么办？这里 Flink 采取的措施是：快流等慢流。(默认为EXACTLY_ONCE在设置checkpoint模式指定，如果设置为AT_LEAST_ONCE则不需要等)

快照的存储方式
  异步：按照上面的机制，每次在把快照存储到我们的状态后端(state BackEnd)时：如果是同步进行就会阻塞正常任务，从而引入延迟。因此 Flink 在做快照存储时，可采用异步方式。
  增量：因为checkpoint的保存大小可能多达T级，所以每次进行增量快照（即都是进行的全量 checkpoint，且是基于上次进行更新的，这样就不用重新创建ck导致慢且占用较多资源）。

两阶段提交

  分布式快照机制可以保证 Flink 系统内部的“精确一次”处理。但是我们在实际生产系统中，Flink 会对接各种各样的外部系统，比如 Kafka、HDFS 等，一旦 Flink 作业出现失败，作业会重新消费旧数据，这时候就会出现重新消费的情况，也就是重复消费。针对这种情况，Flink 1.4 版本引入了一个很重要的功能：两阶段提交，也就是 TwoPhaseCommitSinkFunction。两阶段搭配特定的 source 和 sink（特别是 0.11 版本Kafka）使得“精确一次处理语义”成为可能。
  在 Flink 中两阶段提交的实现方法被封装到了 TwoPhaseCommitSinkFunction 这个抽象类中，我们只需要实现其中的beginTransaction、preCommit、commit、abort 四个方法就可以实现“精确一次”的处理语义，实现的方式我们可以在官网中查到：

1. beginTransaction，在开启事务之前，我们在目标文件系统的临时目录中创建一个临时文件，后面在处理数据时将数据写入此文件；
2. preCommit，在预提交阶段，刷写（flush）文件，然后关闭文件，之后就不能写入到文件了，我们还将为属于下一个检查点的任何后续写入启动新事务；
3. commit，在提交阶段，我们将预提交的文件原子性移动到真正的目标目录中，请注意，这会增加输出数据可见性的延迟；
4. abort，在中止阶段，我们删除临时文件。
   以Kafkasource -> flink -> kafkaSink为例：
   整个过程可以总结为下面四个阶段：
5. 一旦 Flink 开始做 checkpoint 操作，那么就会进入 pre-commit 阶段，同时 Flink JobManager 会将检查点 Barrier 注入数据流中 ；
6. 当所有的 barrier 在算子中成功进行一遍传递，并完成快照后，则 pre-commit 阶段完成；
7. 等所有的算子完成“预提交”，就会发起一个“提交”动作，但是任何一个“预提交”失败都会导致 Flink 回滚到最近的 checkpoint；
8. pre-commit 完成，必须要确保 commit 也要成功，上图中的 Sink Operators 和 Kafka Sink 会共同来保证。