『字节青训营-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