大数据之Spark调优：Spark3.0 AQE

最新推荐文章于 2024-10-02 18:26:26 发布
最新推荐文章于 2024-10-02 18:26:26 发布
阅读量1k 收藏
点赞数 1
分类专栏： # Spark调优 文章标签： spark 大数据
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43597208/article/details/133634780
版权

目录


Spark 在 3.0 版本推出了 AQE（Adaptive Query Execution），即自适应查询执行。AQE 是Spark SQL 的一种动态优化机制，在运行时，每当 Shuffle Map 阶段执行完毕，AQE 都会结合这个阶段的统计信息，基于既定的规则动态地调整、修正尚未执行的逻辑计划和物理计
划，来完成对原始查询语句的运行时优化。

动态合并分区

在 Spark 中运行查询处理非常大的数据时，shuffle 通常会对查询性能产生非常重要的影响。shuffle 是非常昂贵的操作，因为它需要进行网络传输移动数据，以便下游进行计算。
最好的分区取决于数据，但是每个查询的阶段之间的数据大小可能相差很大，这使得该数字难以调整：
（1）如果分区太少，则每个分区的数据量可能会很大，处理这些数据量非常大的分区，可能需要将数据溢写到磁盘（例如，排序和聚合），降低了查询。
（2）如果分区太多，则每个分区的数据量大小可能很小，读取大量小的网络数据块，这也会导致 I/O 效率低而降低了查询速度。拥有大量的 task（一个分区一个 task）也会给Spark 任务计划程序带来更多负担。
为了解决这个问题，我们可以在任务开始时先设置较多的 shuffle 分区个数，然后在运行时通过查看 shuffle 文件统计信息将相邻的小分区合并成更大的分区。
例如，假设正在运行 select max(i) from tbl group by j。输入 tbl 很小，在分组前只有 2个分区。那么任务刚初始化时，我们将分区数设置为 5，如果没有 AQE，Spark 将启动五个任务来进行最终聚合，但是其中会有三个非常小的分区，为每个分区启动单独的任务这样
就很浪费。
在这里插入图片描述
取而代之的是，AQE 将这三个小分区合并为一个，因此最终聚只需三个 task 而不是五个
在这里插入图片描述

spark-submit --master yarn --deploy-mode client --driver-memory 1g --num executors 3 --executor-cores 2 --executor-memory 2g --class com.atguigu.sparktuning.aqe.AQEPartitionTunning spark-tuning-1.0-SNAPSHOT-jar-with-dependencies.jar

具体代码：

package com.atguigu.sparktuning.aqe

import com.atguigu.sparktuning.utils.InitUtil
import org.apache.spark.SparkConf
import org.apache.spark.sql.{SaveMode, SparkSession}

object AQEPartitionTunning {
  def main( args: Array[String] ): Unit = {
    val sparkConf = new SparkConf().setAppName("AQEPartitionTunning")
      .set("spark.sql.autoBroadcastJoinThreshold", "-1") //为了演示效果，禁用广播join
      .set("spark.sql.adaptive.enabled", "true")
      .set("spark.sql.adaptive.coalescePartitions.enabled", "true") // 合并分区的开关
      .set("spark.sql.adaptive.coalescePartitions.initialPartitionNum","1000") // 初始的并行度
      .set("spark.sql.adaptive.coalescePartitions.minPartitionNum","10") // 合并后的最小分区数
      .set("spark.sql.adaptive.advisoryPartitionSizeInBytes", "20mb") // 合并后的分区，期望有多大
    val sparkSession: SparkSession = InitUtil.initSparkSession(sparkConf)
    useJoin(sparkSession)
  }

