flink中的作业一致性保证 | 青训营笔记

139 阅读5分钟

这是我参与「第四届青训营 」笔记创作活动的第1天

1.为什么要进行作业一致性保证

流处理通常也被称之为事件处理,简单来说是指持续不断地处理一系列无穷无尽地数据或事件地过程。比如说统计用户访问网址的数据,用户之间的账户交易。

对于流处理,数据流本身是动态,没有所谓的开始或结束,虽然可以replay buffer的部分数据(批处理),但容错性(fault-tolerant)做起来会复杂的多。当发生故障的时候,需要对数据正确性进行保证。

2. 作业一致性保证

Application Consistency Guarantees: 作业一致性保证

  • At-most-once:每条数据消费至多一次,处理延迟低
  • At-least-once:每条数据消费至少一次,一条数据可能存在重复消费
  • Exactly-once:每条数据都被消费且仅被消费一次,仿佛故障从未发生

2.1 At-most-once

最多一次,可以保证数据或者事件最多由程序中的所有算子处理一次,数据可能丢失。

image.png 这是最简单的恢复方式,直接从失败处的下个数据开始恢复程序,失败的不管了。这意味着如果数据在被流应用程序完全处理之前发生丢失,就不会进行其他重试或者发送。

2.2 At-least-once

至少一次,应用程序中的所有算子都保证数据或事件至少被处理一次,数据可能被处理多次。

image.png 这通常意味着如果事件在流应用程序完全处理之前丢失,则将从源头重放或重新传输事件。然而,由于事件是可以被重传的,因此一个事件有时会被处理多次(至少-次),至于有没有重复数据,不会关心,所以这种场景需要人工干预自己处理重复数据。

但是例如转账场景,是不能允许重复操作这样的处理方式的。

2.3 Exactly-once

精确一次:Exactly-once,不会丢弃,也不会重复(最理想), Exactly-Once 是 Flink、Spark 等流处理系统的核心特性之一

image.png 也就是说数据只会被正确地处理一次,而不是说数据只被处理一次,也有可能是多次,但只有最后一次是正确的,成功的。

通常有两种方法实现:

  1. 分布式快照或状态检查点,思想就是对比检查点和分布式快照中的状态,如出现状态不一致就回退到最小状态处,重新计算。
  2. At least Onece + 去重,重播失败的算子,并删除重复算子的结果。

从理论上看,上面这两种机制之间存在差异,但两者均可理解为至少一次处理外加幂等保证。上面提到的两种机制均使用持久的后端存储作为事实来源(Source of truth),用于保存每个操作符的状态,并自动提交状态更新。

  • 对于机制1(分布式快照/状态检查点),这个持久的后端存储可用于保存流应用程序中全局一致的状态检查点(每个运算符的状态检查点);
  • 对于机制2(至少一次事件交付,外加去重),这个持久的后端存储可用于保存每个运算符的状态,以及为了追踪哪些事件已经被成功处理过而为每个运算符生成的事务日志。

2.4 Effectively-Onece

有效的一次或者最终一次。状态的提交或对事实来源的持久后端进行的更新可描述为事件(Occurring)的严格一次。然而在计算状态的更新 / 改动,例如所处理的事件正在针对事件执行各种用户定义的逻辑时,如果失败则可能进行多次。事件的处理可能会进行多次,但处理的最终结果只会在持久的后端状态存储中体现一次。因此Streamlio认为“实际一次(Effectively-once)”可以更精确地描述这样地处理语义。

3. 端到端 Exactly-Once 实现

3.1 End-to-End Exactly-Once

Flink在1.4.0引入端到端的精确一次概念 如何实现局部的Exactly-Once有三种方式:

  1. At least Onece + 去重

image.png 2. At least Onece + 幂等

image.png 3. 分布式快照/Checkpoint—Flink使用的是这个

image.png

总结 image.png

3.2 Flink 实现Exactly-Once

3.2.1 分布式快照(checkpoint)

JobManager: 负责协调和管理 Checkpoint

Flink 实现各个计算逻辑状态快照算法,也可指一次状态快照

  • Checkpoint barrier 的下发

    • Checkpoint barrier :用于标识状态快照的制作,也将数据划分成不同的消费区间
    • 算子状态制作和 barrier 传递
    • Checkpoint Alignment:多个上游的等待 barrier 对齐现象
    • Checkpoint 并不阻塞算子数据处
    • Checkpoint ACK和制作完成

3.2.2 两阶段提交

  • Transaction: 一系列保证原子性操作的集合,即操作同时执行或者都不执行
  • State Backend: 用于管理和保存状态到远端可靠存储 img
  • Coordinator:协作者,同步和协调所有节点处理逻辑的中心节点
  • Participant:参与者,被中心节点调度的其他执行处理逻辑的业务节点

两阶段提交协议在 Flink 中的应用

  • Flink 中协作者和参与者的角色分配
  • 协作者(JobManager)发起阶段一提交
  • 各算子 Checkpoint 的制作
  • 提交阶段及 Checkpoint 的制作完成

参考文献

  1. 流式处理 术语解释 Exactly-once与Effectively-once

  2. Flink中 End-to-End Exactly-Once数据一致性语义详解

  3. 分布式一致性语义之Exactly-Once、Effectively-Onece等概念

  4. 大数据专场 学习资料一】第四届字节跳动青训营