flinkcheckpoint（flinkcheckpoint会产生小文件吗）

本篇文章给大家谈谈flinkcheckpoint，以及flinkcheckpoint会产生小文件吗对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、flink checkpoint
• 2、FLink Checkpoint 介绍
• 3、Flink1.13 Checkpoint原理

flink checkpoint

关于flink的状态， checkpoint，exactly once 消费

这一篇文章写的特别的好。

个人用自己的语言在捋一遍。

假设有如下一个程序：

kafka-source- keybyUser-sink(统计PV)

首先简单起见，假设只有一个并行度。

第一步是要开启 checkpoint机制，设置checkpoint的时间间隔，可以当作是某种形式的备份状态数据。

既然要备份，那么就可以选择需要备份的地方，可以是内存，也可以使外存，比如hdfs，rocketdb等。慧拦漏

以上面的例子为例，假设10分钟做一个checkpoint，我们看看是如何实前烂现的。

首先，jobManager 为整个job指定一个 checkpointer coordinator管理者（cdr），有他负责整个备份流程。

cdr 每10分钟发送一个事件，叫做barrier到流数据中。

从source 开始，在我们的例子中，source 备份了什么，主要就是记住，我已经消费了的kafka 的offset，比如

记录下来（partion-1， 1000）

然后，把barrier 转发给下游的算子，下游统计pv的程序，比如此时此刻，统计到

（site1,1000）, 在收到 barrier之后，就会停止目前的流计算，然后进行state备份。

备份完之后，发给下游sink，sink 看自己需求是否是无状态，决定是否需要备份。

等这三个阶段都完成之后，cdr 就会决定这个程序完成了一次checkpoint机制。

加入下一个轮回中，有相关的算子出现了异常，整个jobmanager可以从最新的checkpoint中进行恢复。

在上面的例子中，就是从kafka 最最新的offset 读取数据，然后，统计pv的算子，也可以从已有的

（site1,1000）继续统计。这就是整个checkpoint 和异常恢复的机制。

这里涉及到一点，就是在处理快照的时候，整个处理程序是要倍阻塞停顿的，比如（site1,1000）触发快照，

如果不停段，在写入state的时候可能就是（site1,1001）了，造成不准确，exactly-once无法保障。

现在让我们提高复杂度？假设在多个并行度的情况下如何做处理？

这里有一个类似与join的概念， 如果 一个 task，衡稿他的上游输入是有多个流的，那么

对于 sub1，sub2 的barrier，task 需要等待这两个barrier都到达之后做一个checkpoint 并且向下游发送barrier。

这个操作在flink里面叫做barrier对齐。 先到barrier，对于后续的流数据，通常会存在缓冲里面，并不做处理。

这样做通常会影响部分性能，但是Exactly Once时必须barrier对齐，如果barrier不对齐就变成了At Least Once；

那么exactly once 的case 我们也就大概明白。

对于多个并行度，只有做barrier对齐才能达到exactly once。

FLink Checkpoint 介绍

这一篇主要整理下Lightweight Asynchronous Snapshots for Distributed Dataflows 知识点。

算法的前提:

1.状态只有进程本地状态，并没有管道状态(输入档镇管道buffer数据，不作为状态一分部行唤粗)

2.由同类型进程(source节点)周期出发marker消息。

更接近Candy-Lamport的实现

这里Operator的输入分为两种

有环ABS比起无环ABS,更像是Candy-Lamport的最完整的实现。

非对齐checkpoint也是最接近Candy-Lamport的实现，状态是进程状态和管道消息。

flink的快照机制其实是参考Candy-Lamport算法实现的链滑，除了在source周期注入marker消息以外，最大的区别就是状态的组成上。

无法环ABS只有本地快照状态，有环ABS状态是本地快照状态 + 环路输入消息

非对齐checkpoint则是本地快照 + 输入消息 + 输出消息

[img]

Flink1.13 Checkpoint原理

Flink具体如何保证exactly-once呢? 它使用一种被称为"检查点"（ checkpoint ）的特性，在出现 故障时将系统重置回正确状态 。下面通过简单的类比来解释检查点的作用。

假设你和两位朋友正在数项链上有多少颗珠子，如下图所示。你捏住珠子，边数边拨，每拨过一颗珠子就给总数加一。你的朋友也这样数他们手中的珠子。当你分神忘记数到哪里时，怎么办呢? 如果项链上有很多珠子，你显然不想从头再数一遍，尤其是当三人的速度不一样却又试图合作的时候，更是如此(比如想记录前一分钟三人一共数了多少颗珠子，回想一下一分钟滚动窗口)。

于是，你想了一个更好的办法: 在项链上每隔一段就松松地系上一根有色皮筋，将珠子分隔开; 当珠子被拨扮晌动的时候，皮筋也可以被拨动; 然后，你安排一个助手，让他在你和朋友拨到皮筋时记录总数。用这种方法，当有人数错时，就不必从头开始数。相反，你向其他人发出错误警示，然后你们都从上一根皮筋处开始重数，助手则会告诉每个人重数时的起始数值，例如在粉色皮筋处的数值是多少。

Flink检查点的作用就类似于皮筋标记。数珠子这个类比的关键点是: 对于指定的皮筋而言，珠子的相对位置是确定的; 这让皮筋成为重新计数的参考点。总状态(珠子的总数)在每颗珠子被拨动之后更新一次，助手则会保存与每根皮筋对应的检查点状态，如当遇到粉色皮筋时一共数了多少珠子，当遇到橙色皮筋时又是多少。当问题出现时，这种方法使得重新计数变得简单。

checkpoint机制是Flink可靠性的基石，可以保证Flink集群在某个算子因为某些原因(如 异常退出)出现故障时，能够将整个应用流图的状态恢复到故障之前的某一状态，保证应用流图状态的一致性.

. 每个需要checkpoint的应用在启动时，Flink的JobManager为其创建一个 CheckpointCoordinator ，CheckpointCoordinator全权负责本应用的快照制作。

流的barrier是Flink的Checkpoint中的一个核心概念. 多个barrier被插入到数据流中, 然后作为数据流的一部分随着数据流动 (有点类似于Watermark). 这些barrier不会跨越流中的数据 .

每个barrier会把数据流分成两部分: 一部分数据进入 当前的快照 , 另昌缺扰一部分数据进入 下一个快照 . 每个barrier携带着快照的id. barrier 不会暂停数据 的流动, 所以非常轻量级. 在流中, 同一时间可以耐旦有来源于多个不同快照的多个barrier, 这个意味着可以并发的出现不同的快照.

Job Manager 对每一个job都会产生一个 Checkpoint Coordinator

向所有 source 节点 触发 trigger Checkpoint 节点， 并行度是几，就会触发多少个。

source 会向流中触发 Barrier ，接收到 Barrier 的节点就会保存快照（包括source）。

表示两秒钟 source 向流中触发一次 Barrier

source先收到 barrier ，然后往后传递，若是多并行度，相当于多组接力赛跑比赛，所以顺序是不一致的，并不是同步。

在多并行度下, 如果要实现 严格一次 , 则要执行 barrier对齐 .

当 job graph 中的每个 operator 接收到 barriers 时，它就会记录下其状态。拥有两个输入流的 Operators（例如 CoProcessFunction）会执行 barrier 对齐（barrier alignment） 以便当前快照能够包含消费两个输入流 barrier 之前（但不超过）的所有 events 而产生的状态。

会 重复消费 , 就是至少一次语义.

关于flinkcheckpoint和flinkcheckpoint会产生小文件吗的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。