Catalyst是Spark SQL外围优化器，晚期次要基于规定的优化器RBO，前期又引入基于代价进行优化的CBO。然而在这些版本中，Spark SQL执行打算一旦确定就不会扭转。因为不足或者不精确的数据统计信息（如行数、不同值的数量、NULL值、最大/最小值等）和对老本的谬误估算导致生成的初始大数据培训打算不现实，从而导致执行效率绝对低下。

那么就引来一个思考：咱们如何可能在运行时获取更多的执行信息，而后依据这些信息来动静调整并抉择一个更优的执行打算呢？

Spark SQL自适应执行优化引擎（Adaptive Query Execution，简称AQE）应运而生，它能够依据执行过程中的两头数据优化后续执行，从而进步整体执行效率。外围在于：通过在运行时对查问执行打算进行优化，容许Spark Planner在运行时执行可选的执行打算，这些打算将基于运行时统计数据进行优化，从而晋升性能。

AQE齐全基于准确的运行时统计信息进行优化，引入了一个根本的概念Query Stages，并且以Query Stage为粒度，进行运行时的优化，其工作原理如下所示：

由shuffle和broadcast exchange把查问执行打算分为多个query stage，query stage执行实现时获取两头后果

query stage边界是运行时优化的最佳时机（人造的执行间歇；分区、数据大小等统计信息曾经产生）

整个AQE的工作原理以及流程为：

运行没有依赖的stage

在一个stage实现时再根据新的统计信息优化残余局部

执行其余曾经满足依赖的stage

反复步骤（2）（3）直至所有stage执行实现

自适应查问执行框架（AQE）

自适应查问执行最重要的问题之一是何时进行从新优化。Spark算子通常是pipeline化的，并以并行的形式执行。然而shuffle或broadcast exchange会突破这个pipeline。咱们称它们为物化点，并应用术语"查问阶段"来示意查问中由这些物化点限定的子局部。每个查问阶段都会物化它的两头后果，只有当运行物化的所有并行过程都实现时，能力继续执行下一个阶段。这为从新优化提供了一个绝佳的机会，因为此时所有分区上的数据统计都是可用的，并且后续操作还没有开始。

当查问开始时，自适应查问执行框架首先启动所有叶子阶段（leaf stages）—— 这些阶段不依赖于任何其余阶段。一旦其中一个或多个阶段实现物化，框架便会在物理查问打算中将它们标记为实现，并相应地更新逻辑查问打算，同时从实现的阶段检索运行时统计信息。

基于这些新的统计信息，框架将运行优化程序、物理打算程序以及物理优化规定，其中包含惯例物理规定（regular physical rules）和自适应执行特定的规定，如coalescing partitions（合并分区）、skew join handling（join数据歪斜解决）等。当初咱们有了一个新优化的查问打算，其中蕴含一些已实现的阶段，自适应执行框架将搜寻并执行子阶段已全副物化的新查问阶段，并反复下面的execute-reoptimize-execute过程，直到实现整个查问。

在Spark 3.0中，AQE框架带来了以下三个个性：

Dynamically coalescing shuffle partitions（动静合并shuffle的分区）能够简化甚至防止调整shuffle分区的数量。用户能够在开始时设置绝对较多的shuffle分区数，AQE会在运行时将相邻的小分区合并为较大的分区。

Dynamically switching join strategies（动静调整join策略）在肯定水平上防止因为短少统计信息或着谬误预计大小（当然也可能两种状况同时存在），而导致执行次优打算的状况。这种自适应优化能够在运行时sort merge join转换成broadcast hash join，从而进一步晋升性能

Dynamically optimizing skew joins（动静优化数据歪斜的join）skew joins可能导致负载的极其不均衡，并重大升高性能。在AQE从shuffle文件统计信息中检测到任何歪斜后，它能够将歪斜的分区宰割成更小的分区，并将它们与另一侧的相应分区连接起来。这种优化能够并行化歪斜解决，取得更好的整体性能。

上面咱们来具体介绍这三个个性。

动静合并shuffle的分区

当在Spark中运行查问来解决十分大的数据时，shuffle通常对查问性能有十分重要的影响。shuffle是一个低廉的操作，因为它须要在网络中挪动数据，以便数据依照上游操作所要求的形式从新散布。

分区的数量是shuffle的一个要害属性。分区的最佳数量取决于数据，然而数据大小可能在不同的阶段、不同的查问之间有很大的差别，这使得这个分区数很难调优：

如果分区数太少，那么每个分区解决的数据可能十分大，解决这些大分区的工作可能须要将数据溢写到磁盘（例如，波及排序或聚合的操作），从而减慢查问速度

如果分区数太多，那么每个分区解决的数据可能十分小，并且将有大量的网络数据获取来读取shuffle块，这也会因为低效的I/O模式而减慢查问速度。大量的task也会给Spark任务调度程序带来更多的累赘

为了解决这个问题，咱们能够在开始时设置绝对较多的shuffle分区数，而后在运行时通过查看shuffle文件统计信息将相邻的小分区合并为较大的分区。

假如咱们运行如下SQL：

SELECT max(i)FROM tbl GROUP BY j

tbl表的输出数据相当小，所以在分组之前只有两个分区。咱们把初始的shuffle分区数设置为5，因而在shuffle的时候数据被打乱到5个分区中。如果没有AQE，Spark将启动5个task来实现最初的聚合。然而，这里有三个十分小的分区，为每个分区启动一个独自的task将是一种节约。

