Flink-Barrier理解与checkpoint检查点制作过程(图解)
听说这个barrier很难理解?且听我细细道来.
目录
理解Barrier
流的barrier是Flink的Checkpoint中的一个核心概念.多个barrier被插入到数据流中,然后作为数据流的一部分随着数据流动(有点类似于Watermark),这些 barrier不会跨越流中的数据
每个barrier会把数据流分成两部分:一部分数据进入当前的快照,另一部分数据进入下一个快照.每个barrier携带者快照的id.barrier不会暂停数据的流动, 所以非常轻量级
所以说:在流中,同一时间可以由来源于多个不同快照的多个barrier,这意味着可以并发的出现不同的快照
光看文字看能有点不好理解,下面画个图
在上图中,数据流中插入了barrier,意味当barrier流入到下游的算子(例如Map时),Map即需进行快照
ExactlyOnce--精准一次性--Barrier对齐
在多并行度下,如果想要实现精准一次性,需要使用Barrier对齐
当 job graph 中的每个 operator 接收到 barriers 时，它就会记录下其状态。拥有两个输入流的 Operators（例如CoProcessFunction)会执行 barrier 对齐(barrier alignment) 以便当前快照能够包含消费两个输入流 barrier 之前（但不超过）的所有 events 而产生的状态.
那这句话怎么理解呢?压根看不懂啊?
莫慌,莫慌,上图!
在上图中,上游有两个并行度,中间都被Source Task安插了barrier,目的地是下游的Map Task
随着数据的流动,Source①的barrier已经进入了Map中.重点来了
此时因为规则是Barrier对齐,Map需要等待Source②的barrier也到达,才可以做快照
并且为了保证barrier可以划分出明确的前后两个部分,在等待Source②的barrier到来的过程中,Source①流到Map的数据不会被处理
那么有小朋友就会问了,那我不处理Source①流入的数据,那不就丢失数据了吗?这可不讲究啊
但是咱们老实人,怎么可能就把数据给丢掉呢?
其实我们是把 在等待Source②过程中,Source①流入的数据,放到了一个缓存区内,等到barrier对齐之后,再把他们读出来处理.
OK!这样的话原理就讲完了,来总结一下
1.当Map收到Source①的barrier id=n 时, 它就不能处理(但是可以接收)来自该流的任何数据记录，直到它从Source②所有输入接收到 barrier id=n 为止。否则，它会混合属于快照 id=n 的记录和属于快照 id=n 的记录。
2.接收到 barrier id=n 的流(数字流)暂时被搁置。从这些流接收的记录入输入缓冲区, 不会被处理。
3.图三中的 Checkpoint barrier id=n之后的数据 234已结到达了算子, 存入到输入缓冲区没有被处理, 只有等到Source②的Checkpoint barrier id=n到达之后才会开始处理.
4.一旦最后所有输入流都接收到 barrier id=n，Operator 就会把缓冲区中 pending 的输出数据发出去，然后把 CheckPoint barrier id=n 接着往下游发送。这里还会对自身进行快照。
AtleastOnce--至少一次--Barrier不对齐
在了解这个Barrier不对齐之前,首先咱们得明确一个事实!!!
就是咱们在恢复故障的时候,用的是最新的,完整的checkpoint
也就是说,那些不完整的checkpoint是不能作为恢复的依据的
那么到底是啥意思?
再拿前面的图来说
看看看,不用等对齐,就可以向下流动,这个时候要是恢复故障,那不就是因为barrier id=n不完整
(下面的barrier还在路上呢!),所以这个checkpoint不可用,要用之前.完整的checkpoint
所以你可以发现,这个二号小方块是不是又能被算一遍???
哟西!!!所得寺内!!
未对齐的检查点确保障碍尽可能快地到达接收器。 它特别适用于具有至少一个缓慢移动数据路径的应用程序，其中对齐时间可能达到数小时。
咱们都是老实人,不能白嫖,别忘记点赞