Spark Sql执行原理介绍

Spark SQL整体架构

从上图可见，无论是直接使用 SQL 语句还是使用 DataFrame，都会经过如下步骤转换成 DAG 对 RDD 的操作

1） Parser 解析 SQL，生成 Unresolved Logical Plan

在Unresolved Logical Plan中，不知道涉及表是什么类型，数据存在何处，表的结构是什么；
这一步主要完成词法和语法解析，生成解析树

2）由 Analyzer 结合 Catalog 信息生成 Resolved Logical Plan

Catalog中包括表名称、表字段名称和字段类型等。借助catalog完成数据，类型，操作的绑定。

有了这些信息，已经可以直接将该 LogicalPlan 转换为 Physical Plan 进行执行。但每个用户提交的SQl质量不一样，直接执行会导致执行效率差距太大。因此需要进行SQL优化

3） Optimizer根据预先定义好的规则对 Resolved Logical Plan 进行优化并生成 Optimized Logical Plan

基于预先定义好的规则也叫做RBO （Rule-based optimization），优化思路主要是减少参与计算的数据量以及计算本身的代价。

1）PushdownPredicate 是最常见的用于减少参与计算的数据量的方法
例如在两表进行 Join 操作，然后再 进行 Filter 操作。引入 PushdownPredicate 后，可先对两表进行 Filter 再进行 Join；此处的优化是 LogicalPlan 的优化，从逻辑上保证了将 Filter 下推后由于参与 Join 的数据量变少而提高了性能。
此外ColumnPruning 也是将选择的字段提前select出来减少计算量的方法。
2）ConstantFolding是减少计算本身代价的方法
例如select 100+80+math_score+english_score,如果不进行优化，那如果有一亿条记录，就会计算一亿次 100 + 80，非常浪费资源。因此可通过 ConstantFolding 将这些常量合并，从而减少不必要的计算，提高执行速度。

以上优化都是基于逻辑层面的优化，进而带来实际执行时物理效率的提高

4）Query Planner 将 Optimized Logical Plan 转换成多个 Physical Plan

5） CBO 根据 Cost Model 算出每个 Physical Plan 的代价并选取代价最小的 Physical Plan 作为最终的Physical Plan

BRO属于 LogicalPlan 的优化，所有优化均基于 LogicalPlan 本身的特点，未考虑数据本身的特点，也未考虑算子本身的代价。 因此CBO充分考虑了数据本身的特点（如大小、分布）以及操作算子的特点（中间结果集的分布及大小）及代价，从而更好的选择执行代价最小的物理执行计划，

6）Spark 以 DAG 的方法执行上述 Physical Plan 在执行 DAG 的过程中，Adaptive Execution 根据运行时信息动态调整执行计划从而提高执行效率

这一步还存在着将物理执行计划转变成可执行物理计划

参考：
https://www.cnblogs.com/qoix/p/9649310.html
https://blog.csdn.net/junerli/article/details/78607708
https://www.2cto.com/net/201805/742744.html
https://blog.csdn.net/junerli/article/details/78607708
https://blog.csdn.net/zhanglh046/article/details/78360980
https://www.cnblogs.com/moon0201/p/10415178.html