Exactly Once(不丢不重)语义在Flink中的实现

一、内容介绍

数据流和动态表

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

Exactly-Once 和 Checkpoint

• Application Consistency Guarantees: 作业一致性保证
  • At-most-once：每条数据消费至多一次（出现故障啥也不做）
  • At-least-once：每条数据消费至少一次（可能存在重复消费）
  • Exactly-once: 每条数据都被消费且仅被消费一次（仿佛故障从未发生）
• Checkpoint: Flink 实现各个计算逻辑状态快照算法，也可指一次状态快照
• Checkpoint barrier: 用于标识状态快照的制作，也将数据划分成不同的消费区间
• Checkpoint Alignment: 等待多个上游的Checkpoint barrier到达的现象
• JobManager: 负责协调和管理 Checkpoint

端到端 Exactly-Once 实现

• Two-phase commit protocol: 两阶段提交协议
• Transaction: 一系列保证原子性操作的集合，即操作同时执行或者都不执行
• Kafka: 消息中间件
• State Backend: 用于管理和保存状态到远端可靠存储

Flink 案例讲解

• Deduplication：去重，在 state 保留的时间内对重复消息进行去重
• Aggregation：聚合操作，比如求和、求最大值等

---

二、数据流和动态表

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

    简介：动态表是数据流的SQL表达

2.1数据流和动态表转换

• Stream: 数据流
• Dynamic Table: 动态表
• Continuous Queries: 连续查询
• State 状态

流到动态表

 

动态表:与表示批处理数据的静态表不同，动态表是随时间变化的。可以像查询静态批处理表一样查询它们。数据库表是INSERT、UPDATE和DELETEDML语句的stream（流）的结果，通常称为changelog stream

• Changelog: 包含 INSERT/UPDATE/DELETE 等的数据流

2.2连续查询

连续查询特点
(流式)查询从不终止
查询结果会不断更新，产生一个新的动态表
在任何时候，连续查询的结果在语义上与以批处理模式在输入表快照上执行的相同查询的结果相同。

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

1.第一个查询更新先前输出的结果，即定义结果表的changelog流包含INSERT和>UPDATE操作;

2.第二个查询只附加到结果表，即结果表的changelog流只包含INSERT 操作。

 

 

2.3Retract（撤回）消息的产生

日志

 

2.4状态(针对故障)

需要存储每个用户的URL计数，以便能够增加该计数并在输入表接收新行时发送新结果（即能分布式对每一个数据统计运算）

 

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

1.At-most-once:出现故障的时候，啥也不做。数据处理不保证任何语义，处理时延低;数据丢失，但速度快，适合数据转接性不高，数据转接量大程序
2.At-least-once:保证每条数据均至少被处理一次（数据精确），一条数据可能存在重复消费。
3.Exactly-once:最严格的处理语义（银行金融），从输出结果来看，每条数据均被消费且仅消费一次，仿佛故障从未发生。

---

三、Exactly-Once（最严格的处理语义）和 Checkpoin

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

3.1状态快照与恢复

性质：时间结点备份恢复

 

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

一个简单的快照制作算法:
1．暂停处理输入的数据;
2．等待后续所有处理算子消费当前已经输入的数据;
3．待2处理完后，作业所有算子复制自己的状态并保存到远端可靠存储;
4．恢复对输入数据的处理

3.2Chandy-Lamport算法

3.3快照实现

• Checkpoint: Flink 实现各个计算逻辑状态快照算法，也可指一次状态快照
• Checkpoint barrier: 用于标识状态快照的制作，也将数据划分成不同的消费区间
• Checkpoint Alignment: 等待多个上游的Checkpoint barrier到达的现象
• JobManager: 负责协调和管理 Checkpoint

每一个source算子（预定频率）都接收到JM发送的Checkpoint Barrier标识状态快照制作(备份)的开始(上一次结束)

（上游）Source算子的处理:
各个source保存自己状态后，向所有连接的下游继续发送Checkpoint Barrier，同时告知JM自己状态已经制作完成。

（下游）Barrier Alignment:
source的下游算子会等待所有上游的Checkpoint barrier到达后才开始快照的制作;
已经制作完成的上游算子会继续处理数据，并不会被下游算子制作快照的过程阻塞，并为下游数据备份前进行数据缓存。
最后向JM发送快照制作完成信号，等待下一次备份

注：快照制作和处理数据的解耦（双方依赖的程度降低，反之耦和）
不会等所以快照结束，当本算子快照结束后会继续处理数据（按顺序，先缓存后上游）

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

3.4Checkpoint快照实现总结

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

---

四、端到端Exactly-Once 实现

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

4.1.端到端Exactly-once语义

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

4.2两阶段提交协议

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

4.2.1 两阶段提交协议(一)–预提交阶段

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

4.2.2两阶段提交协议(二)–提交阶段

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

1. 协作者向所有参与者发送一个 commit消息;
2. 每个收到commit消息的参与者释放执行事务所需的资源，并结束这次事务的执行;
3. 完成步骤2后，参与者发送一个ack(确认字符，表示接收到的字符无错误)消息给协作者;
4. 协作者收到所有参与者的ack消息后，标识该事务执行完成。

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

4.2.3Flink中2PC Sink(两阶段提交协议在Sink实现)

协作者(coordinator)参与者(participant)

 

预提交阶段：

 

提交阶段：barrier发布参与者

 

（barrier传递，向State Backend反馈vote）

正式提交（全vote yes,向下游发起commit，提交）

 

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

---

五、Flink案例讲解

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

5.1账单计算服务

当前方案：从Kafka中读取账单消息，进行处理后写入到 MySQL中

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

 

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

Flink方案
优势:
1．严格意义上的端到端的Exactly-Once语义:下游读到的数据是不丢不重的;
2．增强的去重能力:可以在更长的时间维度对数据进行去重。