Flink容错机制(一)

目录

十:容错机制

10.1 检查点(Checkpoint)

10.1.1 检查点的保存

10.1.2 从检查点恢复状态

 10.1.3 检查点算法

 10.1.4 检查点配置

10.1.5 保存点(Savepoint)


十:容错机制

流式数据连续不断地到来,无休无止;所以流处理程序也是持续运行的,并没有一个明确 的结束退出时间。机器运行程序,996 起来当然比人要容易得多,不过希望“永远运行”也是 不切实际的。因为各种硬件软件的原因,运行一段时间后程序可能异常退出、机器可能宕机, 如果我们只依赖一台机器来运行,就会使得任务的处理被迫中断。

一个解决方案就是多台机器组成集群,以“分布式架构”来运行程序。这样不仅扩展了系 统的并行处理能力,而且可以解决单点故障的问题,从而大大提高系统的稳定性和可用性。

在分布式架构中,当某个节点出现故障,其他节点基本不受影响。这时只需要重启应用, 恢复之前某个时间点的状态继续处理就可以了。这一切看似简单,可是在实时流处理中,我们 不仅需要保证故障后能够重启继续运行,还要保证结果的正确性、故障恢复的速度、对处理性 能的影响,这就需要在架构上做出更加精巧的设计。

在 Flink 中,有一套完整的容错机制(fault tolerance)来保证故障后的恢复,其中最重要 的就是检查点(checkpoint)。在第九章中,我们已经介绍过检查点的基本概念和用途,接下来 我们就深入探讨一下检查点的原理和 Flink 的容错机制。

10.1 检查点(Checkpoint)

发生故障之后怎么办?最简单的想法当然是重启机器、重启应用。由于是分布式的集群, 即使一个节点无法恢复,也不会影响应用的重启执行。这里的问题在于,流处理应用中的任务 都是有状态的,而为了快速访问这些状态一般会直接放在堆内存里;现在重启应用,内存中的 状态已经丢失,就意味着之前的计算全部白费了,需要从头来过。就像编写文档或是玩 RPG游戏,因为宕机没保存而要重来一遍是一件令人崩溃的事情;这种惨痛的经历让我们养成了一 个好习惯——随时存档,这样即使遇到宕机也可以读档继续了。

在流处理中,我们同样可以用存档读档的思路,把之前的计算结果做个保存,这样重启之 后就可以继续处理新数据、而不需要重新计算了。进一步地,我们知道在有状态的流处理中, 任务继续处理新数据,并不需要“之前的计算结果”,而是需要任务“之前的状态”。所以我们 最终的选择,就是将之前某个时间点所有的状态保存下来,这份“存档”就是所谓的“检查点” (checkpoint)。

遇到故障重启的时候,我们可以从检查点中“读档”,恢复出之前的状态,这样就可以回 到当时保存的一刻接着处理数据了。

检查点是 Flink 容错机制的核心。这里所谓的“检查”,其实是针对故障恢复的结果而言 的:故障恢复之后继续处理的结果,应该与发生故障前完全一致,我们需要“检查”结果的正 确性。所以,有时又会把 checkpoint 叫作“一致性检查点”。

10.1.1 检查点的保存

1. 周期性的触发保存

随时存档”确实恢复起来方便,可是需要我们不停地做存档操作。如果每处理一条数据 就进行检查点的保存,当大量数据同时到来时,就会耗费很多资源来频繁做检查点,数据处理 的速度就会受到影响。

所以更好的方式是,每隔一段时间去做一次存档,这样既不会影响数据 的正常处理,也不会有太大的延迟——毕竟故障恢复的情况不是随时发生的。在 Flink 中,检查点的保存是周期性触发的,间隔时间可以进行设置。

所以检查点作为应用状态的一份“存档”,其实就是所有任务状态在同一时间点的一个“快照”(snapshot),它的触发是周期性的。具体来说,当每隔一段时间检查点保存操作被触发时, 就把每个任务当前的状态复制一份,按照一定的逻辑结构放在一起持久化保存起来,就构成了检查点。

