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

二粒砂
125 阅读8分钟

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

1.数据流和动态表

如何在数据流上执行SQL语句，说明流式处理中状态的概念

①传统SQL和流处理对比

image.png

②数据流和动态表转换

image.png

在流上定义表

动态表：与表示批处理数据的静态表不同，动态表是随时间变化的。可以像查询静态批处理表一样查询它们

③连续查询

image.png

连续查询：

  • 查询从不终止
  • 查询结果会不断更新，产生一个新的动态表

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

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

由于查询的时间窗口变化，因此不会产生新的动态表，而是在原有的表的基础上进行追加

上述两种查询的区别：

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

  • 第一个查询根棍先前输出的结果，即定义结果表的changekog流包含Insert和Update操作
  • 第二个查询只附加到结果表，即结果表的changelog流中只包含INSERT操作

⑤Retract消息的产生

回撤消息

image.png

第三行数据进入，先回撤之前对于记录的Mary的操作，再进行更新

⑥状态

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

查询可能会有状态，用来不断更新查询的结果

⑦不同数据处理保证的语义

  • At-most-once：出现故障时，啥也不做。数据处理不保证任何语义，处理时延低
  • At-least-once：保证每条数据均至少被处理一次，一条数据可能存在重复消费
  • Exactly-once：最严格的处理语义，从输出结果看，每条数据均被消费且仅消费一次，仿佛故障从未发生

2.Exactly-Once和Checkpoint

当故障发生时，Flink自身如何从故障中恢复，保证对数据消费的不丢不重

①状态快照与恢复

例：三个算子:source（对其状态备份即其计算到的位置）、sum_even、sum_odd（状态：当前累加和）

image.png

②制作快照的时间点

状态恢复的时间点：需要等待所有处理逻辑消费完成source保留状态及之前的数据

一个简单的快照制作算法：

  1. 暂停处理输入的数据
  2. 等待后续所有处理算子消费当前以及输入的数据（即上流下发数据被当前需要用的所有算子都处理过）
  3. 等2处理完成后，作业所有算子复制自己的状态并保存远端可靠存储
  4. 恢复对输入数据的处理

③Chandy-Lamport算法

整体：向下传递barrier，恢复数据处理

image.png

  1. 快照制作的开始

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

  2. Source算子的处理

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

  3. Barrier Alignment

    算子会等待所有上游的barrier到达后才开始快照的制作

    已经制作完成的上游算子会继续处理数据，并不会被下游算子制作快照的过程阻塞

    快照制作保存完成后，算子才会给下游下发barrier，同时，算子会恢复处理缓存的数据

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

    sink的制作完成后会通知JM

  5. checkpoint的结束

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

④Checkpoint对作业性能的影响

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

3.端到端Exactly-Once实现

Flink本身的Checkpoint机制如何和外部存储结合，实现端到端的不丢不重语义

①端到端Exactly-once语义

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

②两阶段提交协议

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

  1. 预提交阶段

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

  2. 提交阶段

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

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

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

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

③Flink中2PC Sink

第一阶段

image.png

第二阶段

image.png

sink向Kafka commit后数据才是可见的

④Flink两阶段提交总结

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

4.Flink案例讲解

选择字节内部真实的案例场景，介绍Flink如何解决和实现账单计费服务

①账单计算服务：场景简介

从Kafka中读取账单消息，进行处理后写入到MySQL中

执行步骤

  1. 在上次记录的位点之后，从Kafka中读取固定大小的数据
  2. 对该批数据及逆行去重和聚合计算
  3. 处理完成后写入Mysql中，若全部写入成功，则记录下当前读取到的消息的终止位置；若处理或者写入失败，则不记录位点
  4. 跳回步骤1

存在的问题

  1. 非严格意义上的端到端的Exactly-once语义：若该批数据处理完成之后，在写入MySQL中发生异常，则存在部分数据写入的情况，下次作业启动后，这部分数据仍然会重复写入
  2. 去重能力有限：只能在当前处理的一批数据内进行去重，无法在批与批之间进行去重

Flink解决方案

image.png

  1. 优势

    • 严格意义上的端到端的Exactly-Once语义：下游读到的数据是不丢不重的
    • 增强的去重能力：可以在更长时间维度对数据进行去重

5.总结

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