这是我参与「第四届青训营 」笔记创作活动的第7天
课堂笔记
一、本堂课重点内容：
- 数据流和动态表
- checkpoint与Exactly-Once
- 端到端Exactly-Once
二、详细知识点介绍：
1.数据流与动态表的具体转化流程
在mysql等数据库中表是静态的。而在Flink SQL中由于数据流源源不断的进入，因此表是实时更新的，我们把这样的表叫做动态表。其具体转化流程如下：
从上可以看到数据流先转换为动态表,动态表接收连续的查询会转换为新的动态表，而动态表也可以转为新的流。
2.Retact消息的介绍
当动态表中某条消息的某个字段数据因新来的流数据需要变化时，是直接update还是怎么样呢？
- 首先并不是直接update,而是会有一个retract的操作,即把字段数据先删除；然后接着再insert一条更新后的数据。
3.三种不同的数据处理语义
- At-most-once:即一条数据最多发送一次，保证数据不重复，但不保证不丢失。
- At-least-once:即一条数据最少发送一次，保证数据不丢失,但不保证不重复。
- Exactly-once:每条数据被精确消费一次，是最严格的数据处理语义
4.checkpoint分布式一致性快照
为保证集群宕机之后数据处理不丢失,会对每个算子状态进行快照保存，因此宕机重启之后就能拿到之前的状态接着计算。checkpoint机制是Flink内部精确一次性的保证。
- 一个简单的算法实现是先暂停数据流再等待计算并保存状态，之后再打开数据流。显然这种stop the work的算法延迟太高，不适合流式计算低延迟的要求。
- Flink采用的是基于Chandy-Lamport的分布式一致性快照算法。source算子接收到JobManager的Barrier标志快照的开始，source保存完状态之后会接着往下传送Barrier,等到sink算子接收到Barrier保存完状态后，sink算子向JobManager发送通知标志一次chekpoint进行完。
5.严格端到端Exactly-Once具体实现
checkpoint能保证每条数据都对各个有状态的算子更新一次，sink输出算子仍然可能下发重复的数据。严格的Exactly-Once需要特殊sink算子的支持。具体实现为两提交阶段：
- 首先开启一个事物,sink写数据操作均在这个事物里进行
- 预提交阶段:JobManager下发barrier后，等待所有算子保存状态后成功后就向JobManager发送成功checkpoint的消息。
- 正式提交阶段：JobManager接收到成功消息后向sink算子发送可以提交事物的消息，sink正式提交事物。若JobManager收到失败消息，sink就会回滚事物。
三、课后个人总结：
通过本次课了解了Flink容错机制，以及数据精确一致性消费底层原理。