2. 保存的时间点

这里有一个关键问题:当检查点的保存被触发时,任务有可能正在处理某个数据,这时该怎么办呢?

方案:(如果一个数据被所有任务处理完,则保存状态,否则,恢复到之前保存的状态,然后故障恢复后,重新提交任务)

当所有任务都恰好处理完一个相同的输入数据的时候,将它们的状态保存下来。首先,这样避免了除状态之外其他额外信息的存储,提高了检查点保存的效率。 其次,一个数据要么就是被所有任务完整地处理完,状态得到了保存;要么就是没处理完,状态全部没保存:这就相当于构建了一个“事务”(transaction)。如果出现故障,我们恢复到之前保存的状态,故障时正在处理的所有数据都需要重新处理;所以我们只需要让源(source) 任务向数据源重新提交偏移量、请求重放数据就可以了。这需要源任务可以把偏移量作为算子状态保存下来,而且外部数据源能够重置偏移量;Kafka 就是满足这些要求的一个最好的例子。

3. 保存的具体流程  

检查点的保存,最关键的就是要等所有任务将“同一个数据”处理完毕。下面我们通过一 个具体的例子,来详细描述一下检查点具体的保存过程。

回忆一下我们最初实现的统计词频的程序——WordCount。这里为了方便,我们直接从数 据源读入已经分开的一个个单词,例如这里输入的就是:

“hello”“world”“hello”“flink”“hello”“world”“hello”“flink”……

对应的代码就可以简化为:

SingleOutputStreamOperator> wordCountStream = 
env.addSource(...) 
 .map(word -> Tuple2.of(word, 1L)) 
 .returns(Types.TUPLE(Types.STRING, Types.LONG)); 
 .keyBy(t -> t.f0); 
 .sum(1); 

源(Source)任务从外部数据源读取数据,并记录当前的偏移量,作为算子状态(Operator State)保存下来。然后将数据发给下游的 Map 任务,它会将一个单词转换成(word, count)二元 组,初始 count 都是 1,也就是(“hello”, 1)、(“world”, 1)这样的形式;这是一个无状态的算子任 务。进而以 word 作为键(key)进行分区,调用.sum()方法就可以对 count 值进行求和统计了;Sum 算子会把当前求和的结果作为按键分区状态(Keyed State)保存下来。最后得到的就是当 前单词的频次统计(word, count)

Flink容错机制(一)_第1张图片

当我们需要保存检查点(checkpoint)时,就是在所有任务处理完同一条数据后对状态做个快照保存下来。例如上图中,已经处理了 3 条数据:“hello”“world”“hello”,所以我们 会看到 Source 算子的偏移量为 3;后面的 Sum 算子处理完第三条数据“hello”之后,此时已 经有 2 个“hello”和 1 个“world”,所以对应的状态为“hello”-> 2,“world”-> 1(这里 KeyedState底层会以 key-value 形式存储)。

此时所有任务都已经处理完了前三个数据,所以我们可以把当前的状态保存成一个检查点,写入外部存储中。

至于具体保存到哪里,这是由状态后端的配置项 “ 检查点存储 ”( CheckpointStorage )来决定的,可以有作业管理器的堆内存 (JobManagerCheckpointStorage)和文件系统(FileSystemCheckpointStorage)两种选择。一般 情况下,我们会将检查点写入持久化的分布式文件系统

10.1.2 从检查点恢复状态

在运行流处理程序时,Flink 会周期性地保存检查点。当发生故障时,就需要找到最近一次成功保存的检查点来恢复状态

例如在上节的 word count 示例中,我们处理完三个数据后保存了一个检查点。之后继续运行,又正常处理了一个数据“flink”,在处理第五个数据“hello”时发生了故障。

 Flink容错机制(一)_第2张图片

这里 Source 任务已经处理完毕,所以偏移量为 5;Map 任务也处理完成了。而 Sum 任务 在处理中发生了故障,此时状态并未保存。

接下来就需要从检查点来恢复状态了。具体的步骤为:

(1)重启应用

