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

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

1 数据流和动态表

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

1.1 随处可见的流式数据

DB，GPS，银行存储，物联网

1.2 传统SQL和流处理

特征	SQL	流处理
处理数据的有界性	处理的表是有界的	流是一个无限元组概念
处理数据的完整性	执行查询可以访问完整的数据	执行查询无法访问所有数据
执行时间	批处理查询产生固定大小结果后终止	查询不断更新结果，永不终止

1.3概述-数据流和动态表的转换

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

1.4连续查询

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

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

1. At-most-once：出现故障的时候，啥也不做

2. At-least-once：保障每天数据至少被处理一次，一条数据可能存在重复消费

3. Exactly-once：最严格的语义，从输出结果来看，每条数据均被消费且消费一次

2 Exactly Once 和 checkpoint

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

2.1状态快照和恢复

快照：恢复到过去某一个状态

恢复：奇数累加器，偶数累加器，总数累加器

2.2 制作快照的时间点

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

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

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

2.3 Chandy—Lamport算法

1. 快照制作的开始：每一个source算子都接受到JM发生的checkpoint barrier 标识状态快照制作的开始
2. source算子的处理：各个source保存自己状态后，向所有连接的下游继续发生checkpoint barrier，同时告知JM自己状态已经制作完成
3. barrier alignment：
   1. 算子会等待所有上有的barrier到达后才开始快照的制作
   2. 已经制作完成的尚有算子会继续处理数据，并不会被下游算子制作快照的过程阻塞
4. 快照制作和处理数据的解耦
5. checkpoint的结束：所有算子都告知JM快照制作完成

2.4 checkpoint 对作业性能的影响

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

3.端到端 Exactly Once 实现

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

3.1 端到端Exactly Once语义

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

3.2两阶段提交协议

引入了一个中心节点来统一处理所有节点的执行逻辑，这个中心叫做协助者（coordinator），被中心节点调度的其他业务节点叫做参与者（participant）

1. 预提交阶段：
   1. 协助者向所有参与者发送一个commit消息
   2. 每个参与的协助者收到消息后，执行事务，但是不真正提交
   3. 若事务成功执行完成，发送一个成功的消息，执行失败，则发送一个失败的消息
2. 提交阶段：
   1. 协助者向所有参与者发送一个commit消息
   2. 每个收到commit消息的参与者释放执行事务所需的资源，并释放事务所占资源
   3. 完成步骤2后，参与者发送一个ack给协助者
   4. 协助者收到所有参与者的ack后，标识事务完成
   5. 如果没有收到全部ack，则发送rollback消息

3.3 Flink 中 2PC Sink

JM为协作者

Kafka中的data suorce， window（算子）， data sink 为参与者

3.4 Flink两阶段提交总结

1. 事务开启：在sink task写数据前开启事务
2. 预提交阶段：JM下发checkpoint，事务收到barrier 后停止处理后续数据，对当前状态制作快照，状态制作结果发送JM
3. 提交阶段：若JM收到所有预提交成功的消息，则向所有处理逻辑发送可以提交此次事务的消息，此时sink收到消息后，完成这次事务的提交，此时下游可以读到这次事务写入的数据，若JM收到失败消息，则通知所有处理逻辑回滚这次事务的操作，此时sink则丢弃这次事务提交的数据