动态调整spark sql执行计划

1 固定执行计划的不足

在不开启 Adaptive Execution 之前，执行计划一旦确定，即使发现后续执行计划可以优化，也不可更改。如下图所示，SortMergJoin 的 Shuffle Write 结束后，发现 Join 一方的 Shuffle 输出只有 46.9KB，仍然继续执行 SortMergeJoin

此时完全可将 SortMergeJoin 变更为 BroadcastJoin 从而提高整体执行效率。

2 SortMergeJoin 原理

SortMergeJoin 是常用的分布式 Join 方式，它几乎可使用于所有需要 Join 的场景。但有些场景下，它的性能并不是最好的。

SortMergeJoin 的原理如下图所示

• 将 Join 双方以 Join Key 为 Key 按照 HashPartitioner 分区，且保证分区数一致

• Stage 0 与 Stage 1 的所有 Task 在 Shuffle Write 时，都将数据分为 5 个 Partition，并且每个 Partition 内按 Join Key 排序

• Stage 2 启动 5 个 Task 分别去 Stage 0 与 Stage 1 中所有包含 Partition 分区数据的 Task 中取对应 Partition 的数据。（如果某个 Mapper 不包含该 Partition 的数据，则 Redcuer 无须向其发起读取请求）。

• Stage 2 的 Task 2 分别从 Stage 0 的 Task 0、1、2 中读取 Partition 2 的数据，并且通过 MergeSort 对其进行排序

• Stage 2 的 Task 2 分别从 Stage 1 的 Task 0、1 中读取 Partition 2 的数据，且通过 MergeSort 对其进行排序

• Stage 2 的 Task 2 在上述两步 MergeSort 的同时，使用 SortMergeJoin 对二者进行 Join

3 BroadcastJoin 原理

当参与 Join 的一方足够小，可全部置于 Executor 内存中时，可使用 Broadcast 机制将整个 RDD 数据广播到每一个 Executor 中，该 Executor 上运行的所有 Task 皆可直接读取其数据。（本文中，后续配图，为了方便展示，会将整个 RDD 的数据置于 Task 框内，而隐藏 Executor）

对于大 RDD，按正常方式，每个 Task 读取并处理一个 Partition 的数据，同时读取 Executor 内的广播数据，该广播数据包含了小 RDD 的全量数据，因此可直接与每个 Task 处理的大 RDD 的部分数据直接 Join

根据 Task 内具体的 Join 实现的不同，又可分为 BroadcastHashJoin 与 BroadcastNestedLoopJoin。后文不区分这两种实现，统称为 BroadcastJoin

与 SortMergeJoin 相比，BroadcastJoin 不需要 Shuffle，减少了 Shuffle 带来的开销，同时也避免了 Shuffle 带来的数据倾斜，从而极大地提升了 Job 执行效率

同时，BroadcastJoin 带来了广播小 RDD 的开销。另外，如果小 RDD 过大，无法存于 Executor 内存中，则无法使用 BroadcastJoin

对于基础表的 Join，可在生成执行计划前，直接通过 HDFS 获取各表的大小，从而判断是否适合使用 BroadcastJoin。但对于中间表的 Join，无法提前准确判断中间表大小从而精确判断是否适合使用 BroadcastJoin

《Spark SQL 性能优化再进一步 CBO 基于代价的优化》一文介绍的 CBO 可通过表的统计信息与各操作对数据统计信息的影响，推测出中间表的统计信息，但是该方法得到的统计信息不够准确。同时该方法要求提前分析表，具有较大开销

而开启 Adaptive Execution 后，可直接根据 Shuffle Write 数据判断是否适用 BroadcastJoin

4 动态调整执行计划原理

如上文 SortMergeJoin 原理 中配图所示，SortMergeJoin 需要先对 Stage 0 与 Stage 1 按同样的 Partitioner 进行 Shuffle Write

Shuffle Write 结束后，可从每个 ShuffleMapTask 的 MapStatus 中统计得到按原计划执行时 Stage 2 各 Partition 的数据量以及 Stage 2 需要读取的总数据量。（一般来说，Partition 是 RDD 的属性而非 Stage 的属性，本文为了方便，不区分 Stage 与 RDD。可以简单认为一个 Stage 只有一个 RDD，此时 Stage 与 RDD 在本文讨论范围内等价）

如果其中一个 Stage 的数据量较小，适合使用 BroadcastJoin，无须继续执行 Stage 2 的 Shuffle Read。相反，可利用 Stage 0 与 Stage 1 的数据进行 BroadcastJoin，如下图所示

具体做法是

• 将 Stage 1 全部 Shuffle Write 结果广播出去

• 启动 Stage 2，Partition 个数与 Stage 0 一样，都为 3

• 每个 Stage 2 每个 Task 读取 Stage 0 每个 Task 的 Shuffle Write 数据，同时与广播得到的 Stage 1 的全量数据进行 Join

注：广播数据存于每个 Executor 中，其上所有 Task 共享，无须为每个 Task 广播一份数据。上图中，为了更清晰展示为什么能够直接 Join 而将 Stage 2 每个 Task 方框内都放置了一份 Stage 1 的全量数据

虽然 Shuffle Write 已完成，将后续的 SortMergeJoin 改为 Broadcast 仍然能提升执行效率

• SortMergeJoin 需要在 Shuffle Read 时对来自 Stage 0 与 Stage 1 的数据进行 Merge Sort，并且可能需要 Spill 到磁盘，开销较大

• SortMergeJoin 时，Stage 2 的所有 Task 需要取 Stage 0 与 Stage 1 的所有 Task 的输出数据（如果有它要的数据 ），会造成大量的网络连接。且当 Stage 2 的 Task 较多时，会造成大量的磁盘随机读操作，效率不高，且影响相同机器上其它 Job 的执行效率

• SortMergeJoin 时，Stage 2 每个 Task 需要从几乎所有 Stage 0 与 Stage 1 的 Task 取数据，无法很好利用 Locality

• Stage 2 改用 Broadcast，每个 Task 直接读取 Stage 0 的每个 Task 的数据（一对一），可很好利用 Locality 特性。最好在 Stage 0 使用的 Executor 上直接启动 Stage 2 的 Task。如果 Stage 0 的 Shuffle Write 数据并未 Spill 而是在内存中，则 Stage 2 的 Task 可直接读取内存中的数据，效率非常高。如果有 Spill，那可直接从本地文件中读取数据，且是顺序读取，效率远比通过网络随机读数据效率高

5 使用与优化方法

该特性的使用方式如下

• 当 spark.sql.adaptive.enabled 与 spark.sql.adaptive.join.enabled 都设置为 true 时，开启 Adaptive Execution 的动态调整 Join 功能

• spark.sql.adaptiveBroadcastJoinThreshold 设置了 SortMergeJoin 转 BroadcastJoin 的阈值。如果不设置该参数，该阈值与 spark.sql.autoBroadcastJoinThreshold 的值相等

• 除了本文所述 SortMergeJoin 转 BroadcastJoin，Adaptive Execution 还可提供其它 Join 优化策略。部分优化策略可能会需要增加 Shuffle。spark.sql.adaptive.allowAdditionalShuffle 参数决定了是否允许为了优化 Join 而增加 Shuffle。其默认值为 false