这是我参与「第四届青训营 」笔记创作活动的的第3天
01 数据流和动态表
如何在数据流上执行SQL语句，说明流式处理中的状态的概念
1.1 随处可见的流式数据
1.2 传统SQL和流处理
1.3 数据流和动态表转换
- 流->表->流
1.3.1 在流上定义表
1.3.2 连续查询
- 查询从不终止
- 查询结果会不断更新，产生一个新的动态表
- 查询网络是有状态的
1.3.3 查询时产生仅追加数据的动态表
- 统计某一个时间窗口内的数据：统计一小时内用户的点击数，且时间窗口不重叠。
1.3.4 两次查询对比
1.3.5 Retract 消息的产生 （撤回消息）
- 这种场景一般只发生在流处理中
- 发生一个撤回消息，然后再插入新的消息
1.4 查询状态
1.5 不同数据处理保证的语义
\
02 Exactly-Once 和 Checkpoint
故障恢复机制
\
2.1 状态快照与恢复
- 如何选择Checkpoint
2.2 制作快照的时间点
\
2.3 Chandy-Lamport算法
2.3.1 开始制作快照
每一个source算子都接收到JM发送的Checkpoint Barrier标识状态快照制作的开始
2.3.2 Source算子的处理
2.3.3 Barrier Alignment
- 定义：算子会等待所有上游的barrier到大后才开始快照的制作
- 当source1的barrier到达时，source2的barrier还未到达，只会接受source1发送的数据。知道source2的barrier到达时，才会接受其发送的数据。
2.3.4 快照制作和数据处理的解耦
2.3.5 checkpoint的结束
2.4 Checkpoint对作业性能的影响
03 端到端 Exactly-Once实现
做到端到端的不丢不重语义
3.1 端到端 Exactly-Once的语义
\
3.2 两阶段提交协议
3.2.1 预提交阶段
3.2.2 提交阶段
- ALL Vote Yes
- Vote No
3.3 Flink中的2PC (2阶段提交) Sink
- Kafka是消息队列，可以理解为一个二维有序数组（二维队列），每一维的长度都是无限的，从头读数据，从尾写入数据。可读可写。本图中是上游从Kfaka读数据，下游将数据写入Kfaka
- Window算子是一个窗口算子，就像前面计算时间窗口的算子。
3.3.1 Pre-commit
\
3.3.2 Commit
\
3.4 Flink 2PC总结
04 Flink案例讲解
4.1 账单计算服务：场景简介
4.1.1 Kfaka读数据
\
- 针对第一点
-
- At least Once
- 由于Mysql本身有去重，做到了Exactly-once
