8.spark自适应查询-AQE之自适应调整Shuffle分区数量

目录

概述

自适应查询执行(AQE)是 Spark SQL中的一种优化技术,它利用运行时统计信息来选择最高效的查询执行计划,自Apache Spark 3.2.0以来默认启用该计划。从Spark 3.0开始,AQE有三个主要功如下

  • 自适应查询AQE(Adaptive Query Execution)
    • 自适应调整Shuffle分区数量
      • 原理
      • 默认环境配置
      • 修改配置
    • 动态调整Join策略
    • 动态优化倾斜的 Join

主要功能

自适应调整Shuffle分区数量

spark.sql.adaptive.enabledspark.sql.adaptive.coalescePartitions.enabled配置均为true时,自适应调整Shuffle分区数量功能就启动了

属性名称 默认值 功能 版本
spark.sql.adaptive.enabled true 必备条件之一 3.0.0
spark.sql.adaptive.coalescePartitions.enabled true 必备条件之二 3.0.0
spark.sql.adaptive.advisoryPartitionSizeInBytes 64 MB 自适应优化期间shuffle分区的建议大小(以字节为单位)。当Spark合并小的shuffle分区或拆分倾斜的shuffler分区时,它就会生效。 3.0.0
spark.sql.adaptive.coalescePartitions.parallelismFirst true 当为true时,Spark在合并连续的shuffle分区时会忽略Spark.sql.adaptive.advisoryPartitionSizeInBytes(默认64MB)指定的目标大小,并且只遵循Spark.sql.adaptive.salecePartitions.minPartitionSize(默认1MB)指定的最小分区大小,以最大限度地提高并行性。这是为了在启用自适应查询执行时避免性能回归建议将此配置设置为false ,并遵守spark.sql.adaptive.advisoryPartitionSizeInBytes指定的目标大小。 3.2.0

原理

Spark在处理海量数据的时候,其中的Shuffle过程是比较消耗资源的,也比较影响性能,因为它需要在网络中传输数据

shuffle 中的一个关键属性是:分区的数量。

分区的最佳数量取决于数据自身大小,但是数据大小可能在不同的阶段、不同的查询之间有很大的差异,这使得这个数字很难精准调优。

如果分区数量太多,每个分区的数据就很小,读取小的数据块会导致IO效率降低 ,并且也会产生过多的task, 这样会给Spark任务带来更多负担。

如果分区数量太少,那么每个分区处理的数据可能非常大,处理这些大分区的数据可能需要将数据溢写到磁盘(例如:排序或聚合操作),这样也会降低计算效率。

Spark初始会设置一个较大的Shuffle分区个数,这个数值默认是200,后续在运行时会根据动态统计到的数据信息,将小的分区合并,也就是慢慢减少分区数量。

测试时将以SELECT workorder,unitid,partid,partname,routeid,lineid from ods.xx where dt ='2023-06-24' group by workorder,unitid,partid ,partname ,routeid,lineid 语句进行测试,为了看出 Shuffle 的效果,group 字段多了一些

将初始的 Shuffle 分区数量设置为 5,所以在 Shuffle 过程中数据会产生5 个分区。如果没有开启自适应调整Shuffle分区数量这个策略,Spark会启动5个Recuce任务来完成最后的聚合。但是这里面有3个非常小的分区,为每个分区分别启动一个单独的任务会浪费资源,并且也无法提高执行效率。如下图:

开启自适应调整 Shuffle 分区数量之后,Spark 会将这3个数据量比较小的分区合并为 1 个分区,让1个reduce任务处理

默认环境配置

测试案例:

案例环境,使用的是 spark 3.2.4kyuubi 1.7.1 版本,使用一张 20 亿的表做优化测试的,也可以准备一个 json 文件,加载后转成 DataFrame

sql 复制代码
SELECT  workorder,unitid,partid,partname,routeid,lineid  from ods.xx where dt ='2023-06-24' group by workorder,unitid,partid ,partname ,routeid,lineid 


由上两个图,可以看出21任务,每个任务只是 3~4 M 这样,原因是因

bash 复制代码
spark.sql.adaptive.coalescePartitions.parallelismFirst = true

修改配置

bash 复制代码
spark.sql.adaptive.coalescePartitions.parallelismFirst=false


可以看出,两三千万的数据,shuffle 处理上还是有倾斜的,但海量数据下,基本上是接近64m的。

结束

至此,自适应调整Shuffle分区数量,就结束了。

相关推荐
黎子越17 小时前
大模型基础名词概念
大数据
zandy101117 小时前
主流 AI Agent搜索Skill推荐及高阶选型指南
大数据·人工智能
跨境卫士苏苏17 小时前
2026年做跨境电商,TikTok美区半托管这3个品类正在严查,第2个很多新手还在铺货
大数据·人工智能·跨境电商·营销策略
GIS数据转换器17 小时前
村镇无人机物流配送与跨域监测一体化平台
大数据·运维·人工智能·科技·无人机
知识燃料18 小时前
企业技术决策者落地 AI Agent 体系,AWS 中国峰会有哪些战略与工程内容可看?
大数据·人工智能
TDengine (老段)18 小时前
TDengine 第三方工具 — Telegraf、Kafka Connect、Flink、Spark
大数据·数据库·物联网·flink·kafka·时序数据库·tdengine
guwentian1 天前
Git Worktree 实战:用并行多 Agent 把开发提速 N 倍
大数据·git·elasticsearch·wroktree
乌恩大侠1 天前
【AI-RAN】硬件产品:DELL 前传交换机
人工智能·spark·aerial·o-ru·ai-ran
2503_931712481 天前
OpenInsight领衔:企业AI数据分析平台(Data Agent/智能问数/智能数据报告)
大数据
朴马丁1 天前
国际与国产PLM在精细化工赛道的布局:2026年主要厂商技术特色
大数据·运维·人工智能·流程行业plm·化工新材料