  def useJoin( sparkSession: SparkSession ) = {
    val saleCourse = sparkSession.sql("select *from sparktuning.sale_course")
    val coursePay = sparkSession.sql("select * from sparktuning.course_pay")
      .withColumnRenamed("discount", "pay_discount")
      .withColumnRenamed("createtime", "pay_createtime")
    val courseShoppingCart = sparkSession.sql("select *from sparktuning.course_shopping_cart")
      .drop("coursename")
      .withColumnRenamed("discount", "cart_discount")
      .withColumnRenamed("createtime", "cart_createtime")

    saleCourse.join(courseShoppingCart, Seq("courseid", "dt", "dn"), "right")
      .join(coursePay, Seq("orderid", "dt", "dn"), "left")
      .select("courseid", "coursename", "status", "pointlistid", "majorid", "chapterid", "chaptername", "edusubjectid"
        , "edusubjectname", "teacherid", "teachername", "coursemanager", "money", "orderid", "cart_discount", "sellmoney",
        "cart_createtime", "pay_discount", "paymoney", "pay_createtime", "dt", "dn")
      .write.mode(SaveMode.Overwrite).insertInto("sparktuning.salecourse_detail_1")
  }

}

结合动态申请资源：

spark-submit --master yarn --deploy-mode client --driver-memory 1g --num executors 3 --executor-cores 2 --executor-memory 2g --class com.atguigu.sparktuning.aqe.DynamicAllocationTunning spark-tuning-1.0-SNAPSHOT-jar-with-dependencies.jar

具体代码：

package com.atguigu.sparktuning.aqe

import com.atguigu.sparktuning.utils.InitUtil
import org.apache.spark.SparkConf
import org.apache.spark.sql.{SaveMode, SparkSession}

object DynamicAllocationTunning {
  def main( args: Array[String] ): Unit = {
    val sparkConf = new SparkConf().setAppName("DynamicAllocationTunning")
      .set("spark.sql.autoBroadcastJoinThreshold", "-1")
      .set("spark.sql.adaptive.enabled", "true")
      .set("spark.sql.adaptive.coalescePartitions.enabled", "true")
      .set("spark.sql.adaptive.coalescePartitions.initialPartitionNum","1000")
      .set("spark.sql.adaptive.coalescePartitions.minPartitionNum","10")
      .set("spark.sql.adaptive.advisoryPartitionSizeInBytes", "20mb")
      .set("spark.dynamicAllocation.enabled","true")  // 动态申请资源
      .set("spark.dynamicAllocation.shuffleTracking.enabled","true") // shuffle动态跟踪
    val sparkSession: SparkSession = InitUtil.initSparkSession(sparkConf)
    useJoin(sparkSession)
  }

  def useJoin( sparkSession: SparkSession ) = {
    val saleCourse = sparkSession.sql("select *from sparktuning.sale_course")
    val coursePay = sparkSession.sql("select * from sparktuning.course_pay")
      .withColumnRenamed("discount", "pay_discount")
      .withColumnRenamed("createtime", "pay_createtime")
    val courseShoppingCart = sparkSession.sql("select *from sparktuning.course_shopping_cart")
      .drop("coursename")
      .withColumnRenamed("discount", "cart_discount")
      .withColumnRenamed("createtime", "cart_createtime")
    saleCourse.join(courseShoppingCart, Seq("courseid", "dt", "dn"), "right")
      .join(coursePay, Seq("orderid", "dt", "dn"), "left")
      .select("courseid", "coursename", "status", "pointlistid", "majorid", "chapterid", "chaptername", "edusubjectid"
        , "edusubjectname", "teacherid", "teachername", "coursemanager", "money", "orderid", "cart_discount", "sellmoney",
        "cart_createtime", "pay_discount", "paymoney", "pay_createtime", "dt", "dn")
      .write.mode(SaveMode.Overwrite).insertInto("sparktuning.salecourse_detail_1")
  }

}

动态切换 Join 策略

Spark 支持多种 join 策略，其中如果 join 的一张表可以很好的插入内存，那么broadcast shah join 通常性能最高。因此，spark join 中，如果小表小于广播大小阀值（默认10mb），Spark 将计划进行 broadcast hash join。但是，很多事情都会使这种大小估计出错（例如，存在选择性很高的过滤器），或者 join 关系是一系列的运算符而不是简单的扫描表操作。
为了解决此问题，AQE 现在根据最准确的 join 大小运行时重新计划 join 策略。从下图实例中可以看出，发现连接的右侧表比左侧表小的多，并且足够小可以进行广播，那么AQE 会重新优化，将 sort merge join 转换成为 broadcast hash join。
在这里插入图片描述
对于运行是的 broadcast hash join,可以将 shuffle 优化成本地 shuffle,优化掉 stage 减少网络传输。Broadcast hash join 可以规避 shuffle 阶段，相当于本地 join。