遇到故障之后,第一步当然就是重启。我们将应用重新启动后,所有任务的状态会清空.

Flink容错机制(一)_第3张图片

(2)读取检查点,重置状态

找到最近一次保存的检查点,从中读出每个算子任务状态的快照,分别填充到对应的状态中。这样,Flink 内部所有任务的状态,就恢复到了保存检查点的那一时刻,也就是刚好处理完第三个数据的时候。

这里 key 为“flink”并没有数据到来,所以初始为 0。

Flink容错机制(一)_第4张图片

(3)重放数据

从检查点恢复状态后还有一个问题:如果直接继续处理数据,那么保存检查点之后、到发生故障这段时间内的数据,也就是第 4、5 个数据(“flink”“hello”)就相当于丢掉了;这会造成计算结果的错误。

为了不丢数据,我们应该从保存检查点后开始重新读取数据,这可以通过 Source 任务向 外部数据源重新提交偏移量(offset)来实现

Flink容错机制(一)_第5张图片

这样,整个系统的状态已经完全回退到了检查点保存完成的那一时刻。

(4)继续处理数据

接下来,我们就可以正常处理数据了。首先是重放第 4、5 个数据,然后继续读取后面的数据Flink容错机制(一)_第6张图片

当处理到第 5 个数据时,就已经追上了发生故障时的系统状态。

之后继续处理,就好像没 有发生过故障一样;我们既没有丢掉数据也没有重复计算数据,这就保证了计算结果的正确性。 在分布式系统中,这叫作实现了“精确一次”(exactly-once)的状态一致性保证。 

 这里我们也可以发现,想要正确地从检查点中读取并恢复状态,必须知道每个算子任务状态的类型和它们的先后顺序(拓扑结构);因此为了可以从之前的检查点中恢复状态,我们在 改动程序、修复 bug 时要保证状态的拓扑顺序和类型不变。状态的拓扑结构在 JobManager 上 可以由 JobGraph 分析得到,而检查点保存的定期触发也是由 JobManager 控制的;所以故障恢 复的过程需要 JobManager 的参与。

 10.1.3 检查点算法

我们已经知道,Flink 保存检查点的时间点,是所有任务都处理完同一个输入数据的时候。 但是不同的任务处理数据的速度不同,当第一个 Source 任务处理到某个数据时,后面的 Sum任务可能还在处理之前的数据;而且数据经过任务处理之后类型和值都会发生变化,面对着“面 目全非”的数据,不同的任务怎么知道处理的是“同一个”呢?

一个简单的想法是,当接到 JobManager 发出的保存检查点的指令后,Source 算子任务处理完当前数据就暂停等待,不再读取新的数据了。这样我们就可以保证在流中只有需要保存到检查点的数据,只要把它们全部处理完,就可以保证所有任务刚好处理完最后一个数据;这时把所有状态保存起来,合并之后就是一个检查点了。这就好比我们想要保存所有同学刚好毕业时的状态,那就在所有人答辩完成之后,集合起来拍一张毕业合照。这样做最大的问题,就是 每个人的进度可能不同;先答辩完的人为了保证状态一致不能进行其他工作,只能等待。当先保存完状态的任务需要等待其他任务时,就导致了资源的闲置和性能的降低。

所以更好的做法是,在不暂停整体流处理的前提下,将状态备份保存到检查点。在 Flink中,采用了基于 Chandy-Lamport 算法的分布式快照。

 1. 检查点分界线(Barrier)

我们现在的目标是,在不暂停流处理的前提下,让每个任务“认出”触发检查点保存的那个数据。

自然想到,如果给数据添加一个特殊标识,任务就可以准确识别并开始保存状态了。这需 要在 Source 任务收到触发检查点保存的指令后,立即在当前处理的数据中插入一个标识字段, 然后再向下游任务发出。但是假如 Source 任务此时并没有正在处理的数据,这个操作就无法 实现了。

