Flink调优----资源配置调优与状态及Checkpoint调优

目录

第 1 章 资源配置调优

1.1 内存设置

1.1.1 TaskManager 内存模型

1、内存模型详解

2、案例分析

1.1.2 生产资源配置示例

1.2 合理利用 cpu 资源

1.2.1 使用 DefaultResourceCalculator 策略

1.2.2 使用 DominantResourceCalculator 策略

1.2.3 使用 DominantResourceCalculator 策略并指定容器 vcore 数

1.3 并行度设置

1.3.1 全局并行度计算

1.3.2 Source 端并行度的配置

1.3.3 Transform 端并行度的配置

1.3.4 Sink 端并行度的配置

第 2 章 状态及 Checkpoint 调优

2.1 RocksDB 大状态调优

2.1.1 开启 State 访问性能监控

2.1.2 开启增量检查点和本地恢复

1)开启增量检查点

2)开启本地恢复

3)设置多目录

2.1.3 调整预定义选项

2.1.4 增大 block 缓存

2.1.5 增大 write buffer 和 level 阈值大小

2.1.6 增大 write buffer 数量

2.1.7 增大后台线程数和 write buffer 合并数

1)增大线程数

2)增大 writebuffer 最小合并数

2.1.8 开启分区索引功能

2.1.9 参数设定案例

2.2 Checkpoint 设置

总结


       在大数据处理领域,Flink 作为一款强大的流处理框架,其性能优化对于高效数据处理至关重要。合理的资源配置是实现卓越性能的基石,它直接关系到 Flink 作业在处理大规模数据时的效率、稳定性以及资源利用率。而状态及 Checkpoint 调优则是确保数据处理准确性与可靠性的关键环节,能够有效应对系统故障与数据一致性挑战。通过深入探究资源配置调优以及状态和 Checkpoint 调优的策略与方法,可使 Flink 在复杂的数据处理场景中充分发挥其潜力,满足日益增长的实时数据处理需求,为企业和组织提供更加精准、及时的数据洞察与决策支持。

第 1 章 资源配置调优

        Flink 性能调优的第一步,就是为任务分配合适的资源,在一定范围内,增加资源的分配与性能的提升是成正比的,实现了最优的资源配置后,在此基础上再考虑进行后面论述的性能调优策略。

        提交方式主要是 yarn-per-job,资源的分配在使用脚本提交 Flink 任务时进行指定。

标准的 Flink 任务提交脚本(Generic CLI 模式)

从 1.11 开始,增加了通用客户端模式,参数使用 -D <property=value> 指定

bin/flink run \
-t yarn-per-job \
-d \
-p 5 \ 指定并行度
-Dyarn.application.queue=test \ 指定 yarn 队列
-Djobmanager.memory.process.size=1024mb \ 指定 JM 的总进程大小
-Dtaskmanager.memory.process.size=1024mb \ 指定每个 TM 的总进程大小
-Dtaskmanager.numberOfTaskSlots=2 \ 指定每个 TM 的 slot 数
-c com.atguigu.flink.tuning.UvDemo \
/opt/module/flink-1.13.1/myjar/flink-tuning-1.0-SNAPSHOT.jar

参数列表:
//nightlies.apache.org/flink/flink-docs-release-1.13/docs/deployment/config/

1.1 内存设置

1.1.1 TaskManager 内存模型

1、内存模型详解
  • JVM 特定内存:JVM本身使用的内存,包含JVM的metaspace和over-head

1)JVM metaspace:JVM元空间

taskmanager.memory.jvm-metaspace.size,默认256mb

2)JVM over-head执行开销:JVM执行时自身所需要的内容,包括线程堆栈、IO、编译缓存等所使用的内存。

taskmanager.memory.jvm-overhead.fraction,默认0.1

taskmanager.memory.jvm-overhead.min,默认192mb

taskmanager.memory.jvm-overhead.max,默认1gb

