Flink 容错机制与状态
简介
- Apache Flink提供了一种容错机制，可以持续恢复数据流应用程序的状态。
- 该机制确保即使出现故障，经过恢复，程序的状态也会回到以前的状态。
- Flink 主持 at least once 语义 和 exactly once 语义
- Flink 通过定期地做 checkpoint 来实现容错 和 恢复, 容错机制不断地生成数据流的快照, 而不会对性能产生太大的影响。
- 流应用程序的状态存储在一个可配置的地方(例如主节点或HDFS)
- 如果出现车程序故障(由于机器、网络或软件故障), Flink 将停止分布式流数据流。
- 然后系统重新启动 operator, 并将其设置为最近一批的检查点。
- 注意点:
- 默认情况下, 禁用checkpoint
- 要使得容错机制正常运行, 数据流 source 需要能够将流倒回到指定的之前的点。
- 比如 Apache Kafka 有这种方法, flink与 Kafka 的 connector 可以利用重置 kafka topic 的偏移量来达到数据重新读取的目的。
- 由于 Flink 的检查点由分布快照实现, 以下的"检查点" 和 "快照" 是同意义的。
CheckPoint(检查点)
- Flink 的容错机制的核心部分是生成分布式数据流和operator状态一致的快照。
- 这些快照充当检查点, 系统可以早发生故障时将其回滚。
- 分布式快照是由 Chandy-Lamport 算法实现的。
- Barriers(栅栏)
恢复
- Flink 恢复时的机制是十分直接的: 在系统失效时, Flink选择最近的已完成的检查点k, 系统接下来重新部署整个数据流图, 然后给每个Operator 在检查点 k 时的相应状态。
- 数据源则被设置为从数据流的 Sk 位置开始读取。
- 例如, 在 Apache Kafka 执行恢复时, 系统会通知消费者从便宜 Sk 开始获取数据。
先决条件
- Flink 的 checkpoint机制一般来说, 它需要:
- 持续的数据源
- 比如消息队列(Apache Kafka, RabbitMQ) 或文件系统(例如, HDFS, Amazon S3, GFS, NFS, Ceph ......)。
- 状态存储的持久化
- 通常是分布式文件系统(HDFS, Amazon S3, GFS, ...)
- 持续的数据源
启用和配置检查点
-
默认情况下, flink禁用检查点。
-
开启 checkpoint 的方式: 调用env.enableCheckpointing(n), 其中 N 是以毫秒为单位的检查点间隔。
-
Checkpoint 的相关参数:
State Backends(状态反压)
-
流计算中再以下场景中需要保存状态:
- 窗口操作
- 使用了 KV 操作的函数
- 继承了 CheckpointFunction 的函数
-
当检查点(checkpoint) 机制启动时, 状态将在检查点中持久化来应对数据丢失以及恢复。
-
而状态在内部是如何表示的、状态是如何持久化到检查点中以及持久化到哪里都取决于选定的 State Backend。
-
Flink 在保存状态时, 支持3中存储方式:
- MemoryStateBackend(内存状态反压)
- FsStateBackend(文件状态反压)
- RocksDBStateBackend(RocksDB状态反压)
-
如果没有配置其他任何内容, 系统默认将使用 MemoryStateBackend。
-
MemoryStateBackend
-
此种存储策略将数据保存在java的堆里，比如：kv的状态或者窗口操作用hash table来保存value等等。
-
当进行checkpoints的时候，这种策略会对状态做快照，然后将快照作为checkpoint中的一部分发送给JobManager，JM也将其保存在堆中。
-
Memory StateBackend可以使用异步的方式进行快照，官方也鼓励使用异步的方式，避免阻塞，现在默认就是异步。
-
注意点:
- 异步快照方式时，operator操作符在做快照的同时也会处理新流入的数据，默认异步方式
- 同步快照方式：operator操作符在做快照的时候，不会处理新流入的数据，同步快照会增加数据处理的延迟度。
-
如果不希望异步，可以在构造的时候传入false，如下：
new MemoryStateBackend(MAX_MEM_STATE_SIZE, false); -
此策略的限制:
- 单次状态大小最大默认被限制为5MB，这个值可以通过构造函数来更改。
- 无论单次状态大小最大被限制为多少，都不可用大过akka的frame大小。
- 聚合的状态都会写入JM的内存。
-
适合的场景:
- 本地开发和调试
- 状态比较少的作业
-
-
FsStateBackend
-
通过文件系统的URL来设置，如下:
- hdfs://namenode:40010/flink/checkpoints
- file:///data/flink/checkpoints
-
当选择FsStateBackend时，会先将数据保存在任务管理器（ Task Manager）的内存中。
-
当做checkpointing的时候，会将状态快照写入文件，保存在文件系统。
-
少量的元数据会保存在JM的内存中。
-
默认情况下，FsStateBackend配置为提供异步快照，以避免在写入状态检查点时阻塞处理管道(processing pipeline)。
-
可以通过将构造函数中相应的boolean标志设置为false来禁用该功能
new FsStateBackend(path, false); -
适用场景:
- 状态比较大, 窗口比较长, 大的 KV 状态
- 需要做 HA 的场景
-
-
-
RockDBStateBackend
-
通过文件系统的URL来设置, 例如:
- hdfs://namenode:40010/flink/checkpoints
- file:///data/flink/checkpoints
-
此种方式kv state需要由rockdb数据库来管理，这是和内存或file backend最大的不同。
-
RocksDBStateBackend使用RocksDB数据库保存数据，这个数据库保存在TaskManager的数据目录中。
-
注意：RocksDB，它是一个高性能的Key-Value数据库。数据会放到先内存当中，在一定条件下触发写到磁盘文件上
-
在 checkpoint时, 整个 RocksDB数据库的数据会快照一份, 然后存到配置的文件系统中(一般是 hdfs)。
-
同时, Apache Flink将一些最小的元数据存储在 JobManager 的内存或者 Zookeeper 中(对于高可用性情况)。
-
RocksDB默认配置为执行异步快照
-
适合场景:
- RocksDBStateBackend是目前唯一可用于支持有状态流处理应用程序的增量检查点。
- 注意：增量的checkpoint指的是在保存快照时，快照里的数据只要保存差异数据就好。
- RocksDBStateBackend方式能够持有的状态的多少只取决于可使用的磁盘大小。
- 相比较MemoryStateBackend将状态保存在内存中，这会允许使用非常大的状态。
- 但这也同时意味着，这个策略的吞吐量会受限。
-
代码:
// 默认使用内存的方式存储状态值, 单词快照的状态上限为10MB, 使用同步方式进行快照。 env.setStateBackend(new MemeoryStateBackend(10*1024*1024, false)); // 使用 FsStateBackend的方式进行存储, 并且是同步方式进行快照 env.setStateBackend(new FsStateBackend("hdfs://namenode....", false)); try{ // 使用 RocksDBStateBackend方式存储, 并采用增量的快照方式进行存储。 env.setStateBackend(new RocksDBStateBackend("hdfs://namenode....", true)); } catch(IOException e){ e.printStackTrace(); }
-
Checkpoint使用
-
程序的运行过程中会每隔env.enableCheckpointing(5000)时间, 产生一个checkpoint快照点。
-
当使用 hdfs 来存储checkpoint 的快照点状态数据时,
-
如果程序失败, 我们重启程序时, 可以指明从哪个快照点进行恢复。
flink-1.9.1/bin/flink run -s hdfs://ronnie01:8020/data/flink-checkpoint/xxxxxxxxxxxxxxx(哈希码)/chk-xxx/ metadata -c com.ronnie.flink.test.checkPointTest flink-test.jar -
代码:
package com.ronnie.flink.stream.test; import org.apache.flink.api.common.functions.FlatMapFunction; import org.apache.flink.api.common.restartstrategy.RestartStrategies; import org.apache.flink.api.java.tuple.Tuple; import org.apache.flink.api.java.tuple.Tuple2; import org.apache.flink.contrib.streaming.state.RocksDBStateBackend; import org.apache.flink.runtime.state.filesystem.FsStateBackend; import org.apache.flink.runtime.state.memory.MemoryStateBackend; import org.apache.flink.streaming.api.CheckpointingMode; import org.apache.flink.streaming.api.datastream.DataStreamSource; import org.apache.flink.streaming.api.datastream.KeyedStream; import org.apache.flink.streaming.api.datastream.SingleOutputStreamOperator; import org.apache.flink.streaming.api.environment.CheckpointConfig; import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment; import org.apache.flink.util.Collector; import java.io.IOException; public class CheckPointTest { public static void main(String[] args) { StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); // 启动checkpoint, 并且设置多久进行一次checkpoint, 即两次checkpoint的时间间隔 env.enableCheckpointing(5000); env.setParallelism(1); CheckpointConfig checkpointConfig = env.getCheckpointConfig(); env.setRestartStrategy(RestartStrategies.fallBackRestart()); /* 设置 checkpoint 语义, 一般使用 exactly_once 语义。 at_least_once 一般在那里非常低的延迟场景使用。*/ checkpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE); /* 设置检查点之间的2最短时间 检查点之间的最短时间: 为确保流应用程序在检查点之间取得一些进展, 可以定义检查点之间需要经过多长时间。 如果将此值设置为例如500, 则无论检查点持续时间和检查点间隔如何, 下一个检查点将在上一个检查点完成后的500ms内启动 请注意, 这意味检查点间隔永远不会小于此参数。 */ checkpointConfig.setMinPauseBetweenCheckpoints(500); // 设置超时时间, 若本次checkpoint时间超时, 则放弃本次checkpoint操作 checkpointConfig.setCheckpointTimeout(60000); /* 同一时间最多可以进行多少个checkpoint 默认情况下, 当一个检查点仍处于运行状态时, 系统不会触发另一个检查点 */ checkpointConfig.setMaxConcurrentCheckpoints(1); /*开启checkpoints的外部持久化，但是在job失败的时候不会自动清理，需要自己手工清理state DELETE_ON_CANCELLATION:在job canceled的时候会自动删除外部的状态数据，但是如果是FAILED的状态则会保留； RETAIN_ON_CANCELLATION:在job canceled的时候会保留状态数据 */ checkpointConfig.enableExternalizedCheckpoints(CheckpointConfig.ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION); // 默认使用内存的方式存储状态值。单次快照的状态上限内存为10MB, 使用同步方式进行快照。 env.setStateBackend(new MemoryStateBackend(10*1024*1024, false)); // 使用 FsStateBackend的方式进行存储, 并且是同步方式进行快照 env.setStateBackend(new FsStateBackend("hdfs://ronnie01:8020/data/flink-checkpoint",false)); try { env.setStateBackend(new RocksDBStateBackend("hdfs://ronnie:8020/data/flink-checkpoint", true)); } catch (IOException e) { e.printStackTrace(); } // DataStreamSource<String> dataStreamSource = env.socketTextStream("ronnie01",9999); // // SingleOutputStreamOperator<Tuple2<String, Integer>> pairStream = dataStreamSource.flatMap(new FlatMapFunction<String, Tuple2<String, Integer>>() { // @Override // public void flatMap(String value, Collector<Tuple2<String, Integer>> out) throws Exception { // String[] split = value.split(" "); // for (String word : split) { // System.out.println("--------- lala --------"); // out.collect(new Tuple2<String, Integer>(word, 1)); // } // } // }); // // // KeyedStream<Tuple2<String, Integer>, Tuple> keyedStream = pairStream.keyBy(0); // // // SingleOutputStreamOperator<Tuple2<String, Integer>> sum = keyedStream.sum(1); // // // sum.print(); // // // try { // //转换算子都是懒执行的，最后要显示调用 执行程序， // env.execute("checkpoint-test"); // } catch (Exception e) { // e.printStackTrace(); // } } }
Savepoint (保存点)
-
Flink的Savepoints与Checkpoints的不同之处在于备份与传统数据库系统中的恢复日志不同。
-
检查点的主要目的是在job意外失败时提供恢复机制。
-
Checkpoint的生命周期由Flink管理，即Flink创建，拥有和发布Checkpoint - 无需用户交互。
-
作为一种恢复和定期触发的方法，Checkpoint主要的设计目标是:
- 创建checkpoint,是轻量级的
- 尽可能快地恢复
-
与此相反，Savepoints由用户创建，拥有和删除。
-
他们一般是有计划的进行手动备份和恢复。
-
例如，在Flink版本需要更新的时候，或者更改你的流处理逻辑，更改并行性等等。
-
在这种情况下，我们往往关闭一下流，这就需要我们将流中的状态进行存储，后面重新部署job的时候进行会。
-
从概念上讲，Savepoints的生成和恢复成本可能更高，并且更多地关注可移植性和对前面提到的作业更改的支持。
-
使用:
-
命令:
flink savepoint jobID target_directory -
保存当前流的状态到指定目录:
bin/flink savepoint xxxxxxxx(哈希码) hdfs://ronnie01:8020/data/flink/savepoint -
重启, 恢复数据流:
flink-1.9.1/bin/flink run -s hdfs://ronnie01:8020/data/flink/savepoint/savepoint-xxxxx-xxxxxxxxx -c com.ronnie.flink.stream.test.CheckPointTest flink-test.jar
-