spark-submit --master yarn --deploy-mode client --driver-memory 1g --num executors 3 --executor-cores 4 --executor-memory 2g --classcom.atguigu.sparktuning.aqe.AqeDynamicSwitchJoin spark-tuning-1.0-SNAPSHOT-jar-with-dependencies.jar

具体代码：

package com.atguigu.sparktuning.aqe

import com.atguigu.sparktuning.utils.InitUtil
import org.apache.spark.SparkConf
import org.apache.spark.sql.{SaveMode, SparkSession}

object AqeDynamicSwitchJoin {
  def main( args: Array[String] ): Unit = {
    val sparkConf = new SparkConf().setAppName("AqeDynamicSwitchJoin")
      .set("spark.sql.adaptive.enabled", "true")
      .set("spark.sql.adaptive.localShuffleReader.enabled", "true") //在不需要进行shuffle重分区时，尝试使用本地shuffle读取器。将sort-meger join 转换为广播join
    val sparkSession: SparkSession = InitUtil.initSparkSession(sparkConf)
    switchJoinStartegies(sparkSession)
  }


  def switchJoinStartegies( sparkSession: SparkSession ) = {
    val coursePay = sparkSession.sql("select * from sparktuning.course_pay")
      .withColumnRenamed("discount", "pay_discount")
      .withColumnRenamed("createtime", "pay_createtime")
      .where("orderid between 'odid-9999000' and 'odid-9999999'")
    val courseShoppingCart = sparkSession.sql("select *from sparktuning.course_shopping_cart")
      .drop("coursename")
      .withColumnRenamed("discount", "cart_discount")
      .withColumnRenamed("createtime", "cart_createtime")
    val tmpdata = coursePay.join(courseShoppingCart, Seq("orderid"), "right")
    tmpdata.show()
  }
}

动态优化 Join 倾斜

当数据在群集中的分区之间分布不均匀时，就会发生数据倾斜。严重的倾斜会大大降低查询性能，尤其对于 join。AQE skew join 优化会从随机 shuffle 文件统计信息自动检测到这种倾斜。然后它将倾斜分区拆分成较小的子分区。
例如,下图 A join B,A 表中分区 A0 明细大于其他分区
在这里插入图片描述
因此，skew join 会将 A0 分区拆分成两个子分区，并且对应连接 B0 分区
在这里插入图片描述
没有这种优化，会导致其中一个分区特别耗时拖慢整个 stage,有了这个优化之后每个task 耗时都会大致相同，从而总体上获得更好的性能。
可以采取第 4 章提到的解决方式，3.0 有了 AQE 机制就可以交给 Spark 自行解决。
Spark3.0 增加了以下参数。
1）spark.sql.adaptive.skewJoin.enabled :是否开启倾斜 join 检测，如果开启了，那么会将倾斜的分区数据拆成多个分区,默认是开启的，但是得打开 aqe。
2）spark.sql.adaptive.skewJoin.skewedPartitionFactor :默认值 5，此参数用来判断分区数据量是否数据倾斜，当任务中最大数据量分区对应的数据量大于的分区中位数乘以此参数，并且也大于 spark.sql.adaptive.skewJoin.skewedPartitionThresholdInBytes 参数，那么此任务
是数据倾斜。
3）spark.sql.adaptive.skewJoin.skewedPartitionThresholdInBytes :默认值 256mb，用于判断是否数据倾斜
4）spark.sql.adaptive.advisoryPartitionSizeInBytes :此参数用来告诉 spark 进行拆分后推荐分区大小是多少。

spark-submit --master yarn --deploy-mode client --driver-memory 1g --numexecutors 3 --executor-cores 4 --executor-memory 2g --class com.atguigu.sparktuning.aqe.AqeOptimizingSkewJoin spark-tuning-1.0-SNAPSHOT-jar-with-dependencies.jar

具体代码：

package com.atguigu.sparktuning.aqe

