Exactly Once 语义在 Flink 中的实现 ｜ 青训营笔记
这是我参与「第四届青训营 」笔记创作活动的第1天
重点内容：
一、数据流和动态表
不同数据处理保证的语义
1. At-most-once: 出现故障的时候，啥也不做。数据处理不保证任何语义，但处理时延迟低;
2. At-least-once: 保证每条数据均至少被处理一次，但是一条数据可能存在重复消费。
3. Exactly-once: 最严格的处理语义，从输出结果来看，每条数据均被消费且仅消费一次，仿佛故障从未发生。
二、Exactly-Once 和 Checkpoint
Flink是通过Checkpoint来实现Exactly-Once领域的
1、状态快照与恢复
我们的计算是有状态的，为了保证数据的不丢不重，我们要对设置一个数据恢复的时间点（”进行备份“），那我们怎样才能选择一个好的时间点呢？
2、制作快照时间点
数据恢复的时间点是有要求的：需要等待所有处理逻辑消费完成，source保留状态及之前的数据。否则的话，使用其他时间点可能会造成数据的丢失。
简单制作快照的算法：
-
1.暂停处理输入的数据
-
2.等待后续所有处理算子消费当前已经输入的数据
-
3.待2处理完后，作业所有算子复制自己的状态并保存到远端可靠存储
-
4.恢复对输入数据的处理
三、Flink端到端的Exactly-once语义
问题：
图一
- Checkpoint 能保证每条数据都对各个有状态的算子更新一次，sink输出算子仍然可能下发重复的数据；
严格意义的端到端的Exactly-once语义需要特殊的sink 算子实现---两阶段提交协议
两阶段提交协议在Sink中的运用：
图二
-
事务开启：在 sink task 向下游写数据之前，均会开启一个事务，后续所有写数据的操作均在这个事务中执行，事务未提交前，事务写入的数据下游不可读；
-
预提交阶段：JobManager 开始下发 Checkpoint Barrier，当各个处理逻辑接收到 barrier 后停止处理后续数据，对当前状态制作快照，此时 sink 也不在当前事务下继续处理数据（处理后续的数据需要新打开下一个事务）。状态制作成功则向JM成功的消息，失败则发送失败的消息；
-
提交阶段：若 JM 收到所有预提交成功的消息，则向所有处理逻辑（包括 sink）发送可以提交此次务的消息，sink 接收到此消息后，则完成此次事务的提交，此时下游可以读到这次事务写入的数据；若 JM 有收到预提交失败的消息，则通知所有处理逻辑回滚这次事务的操作，此时 sink 则丢弃这次事务提交的数据。
四、总结
1、
| 特征 | SQL | 流处理 |
|---|---|---|
| 处理数据的有界性 | 处理的表是有界的 | 流是一个无限元组序列 |
| 处理数据的完整性 | 执行查询可以访问完整的数据 | 执行查询无法访问所有的数据 |
| 执行时间 | 批处理查询产生固定大小结果后终止 | 查询不断更新结果，永不终止 |
2、Flink是通过Checkpoint来实现Exactly-once领域的
3、我们的计算是有状态的，为了保证数据的不丢不重，我们要对设置一个数据恢复的时间点
4、两阶段提交协议在Sink中的运用可以使下游读到的数据是不丢不重的
注：
图片来源
图一：Stream Processing with Apache Flink by Fabian Hueske Vasiliki Kalavri
图二：An Overview of End-to-End Exactly-Once Processing in Apache Flink(with Apache Kafka, too!)
