Spark SQL工作负载的性能问题，一直都是优化需要考虑的重要问题。在Spark 3.0之后，推出了自适应查询框架，致力于提升和优化查询当中的工作负载带来的性能问题。今天的大数据开发学习分享，我们就主要来讲讲Spark 3.0 SQL工作负载性能优化。
自适应查询执行设计原理
AQE的主要思想是使执行计划不是最终的，并允许在每个阶段的边界进行审核。因此，执行计划被分解为由阶段界定的新的“查询阶段”抽象。
催化剂现在停在每个阶段的边界，以根据中间数据上可用的信息尝试并应用其他优化。
因此，可以将AQE定义为Spark Catalyst之上的一层，它将动态修改Spark计划。
有什么缺点吗？有一些，但它们很小：
执行在Spark的每个阶段边界处停止，以查看其计划，但这被性能提升所抵消。
Spark UI更加难以阅读，因为Spark为给定的应用程序创建了更多的作业，而这些作业不会占用您设置的Job组和描述。
Shuffle分区的自适应数目
自Spark 2.4起，AQE的此功能已可用。
要启用它，您需要将spark.sql.adaptive.enabled设置为true，该参数默认值为false。启用AQE后，随机调整分区的数量将自动调整，不再是默认的200或手动设置的值。
这是启用AQE之前和之后第一个TPC-DS查询的执行结果：
动态将排序合并联接转换为广播联接
当任何联接端的运行时统计信息小于广播哈希联接阈值时，AQE会将排序合并联接转换为广播哈希联接。
这是启用AQE之前和之后第二个TPC-DS查询执行的最后阶段：
动态合并shuffle分区
如果随机播放分区的数量大于按键分组的数量，则由于键的不平衡分配，会浪费很多CPU周期
当两个
spark.sql.adaptive.enabled
spark.sql.adaptive.coalescePartitions.enabled
设置为true，Spark将根据以下内容合并连续的shuffle分区
设置为spark.sql.adaptive.advisoryPartitionSizeInBytes指定的目标大小，以避免执行过多的小任务。
动态优化倾斜的连接
倾斜是分布式处理的绊脚石。它实际上可能会使您的处理暂停数小时：
如果不进行优化，则执行连接所需的时间将由最大的分区来定义。
因此，倾斜联接优化将使用spark.sql.adaptive.advisoryPartitionSizeInBytes指定的值将分区A0划分为子分区，并将它们中的每一个联接到表B的对应分区B0。
因此，您需要向AQE提供您的倾斜定义。
这涉及两个属性：
spark.sql.adaptive.skewJoin.skewedPartitionFactor是相对的：如果分区的大小大于此因子乘以中位数分区大小且也大于，则认为该分区是倾斜的
spark.sql.adaptive.skewedPartitionThresholdInBytes，这是绝对的：这是阈值，低于该阈值将被忽略。
动态分区修剪
动态分区修剪（DPP）的想法是最有效的优化技术之一：仅读取所需的数据。DPP不是AQE的一部分，实际上，必须禁用AQE才能进行DPP。从好的方面来说，这允许将DPP反向移植到Spark 2.4 for CDP。
该优化在逻辑计划和物理计划上均实现。
在逻辑级别上，识别维度过滤器，并通过连接传播到扫描的另一侧。
然后，在物理级别上，过滤器在维度侧执行一次，结果被广播到主表，在该表中也应用了过滤器。
如果禁用spark.sql.optimizer.dynamicPartitionPruning.reuseBroadcastOnly，则DPP实际上可以与其他类型的联接一起使用（例如，SortMergeJoin）。
在那种情况下，Spark会估计DPP过滤器是否真正提高了查询性能。
DPP可以极大地提高高度选择性查询的性能，例如，如果您的查询从5年的数据中的一个月中筛选出来。
并非所有查询的性能都有如此显着的提高，但是在99个TPC-DS查询中，有72个受到DPP的积极影响。
关于大数据开发学习，Spark 3.0 SQL工作负载性能优化，以上就为大家做了简单的介绍了。Spark SQL的性能优化，是实际场景下常常遇到的问题，这部分也值得去多理解和掌握。
网友评论