所以我们可以借鉴水位线(watermark)的设计,在数据流中插入一个特殊的数据结构, 专门用来表示触发检查点保存的时间点。收到保存检查点的指令后,Source 任务可以在当前 数据流中插入这个结构;之后的所有任务只要遇到它就开始对状态做持久化快照保存。

由于数据流是保持顺序依次处理的,因此遇到这个标识就代表之前的数据都处理完了,可以保存一个 检查点;而在它之后的数据,引起的状态改变就不会体现在这个检查点中,而需要保存到下一 个检查点。

这种特殊的数据形式,把一条流上的数据按照不同的检查点分隔开,所以就叫作检查点的 “分界线”(Checkpoint Barrier)。

与水位线很类似,检查点分界线也是一条特殊的数据,由 Source 算子注入到常规的数据 流中,它的位置是限定好的,不能超过其他数据,也不能被后面的数据超过。检查点分界线中 带有一个检查点 ID,这是当前要保存的检查点的唯一标识。

Flink容错机制(一)_第7张图片

这样,分界线就将一条流逻辑上分成了两部分:分界线之前到来的数据导致的状态更改, 都会被包含在当前分界线所表示的检查点中;而基于分界线之后的数据导致的状态更改,则会 被包含在之后的检查点中。

在 JobManager 中有一个“检查点协调器”(checkpoint coordinator),专门用来协调处理检 查点的相关工作。

检查点协调器会定期向 TaskManager 发出指令,要求保存检查点(带着检查 点 ID);TaskManager 会让所有的 Source 任务把自己的偏移量(算子状态)保存起来,并将带 有检查点 ID 的分界线(barrier)插入到当前的数据流中,然后像正常的数据一样像下游传递; 之后 Source 任务就可以继续读入新的数据了。

每个算子任务只要处理到这个 barrier,就把当前的状态进行快照;在收到 barrier 之前, 还是正常地处理之前的数据,完全不受影响。比如上图中,Source 任务收到 1 号检查点保存 指令时,读取完了三个数据,所以将偏移量 3 保存到外部存储中;而后将 ID 为 1 的 barrier 注 入数据流;与此同时,Map 任务刚刚收到上一条数据“hello”,而 Sum 任务则还在处理之前的 第二条数据(world, 1)。下游任务不会在这时就立刻保存状态,而是等收到 barrier 时才去做快照,这时可以保证前三个数据都已经处理完了。同样地,下游任务做状态快照时,也不会影响上游任务的处理,每个任务的快照保存并行不悖,不会有暂停等待的时间。

如果还是拿拍毕业照来类比的话,现在就不需要大家答辩完之后聚在一起排队摆 pose 了 ——每个人完成答辩之后只要单独照张相,就可以继续做自己的事情去了;最后由班主任老师 发挥 P 图技能合成合照,这样无疑就省去了大家集合等待的时间。

2. 分布式快照算法

通过在流中插入分界线(barrier),我们可以明确地指示触发检查点保存的时间。在一条 单一的流上,数据依次进行处理,顺序保持不变;不过对于分布式流处理来说,想要一直保持 数据的顺序就不是那么容易了。

我们先回忆一下水位线(watermark)的处理:上游任务向多个并行下游任务传递时,需 要广播出去;而多个上游任务向同一个下游任务传递时,则需要下游任务为每个上游并行任务 维护一个“分区水位线”,取其中最小的那个作为当前任务的事件时钟。

那 barier 在并行数据流中的传递,是不是也有类似的规则呢? watermark 指示的是“之前的数据全部到齐了”,而 barrier 指示的是“之前所有数据的状态更改保存入当前检查点”:它们都是一个“截止时间”的标志。所以在处理多个分区的传递 时,也要以是否还会有数据到来作为一个判断标准。

具体实现上,Flink 使用了 Chandy-Lamport 算法的一种变体,被称为“异步分界线快照” (asynchronous barrier snapshotting)算法。

算法的核心就是两个原则:当上游任务向多个并行 下游任务发送 barrier 时,需要广播出去;而当多个上游任务向同一个下游任务传递 barrier 时, 需要在下游任务执行“分界线对齐”(barrier alignment)操作,也就是需要等到所有并行分区 的 barrier 都到齐,才可以开始状态的保存。

