SparkSQL自适应执行

简介: 阿里云EMR-3.13.0版本的SparkSQL支持自适应执行功能,用来解决Reduce个数的动态调整/数据倾斜/执行计划的动态优化问题。

阿里云EMR-3.13.0版本的SparkSQL支持自适应执行功能。

解决哪些问题

SparkSQL自适应执行解决以下问题:

shuffle partition个数

目前SparkSQL中reduce阶段的task个数取决于固定参数spark.sql.shuffle.partition(默认值200),一个作业一旦设置了该参数,它运行过程中的所有阶段的reduce个数都是同一个值。

而对于不同的作业,以及同一个作业内的不同reduce阶段,实际的数据量大小可能相差很大,比如reduce阶段要处理的数据可能是10MB,也有可能是100GB, 如果使用同一个值对实际运行效率会产生很大影响,比如10MB的数据一个task就可以解决,如果spark.sql.shuffle.partition使用默认值200的话,那么10MB的数据就要被分成200个task处理,增加了调度开销,影响运行效率。

SparkSQL自适应框架可以通过设置shuffle partition的上下限区间,在这个区间内对不同作业不同阶段的reduce个数进行动态调整。

通过区间的设置,一方面可以大大减少调优的成本(不需要找到一个固定值),另一方面同一个作业内部不同reduce阶段的reduce个数也能动态调整。

参数:

属性名称 默认值 备注
spark.sql.adaptive.enabled false 自适应执行框架的开关
spark.sql.adaptive.minNumPostShufflePartitions 1 reduce个数区间最小值
spark.sql.adaptive.maxNumPostShufflePartitions 500 reduce个数区间最大值
spark.sql.adaptive.shuffle.targetPostShuffleInputSize 67108864 动态调整reduce个数的partition大小依据,如设置64MB则reduce阶段每个task最少处理64MB的数据
spark.sql.adaptive.shuffle.targetPostShuffleRowCount 20000000 动态调整reduce个数的partition条数依据,如设置20000000则reduce阶段每个task最少处理20000000条的数据

数据倾斜

join中会经常碰到数据倾斜的场景,导致某些task处理的数据过多,出现很严重的长尾。目前SparkSQL没有对倾斜的数据进行相关的优化处理。

SparkSQL自适应框架可以根据预先的配置在作业运行过程中自动检测是否出现倾斜,并对检测到的倾斜进行优化处理。

优化的主要逻辑是对倾斜的partition进行拆分由多个task来进行处理,最后通过union进行结果合并。

支持的Join类型:

join类型 备注
Inner 左/右表均可处理倾斜
Cross 左/右表均可处理倾斜
LeftSemi 只对左表处理倾斜
LeftAnti 只对左表处理倾斜
LeftOuter 只对左表处理倾斜
RightOuter 只对右表处理倾斜

参数:

属性名称 默认值 备注
spark.sql.adaptive.enabled false 自适应执行框架的开关
spark.sql.adaptive.skewedJoin.enabled false 倾斜处理开关
spark.sql.adaptive.skewedPartitionFactor 10 当一个partition的size大小 大于 该值(所有parititon大小的中位数) 且 大于spark.sql.adaptive.skewedPartitionSizeThreshold,或者parition的条数 大于 该值(所有parititon条数的中位数) 且 大于 spark.sql.adaptive.skewedPartitionRowCountThreshold, 才会被当做倾斜的partition进行相应的处理
spark.sql.adaptive.skewedPartitionSizeThreshold 67108864 倾斜的partition大小不能小于该值
spark.sql.adaptive.skewedPartitionRowCountThreshold 10000000 倾斜的partition条数不能小于该值
spark.shuffle.statistics.verbose false 打开后MapStatus会采集每个partition条数的信息,用于倾斜处理

Runtime执行计划优化

SparkSQL的Catalyst优化器会将sql语句转换成物理执行计划,然后真正运行物理执行计划。但是Catalyst转换物理执行计划的过程中,由于缺少Statistics统计信息,或者Statistics统计信息不准等原因,会到时转换的物理执行计划可能并不是最优的,比如转换为SortMergeJoinExec,但实际BroadcastJoin更合适。

