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

哈喽大家好，今天是录播学习的第三天，我在这里做了简要的笔记总结供大家查阅。

01.数据流和动态表

传统的SQL和流处理的特征

数据流和动态表转换

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

通过连续查询来不断更新查询结果，产生一个新的动态表作为输出结果。

retract消息:不断对前面消息进行回撤。

数据处理保证的语义：
    1.At-most-once:出现故障的时候，啥也不做。数据处理不保证任何语义，处理时延低；当错误解决后运算耗时低。
    2.At-least-once:保证每条数据均至少被处理一次，但一条数据可能存在重复消费。
    3.Exactly-once:最严格的处理语义，从输出结果来看，每条数据均被消费且仅消费一次，仿佛故障从未发生。

02.Excatly-Once和Checkpoint

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

一个简单的快照制作算法：
    ·暂停处理输入的数据；
    ·等待后续所有处理算子消费当前已经输入的数据；
    ·步骤二结束后，作业所有算子复制自己的状态并保存到远端可靠存储；
    ·恢复对输入数据的处理。

当所有的算子JM状态全部完成后，checkpoint结束

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

03.端到端Rxcatly-Once实现

端到端Rxcatly-Once语义：Checkpoint 能保证每条数据都对各个有状态的算子更新一次，sink输出算子仍然可能下发重复的数据。\

两阶段提交协议:

在多个节点参与执行的分布式系统中，为了协调每个节点都能同时执行或者回滚某个事务性的操作，引入了一个中心节点来统一处理所有节点的执行逻辑，这个中心节点叫做协作者（coordinator），被中心节点调度的其他业务节点叫做参与者（participant）。\

预提交阶段:

1.协作者向所有参与者发送一个commit消息；
2.每个参与的协作者收到消息后，执行事务，但是不真正提交；
3.若事务成功执行完成，发送一个成功的消息（vote yes）；执行失败，则发送一个失败的消息（vote no）\

提交阶段:\

若协作者成功接收到所有的参与者 vote yes 的消息： 1.协作者向所有参与者发送一个 commit 消息；
2.每个收到 commit 消息的参与者释放执行事务所需的资源，并结束这次事务的执行；
3.完成步骤2后，参与者发送一个 ack 消息给协作者；
4.协作者收到所有参与者的 ack 消息后，标识该事务执行完成。\

若协作者有收到参与者 vate no 的消息（或者发生等待超时）： 1.协作者向所有参与者发送一个 rollback 消息；
2.每个收到 rollback 消息的参与者回滚事务的执行操作，并释放事务所占资源；
3.完成步骤2后，参与者发送一个 ack 消息给协作者；
4.协作者收到所有参与者的 ack 消息后，标识该事务成功完成回滚。

04.Flink案例讲解

从kafka队列中读取账单信息，进行处理后写入mysql数据库： 1.在上次记录的位点之后，从kafka中读取固定大小的数据；
2.对该批数据进行去重和聚合计算；
3.处理完成后写入mysql，若全部写入成功，记录下当前读取道德消息的最终位置；若处理或者写入失败，则不记录；
4.返回步骤1

今天对Exactly Once 语义在 Flink 中的实现的学习就到这里了，感谢观看！