为了详细解释检查点算法的原理,我们对之前的 word count 程序进行扩展,考虑所有算子并行度为 2 的场景。

Flink容错机制(一)_第8张图片

我们有两个并行的 Source 任务,会分别读取两个数据流(或者是一个源的不同分区)。这里每条流中的数据都是一个个的单词:“hello”“world”“hello”“flink”交替出现。此时第一 条流的 Source 任务(为了方便,下文中我们直接叫它“Source 1”,其他任务类似)读取了 3

个数据,偏移量为 3;而第二条流的 Source 任务(Source 2)只读取了一个“hello”数据,偏移量为 1。第一条流中的第一个数据“hello”已经完全处理完毕,所以 Sum 任务的状态中 key为 hello 对应着值 1,而且已经发出了结果(hello, 1);第二个数据“world”经过了 Map 任务的 转换,还在被 Sum 任务处理;第三个数据“hello”还在被 Map 任务处理。而第二条流的第一 个数据“hello”同样已经经过了 Map 转换,正在被 Sum 任务处理。

接下来就是检查点保存的算法。具体过程如下:

(1)JobManager 发送指令,触发检查点的保存

Source 任务保存状态,插入分界线 JobManager 会周期性地向每个 TaskManager 发送一条带有新检查点 ID 的消息,通过这种方式来启动检查点。收到指令后,TaskManger 会在所有 Source 任务中插入一个分界线 (barrier),并将偏移量保存到远程的持久化存储中。

Flink容错机制(一)_第9张图片

 

并行的 Source 任务保存的状态为 3 和 1,表示当前的 1 号检查点应该包含:第一条流中截至第三个数据、第二条流中截至第一个数据的所有状态更改。可以发现 Source 任务做这些 的时候并不影响后面任务的处理,Sum 任务已经处理完了第一条流中传来的(world, 1),对应的状态也有了更改。

(2)状态快照保存完成,分界线向下游传递

状态存入持久化存储之后,会返回通知给 Source 任务;Source 任务就会向 JobManager确认检查点完成,然后像数据一样把 barrier 向下游任务传递。

Flink容错机制(一)_第10张图片

由于 Source 和 Map 之间是一对一(forward)的传输关系(这里没有考虑算子链 operator chain),所以 barrier 可以直接传递给对应的 Map 任务。之后 Source 任务就可以继续读取新的数据了。与此同时,Sum 1 已经将第二条流传来的(hello,1)处理完毕,更新了状态。

(3)向下游多个并行子任务广播分界线,执行分界线对齐 Map 任务没有状态,所以直接将 barrier 继续向下游传递。

这时由于进行了 keyBy 分区, 所以需要将 barrier 广播到下游并行的两个 Sum 任务,如图所示。同时,Sum 任务可能 收到来自上游两个并行 Map 任务的 barrier,所以需要执行“分界线对齐”操作。

Flink容错机制(一)_第11张图片

此时的 Sum 2 收到了来自上游两个 Map 任务的 barrier,说明第一条流第三个数据、第二 条流第一个数据都已经处理完,可以进行状态的保存了;而 Sum 1 只收到了来自 Map 2 的barrier,所以这时需要等待分界线对齐。在等待的过程中,如果分界线尚未到达的分区任务Map 1 又传来了数据(hello, 1),说明这是需要保存到检查点的,Sum 任务应该正常继续处理数据,状态更新为 3;而如果分界线已经到达的分区任务 Map 2 又传来数据,这已经是下一个检 查点要保存的内容了,就不应立即处理,而是要缓存起来、等到状态保存之后再做处理。

(4)分界线对齐后,保存状态到持久化存储

各个分区的分界线都对齐后,就可以对当前状态做快照,保存到持久化存储了。存储完成 之后,同样将 barrier 向下游继续传递,并通知 JobManager 保存完毕。

Flink容错机制(一)_第12张图片