应用AQE之后，Spark将这三个小分区合并为一个，因而，最终的聚合只须要执行3个task，而不是5个task。

动静调整join策略

Spark反对多种join策略（如broadcast hash join、shuffle hash join、sort merge join），通常broadcast hash join是性能最好的，前提是参加join的一张表的数据可能装入内存。因为这个起因，当Spark预计参加join的表数据量小于播送大小的阈值时，它会将join策略调整为broadcast hash join。然而，很多状况都可能导致这种大小预计出错——例如存在一个十分有选择性的过滤器。

为了解决这个问题，AQE当初依据最准确的连贯关系大小在运行时从新布局join策略。在上面的示例中能够看到join的右侧比估计值小得多，并且小到足以进行播送，因而在AQE从新优化之后，动态打算的sort merge join会被转换为broadcast hash join。

对于在运行时转换的broadcast hash join，咱们能够进一步将惯例的shuffle优化为本地化shuffle来缩小网络流量。

动静优化数据歪斜的join

当数据在集群中的分区之间散布不均时，就会产生数据歪斜。重大的歪斜会显著升高查问性能，特地是在进行join操作时。AQE歪斜join优化从shuffle文件统计信息中自动检测到这种歪斜。而后，它将歪斜的分区宰割成更小的子分区，这些子分区将别离从另一端连贯到相应的分区。

假如表A join 表B，其中表A的分区A0外面的数据显著大于其余分区。

skew join optimization将把分区A0分成两个子分区，并将每个子分区join表B的相应分区B0。

如果没有这个优化，将有四个工作运行sort merge join，其中一个工作将破费十分长的工夫。在此优化之后，将有5个工作运行join，但每个工作将破费大致相同的工夫，从而取得总体更好的性能。

AQE查问打算

AQE查问打算的一个次要区别是，它通常随着执行的停顿而演变。引入了几个AQE特定的打算节点，以提供无关执行的更多详细信息。

此外，AQE应用了一种新的查问打算字符串格局，能够显示初始和最终的查问执行打算。

|| AdaptiveSparkPlan节点

利用了AQE的查问通常有一个或多个AdaptiveSparkPlan节点作为每个查问或子查问的root节点。在执行之前或期间，isFinalPlan标记将显示为false。查问实现后，此标记将变为true，并且AdaptiveSparkPlan节点下的打算将不再变动。

|| CustomShuffleReader节点

CustomShuffleReader节点是AQE优化的要害。它能够依据在shuffle map stage收集的统计信息动静调整shuffle后的分区数。在Spark UI中，用户能够将鼠标悬停在该节点上，以查看它利用于无序分区的优化。当CustomShuffleReader的标记为coalesced时，示意AQE已依据指标分区大小在shuffle后检测并合并了小分区。此节点的详细信息显示合并后的无序分区数和分区大小。

当CustomShuffleReader的标记为"skewed"时，这意味着AQE在排序合并连贯操作之前检测到一个或多个分区中的数据歪斜。此节点的详细信息显示了歪斜分区的数量以及从歪斜分区拆分的新分区的总数。

coalesced和skewed也能够同时产生：

|| 检测join策略扭转

通过比拟AQE优化前后查问打算join节点的变动，能够辨认join策略的变动。在dbr7.3中，AQE查问打算字符串将包含初始打算（利用任何AQE优化之前的打算）和以后或最终打算。这样能够更好地理解利用于查问的优化AQE。

Spark UI将只显示以后打算。为了查看应用Spark UI的成果，用户能够比拟查问执行之前和执行实现后的打算图：

|| 检测歪斜join

歪斜连贯优化的成果能够通过连贯节点名来辨认。

在Spark UI中：

在查问打算字符串中：

AQE的TPC-DS体现

在咱们应用TPC-DS数据和查问的试验中，自适应查问执行的查问性能进步了8倍，32个查问的性能进步了1.1倍以上。上面是通过AQE取得的10个TPC-DS查问性能进步最多的图表。

这些改良大部分来自动静分区合并和动静join策略调整，因为随机生成的TPC-DS数据没有歪斜。在理论生产中，AQE 带来了更大的性能晋升。

启用AQE

能够通过设置参数spark.sql.adaptive为true来启用AQE（在Spark3.0中默认为false）。

如果查问满足以下条件倡议启用：

不是一个流查问

至多蕴含一个exchange（通常在有join、聚合或窗口操作时）或是一个子查问

通过缩小查问优化对动态统计的依赖，AQE解决了Spark基于老本优化的最大难题之一：统计信息收集开销和预计精度之间的均衡。

为了获得最佳的预计精度和布局后果，通常须要保护具体的、最新的统计信息，其中一些统计信息的收集老本很高，比方列直方图，它可用于进步选择性和基数预计或检测数据歪斜。AQE在很大水平上打消了对此类统计数据的须要，以及手动调优工作的须要。

除此之外，AQE还使SQL查问优化对于任意udf和不可预测的数据集更改（例如数据大小的忽然减少或缩小、频繁的和随机的数据歪斜等）更有弹性。不再须要提前"晓得"您的数据。随着查问的运行，AQE将计算出数据并改良查问打算，进步查问性能以取得更快的剖析和零碎性能。