这是我参与「第四届青训营」笔记创作活动的第3天。
课程目录
1.数据流和动态表
2.Exactly-Once和Checkpoint
3.端到端Exactly-Once实现
4.Flink案例讲解
1.数据流和动态表
1.1 随处可见的流式数据
1.2 传统SQL和流处理
| 特征 | SQL | 流处理 |
|---|---|---|
| 处理数据的有界性 | 处理的表是有界的 | 流是一个无限元组序列 |
| 处理数据的完整性 | 执行查询可以访问完整的数据 | 执行查询无法访问所有的数据 |
| 执行时间 | 批处理查询产生固定大小结果后终止 | 查询不断更新结果，永不终止 |
1.3 概述-数据流和动态表转换
- 数据流和动态表之间的转换
- 在数据流的查询不会终止
- 查询可能会有状态，用来不断更新查询的结果
在流上定义表
下图显示了单击事件流（左侧）如何转换为表（右侧）。当插入更多的单击流记录时，结果表将不断增长。
动态表：与表示批处理数据的静态表不同，动态表是随时间变化的。可以像查询静态批处理表一样查询他们，数据表是INSERT、UPDATE和DELETE DML语句的steam的结果，通常称为changelog stream。
1.4 连续查询
- 查询从不终止
- 查询结果会不断更新，产生一个新的动态表
1.5 查询产生仅追加数据的动态表
1.6 两个连续查询对比
- 第一个查询更新先前输出的结果，即定义结果表的changelog流包含INSERT和UPDATE操作
- 第二个查询只附加到结果表，即结果表的changelog流只包含INSERT操作
1.7 Retract消息的产生
1.8 状态
需要存储每个用户的URL计数，以便能够增加该计数并在输入表接收新行时发送新结果。
1.9 数据流和动态表转换回顾
1.10 不同数据处理保证的语义
- At-most-once：出现故障的时候，啥也不做。数据处理不保证任何语义，处理时延低
- At-least-once：保证每条数据至少被处理一次，一条数据可能存在重复消费
- Exactly-once：最严格的处理语义，从输出结果来看，每条数据均被消费且仅消费一次，仿佛故障从未发生
2.Exactly-Once和Checkpoint
2.1 状态快照与恢复
2.2 制作快照的时间点
状态恢复的时间点：需要等待所有处理逻辑消费完成source保留状态机之前的数据。
一个简单的快照制作算法：
- 暂停处理输入的数据
- 等待后续所有处理算子消费当前已经输入的数据
- 待2处理完后，作业所有算子复制自己的状态并保存到远端可靠存储
- 恢复对输入数据的处理
2.3 chady-Lamport算法
2.3.1 快照制作的开始
每一个source算子都接收到JM发送的Checkpoint Barrier标识状态快照制作的开始。
2.3.2 Source算子的处理
各个source保存自己状态后，向所有连接的下游继续发送Checkpoint Barrier，同时告知JM自己状态已经制作完成。
2.3.3 Barrier Alignment
- 算子会等待所有上游的barrier到达后才开始快照的制作
- 已经制作完成的上游算子会继续处理数据，并不会被下游算子制作快照的过程阻塞
2.3.4 快照制作和处理数据的解耦
2.3.5 checkpoint的结束
所有算子都告知JM状态制作完成后，整个Checkpoint就结束了
2.4 Checkpoint对作业性能的影响
- 解耦了快照制作和数据处理过程，各个算子制作完成状态快照后就可以正常处理数据，不用等下游算子制作完成快照
- 在快照制作和Barrier Alignment过程中需要暂停处理数据，仍然会增加数据处理延迟
- 快照保存到远端也可能极为耗时
3.Flink端到端的Exactly-once语义
3.1 端到端Exactly-once语义
3.2 两阶段提交协议
3.2.1 两阶段提交协议（一）-预提交阶段
3.2.2 两阶段提交协议（二）-提交阶段
若协作者成功接收到所有的参与者vote yes的消息：
3.2.3 两阶段提交协议（二）-提交阶段
若协作者有收到参与者vote no的消息（或者发生等待超时）：
3.3 Flink中2PC Sink
3.4 Flink两阶段提交总结
- 事务开启
- 预提交阶段
- 提交阶段
4.Flink案例讲解
4.1 账单计算服务：场景简介
从Kafka中读取账单消息，进行处理后写入到MySQL中。
4.1 账单计算服务：当前方案
从Kafka中读取账单消息，进行处理后写入到MySQL中。
执行步骤
- 在上次记录的位点之后，从Kafka中读取固定大小的数据
- 对该批数据进行去重和聚合计算
- 处理完成后写入Mysql中，若全部写入成功，则记录下当前读取到的消息的终止位置；若处理或者写入失败，则不记录位点
- 跳回步骤1
4.1 账单计算服务：存在的问题
从Kafka中读取账单消息，进行处理后写入到MySQL中。
存在的问题
- 非严格意义上的端到端的Exactly-Once语义
- 去重能力有限
4.1 账单计算服务：Flink解决方案
从Kafka中读取账单消息，进行处理后写入到MySQL中。
优势
- 严格意义上的端到端的Exactly-Once语义
- 增强的去重能力
