『字节青训营-4th』L3:Exactly Once 语义在 Flink 中的实现
相关链接
🎶 学员手册:【大数据专场 学习资料一】第四届字节跳动青训营 - 掘金
数据流和动态表
随处可见的流式数据
传统 SQL 和流处理
数据流和动态图转换
先转换为动态表,再执行 SQL,再转为流
连续查询
查询产生仅追加数据的动态表
两个连续查询对比
Retract 消息的产生
对之前的结果进行回撤
状态
数据流和动态表转换回顾
不同数据处理保证的语义
Exactly-Once 和 Checkpoint
状态快照与恢复
一个源源不断的数字流,分布对奇数和偶数进行累加和
现在要备份,需要记录现在消费的位点(Source 算子)与目前的和(两个 sum 算子)
保存这 3 个状态,发生故障后就可以通过最近的保存点恢复
制作快照的时间点
不能在任意时间点保存,必须等待下游数据全部处理完成
因为恢复时上游不会重复下发数据,而下游可能在快照时还没处理或收到
可见这种方法需要停止业务消费,有没有更好的方法?
Chandy - Lamport 算法
更复杂一点的场景,有两个数据流并行处理
快照制作的开始
Source 收到 JM 发送的 Checkpoint Barrier 标识
Source 算子的处理
Source 短暂地停止处理,保存当前状态,然后继续向下游传递 Checkpoint Barrier 标识,然后就恢复数据的处理,不需要管下游
Barrier Alignment
对于下游节点,两个 Source 的 Checkpoint Barrier 不一定是同时到的(例如对于这里的 Sum even,Source 1 的 Checkpoint Barrier 先到了,而 Source 2 的还在路上),这时就需要等待上游的所有 Checkpoint Barrier 都到达,并且等待的时候要把数据阻塞起来,不进行处理,这个过程称为 Barrier Alignment
快照制作和处理数据的解耦
类似的过程也会发生在 Sink ,在这个过程中可以看见,快照的制作和处理数据是解耦的
Checkpoint 的结束
Checkpoint 对作业性能的影响
端到端 Exactly-Once 实现
端到端 Exactly-Once 语义
两阶段提交协议
预提交阶段
提交阶段
Flink 中 2PC Slink
预提交阶段,向 Source 发送 Checkpoint
向下游传递,每个节点开始制作快照,无论成功与否都向 JM 汇报结果
图中的三个算子都汇报成功的话,JM 就认定为快照制作成功
这个方案整体来看还是有延迟的
Flink 案例讲解
账单计算服务
场景介绍
当前方案
存在的问题
Flink 解决方案
课程总结
评论
GiscusTwikoo