Flink(4)容错、SQL、优化

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
<think>好的,用户想了解Flink SQL和传统SQL在大数据处理中的差异。首先,我需要回顾一下自己对这两个概念的理解。Flink SQL是Apache FlinkSQL接口,用于处理流式和批处理数据,而传统SQL通常指关系型数据库中的SQL,用于处理静态数据。 接下来,我需要从几个方面来比较它们的差异。首先是数据模型,传统SQL处理的是静态的表数据,而Flink SQL处理的是动态的流数据,可能需要用到时间属性和窗口机制。然后,执行模式方面,传统SQL是批处理,而Flink SQL支持流处理和批处理。此外,状态管理也是一个关键点,Flink SQL需要处理状态存储和容错,而传统SQL通常不涉及这些。 另外,用户提到的引用中有提到Beam作为抽象层,可能Flink SQL在API设计上也有类似的抽象,比如统一批流处理。还有引用3中提到数据排序对压缩和性能的影响,可能Flink SQL优化方面有特别处理,比如状态存储和查询优化。 需要确保回答的结构清晰,分点列出差异,并且结合用户提供的引用内容。例如,引用2提到Beam支持多后端执行,可能Flink SQL也有类似的跨平台特性?或者Flink SQL在流处理中的状态管理是否引用了某些缓存库,比如引用4中的缓存库? 还要注意用户的问题可能关注性能、应用场景、语法差异等方面。可能需要提到Flink SQL的时间窗口、水印机制,以及与传统SQL在事务处理上的不同,如传统SQL支持ACID,而Flink SQL更注重高吞吐和低延迟。 最后,生成相关问题时,要考虑用户可能的后续疑问,比如优化方法、使用场景、性能调优等,确保问题有逻辑连贯性,帮助用户深入理解。</think>### Flink SQL与传统SQL的核心差异 #### 1. 数据处理模型 **传统SQL**:面向静态数据集,基于关系型数据库的存储模式(如表结构),适用于$T+1$时效性的离线分析。例如: ```sql SELECT user_id, SUM(order_amount) FROM orders WHERE order_date BETWEEN '2023-01-01' AND '2023-01-31' GROUP BY user_id ``` **Flink SQL**:支持**流批一体**处理,通过动态表(Dynamic Table)模型将数据流映射为持续更新的表[^2]。例如流式聚合: ```sql SELECT user_id, SUM(order_amount) FROM orders GROUP BY user_id, TUMBLE(event_time, INTERVAL '1' HOUR) ``` #### 2. 时间语义支持 **传统SQL**:无显式时间概念,依赖数据写入时间戳。 **Flink SQL**:强制定义**事件时间(Event Time)**与**处理时间(Processing Time)**,需通过`WATERMARK`声明水位线: ```sql CREATE TABLE orders ( user_id INT, order_amount DOUBLE, event_time TIMESTAMP(3), WATERMARK FOR event_time AS event_time - INTERVAL '5' SECOND ) ``` #### 3. 状态管理与容错 **传统SQL**:事务完成后状态即释放,依赖数据库的ACID特性保障一致性[^4]。 **Flink SQL**:需维护**长周期状态**(如窗口聚合结果),通过检查点(Checkpoint)机制实现容错,状态存储支持RocksDB或堆内存[^3]。 #### 4. 执行优化差异 **传统SQL**:优化器侧重索引选择与连接顺序,如B+树索引优化范围查询。 **Flink SQL**:优化器针对流处理特性,例如: - **最小化状态访问**:将过滤操作前置以减少状态存储量 - **增量计算**:对滑动窗口使用`EMIT`语法输出中间结果 ```sql SELECT window_start, COUNT(*) FROM TABLE( HOP(TABLE orders, DESCRIPTOR(event_time), INTERVAL '5' MINUTES, INTERVAL '10' MINUTES)) GROUP BY window_start EMIT DELAY 1 MINUTE ``` #### 5. 资源扩展性 **传统SQL**:通常依赖垂直扩展(如增加数据库服务器配置)[^1]。 **Flink SQL**:原生支持水平扩展,可通过调整并行度(Parallelism)实现分布式计算: ```sql SET 'parallelism.default' = '8'; ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值