import com.atguigu.sparktuning.utils.InitUtil
import org.apache.spark.SparkConf
import org.apache.spark.sql.{SaveMode, SparkSession}

object AqeOptimizingSkewJoin {
  def main( args: Array[String] ): Unit = {
    val sparkConf = new SparkConf().setAppName("AqeOptimizingSkewJoin")
      .set("spark.sql.autoBroadcastJoinThreshold", "-1")  //为了演示效果，禁用广播join
      .set("spark.sql.adaptive.coalescePartitions.enabled", "true") // 为了演示效果，关闭自动缩小分区
      .set("spark.sql.adaptive.enabled", "true")
      .set("spark.sql.adaptive.skewJoin.enable","true")
      .set("spark.sql.adaptive.skewJoin.skewedPartitionFactor","2")
      .set("spark.sql.adaptive.skewJoin.skewedPartitionThresholdInBytes","20mb")
      .set("spark.sql.adaptive.advisoryPartitionSizeInBytes", "8mb")
    val sparkSession: SparkSession = InitUtil.initSparkSession(sparkConf)
    useJoin(sparkSession)
  }

  def useJoin( sparkSession: SparkSession ) = {
    val saleCourse = sparkSession.sql("select *from sparktuning.sale_course")
    val coursePay = sparkSession.sql("select * from sparktuning.course_pay")
      .withColumnRenamed("discount", "pay_discount")
      .withColumnRenamed("createtime", "pay_createtime")
    val courseShoppingCart = sparkSession.sql("select *from sparktuning.course_shopping_cart")
      .drop("coursename")
      .withColumnRenamed("discount", "cart_discount")
      .withColumnRenamed("createtime", "cart_createtime")
    saleCourse.join(courseShoppingCart, Seq("courseid", "dt", "dn"), "right")
      .join(coursePay, Seq("orderid", "dt", "dn"), "left")
      .select("courseid", "coursename", "status", "pointlistid", "majorid", "chapterid", "chaptername", "edusubjectid"
        , "edusubjectname", "teacherid", "teachername", "coursemanager", "money", "orderid", "cart_discount", "sellmoney",
        "cart_createtime", "pay_discount", "paymoney", "pay_createtime", "dt", "dn")
      .write.mode(SaveMode.Overwrite).insertInto("sparktuning.salecourse_detail_1")
  }


}

如果同时开启了 spark.sql.adaptive.coalescePartitions.enabled 动态合并分区功能，那么
会先合并分区，再去判断倾斜，将动态合并分区打开后，重新执行：

spark-submit --master yarn --deploy-mode client --driver-memory 1g --num executors 3 --executor-cores 4 --executor-memory 2g --class com.atguigu.sparktuning.aqe.AqeOptimizingSkewJoin spark-tuning-1.0-SNAPSHOT-jar-with-dependencies.jar

修改中位数的倍数为 2，重新执行：

