这是我参与「第四届青训营 」笔记创作活动的的第3天
课堂内容
数据流和动态表
大致过程是这样
就是说数据流要变成动态表，去进行一系列的查询工作continuous Quey，并且要保留他的状态到STATE，然后查询结果产生出一个新的动态表输出到数据流中。数据流和动态表是可以转化的。
具体过程如下：
然后呢，下面这个是有窗口和没窗口的查询，有窗口就有UPDATE和INSERT,没窗口就只要INSERT
对数据进行计数的过程有一个Retract的产生，就是一个更新的过程，把前面的数据删掉，然后加人新的数据。
对数据处理保证的语义有三种：At-most-once,At-least-once,Exactly-once
Exactly-once和Checkpoint
在Flink中的Exactly-once语义是通过JM发出checkpoint的指令实现的。 在这之前我们需要了解状态快照和恢复的概念，我们是用状态快照来恢复我们的数据，从而实现Exactly-once。
source算子:记录当前消费的数据流的位点
sum_even算子：记录当前偶数累加的值
sum_odd算子：记录当前奇数累加的值
Chandy-Lamport算法：分布式的数据流奇偶数累加
Flink的快照制作过程\
首先是JM发出checkpoint指令，然后source短暂的停止运行，并保存自己的状态，然后向下游发送checkpiont barrier同时告诉JM自己的状态已经保存完毕。下游接收到checkpoint barrier就开始快照的执行，然后告诉JM自己的状态保存好了，当所有的算子都告诉JM状态制作完成后，整个checkpoint就结束即快照制作完成。同时我们需要知道一点整个过程解耦，上游完成之后就可以继续运行，不用等全部执行完。
Flink的端到端的Excatly-once
严格意义的端到端需要特殊的sink，所以我们有了一个两阶段提交协议，第一阶段预提交，commit指令先走一遍。第二阶段提交阶段，就是根据第一阶段如果全部yes，就实际commit执行然后做完了发个ask回来。然后第一阶段有no，就回滚rollback。
实际过程如下
预提交
提交阶段
总结
Flink案例讲解
当前方案
Flink方案
课后学习
- 流式处理中算子为什么会有状态？
- 数据流和动态表之间是如何进行转换的？
- Flink 作业为什么需要考虑故障恢复？
- Flink 故障恢复前为什么需要Checkpoint？
- 为什么不能保留任意时刻的状态作为故障恢复的时间点？
- Flink Checkpoint 对作业性能的影响有多大？
- 两阶段提交协议对性能影响有多大？
- 写入下游如果不支持事务读写，能做到 Exactly-Once 语义么
