共计 4657 个字符，预计需要花费 12 分钟才能阅读完成。
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 将计算出数据并改良查问打算，进步查问性能以取得更快的剖析和零碎性能。