Flink(4)容错、SQL、优化

最新推荐文章于 2023-10-24 14:00:03 发布

xiuxiuhh

最新推荐文章于 2023-10-24 14:00:03 发布

阅读量223

点赞数

文章标签： flink sql 数据库

本文链接：https://blog.csdn.net/xiuxiuhh/article/details/132595930

版权

1 检查点机制Checkpoint

Checkpoint，是Flink用来容错的一种机制。
Checkpoint的流程：

1、CheckpointCoordinator周期性的向该流应用的所有source算子发送barrier。
2、当某个source算子收到一个barrier时，便暂停数据处理过程，然后将自己的当前状态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告自己快照制作情况，同时向自身所有下游算子广播该barrier，恢复数据处理
3、下游算子收到barrier之后，会暂停自己的数据处理过程，然后将自身的相关状态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告自身快照情况，同时向自身所有下游算子广播该barrier，恢复数据处理。
4、每个算子按照步骤3不断制作快照并向下游广播，直到最后barrier传递到sink算子，快照制作完成。
5、当CheckpointCoordinator收到所有算子的报告之后，认为该周期的快照制作成功; 否则，如果在规定的时间内没有收到所有算子的报告，则认为本周期快照制作失败

2 重启策略

在有了Checkpoint之后，我们可以通过两种操作来保证Flink程序的健壮性，实现容错的能力。

重启策略Restart Strategy （能够解决程序挂了的问题）
状态后端State Backend（能够解决状态丢失的问题）

Flink支持的重启策略类型如下：

1、none, off, disable：无重启策略，作业遇到问题直接失败，不会重启。
2、fixeddelay, fixed-delay：固定延迟重启策略，作业失败后，延迟一定时间重启。但是有最大重启次数限制，超过这个限制后作业失败，不再重启。
3、failurerate, failure-rate：失败率重启策略，作业失败后，延迟一定时间重启。但是有最大失败率限制。如果一定时间内作业失败次数超过配置值，则标记为真的失败，不再重启。
4、exponentialdelay, exponential-delay：指数延时重启，作业失败后重启延迟时间随着失败次数指数递增。没有最大重启次数限制，无限尝试重启作业。
注意：如果启用了checkpoint并且没有显式配置重启策略，会默认使用fixeddelay策略，最大重试次数为Integer.MAX_VALUE。

https://nightlies.apache.org/flink/flink-docs-release-1.17/docs/ops/state/task_failure_recovery/
全局配置影响Flink提交的所有作业的。修改全局配置需要编辑flink-conf.yaml文件。
配置重启策略的方式：

代码中配置：
restart-strategy: none, off, disable | fixeddelay, fixed-delay | failurerate, failure-rate | exponentialdelay, exponential-delay
如：
配置文件中配置
no restart 不重启，遇到异常就挂了：restart-strategy: none
fixeddelay 固定延时重启：restart-strategy: fixed-delay
failurerate:restart-strategy: failure-rate

2.1 固定延时重启配置

代码中配置：

env.setRestartStrategy(RestartStrategies.fixedDelayRestart(
  3, // number of restart attempts，固定重启的次数
  Time.of(10, TimeUnit.SECONDS) // delay，延迟时间
));

配置中配置：

restart-strategy: fixed-delay   #配置固定延迟重启
# 尝试重启次数
restart-strategy.fixed-delay.attempts: 10
# 两次连续重启的间隔时间
restart-strategy.fixed-delay.delay: 20 s

2.2 失败率重启配置

在一定的时间范围内，允许失败的次数。
代码中设置：

env.setRestartStrategy(RestartStrategies.failureRateRestart(
  3, // max failures per interval，最大失败的次数
  Time.of(5, TimeUnit.MINUTES), //time interval for measuring failure rate     #失败率的时间间隔
  Time.of(10, TimeUnit.SECONDS) // delay    #重启的时间间隔（每隔多次时间重启）
));

配置中配置：

# 两次连续重启的间隔时间
restart-strategy.failure-rate.delay: 10 s
# 计算失败率的统计时间跨度
restart-strategy.failure-rate.failure-rate-interval: 2 min
# 计算失败率的统计时间内的最大失败次数
restart-strategy.failure-rate.max-failures-per-interval: 10

2.3 指数延迟重启策略

Flink程序的重启时间随着指数的增加而呈指数级别递增。
代码中设置：