这个过程中,每个任务保存自己的状态都是相对独立的,互不影响。我们可以看到,当Sum 将当前状态保存完毕时,Source 1 任务已经读取到第一条流的第五个数据了。

(5)先处理缓存数据,然后正常继续处理

完成检查点保存之后,任务就可以继续正常处理数据了。这时如果有等待分界线对齐时缓存的数据,需要先做处理;然后再按照顺序依次处理新到的数据。

当 JobManager 收到所有任务成功保存状态的信息,就可以确认当前检查点成功保存。之 后遇到故障就可以从这里恢复了。

由于分界线对齐要求先到达的分区做缓存等待,一定程度上会影响处理的速度;当出现背压(backpressure)时,下游任务会堆积大量的缓冲数据,检查点可能需要很久才可以保存完 毕。为了应对这种场景,Flink 1.11 之后提供了不对齐的检查点保存方式,可以将未处理的缓 冲数据(in-flight data)也保存进检查点。这样,当我们遇到一个分区 barrier 时就不需等待对齐,而是可以直接启动状态的保存了。

 10.1.4 检查点配置

检查点的作用是为了故障恢复,我们不能因为保存检查点占据了大量时间、导致数据处理 性能明显降低。为了兼顾容错性和处理性能,我们可以在代码中对检查点进行各种配置。

1. 启用检查点

默认情况下,Flink 程序是禁用检查点的。如果想要为 Flink 应用开启自动保存快照的功能,需要在代码中显式地调用执行环境的.enableCheckpointing()方法:

StreamExecutionEnvironment env = 
StreamExecutionEnvironment.getExecutionEnvironment(); 
// 每隔 1 秒启动一次检查点保存 
env.enableCheckpointing(1000); 

这里需要传入一个长整型的毫秒数,表示周期性保存检查点的间隔时间。如果不传参数直 接启用检查点,默认的间隔周期为 500 毫秒,这种方式已经被弃用。

检查点的间隔时间是对处理性能和故障恢复速度的一个权衡。如果我们希望对性能的影响更小,可以调大间隔时间;而如果希望故障重启后迅速赶上实时的数据处理,就需要将间隔时间设小一些。

2. 检查点存储(Checkpoint Storage)

检查点具体的持久化存储位置,取决于“检查点存储”(CheckpointStorage)的设置。默认情况下,检查点存储在 JobManager 的堆(heap)内存中。而对于大状态的持久化保存,Flink也提供了在其他存储位置进行保存的接口,这就是 CheckpointStorage。具体 可以通过调用检查点配置的 .setCheckpointStorage() 来 配 置 , 需 要 传 入一 个CheckpointStorage 的实现类。

Flink 主要提供了两种 CheckpointStorage

一:作业管理器的堆内存 (JobManagerCheckpointStorage)

二:文件系统(FileSystemCheckpointStorage)

// 配置存储检查点到 JobManager 堆内存 
env.getCheckpointConfig().setCheckpointStorage(new JobManagerCheckpointStorage()); 
// 配置存储检查点到文件系统 
env.getCheckpointConfig().setCheckpointStorage(new FileSystemCheckpointStorage("hdfs://namenode:40010/flink/checkpoints")); 

注意:对于实际生产应用,我们一般会将 CheckpointStorage 配置为高可用的分布式文件系统 (HDFS,S3 等)。

3. 其他高级配置  

检查点还有很多可以配置的选项,可以通过获取检查点配置(CheckpointConfig)来进行设置。

CheckpointConfig checkpointConfig = env.getCheckpointConfig();

我们这里做一个简单的列举说明:

(1)检查点模式(CheckpointingMode)

设置检查点一致性的保证级别,有“精确一次”(exactly-once)“至少一次”(at-least-once) 两个选项。默认级别为 exactly-once,而对于大多数低延迟的流处理程序,at-least-once 就够用 了,而且处理效率会更高。

(2)超时时间(checkpointTimeout)

用于指定检查点保存的超时时间,超时没完成就会被丢弃掉。传入一个长整型毫秒数作为 参数,表示超时时间。