spark-submit --master yarn --deploy-mode client --driver-memory 1g --num executors 3 --executor-cores 4 --executor-memory 2g --class com.atguigu.sparktuning.aqe.AqeOptimizingSkewJoin spark-tuning-1.0-SNAPSHOT-jar-with-dependencies.jar
浊酒南街
关注
专栏目录
发掘Spark 3.0潜能：探索与利用调优新特性提升大数据处理性能
击水三千里的专栏
05-03 961
Spark 3.0 大版本发布，Spark SQL 的优化占比将近 50%。Spark SQL 取代 Spark Core，成为新一代的引擎内核，所有其他子框架如 Mllib、Streaming 和 Graph，都可以共享 Spark SQL 的性能优化，都能从 Spark 社区对于 Spark SQL 的投入中受益。
大数据技术Spark3.0详解
悦分享
10-04 2204
Spark3.0版本包含了3400多个补丁程序，是开源社区做出巨大贡献的最高峰，带来了Python和SQL功能的重大进步，并着眼于探索和生产的易用性。
SPARK调优：AQE特性（含脑图总结）
最新发布
ALX3li的博客
10-02 1739
SparkAQE是spark 3.0引入的一大重要功能，今天我们来聊一聊AQE的实现原理。了解一个功能，先来了解其面临的问题。当涉及到大型集群中的复杂查询性能时，处理的并行度和正确Join策略选择已被证明是影响性能的关键因素。
Spark3 新特性之AQE
Shyllin的博客
02-24 3729
Spark3 新特性之AQE
Spark 3.0 - AQE浅析 (Adaptive Query Execution)
热门推荐
Deegue
06-03 1万+
1、前言 近些年来，在对Spark SQL优化上，CBO是最成功的一个特性之一。 CBO会计算一些和业务数据相关的统计数据，来优化查询，例如行数、去重后的行数、空值、最大最小值等。 Spark根据这些数据，自动选择BHJ或者SMJ，对于多Join场景下的Cost-based Join Reorder（可以参考之前写的这篇文章），来达到优化执行计划的目的。 但是，由于这些统计数据是需要预先处理的，会过时，所以我们在用过时的数据进行判断，在某些情况下反而会变成负面效果，拉低了SQL执行效率。 AQE在执行过程中
Spark3.0新特性-AQE
wangleigiser的博客
03-15 3896
想要更全面了解Spark内核和应用实战，可以购买我的新书。 《图解Spark 大数据快速分析实战》(王磊)【摘要 书评 试读】- 京东图书https://item.jd.com/13613302.html AQE 1．AQE的概念 Spark SQL是Spark开发中使用最广泛的引擎，它使得我们通过简单的几条SQL语句就能完成海量数据（TB或PB级数据）的分析。 AQE（Adaptive Query Execution，自适应查询执行）的作用是对正在执行的查询任务进行优化。AQE使Spark计划.
【笔记】Spark3 AQE(Adaptive Query Execution)
JH_Zhai的博客
08-21 1048
不同于传统以整个执行计划为粒度进行调度的方式，AQE 会把执行计划基于 shuffle 划分成若干个子计划，每个子计划用一个新的叶子节点包裹起来，从而使得执行计划的调度粒度细化到 stage 级别 (stage 也是基于 shuffle 划分)。我们知道一般的 SQL 执行流程是，逻辑执行计划 -> 物理执行计划，而 AQE 的执行逻辑是，子物理执行计划 -> 父逻辑执行计划 -> 父物理执行计划，这样的执行流程提供了更多优化的空间。比如在对 Join 算子选择执行方式的时候可能有原来的。
Spark AQE
南风知我意
07-04 1587
我们都知道，之前的 CBO，都是基于静态信息来对 执行计划进行优化，静态统计信息大家都懂的，不一定准确，比如hive中的catalog中记录的统计信息可以认为是不可信的，在一个不准确的统计信息的基础上优化出来的执行计划必然不是最优的。AQE 就是为了解决这个问题而诞生的，随着spark 官方对AQE持续的优化，下面举一些用户使用场景来展示AQE是如何用的Spark shuffles 可以认为是影响查询性能最重要的影响因素，在 shuffle 的时候， 配置多少个 reducer 从来都是spark 用户的老
Spark AQE（Adaptive Query Execution）机制
fanghailiang2016的博客
04-13 1531
AQE 的全称是 Adaptive Query Execution，翻译过来是“自适应查询执行”。它包含了 3 个动态优化特性，分别是 Join 策略调整、自动分区合并和自动倾斜处理。
【Spark重点难点08】Spark3.0中的AQE和DPP小总结
微信搜：import_bigdata，大数据领域硬核原创作者
12-21 2090
点击上方蓝色字体，选择“设为星标”回复”面试“获取更多惊喜本文已加入「大数据成神之路PDF版」提供下载。后台回复：「PDF」即可获取。更多PDF下载可以参考：《重磅,大数据成神之路PDF...
Spark3.0核心调优参数小总结
微信搜：import_bigdata，大数据领域硬核原创作者
12-23 2904
点击上方蓝色字体，选择“设为星标”回复”面试“获取更多惊喜本文已经加入「大数据成神之路PDF版」中提供下载。你可以关注公众号，后台回复：「PDF」即可获取。更多PDF下载可以参考：《重磅...
Spark 自适应查询执行(AQE)
2401_84052244的博客
07-31 594
AQE 是 Spark SQL 的一种动态优化机制，它的诞生解决了 RBO、CBO，这些启发式、静态优化机制的局限性。想要用好 AQE，我们就要掌握它的特点，以及它支持的三种优化特性的工作原理和使用方法。如果用一句话来概括 AQE 的定义，就是每当 Shuffle Map 阶段执行完毕，它都会结合这个阶段的统计信息，根据既定的规则和策略动态地调整、修正尚未执行的逻辑计划和物理计划，从而完成对原始查询语句的运行时优化。
[spark] spark SQL的AQE
胖胖的博客
02-06 925
AQE是Spark SQL的一种动态优机制，是Spark3才出现的。 总体思想是动态优化和修改物理执行计划，利用执行结束的上游Stage的统计信息（主要是数据量和记录数），来优化下游stage的物理执行计划。 AQE有三大特性
Spark3 AQE (Adaptive Query Execution) 一文搞懂 新特性
青冬的博客
12-03 3076
Spark3 新特性 AQE Adaptive Query Execution 原理 代码 讲解
spark-3.0-AQE（Adaptive Query Execution）自适应查询
DCHAO的博客
05-23 645
前置 AQE是一个运行时SQL优化框架，旨在解决由于优化器统计信息不足、不准确或过时而导致的查询执行计划的低效和缺乏灵活性的问题。 可以理解成是 Spark Catalyst 之上的一层，它可以在运行时修改 Spark plan，之前的物理执行计划不再是最终的计划，而是在每个query stage完成之后，动态的根据数据统计的情况，动态调整后续计划， 动态合并shuffle分区，自动调整SQL JOIN策略；动态优化数据倾斜。默认关闭，可以更改配置 “spark.sql.adaptive.enabled”:
Spark3.0新特性AQE DPP
u012106430的博客
02-23 909
在我们执⾏过程中转化为Broadcast Hash Join的同时，我们甚⾄可以将传统shuffle优化为本地shuffle(例如shuffle读在mapper⽽不是基于reducer)来减⼩⽹络开销。Spark ⽀持的许多 Join 策略中，Broadcast Hash Join通常是性能最好的，前提是参加 join 的。⼤⼩为15M，⽽在该场景下，经过filter过滤后，实际参与join的数据⼤⼩为8M，⼩于了默认。在我们处理的数据量级⾮常⼤时，shuffle通常来说是最影响性能的。
spark的AQE机制
qq_42438830的博客
11-24 378
AQE优化规则和策略。
Spark 3.0 AQE（Adaptive Query Execution）
qq_41775852的博客
04-19 181
Spark Adaptive Execution 数据倾斜？Spark 3.0 AQE专治各种不服
apache spark 3.0 中的sql性能改进概览
03-16
Apache Spark 3.0 中的 SQL 性能改进主要包括以下几个方面： 1. Adaptive Query Execution（自适应查询执行）：Spark 3.0 引入了自适应查询执行（AQE）功能，它可以根据数据的大小、分布和查询的复杂度等因素自动调整查询执行计划，从而提高查询性能。 2. 动态分区剪枝（Dynamic Partition Pruning）：Spark 3.0 改进了动态分区剪枝功能，它可以根据查询条件动态地剪枝分区，从而减少不必要的数据扫描，提高查询性能。 3. 优化的代码生成器（Optimized Code Generator）：Spark 3.0 中的代码生成器进行了优化，可以生成更高效的代码，从而提高查询性能。 4. 改进的列式存储（Improved Columnar Storage）：Spark 3.0 中的列式存储进行了改进，可以更好地支持复杂数据类型和嵌套数据结构，从而提高查询性能。 5. 改进的数据源 API（Improved Data Source API）：Spark 3.0 中的数据源 API 进行了改进，可以更好地支持数据源的优化和扩展，从而提高查询性能。 总的来说，Apache Spark 3.0 中的 SQL 性能改进主要集中在自适应查询执行、动态分区剪枝、优化的代码生成器、改进的列式存储和数据源 API 等方面，这些改进可以显著提高 Spark SQL 的查询性能。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值