env.setRestartStrategy(RestartStrategies.exponentialDelayRestart(
  Time.milliseconds(1),
  Time.milliseconds(1000),
  1.1, // exponential multiplier
  Time.milliseconds(2000), // threshold duration to reset delay to its initial value
  0.1 // jitter
));

配置中配置：

restart-strategy: exponential-delay
# 初次失败后重启时间间隔（初始值）
restart-strategy.exponential-delay.initial-backoff: 1 s
# 以后每次失败，重启时间间隔为上一次重启时间间隔乘以这个值
restart-strategy.exponential-delay.backoff-multiplier: 2
# 抖动因子，每次重启间隔时间的最大抖动值（加或减去该配置项范围内的一个随机数），防止大量作业在同一时刻重启
restart-strategy.exponential-delay.jitter-factor: 0.1
# 最大重启时间间隔，超过这个最大值后，重启时间间隔不再增大
restart-strategy.exponential-delay.max-backoff: 1 min
# 多长时间作业运行无失败后，重启间隔时间会重置为初始值（第一个配置项的值）
restart-strategy.exponential-delay.reset-backoff-threshold: 1 h

重启策略并不是设置的越多越好。
如果Checkpoint被禁用，默认情况下重启策略就是none。
如果Checkpoint被启动，默认情况下的重启策略是fixed-delay，重启的次数为Integer.MAX_VALUE。

3 状态后端

状态后端用来保存Flink中Checkpoint的状态的。
Flink 提供了不同的状态后端，用于指定状态的存储方式和位置。默认情况下，配置文件flink-conf.yaml确定所有 Flink 作业的状态后端。
对于流处理程序，Flink Job的状态后端决定了它的状态如何存储在每个 TaskManager（TaskManager 的 Java 堆或（嵌入式）RocksDB）上。
State 始终在本地访问（只是访问/使用），这有助于 Flink 应用程序实现高吞吐量和低延迟。您可以选择将状态保留在 JVM 堆上，或者如果它太大，则保留在有效组织的磁盘数据结构中，这取决于状态后端的配置。

Flink 提供了三种可用的状态后端用于在不同情况下进行状态的保存（状态存储）：

3.1 内存状态后端MemoryStateBackend

在debug模式下使用，不建议在生产模式下应用
相当于使用HashMapStateBackend和JobManagerCheckpointStorage
在这里插入图片描述

3.2 文件系统状态后端FsStateBackend

分布式文件持久化，每次读写都会产生网络IO，整体性能不佳，公司中一般用分布式文件系统，如: HDFS这是最常见的状态后端
在这里插入图片描述

3.3 RocksDB数据库状态后端RocksDBStateBackend

是目前唯一支持增量 checkpoint 的后端。增量 checkpoint 非常适用于超大状态的场景。本地文件+异步HDFS持久化。
在这里插入图片描述

4 SQL

在这里插入图片描述

Flink SQL> CREATE TABLE user_profile (
>   `user_id` string,
>   `age` string,
>   `sex` string
> )
> WITH (
>    'connector' = 'jdbc',
>    'url' = 'jdbc:mysql://node1:3306/test',
>    'table-name' = 'user_profile',
>    'username'='root',
>    'password'='123456'
> );
[INFO] Execute statement succeed.
Flink SQL> select * from user_profile;

错误记录：

[ERROR] Could not execute SQL statement. Reason:
org.apache.flink.table.api.ValidationException: Could not find any factory for identifier 'jdbc' that implements 'org.apache.flink.table.factories.DynamicTablespath.

Available factory identifiers are:

blackhole
datagen
filesystem
kafka
print
python-input-format
socket
upsert-kafka

Flink SQL> select * from user_profile;
[ERROR] Could not execute SQL statement. Reason:
java.lang.ClassNotFoundException: com.mysql.jdbc.Driver

xiuxiuhh

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Flink(4)容错、SQL、优化

2、当某个source算子收到一个barrier时，便暂停数据处理过程，然后将自己的当前状态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告自己快照制作情况，同时向自身所有下游算子广播该barrier，恢复数据处理。3、下游算子收到barrier之后，会暂停自己的数据处理过程，然后将自身的相关状态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告自身快照情况，同时向自身所有下游算子广播该barrier，恢复数据处理。
复制链接

扫一扫