(3)最小间隔时间(minPauseBetweenCheckpoints)

用于指定在上一个检查点完成之后,检查点协调器(checkpoint coordinator)最快等多久 可以出发保存下一个检查点的指令。这就意味着即使已经达到了周期触发的时间点,只要距离上一个检查点完成的间隔不够,就依然不能开启下一次检查点的保存。这就为正常处理数据留 下了充足的间隙。当指定这个参数时,maxConcurrentCheckpoints 的值强制为 1。

(4)最大并发检查点数量(maxConcurrentCheckpoints)

用于指定运行中的检查点最多可以有多少个。由于每个任务的处理进度不同,完全可能出 现后面的任务还没完成前一个检查点的保存、前面任务已经开始保存下一个检查点了。这个参 数就是限制同时进行的最大数量。

如果前面设置了 minPauseBetweenCheckpoints,则 maxConcurrentCheckpoints 这个参数就 不起作用了。

(5)开启外部持久化存储(enableExternalizedCheckpoints)

用于开启检查点的外部持久化,而且默认在作业失败的时候不会自动清理,如果想释放空 间需要自己手工清理。里面传入的参数 ExternalizedCheckpointCleanup 指定了当作业取消的时 候外部的检查点该如何清理。

⚫ DELETE_ON_CANCELLATION:在作业取消的时候会自动删除外部检查点,但是如 果是作业失败退出,则会保留检查点。

⚫ RETAIN_ON_CANCELLATION:作业取消的时候也会保留外部检查点。

(6)检查点异常时是否让整个任务失败(failOnCheckpointingErrors)

用于指定在检查点发生异常的时候,是否应该让任务直接失败退出。默认为 true,如果设置为 false,则任务会丢弃掉检查点然后继续运行。

(7)不对齐检查点(enableUnalignedCheckpoints)

不再执行检查点的分界线对齐操作,启用之后可以大大减少产生背压时的检查点保存时间。这个设置要求检查点模式(CheckpointingMode)必须为 exctly-once,并且并发的检查点 个数为 1。

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); 
 
// 启用检查点,间隔时间 1 秒 
env.enableCheckpointing(1000); 
CheckpointConfig checkpointConfig = env.getCheckpointConfig(); 
// 设置精确一次模式 
checkpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE); 
// 最小间隔时间 500 毫秒 
checkpointConfig.setMinPauseBetweenCheckpoints(500); 
// 超时时间 1 分钟 
checkpointConfig.setCheckpointTimeout(60000); 
// 同时只能有一个检查点 
checkpointConfig.setMaxConcurrentCheckpoints(1); 
// 开启检查点的外部持久化保存,作业取消后依然保留 
checkpointConfig.enableExternalizedCheckpoints( 
 ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION); 
// 启用不对齐的检查点保存方式 
checkpointConfig.enableUnalignedCheckpoints(); 
// 设置检查点存储,可以直接传入一个 String,指定文件系统的路径 
checkpointConfig.setCheckpointStorage("hdfs://my/checkpoint/dir") 

10.1.5 保存点(Savepoint)

除了检查点(checkpoint)外,Flink 还提供了另一个非常独特的镜像保存功能——保存点 (Savepoint)。

从名称就可以看出,这也是一个存盘的备份,它的原理和算法与检查点完全相同,只是多了一些额外的元数据。事实上,保存点就是通过检查点的机制来创建流式作业状态的一致性镜像(consistent image)的。

保存点中的状态快照,是以算子ID和状态名称组织起来的,相当于一个键值对。从保存点启动应用程序时,Flink 会将保存点的状态数据重新分配给相应的算子任务。

1. 保存点的用途

保存点与检查点最大的区别,就是触发的时机。检查点是由 Flink 自动管理的,定期创建, 发生故障之后自动读取进行恢复,这是一个“自动存盘”的功能;而保存点不会自动创建,必须由用户明确地手动触发保存操作,所以就是“手动存盘”。

因此两者尽管原理一致,但用途就有所差别了:

检查点:主要用来做故障恢复,是容错机制的核心

