这是我参与「第四届青训营 」笔记创作活动的的第3天.
课程内容
01.数据流和动态表
02.Exactly-Once 和 Checkpoint
03.端到端Exactly-Once实现
04.Flink案例讲解
01.数据流和动态表
1. 传统的SQL处理和流处理的异同：
2. 数据流和动态表的转换
2.1. Stream->Dynamic Table
动态表：与表示批处理数据的静态表不同，动态表是随时间变化的。可以像查询静态批处理表一样查询它们。
2.2. Dynamic Table->Continuous Query
连续查询：查询从不终止；查询结果会不断更新，产生一个新的动态表。
在任何时候，连续查询的结果在语义上与以批处理模式在输入快照上执行的相同查询的结果相同。
另一种连续查询方式：查询产生仅追加数据的动态表
上述两种方法的对比：
①第一个连续查询，查询更新了的动态表之前先输出上一次的结果，定义结果表的changelog流包含了insert和update操作；
②第二个查询只附加到结果表，定义结果表的changelog流只包含insert操作
③两个表都计算分组计数聚合
2.3. Retract消息的产生
如上图所示，-表示delete，+表示insert，箭头指向的是上游，处理的步骤是从上游到下游，即与箭头所指方向相反。
2.4. 状态
数据源为流，需要源源不断地更新，查询也在连续地查询，需要引入状态对查询进行标记，以便能够在输入表接收新行时发送新结果。
3.不同数据处理保证语义
应对查询出现故障的处理
三种语义：
02.Exactly-Once 和 Checkpoint
如何确保语义不丢不重：设置故障恢复的时间点
1. 状态快照与恢复
规定每次到某一时刻，将系统所有的状态进行一张快照，存储下来，在后续故障发生时，回退到最近一次快照的状态，对计算进行恢复。
制作快照的时间点：
状态恢复的时间点：需要等待所有处理逻辑消费完成source保留状态及之前的数据，保证上游状态的所有数据已被下游处理，即此刻处于一致性状态。
一个简单的快照制作算法：
暂停处理输入的数据
等待后续所有处理算子消费当前已经输入的数据
待2处理完后，作业所有算子复制自己的状态并保存到远端可靠存储；
恢复对输入数据的处理
实践中的快照制作：
Chandy-Lamport算法（九几年的算法）： 可以实现快照制作和处理数据的解耦。
Checkpoint对作业性能的影响：
- 解耦了快照制作和数据处理的过程，各个算子制作完成状态快照后就可以正常处理数据，不用等待下游算子完成快照的制作
- 在快照制作和Barrier Alignment过程中需要暂停处理数据，仍然会增加数据处理的延迟
- 快照保存到远端也有可能极为耗时
03.端到端Exactly-Once实现
端到端Exactly-once语义：
两阶段提交协议：
多节点参与执行的分布式系统中，为了协调每个节点都能同时执行或者回滚某个事务性的操作，引入了一个中心节点来统一处理所有节点的执行逻辑，这个中心节点叫做协作者，被中心节点调度的其他业务节点叫做参与者（participant）。
阶段一：预提交阶段
- Coordinator向所有参与者发送一个commit消息；
- 每个参与的Coordinator收到消息后，执行事务，但是不真正提交；
- 若事务成功执行完成，参与者发送一个成功的消息（vote yes），执行失败则发送失败消息（vote no）给协调者；
阶段二：提交阶段
情况一，若协作者成功接收到所有参与者vote yes的消息：
- 协作者向所有参与者发送一个commit消息；
- 每个收到commit消息的参与者释放执行事务所需的资源，并结束这次事务的执行；
- 完成步骤2后，参与者发送一个ack消息给协作者；
- 协作者收到所有参与者的ack消息后，标识该事务执行完成。
情况二，若协作者有收到vote no的消息（或者发生等待超时）：
- 协作者向所有参与者发送一个rollback消息；
- 每个收到rollback消息的参与者参与事务回滚操作，并释放事务所占资源；
- 完成步骤2后，参与者发送一个ack消息给协作者；
- 协作者收到所有参与者的ack消息后，标识该事务成功完成回滚。
Flink 中的 两阶段提交协议：
