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

恣潜
91 阅读5分钟

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

1、数据流和动态表

传统SQL和流处理

image.png

  • 有界：数据在一定程度上固定

  • 流：数据源源不断改变、增减

数据流和动态表转换

动态表  ：  随时间不断变化的表，在任意时刻，可以像查询静态批处理表一样查询它们

image.png 数据流和动态表是不断转化的。

  • 当查询动态表时，按照那一时刻的状态可以看做静态表。动态表可以变成流。

  • 当插入动态表数据时，将流每一刻的数据动态的输入。流可以变成数据。

动态表到实时流的转换

  • Append-only Stream: Append-only 流（只有 INSERT 消息）

  • Retract Stream: Retract 流（同时包含 INSERT 消息和 DELETE 消息）

两种查询的比较

连续查询

image.png

这是一个从动态表到动态表的过程，每次有新的动态表更新，查询结果跟着更新。（不间断）

查询产生仅追加数据（即定义时间内的记录）的动态表

image.png

虽然这两个实例查询看起来非常相似（都计算分组计数聚合），但它们在一个重要方面不同：

  • 第一个查询：更新先前输出的结果，即定义结果表的 changelog 流包含 INSERT 和 UPDATE 操作
  • 第二个查询：只附加到结果表，即结果表的 changelog 流只包含 INSERT 操作。

Retract （回溯）消息的产生

image.png

状态

image.png

需要存储每个用户的 url 计数，以便能够增加该计数并在输入表接收新行时发送新结果

不同数据保证的语义

  • At-most-once：出现故障时，啥也不做。数据处理不保证任何语义，处理时延低；

  • At-least-once：保证每条数据均至少被处理一次，一条数据可能存在重复消费；

  • Exactly-once：最严格的处理语义，从输出结果来看，每条数据均被消费且仅消费一次，仿佛故障从未发生。

2、Exactly-Once 和 Checkpoint

状态快照与恢复

image.png

设置故障恢复的时间点（例如计算机定时快照备份），一旦故障发生将回到此时刻并恢复此时的状态

三个算子：

  • Source —> 负责读取数据流
  • sum_even —> 进行偶数累加 image.png

Checkpoint

  • Checkpoint barrier 的下发

  • 算子状态制作和 barrier 传递

  • 多个上游的等待 barrier 对齐现象

  • Checkpoint 并不阻塞算子数据处

  • Checkpoint ACK和制作完成

Checkpoint 对作业性能的影响

  • 解耦了快照制作和数据处理过程，各个算子制作完成状态快照后就可以正常处理数据，不用等下游算子制作完成快照

  • 在快照制作和 Barrier Alignment 过程中需要暂停处理数据，仍然会增加数据处理延迟

  • 快照保存到远端也可能会极为耗时

端到端 Exactly-Once 实现

端到端 Exactly-Once 语义

image.png

  • Checkpoint 能保证每条数据都对各个有状态的算子更新一次，sink输出算子仍然可能下发重复的数据

  • 严格意义的端到端的 Exactly-once 语义需要特殊的 sink 算子实现

两阶段提交协议

image.png

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

  • 1.预备提交阶段

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

  • 2.提交阶段

    • 若协作者成功收到所有参与者 vote yes 的消息：

      • 协作者向所有参与者发送一个 commit 消息
      • 每个收到 commit 消息的参与者释放执行事务所需的资源，并结束这次事务的执行
      • 完成 2 后，参与者发送一个 ack 消息给协作者
      • 协作者收到所有参与者的 ack 消息后，标识该事务所执行完成

    • 若协作者有收到参与者 vote no 的消息（或者发生等待超时）

      • 协作者向所有参与者发送一个 roolback 消息
      • 每个收到 roll back 消息的参与者回滚事务的执行操作，并释放事务所占资源
      • 完成 2 后，参与者发送一个 ack 消息给协作者
      • 协作者收到所有参与者的 ack 消息后，标识该事务的成功完成回滚

（3）Flink 中 2PC Sink

image.png image.png image.png image.png

（4）Flink 两阶段提交总结

image.png

  • 1.事务开启：在 sink task 向下游写数据之前，均会开启一个事务，后续所有写数据的操作均会在这个事务中执行，事务未提交之前，事务写入的数据下游不可读；】

  • 2.预提交阶段：JobManager 开始下发 CheckPoint，当各个处理逻辑接收到 barrier 后停止处理后续数据，对当前状态制作快照，此时 sink 也不在当前事务下继续处理数据（处理后续的数据需要新打开下一个事务），状态制作成功则向 JM 成功的消息，失败则发送失败的消息；

  • 3.提交阶段：若 JM 收到所有预提交成功的消息，则向所有处理逻辑（包括 sink）发送可以提交此次事务的消息，sink 接收到此消息后，则完成此次事务的提交，此时下游可以读到这次事务写入的数据；若 JM 有收到预提交失败的消息，则通知所有处理逻辑回滚这次事务的操作，此时 sink 则丢弃这次事务提交的数据下游。

avatar
文章
阅读
粉丝