保存点:则更加灵活,可以用来做有计划的手动备份和恢复

保存点可以当作一个强大的运维工具来使用。我们可以在需要的时候创建一个保存点,然后停止应用,做一些处理调整之后再从保存点重启。它适用的具体场景有:

⚫ 版本管理和归档存储

对重要的节点进行手动备份,设置为某一版本,归档(archive)存储应用程序的状态。

⚫ 更新 Flink 版本

目前 Flink 的底层架构已经非常稳定,所以当 Flink 版本升级时,程序本身一般是兼容的。 这时不需要重新执行所有的计算,只要创建一个保存点,停掉应用、升级 Flink 后,从保存点 重启就可以继续处理了。

⚫ 更新应用程序

我们不仅可以在应用程序不变的时候,更新 Flink 版本;还可以直接更新应用程序。前提 是程序必须是兼容的,也就是说更改之后的程序,状态的拓扑结构和数据类型都是不变的,这 样才能正常从之前的保存点去加载。

这个功能非常有用。我们可以及时修复应用程序中的逻辑 bug,更新之后接着继续处理; 也可以用于有不同业务逻辑的场景,比如 A/B 测试等等。

⚫ 调整并行度

如果应用运行的过程中,发现需要的资源不足或已经有了大量剩余,也可以通过从保存点重启的方式,将应用程序的并行度增大或减小。

⚫ 暂停应用程序

有时候我们不需要调整集群或者更新程序,只是单纯地希望把应用暂停、释放一些资源来处理更重要的应用程序。使用保存点就可以灵活实现应用的暂停和重启,可以对有限的集群资源做最好的优化配置。

需要注意的是,保存点能够在程序更改的时候依然兼容,前提是状态的拓扑结构和数据类型不变。我们知道保存点中状态都是以算子 ID-状态名称这样的 key-value 组织起来的,算子ID 可以在代码中直接调用 SingleOutputStreamOperator 的.uid()方法来进行指定:

DataStream stream = env 
 .addSource(new StatefulSource()) 
 .uid("source-id") 
 .map(new StatefulMapper()) 
 .uid("mapper-id") 
 .print(); 

对于没有设置 ID 的算子,Flink 默认会自动进行设置,所以在重新启动应用后可能会导致ID 不同而无法兼容以前的状态。所以为了方便后续的维护,强烈建议在程序中为每一个算子 手动指定 ID。

2. 使用保存点

保存点的使用非常简单,我们可以使用命令行工具来创建保存点,也可以从保存点恢复作 业。

(1)创建保存点

要在命令行中为运行的作业创建一个保存点镜像,只需要执行:

bin/flink savepoint :jobId [:targetDirectory]

这里 jobId 需要填充要做镜像保存的作业 ID,目标路径 targetDirectory 可选,表示保存点存储的路径

对于保存点的默认路径,可以通过配置文件 flink-conf.yaml 中的 state.savepoints.dir 项来设定:

state.savepoints.dir: hdfs:///flink/savepoints 

当然对于单独的作业,我们也可以在程序代码中通过执行环境来设置:

env.setDefaultSavepointDir("hdfs:///flink/savepoints"); 

由于创建保存点一般都是希望更改环境之后重启,所以创建之后往往紧接着就是停掉作业的操作。除了对运行的作业创建保存点,我们也可以在停掉一个作业时直接创建保存点:

bin/flink stop --savepointPath [:targetDirectory] :jobId 

(2)从保存点重启应用

我们已经知道,提交启动一个 Flink 作业,使用的命令是 flink run;现在要从保存点重启 一个应用,其实本质是一样的:

bin/flink run -s :savepointPath [:runArgs] 

这里只要增加一个-s 参数,指定保存点的路径就可以了,其他启动时的参数还是完全一样 的。细心的读者可能还记得我们在第三章使用 web UI 进行作业提交时,可以填入的参数除了 入口类、并行度和运行参数,还有一个“Savepoint Path”,这就是从保存点启动应用的配置。

你可能感兴趣的:(flink,java,数据库)