1、流程解析

在该系列第二篇文章中介绍了spark sql整体的解析流程，我们知道整体的sql解析分为未解析的逻辑计划（Unresolved LogicalPlan）、解析后的逻辑计划（LogicalPlan）、优化后的逻辑计划（Optimized LogicalPlan）、物理计划（PhysiclPlan）等四个阶段。物理计划是sql转换执行的最后一个环节，过程比较复杂，其内部又分三个阶段，如下图所示：

这3个阶段所做的工作分别如下:

1）由SparkPlanner将各种物理计划策略（Strategy，可自定义扩展）作用于对应的LogicalPlan节点上，生成SparkPlan列表（注:一个 LogicalPlan 可能产生多种 SparkPlan）。

2）选取最佳的SparkPlan，在Spark3.0.1版本中的实现较为简单，在候选列表中直接用 next()方法获取第一个。

3）提交前进行准备工作，进行一些分区排序方面的处理，确保SparkPlan各节点能够正确执行，这一步通过 prepareForExecution方法调用若干规则（Rule，可自定义扩展）进行转换。

 注：如果对Strategy和Rule的扩展入口感兴趣的，可以参考该系列的第二篇文章：spark sql（二）sql解析流程扩展_Interest1_wyt的博客-CSDN博客

2、节点分类

根据SparkPlan的子节点数目，可以大致将其分为4类。分别为 LeafExecNode、UnaryExecNode、BinaryExecNode和其他不属于这3种子节点的类型。

1）LeafExecNode

叶子节点类型的物理执行计划不存在子节点，物理执行计划中与数据源相关的节点都属于该类型。LeafExecNode类型的SparkPlan负责对初始RDD的创建。例如：
angeExec会利用SparkContext中的parallelize方法生成给定范围内的64位数据的RDD；HiveTableScanExec会根据Hive数据表存储的HDFS信息直接生成HadoopRDD；FileSourceScanExec根据数据表所在的源文件生成FileScanRDD。

2）UnaryExecNode

UnaryExecNode类型的物理执行计划的节点是一元的，意味着只包含1个子节点，UnaryExecNode类型的物理计划也是数量最多的类型。UnaryExecNode节点的作用主要是对RDD进行转换操作。例如：
ProjectExec和FilterExec分别对子节点产生的RDD进行列剪裁与行过滤操作；
Exchange负责对数据进行重分区；
SampleExec对输入RDD中的数据进行采样；
SortExec按照一定条件对输入RDD中数据进行排序；
WholeStageCodegenExec类型的SparkPlan将生成的代码整合成单个Java函数。

3）BinaryExecNode

BinaryExecNode类型的SparkPlan具有两个子节点，这种二元类型的物理执行计划大多与数据的关联处理有关，比如常见的join处理。

4）其它节点

除上述3种类型的SparkPlan外，SparkSQL中还有许多其他类型的物理执行计划，如Union等。

3、源码追踪

spark sql物理计划这一块内容很杂，特别是还涉及分区与排序。所以理解起来很困难，本人也是处于知其然不知其所有然的尴尬状态，故下面通过源码的追踪串一下整体的逻辑。具体的细节则需要时间慢慢打磨。代码demo如下：

  def main(args: Array[String]): Unit = {

    //1、创建sparkSession
    val sparkSession = SparkSession.builder
      .appName("test")
      .master("local")
      .getOrCreate

    //2、编辑mysql连接参数
    val url: String = "jdbc:mysql://127.0.0.1:3306/olap"
    val table: String = "person"
    var prop: Properties = new Properties
    prop.put("user", "root")
    prop.put("password", "123456")

    //3、创建临时表
    val dataset: Dataset[Row] = sparkSession.read.format("mysql").jdbc(url, table, prop)
    dataset.toDF.createOrReplaceTempView("temp")

    //4、查询展示
    val dataset2: Dataset[Row] = sparkSession.sql("select id,name,birthday from temp")
    dataset2.show()

  }

前三部分主要是构建环境和创建临时表，这里不过多解释，我们从 第四部分查询开始追踪源码。因为大体流程在前面讲过，所以这里对于物理计划之前的流程简单介绍，在物理计划解析时进行详细介绍。首先是执行sql语句生成Dataset数据集（注意这里的数据集还没数据，只有在执行show方法时才会触发计算操作）：

 

 这里tracker是一个追踪器，追踪sql计划各个阶段的起止时间以及各个规则作用的时间段等。plan则是生成最基础的未解析的逻辑计划。最后通过ofRows返回一个Dataset数据集。我们接着到ofRows中查看：

 ofRows方法中首先是创建一个QueryExecution对象，这是很重要的一个对象，它包含了sql计划的各个阶段。其次是通过assertAnalyzed将未解析的逻辑计划转换为解析后的逻辑计划。最后封装成Dataset返回（此时的Dataset还没有数据，只有遇到action算子才会触发后续流程）。

最后一路返回到最后的demo代码中，接着从show方法开始看：

 

