眉山建设银行官方网站,网站建设平台合同,网站建设财务上做什么费用,东莞品牌网站建设本章内容
一致性检查点从检查点恢复状态检查点实现算法-barrier保存点Savepoint状态后端#xff08;state backend#xff09;
本文先设置一个前提#xff0c;流处理的数据都是可回放的#xff08;可以理解成消费的kafka的数据#xff09;
一致性检查点#xff08;che…本章内容
一致性检查点从检查点恢复状态检查点实现算法-barrier保存点Savepoint状态后端state backend
本文先设置一个前提流处理的数据都是可回放的可以理解成消费的kafka的数据
一致性检查点checkpoints 图1
checkpoint是Flink故障恢复的核心全称是应用状态的一致性检查点有状态流应用的一致性检查点其实就是所有任务处理完数据的状态在某个时间点的一份拷贝一份快照存储在状态后端这个时间点应用是所有任务能恰好处理完一个相同的输入数据的时候
图1中不考虑时间假设1、2、3、4、5、6、7为source源even为偶数624odd为奇数求和9135此时5这个数据在所有tasks都处理完成了每个任务都会提交一份快照给JM最终这份拓扑结构source任务状态是5、sum_even状态是6、sum_odd状态是9称为checkpoint 从检查点恢复状态 图2
在执行流应用期间Flink会定期保存状态的一致性检查点如果发生故障Flink会使用最近的检查点来一致恢复应用程序的状态并重新启动处理流程
假设处理到7这个数据的时候sum_even24612sum_odd在处理7这个数据的时候fail了应该如果恢复数据呢
第一步遇到故障之后重启受影响的应用应用重启的之后所有任务的状态都是空的 图3
第二步从checkpoint中读取状态将状态重置从检查点重新启动应用程序后其内部状态与检查点完成时的状态完全相同回到了和图1相同的状态如果算子设置了并行度也可以恢复。恢复后source任务必须从检查点恢复的结果后开始读取数据必须从6开始读取数据 图4
第三步开始消费并处理检查点到发生故障之间的所有数据。处理完7后sum_even24612sum_odd135716, 所有tasks都处理完后又会提交一个checkpoint 图5
这种检查点的保存和恢复机制可以为应用程序状态提供“精确一次”exactly-once的一致性因为所有的算子都会保存检查点并恢复其所有状态这样依一来所有的输入流就都会被重置到检查点完成时的位置。
检查点的实现算法
基于Chandy-Lamport算法的分布式快照将检查点的保存和数据处理分离开不暂停整个应用
思考一个问题flink如何判断某个数据已经处理完了呢比如图1的offset5的数据
答案是否在每个数据后面跟一个标记当读到这个标记的时候触发task状态的保存 检查点分界线checkpoint barrier
Flink的检查点算法用到了一种称为分界线barrier的特殊数据形式用来把一条流上数据按照不同的检查点分开分界线之前到来的数据导致的状态更改都会包含在当前分界线所属的检查点中二基于分界线之后的数据导致的所有更改就会包含在之后的检查点中 图6
barrier有很多叫法如检查点屏障等 分析一下barrier的工作流程假设现在有这样的一个场景有两个输入流的应用程序用并行的两个source任务来读取可以认为kafka的两个分区source并行度设置为2如图7所示。barrier也是和watermark一样都是通过广播的方式传递给下游算子 图7
source任务的并行度2sum任务的并行度也是2sink任务的并行度也是2。
如图7两个流的数据都是1、2、3、4、5、6蓝色数字圆圈代表最后一个处理的是蓝流里面的数据黄色数字圆圈代表最后一个处理的是黄流里面的数据。 图8
图8中两条流的情况下barrier如何传递呢watermark是取上游分区的最小值下面一起来看一下 图9
barrier是怎么产生的
答JobManager会向每个source任务同时发给并行的source任务发送一条带有检查点ID的消息蓝色三角形2通过这种方式来启动检查点。产生barrier的过程中不会影响下游task的正常工作图9相比图8黄2和蓝2都sink完成了图9中barrierID2插入在stream1的3后面stream2的4后面 图10
barrier随着数据流动广播到下游source任务处理完barrierID2后会向状态后端发送checkpoint记录此时的状态。图10相比图9蓝3和黄4都被sum任务处理了。
数据源将他们的状态写入检查点并发出一个检查点barrier状态后端在状态存入检查点之后会返回通知给source任务source任务就会向JobManager确认检查点完成
sum_even收到上游所有的barrier之后才能去做checkpoint状态保存这就叫做Barrier对齐分分界线对齐 图11
分界线对齐barrier向下游传递sum任务会等待所有的输入分区的barrier到达对于barrier已经到达的分区继续到达的数据会被缓存而barrier尚未到达的分区数据会被正常处理
图11中的sum_even中的蓝4需要被缓存因为来自上游任务的黄色barrierID2还未到达。stream1有可能在同一个slotstream2和stream1跨slot可能barrier到达的时间会不一致 图12
当收到所有分区的barrier时任务就讲其状态保存到状态后端的检查点中然后barrier继续向下游广播
图12中barrierID2继续向下游广播。此时蓝色4会从缓存中拿出来做接下来的计算 图13
图13中sum_even处理完4812以及46818任务开始正常的数据处理 图14
sink任务向JobManager确认状态保存到checkpoint完毕当所有的任务都确认已经成功将状态保存到检查点时检查点就真正完成了3-4-8-8拓扑保存完成
最终JobManager会向所有的任务确认task的状态是否正确确认完成后任务完成。
保存点
Flink还提供了自定义的镜像保存功能就是保存点savepoints原则上创建保存点使用的算法与检查点的完全相同因此保存点可以认为就是具有一些额外元数据的检查点Flink不会自动创建保存点因此用户或者外部调度系统必须明确的触发创建操作保存点是一个强大的功能。除了故障恢复外保存点可以用于有计划的手动备份更新应用程序版本迁移暂停和重启应用等等
状态后端
Flink 提供了三种可用的状态后端用于在不同情况下进行状态的保存 MemoryStateBackend
内存级的状态后端将监控状态作为内存中的对象进行管理将他们存储在TM的JVM堆上而将checkpoint存储在JM的内存中 FsStateBackend
将checkpoint存储到远程的持久化系统FileSystem中而对于本地状态和MemotyStateBackend一样也会存储在TM的JVM堆上 RocksDBStateBackend
将所有的状态序列化后存入本地的RocksDB中注意RocksDb的支持并不直接包含在Flink中需要引入依赖RocksDBStateBackend 是唯一支持增量快照的状态后端。 后续补充具体的代码