SparkSQL自适应执行框架会在物理执行计划真正运行的过程中,动态的根据shuffle阶段shuffle write的实际数据大小,来调整是否可以用BroadcastJoin来代替SortMergeJoin,提高运行效率。

参数:

属性名称 默认值 备注
spark.sql.adaptive.enabled false 自适应执行框架的开关
spark.sql.adaptive.join.enabled true 开关
spark.sql.adaptiveBroadcastJoinThreshold 等于spark.sql.autoBroadcastJoinThreshold 运行过程中用于判断是否满足BroadcastJoin条件

测试

以TPC-DS中某些query为例

shuffle partition个数

query30
原生Spark:
image

自适应调整reduce个数:
image

Runtime执行计划优化(SortMergeJoin转BroadcastJoin)

image

自适应转换为BroadcastJoin
image

欢迎加入E-MapReduce用户群
c7c8f09ebf3cc7795e0dd0da330cec88

目录
相关文章
浦语·灵笔2:一款超强的图文多模态大模型,可直接生成图文并茂的完整文章!
浦语·灵笔2:一款超强的图文多模态大模型,可直接生成图文并茂的完整文章!
798 1
|
SQL 运维 搜索推荐
《揭秘,阿里开源自研搜索引擎Havenask的在线检索服务》
Havenask是阿里巴巴智能引擎事业部自研的开源高性能搜索引擎,深度支持了包括淘宝、天猫、菜鸟、高德、饿了么在内几乎整个阿里的搜索业务。本文针对性介绍了Havenask的在线检索服务,它具备高可用、高时效、低成本的优势,帮助企业和开发者量身定做适合业务发展的智能搜索服务。
85802 138
|
存储 人工智能 前端开发
AI智能体开发实战:17种核心架构模式详解与Python代码实现
本文系统解析了17种AI智能体设计模式,涵盖反思、工具调用、多智能体协作、思维树、规划执行、集成决策等核心架构,结合LangGraph实现与代码演示,揭示如何通过模式组合构建高效、可靠的大规模AI系统。
1528 2
|
9月前
|
机器学习/深度学习 移动开发 人工智能
大模型应用:庖丁解牛:QKV机制详解,大模型的注意力之眼.4
QKV机制是Transformer注意力的核心:Query(提问)、Key(标识)、Value(信息)三者通过点积计算相似度,Softmax归一化后加权融合Value,实现动态上下文感知。它能捕捉长程依赖,解决代词消解、一词多义等问题,支撑大模型强大语言理解能力。
2127 7
|
消息中间件 关系型数据库 MySQL
SpringBoot-Kafka(生产者事务、手动提交offset、定时消费、消息转发、过滤消息内容、自定义分区器、提高吞吐量)
SpringBoot-Kafka(生产者事务、手动提交offset、定时消费、消息转发、过滤消息内容、自定义分区器、提高吞吐量)
SpringBoot-Kafka(生产者事务、手动提交offset、定时消费、消息转发、过滤消息内容、自定义分区器、提高吞吐量)
|
Docker 容器
docker 换国内镜像源,docker换源
docker 换国内镜像源,docker换源
12505 91
|
自然语言处理 搜索推荐 算法
【一文读懂】基于Havenask向量检索+大模型,构建可靠的智能问答服务
Havenask是阿里巴巴智能引擎事业部自研的开源高性能搜索引擎,深度支持了包括淘宝、天猫、菜鸟、高德、饿了么在内的几乎整个阿里的搜索业务。本文针对性介绍了Havenask作为一款高性能的召回搜索引擎,应用在向量检索和LLM智能问答场景的解决方案和核心优势。通过Havenask向量检索+大模型可以构建可靠的垂直领域的智能问答方案,同时快速在业务场景中进行实践及应用。
112392 64
|
SQL 分布式计算 数据处理
【Hive】所有的Hive任务都会有MapReduce的执行吗?
【4月更文挑战第17天】【Hive】所有的Hive任务都会有MapReduce的执行吗?

热门文章

最新文章