Exactly Once 语义在 Flink 中的实现 | 青训营笔记

阿狸啦啦啦
81 阅读7分钟

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

Exactly Once 语义在 Flink 中的实现

1.数据流和动态表

1.1.流式数据随处可见

1.2.传统SQL和流处理

image.png

1.3.数据流和动态表转换

image.png

Stream: 数据流
Dynamic Table: 动态表
Continuous Queries: 连续查询
State: 计算处理逻辑的状态
Append-only Stream: Append-only 流（只有 INSERT 消息）
Retract Stream: Retract 流（同时包含 INSERT 消息和 DELETE 消息）
Upsert Stream: Upsert 流（同时包含 UPSERT 消息和 DELETE 消息）
Changelog: 包含 INSERT/UPDATE/DELETE 等的数据流

image.png

  • 如何在实时数据流中定义 SQL 语义中的表？

    • 动态表 ： 随时间不断变化的表，在任意时刻，可以像查询静态批处理表一样查询它们。
    • 数据库表是INSERT、UPDATE和DELETE DML语句的stream的结果，通常称为changelog stream.

1.4.连续查询

  • 实时流的查询特点（连续查询）？
    • 查询从不终止
    • 查询结果会不断更新，并且会产生一个新的动态表
    • 结果的动态表也可转换成输出的实时流

image.png 查询用户在网页点击的所有次数

在任何时候，连续查询的结果在语义上与以批处理模式在输入表快照上执行的相同查询的结果相同。

1.5.查询产生仅追加数据的动态表

image.png 查询1H内用户点击窗口的次数

1.6.两个连续查询的对比

image.png 前者更新，后者附加

1.7.Retract消息的产生

image.png 1.把mary点击1的次数下发给下游 2.mary点击了prod网页，要更新，会首先先发一条回溯消息（-1），再发更新后的结果（+2）

1.8.状态

image.png

1.9.不同数据处理保证的语义

  • 查询运行中出现故障怎么办？
    • At−most−once\color{Orange}{At-most-once}：每条数据消费至多一次，处理延迟低。出现故障的时候啥也不做，数据处理不保证任何语义。
    • At−least−once\color{Orange}{At-least-once}：每条数据消费至少一次，一条数据可能存在重复消费
    • Exactly−once\color{Orange}{Exactly-once}：每条数据都被消费且仅被消费一次，仿佛故障从未发生。最严格的处理语义。

image.png

2.Exactly-Once和Checkpoint

2.1.状态快照与恢复

image.png

source：读取数据流
sum_even：偶数累加器
sum_odd：技术累加器
checkpoint：存有上述三部分的快照

image.png

出现故障了：1.重启应用 2.用checkpoint中的备份重启应用状态（恢复到上一个正常的状态）3.继续处理（重新处理故障的部分）

2.2.制作快照的时间点

  • 状态恢复的时间点:
    • 需要等待所有处理逻辑消费完成source保留状态及之前的数据。
  • 一个简单的快照制作算法:
    • 1.暂停处理输入的数据;
    • 2.等待后续所有处理算子都已消费当前已经输入的数据;
    • 3.待2处理完后，作业所有算子复制自己的状态并保 存到远端可靠存储;
    • 4.恢复对输入数据的处理

2.3.Chandy-Lamport算法

image.png

2.3.1.快照制作的开始

每一个source算子都接收到JM发送的Checkpoint Barrier标识状态快照制作的开始

image.png

2.3.2.source算子的处理

各个source保存自己状态后，向所有连接的下游继续发送Checkpoint Barrier,同时告知JM自己状态E经制作完成。

image.png

2.3.3.Barrier Alignment

  • 算子会等待所有上游的barrier到达后才开始快照的制作:
  • 已经制作完成的上游算子会继续处理数据，并不会被下游算子制作快照的过程阻塞。

image.png

2.3.4.快照制作和处理数据的解耦

image.png

2.3.5.Checkpoint结束

所有算子都告知JM状态制作完成后，整个Checkpoint就结束了。

image.png

