Adaptive Execution 让 Spark SQL 更智能更高效
|
为了办理这个题目，Spark 新增接口，一次 Shuffle Read 可以读多个 Partition 的数据。如下图所示，Task 1 通过一轮哀求即可同时读取 Task 0 内 Partition 0、1 和 2 的数据，镌汰了收集哀求数目。同时 Mapper 0 一次性读取并返回三个 Partition 的数据，相等于次序 IO，从而晋升了机能。
因为 Adaptive Execution 的自动配置 Reducer 是由 ExchangeCoordinator 按照 Shuffle Write 统计信息抉择的，因此纵然在统一个 Job 中差异 Shuffle 的 Reducer 个数都可以纷歧样，从而使得每次 Shuffle 都尽也许最优。 上文 原有 Shuffle 的题目 一节中的例子，在启用 Adaptive Execution 后，三次 Shuffle 的 Reducer 个数从原本的所有为 3 变为 2、4、3。
2.4 行使与优化要领 可通过 spark.sql.adaptive.enabled=true 启用 Adaptive Execution 从而启用自动配置 Shuffle Reducer 这一特征 通过 spark.sql.adaptive.shuffle.targetPostShuffleInputSize 可配置每个 Reducer 读取的方针数据量，其单元是字节，默认值为 64 MB。上文例子中，假如将该值配置为 50 MB，最终结果如故如上文所示，而不会将 Partition 0 的 60MB 拆分。详细缘故起因上文已声名 3 动态调解执行打算 3.1 牢坚强行打算的不敷 在不开启 Adaptive Execution 之前，执行打算一旦确定，纵然发明后续执行打算可以优化，也不行变动。如下图所示，SortMergJoin 的 Shuffle Write 竣事后，发明 Join 一方的 Shuffle 输出只有 46.9KB，如故继承执行 SortMergeJoin
此时完全可将 SortMergeJoin 改观为 BroadcastJoin 从而进步整体执行服从。 3.2 SortMergeJoin 道理 SortMergeJoin 是常用的漫衍式 Join 方法，它险些可行使于全部必要 Join 的场景。但有些场景下，它的机能并不是最好的。 SortMergeJoin 的道理如下图所示
3.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 （编辑：湖南网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
