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

也是不懂了
123 阅读11分钟

这是我参加「第四届青训营」笔记创作活动的第1天。在此次课中需要学习的主要内容分为四个方面：数据流和动态表、Exactly-Once和Checkpoint、端到端Exactly-Once实现以及Flink案例。

一、数据流和动态表

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

1. 传统SQL和流处理

image.png

2. 数据流和动态表转换

image.png

  • Stream：数据流
  • Dynamic Table：动态表
  • Continuous Queries：连续查询
  • state：计算处理逻辑的状态

流式持续查询的过程为：

  1. 流被转换为动态表。
  2. 对动态表计算连续查询，生成新的动态表。
  3. 生成的动态表被转换回流。

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

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

下图显示了单击事件流（左侧）如何转换为表（右侧）。 image.png 当插入更多的单击流记录时，结果表将不断增长。

4. 连续查询

  • 连续查询：会在动态表上做计算处理，并作为结果生成新的动态表。与批处理查询不同，连续查询从不终止，并根据输入表上的更新更新其结果表。

连续查询的特点：

  • 查询从不终止
  • 查询结果会不断更新，产生一个新的动态表
  • 结果的动态表也可转换成输出的实时流

下图展示了对点击事件流中的一个连续查询，这是一个分组聚合做count统计的查询。它将用户字段上的clicks表分组，并统计访问的url数。该图显示了随着时间的推移，当clicks表被其它行更新时如何计算查询。 image.png 在任何时候，连续查询的结果在语义上与以批处理模式在输入表快照上执行的相同查询的结果相同。

  • 在此处引入一个流式处理中状态的概念：需要存储每个用户的URL计数，以便能够增加该计数并在输入表接收新行时发送新结果。

4.1. 两个连续查询的对比

image.png

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

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

5. Retract消息的产生

  • Retract流是包含两类消息的流，添加（Add）消息和撤回（Retract）消息。
  • 动态表通过将INSERT编码为add消息、DELETE编码为retract消息、UPDATE编码为被更改行（前一行）的retract消息和更新后行（新行）的add消息，转换为retract流。

下图显示了将动态表转换为Retract流的过程。 image.png

6. 查询运行中出现故障怎么办？

以下有三种不同数据处理保证的语义：

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

二、Exactly-Once和Checkpoint

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

  • Checkpoint：Flink实现各个计算逻辑状态快照算法，也可指一次状态快照。在任务进行故障恢复的时候，可以还原到任务故障前最近一次检查点的状态，从而保证数据的一致性。

1. 状态快照与恢复

  • JobManager：负责协调和管理Checkpoint。 image.png

对于图中的数据来说，当前已经处理到了第5个数据，而且由于sum_odd（求奇数的和1+3+5=9）是9，当前这个5已经执行过该Task了，所以可以进行检查点保存了，所以图中保存的检查点是5-6-9，采用的是内存状态后端，保存到了JobManager上。

image.png

如果发生如上图数据来说，checkpoint是怎么工作的呢？

  1. 首先，重启应用。
  2. 从CheckPoint中读取状态将所有的状态重置。
  3. 开始消费并处理检查点到发生故障之间的所有数据。

2. 制作快照的时间点

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

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

  1. 暂停处理输入的数据；
  2. 等待后续所有处理算子消费当前已经输入的数据；
  3. 待2处理完后，作业所有算子复制自己的状态并保存到远端可靠存储；
  4. 恢复对输入数据的处理。

3. Chandy-Lamport算法

image.png

3.1. 快照制作的开始

Checkpoint barrier的下发： 每一个source算子都接收到JM发送的Checkpoint Barrier标识状态快照制作的开始。 image.png

  • Checkpoint barrier：用于标识状态快照的制作，也将数据划分成不同的消费区间。

3.2. Source算子的处理

算子状态制作和barrier传递：各个source保存自己状态后，向所有连接的下游继续发送Checkpoint Barrier，同时告知JM自己状态已经制作完成。 image.png

3.3. Barrier Alignment

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

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

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

Checkpoint并不阻塞算子数据处： image.png

3.5. checkpoint的结束

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

4. Checkpoint对作业性能的影响

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

三、Flink端到端的Exactly-once语义

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

1. 端到端Exactly-once语义

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

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

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

2.1. 两阶段提交协议（一）-预提交阶段

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

2.2. 两阶段提交协议（二）-提交阶段

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

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

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

  1. 协作者向所有参与发送一个rollback消息；
  2. 每个收到rollback消息的参与者回滚事务的执行操作，并释放事务所占资源；
  3. 完成步骤2后，参与者发送一个ack消息给协作者；
  4. 协作者收到所有参与者的ack消息后，标识该事务成功完成回滚。

3. Flink中2PC Sink

  • Transaction：一系列保证原子性操作的集合，即操作同时执行或者都不执行。
  • Kafka：消息中间件
  • State Backend：用于管理和保存状态到远端可靠存储。

  1. Flink中协作者和参与者的角色分配： image.png

  2. 协作者（JobManager）发起阶段-提交： image.png 两阶段提交协议的第一步是预提交。flink的jobmanager会在数据流中插入一个检查点的标记（这个标记可以用来区别这次checkpoint的数据和下次checkpoint的数据）。这个标记会在整个dag中传递。每个dag中的算子遇到这个标记就会触发这个算子状态的快照。

  3. 读取kafka的算子，在遇到检查点标记时会存储kafka的offset。之后，会把这个检查点标记传到下一个算子。到了flink的内存操作算子，这些内部算子不用考虑两阶段提交协议，因为它们的状态会随着flink整体的状态来更新或者回滚。 image.png

  4. 各算子Checkpoint的制作： image.png 到了和外部系统打交道的时候，就需要两阶段提交协议来保证数据不丢不重。在预提交这个步骤下，所有向kafka提交的数据都是预提交。

  5. 提交阶段及Checkpoint的制作完成： image.png 当所有算子的快照完成，也就是这次的checkpoint完成时，flink的jobmanager会向所有算子发通知说这次checkpoint完成，flink负责向kafka写入数据的算子也会正式提交之前写操作的数据。在任务运行中的任何阶段失败，都会从上一次的状态恢复，所有没有正式提交的数据也会回滚。

4. Flink两阶段提交总结

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

四、Flink案例

1. 账单计算服务

从Kafka中读取账单消息，进行处理后写入到MySQL中 image.png 执行步骤：

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

存在的问题：

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

Flink解决方案的优势：

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

五、总结

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