总进程内存*fraction,如果小于配置的min(或大于配置的max大小,则使用min/max大小

  • 框架内存:Flink框架,即TaskManager本身所占用的内存,不计入Slot的资源中。

堆内:taskmanager.memory.framework.heap.size,默认128MB

堆外:taskmanager.memory.framework.off-heap.size,默认128MB

  • Task内存:Task执行用户代码时所使用的内存

堆内:taskmanager.memory.task.heap.size,默认none,由Flink内存扣除掉其他部分的内存得到。

堆外:taskmanager.memory.task.off-heap.size,默认0,表示不使用堆外内存

  • 网络内存:网络数据交换所使用的堆外内存大小,如网络数据交换缓冲区

堆外:taskmanager.memory.network.fraction,默认0.1

  taskmanager.memory.network.min,默认64mb

  taskmanager.memory.network.max,默认1gb

Flink内存*fraction,如果小于配置的min(或大于配置的max大小,则使用min/max大小

  • 托管内存:用于RocksDB State Backend 的本地内存和批的排序、哈希表、缓存中间结果。

堆外:taskmanager.memory.managed.fraction,默认0.4

  taskmanager.memory.managed.size,默认none

如果size没指定,则等于Flink内存*fraction

2、案例分析

        基于 Yarn 模式,一般参数指定的是总进程内存,taskmanager.memory.process.size,比如指定为 4G,每一块内存得到大小如下:

(1)计算Flink内存

        JVM元空间256m

        JVM执行开销: 4g*0.1=409.6m,在[192m,1g]之间,最终结果409.6m

        Flink内存=4g-256m-409.6m=3430.4m

(2)网络内存=3430.4m*0.1=343.04m,在[64m,1g]之间,最终结果343.04m

(3)托管内存=3430.4m*0.4=1372.16m

(4)框架内存,堆内和堆外都是128m

(5)Task堆内内存=3430.4m-128m-128m-343.04m-1372.16m=1459.2m

所以进程内存给多大,每一部分内存需不需要调整,可以看内存的使用率来调整。

1.1.2 生产资源配置示例

bin/flink run \
-t yarn-per-job \
-d \
-p 5 \ 指定并行度
-Dyarn.application.queue=test \ 指定 yarn 队列
-Djobmanager.memory.process.size=2048mb \ JM2~4G 足够
-Dtaskmanager.memory.process.size=4096mb \ 单个 TM2~8G 足够
-Dtaskmanager.numberOfTaskSlots=2 \ 与容器核数 1core:1slot 或 2core:1slot
-c com.atguigu.flink.tuning.UvDemo \
/opt/module/flink-1.13.1/myjar/flink-tuning-1.0-SNAPSHOT.jar

        Flink 是实时流处理,关键在于资源情况能不能抗住高峰时期每秒的数据量,通常用 QPS/TPS 来描述数据情况。

1.2 合理利用 cpu 资源

### Flink 参数设置化技巧 #### 自动并行度整 自动并行度整能够动态适应集群资源的变化,从而提高执行效率。启用此特性可通过配置项 `execution.batch.adaptive.auto-parallelism.enabled` 来实现[^1]。 #### 空闲状态保留时间设定 合理设置空闲状态保留时间有助于预防由于长时间未清理而造成的状态膨胀现象,在涉及常规连接操作以及Top-N去重的应用场合尤为重要。可以通过API接口或是直接修改配置文件中的相应选项来进行定义[^2]。 #### MiniBatch 微批处理机制 MiniBatch 技术通过暂存一定量的数据后再集中处理的方式增强了吞吐能力;然而需要注意的是该方法并非适用于所有情况,并且具体行为可能随Flink版本更新有所改变。它特别适合于那些可以容忍一定程度延迟的任务流程中。 #### LocalGlobal 两阶段聚合策略 针对数据分布不均所引发的问题,采用LocalGlobal双层汇聚方案可显著改善计算节点间负载均衡状况。值得注意的是这种改进措施需配合MiniBatch使用,并且仅当用户自定义聚集函数满足特定条件时才生效。 #### Split Distinct 计数化 对于COUNT DISTINCT类型的统计需求,引入Split Distinct算法提供了一种有效的解决方案。尽管存在一定局限性——比如无法支持全部内置聚合运算符——但在某些特殊条件下确实表现出色,实际应用案例表明开启这项特性的前后性能差距明显。 #### 多维DISTINCT过滤技术 利用Filter算子结合查询计划生成工具的帮助,可以在不影响逻辑正确性的前提下去除不必要的中间结果集副本,进而减少内存占用率。Web界面展示的Checkpoint大小对比图清晰反映了这一改动带来的积极影响。 ```sql -- 设置全局默认的空闲状态超时时长为一天 SET 'state.ttl'='86400s'; -- 启用MiniBatch微批次处理,默认缓冲时间为200毫秒 SET 'table.exec.mini-batch.enabled' = 'true'; SET 'table.exec.mini-batch.allow-latency' = '200ms'; -- 开启LocalGlobal局部加权求模式 CREATE TABLE my_table ( ... ) WITH ('changelog-mode'='I,UA,D'); -- 应用Split Distinct化到COUNT(DISTINCT field) SELECT COUNT(DISTINCT user_id) FROM orders; -- 实现多维度唯一值计数的同时去除冗余记录 SELECT country, city, COUNT(DISTINCT device_type) AS unique_devices FROM sessions GROUP BY country, city; ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

天冬忘忧

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值