-
文章第一句话为“这是我参与「第四届青训营 」笔记创作活动的第27天（
-
数据流
-
SQL和流处理
- 有界性：SQL处理的表是有界的，流式是无限元组序列
- 完整性：SQL查询可访问完整的数据，流查询无法访问完整的数据
- 执行时间：SQL批处理查询产生固定大小结果后终止，流查询不断更新结果，永不终止
-
如何在流上定义表？
- 定义的是动态表，动态表随时间变化，可以像查询静态批处理表一样查询他们，在某一时间视为静态表
-
连续查询
- 查询永不终止，结果不断更新，产生新的动态表
- 任何时候，连续查询结果在语义上与批处理模式在输入表快照执行的相同查询结果相同
- 由动态表->动态表
- retract消息的产生：回撤，对之前的消息进行更新
- 状态：需要存储每个用户的URL计数，以便能够增加该计数并在输入表接受新行时发送新结果
-
查询出现故障怎么办？
- at-most-once：对结果要求不高
- at-least-once
- exactly-once
-
-
exactly-once和checkpoint
-
状态快照和恢复
- 快照：类似备份
-
制作快照的时间点
- 状态恢复的时间点：需要等待所有处理逻辑消费完成source表流状态即之前
- 重点：需要等待所有逻辑，所以很难实现
-
快照制作过程
- 每个算子都接受到JM发送的checkpoint barrier标识快照制作开始
- source先保存状态，并向下游发送checkpoint barrier，后向JM表示自己的状态已准备好
-
chandy-lamport算法
-
barrier alignment
- 算子等上游所有barrier到才开始制作快照
- 已制作完的算子不会影响其它
- checkpoint的结束
-
- 快照制作过程
-
-
flink端对端的exactly-once语义
-
两阶段提交协议
- 分布式协议，为保证协调性、事务性，引入一个中心节点来统一处理所有节点的执行逻辑
- 协作者：中心节点
- 参与者：被中心节点调度的其它业务节点
-
预提交阶段
- 协作者向所有参与者发送commit消息
- 参与者受到commit信息后可执行事务，但不提交
- 参与者状态制作好就向JM发送，我制作好（yes）了的信息；否则，提交no
-
提交阶段：前提协作者受到全部yes的信息
-
协作者想所有参与者发送commit消息
- 每个受到commit消息的参与者释放在此任务中的资源，并结束事务执行
- 参与者发ack消息给协作者
- 标识事务结束
-
-
提交阶段：前提协作者有收到no的信息或延迟了
- 发送rollback信息
- 收到信息的参与者需要回滚并释放资源
- 参与者发ack消息给协作者
- 标识事务成功回滚
- flink中的2pc SINK
- 总结：在这节课中，我们也是延续上一节课flink的基础，然后来继续讲述了一个exactlyonce，我认为exactly once是更加严格，更加精确，但是也要对我们的系统要求更加严格，在现实中想要完成的话，要求会比较高。
-
