Adaptive Execution 让 Spark SQL 更智能更高效

当参与 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

3.4 动态调整执行计划原理

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

（编辑：惠州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!