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

Exactly Once语义在Flink中的实现

一、数据流和动态表

1.1 传统SQL和流处理

1.2 数据流和动态表转换

1.3 在流上定义表

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

1.4 连续查询

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

1.5 两个连续查询对比

1.6 Retract消息的产生

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

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

二、Exactly-Once和Checkpoint

2.1 状态快照与恢复

2.2 制作快照的时间点

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

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

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

2.3 Chandy-Lamport算法

2.3.1 快照制作的开始

每一个source算子都接收到JM发送的Checkpoint Barrier表示状态快照制作的开始

2.3.2 Source算子的处理

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

2.3.3 Barrier Alignment

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

已经制作完成的上游算子会继续处理数据没并不会被下游阻塞。

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

2.4 Checkpoint对作业性能的影响

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

三、端到端Exactly-Once实现

3.1 语义

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

3.2 两阶段提交协议

3.3 Flink中的2PC Sink

3.4 Flink两阶段提交总结

1. 事务开启
2. 预提交阶段
3. 提交阶段