2.4.checkpoint对作业性能的影响

  1. 解耦了快照制作和数据处理过程，各个算子制作完成状态快照后就可以正常处理数据，不用等下游算子 制作制作完成快照;
  2. 在快照制作和Barrier Alignment过程中需要暂停处理数据，仍然会增加数据处理延迟;
  3. 快照保存到远端也有可能极为耗时。

3.端到端 Exactly-Once 实现

3.1.端到端 Exactly-Once语义

  1. Checkpoint能保证每条数据都对各个有状态的算子更新一次，sink输出算子仍然可能下发重复的数据；
  2. 严格意义的端到端的Exactly- once语义需要特殊的sink算子实现。

3.2.两阶段提交协议（2PC）

在多个节点参与执行的分布式系统中，为了协调每个节点都能同时执行或者回滚某个事务性的操作，引入了一个中心节点来统一处理所有节点的执行逻辑，这个中心节点叫做协作者(coordinator)，被中心节点调度的其他业务节点叫做参与者(participant)。

image.png

  • Coordinator：协作者，同步和协调所有节点处理逻辑的中心节点
  • Participant：参与者，被中心节点调度的其他执行处理逻辑的业务节点

3.2.1.预提交阶段

  1. 协作者向所有参与者发送一个commit消息;
  2. 每个参与的协作者收到消息后，执行事务，但是不真正提交;
  3. 若事务成功执行完成，发送一个成功的消息(vote yes) ;执行失败，则发送一个失败的消息(vote no)

3.2.2.提交阶段

  • 若协作者成功接收到所有的参与者vote yes的消息:
  1. 协作者向所有参与者发送一个 commit消息;
  2. 每个收到commit消息的参与者释放执行事务所需的资源，并结束这次事务的执行;
  3. 完成步骤2后，参与者发送一个ack消息给协作者:
  4. 协作者收到所有参与者的ack消息后，标识该事务执行完成。
  • 若协作者有收到参与者vote no的消息(或发生等待超时) :
  1. 协作者向所有参与者发送个 rolback消息;
  2. 每个收到rollback消息的参与者回滚事务的执行操作，并释放事务所占资源;
  3. 完成步骤2后，参与者发送个 ack消息给协作者:
  4. 协作者收到所有参与者的ack消息后，标识该事务成功完成回滚。

3.3.Flink中的2PC

  • Flink 中协作者和参与者的角色分配

  • 协作者（JobManager）发起阶段一提交

  • 各算子 Checkpoint 的制作

  • 提交阶段及 Checkpoint 的制作完成

3.4.Flink两阶段提交总结

  1. 事务开启\color{Orange}{事务开启}：在sink task向下游写数据之前，均会开启一 个事务，后续所有写数据的操作均在这个事务中执行，事务未提交前， 事务写入的数据下游不可读;
  2. 预提交阶段\color{Orange}{预提交阶段}：JobManager 开始下发Checkpoint Barrier,当各个处理逻辑接收到barrier 后停止处理后续数据，对当前状态制作快照，此时sink也不在当前事务下继续处理数据(处理后续的数据需要新打开下一个事务)。状态制作成功则向JM成功的消息，失败则发送失败的消息;
  3. 提交阶段\color{Orange}{提交阶段}：若JM收到所有预提交成功的消息，则向所有处理逻辑(包括sink)发送可以提交此次事务的消息，sink 接收到此消息后，则完成此次事务的提交，此时下游可以读到这次事务写入的数据;若JM有收到预提交失败的消息，则通知所有处理逻辑回滚这次事务的操作，此时sink则丢弃这次事务提交的数据下。

4.Flink 案例讲解

4.1.账单计算场景服务

image.png

image.png

image.png

image.png

5.课程总结

  • 数据流可以转换成动态表，动态表也能重新转换成数据流
  • 处理无限数据流的算子可以是有状态的
  • Flink通过Checkpoint机制实现故障前后的状态快照制作和恢复
  • 支持两阶段提交协议的下游存储可以结合Flink Checkpoint机制实现严格意义上端到端的Exactly-Once语义实现
avatar
文章
阅读
粉丝