这里第一行代码是获取要展示数据的行数，第二行getRows则是获取具体的数据，所以进入getRows看一下：

 这里首先是重新生成一个Dataset数据集，随后对新数据集的数据字段的类型做一些转换——非日期字段统一转为字符串类型。然后执行select转换和take行动操作。select主要是基于逻辑计划做一些转换，不是此次的重点，感兴趣的自己看下。最后一步操作则是拼装返回结果，也不是重点。这里我们直接看下take的操作：

 

 这里withAction是一个高阶函数，乍一看可能不知道这个函数的执行逻辑。这里我大致介绍下：首先当前所在的类是Dataset，所以执行limit(n).queryExecution其实就是在当前数据集所对应的逻辑计划上加一层limit封装，然后返回当前sql计划的QueryExecution对象。至于最后的collectFromPlan则是一个函数，其当做参数传递到withAction方法中。这里我们接着到withAction中看一下：

这里的逻辑也是比较绕，首先最外层SQLExecution.withNewExecutionId还是一个高阶函数，其封装整个action操作。具体的封装细节不是此次重点，感兴趣的可以再看。这里关键操作只有两行代码，第一行是重置SparkPlan物理计划的度量信息，其次是从物理计划获取结果，注意这里的action对象其实是上一步我们传递进来的collectFromPlan方法。这里我们先看下比较重要的qe.executedPlan这个方法，它返回了物理计划SparkPlan。具体我们到源码中看一下：

 

 首先第一行是判断是否执行逻辑计划的优化，如果没执行则执行。其次是执行物理计划的准备，不过在这一步还有一个容易忽略的点。就是sparkPlan.clone方法。它是获取物理计划的第一步。我们进入源码看一下：

 createSparkPlan是物理计划的第一步，其将逻辑计划LogicPlan转换为SparkPlan。我们到plan方法中接着看下其具体的转换流程：

 

可以看到是将各种strategy应用到逻辑计划上，进而生成PhysicalPlan，随后通过map函数对PhysicalPlan进行简单的处理进而转换成SparkPlan。再回到createSparkPlan中可以看到，即使有多个物理计划返回，默认也只返回第一个物理计划进行使用（当前spark版本3.0.1）。至此我们获得了一个可用的SparkPlan物理计划。接着回到executedPlan属性方法中：

这里的QueryExecution.prepareForExecution，主要是将各种规则作用于物理计划上，使得所有逻辑计划树转换为物理算子树。我们接着回到withAction方法中。

 当我们获得了SparkPlan物理计划并重置物理计划的度量信息后，接着执行action操作，这里的action其实就是一开传进来的collectFromPlan方法，所以接着到该方法中查看一下：

在该方法中可以看到会调用物理计划的executeCollect方法。而这里的物理计划通过断点可以看到是一个CollectLimitExec算子对象，所以我们接着到该对象的方法中看一下：

 可以看到这里其实是调用WholeStageCodegenExec中的方法，而该对象其实是用于生成代码的。随后将代码发送到各个节点执行。后续是不是感觉不知道去哪追踪？去除代码生成和任务下发，其实后续剩下的内容不多，主要就是去哪拿数据。这里我们可以一层层展开WholeStageCodegenExec算子，看看其底层的RDD数据到底来自于哪：

 可以看到最底层RDD数据是JDBCRDD，而RDD最核心的就是其compute方法，所以我们直接看下JDBCRDD的compute方法：

可以看到其最终还是通过将语法树转换成sql语句，然后通过jdbc连接发送请求并获得数据。至此是不是感觉豁然开朗，原来sparksql底层也是用jdbc查询的。为了防止大家被误导，这里要介绍下，本文之所以最后是jdbc查询，是跟我查询mysql数据库有关的，如果你查的是文件或其它非数据库的源，最后的物理算子肯定不是通过jdbc去查。但是整个spark sql计划转换流程和物理计划执行过程都是一样的。后期想扩展或者排查问题也可以参考该流程。

至此，我们物理计划获取数据的整个流程就完全清晰了。后续还会有些其它文章进一步探讨spark sql中问题定位以及功能扩展的用法。

4、总结：

1）因为spark sql计划的转换执行，很多都是懒加载，所以有的时候加的断点会不生效。这个时候可以吧其它断点都放开，只在目标位置放一个断点。然后重启程序即可。

2）spark sql物理计划转换的内容真的太多，本文主要注重将整个流程穿起来，所以很多细节讲解的不够到位。感兴趣或者有需要的可以自己再看。

3）物理计划内部包含Physical、SparkPlan、PreparedSparkPlan三个小阶段。

4）spark 3.0.1版本物理计划即使有多个也是默认使用第一个

5）本文之所以最后是jdbc查询，是跟我查询mysql数据库有关的，如果你查的是文件或其它非数据库的源，最后的物理算子肯定不是通过jdbc去查。但是整个spark sql计划转换流程和物理计划执行过程都是一样的。后期想扩展或者排查问题也可以参考该流程。

参考文献：

《spark sql内核剖析》