网站功能报价明细表网络营销成功案例分析

在前一篇Spark SQL 执行计划解析源码分析中，笔者分析了Spark SQL 执行计划的解析，很多文章甚至Spark相关的书籍在讲完执行计划解析之后就开始进入讲解Stage切分和调度Task执行，每个概念之间没有强烈的关联，因此这中间总感觉少了点什么，执行计划是如何触发执行的？是Spark自动触发的？还是由客户端的代码触发的？本文笔者为了解答这几个疑问，尝试进行了相关代码的分析。

物理计划都是继承自SparkPlan类，在研究如何触发执行计划之前我们来看一下最终的物理计划是实现逻辑是怎么样的，这里以SparkPlan的子类FileSourceScanExec作为列子来分析一下：

在非Columnar的模式下，普通的算子执行都是以重写doExecute方法来实现的，FileSourceScanExec同样也不例外，下面是FileSourceScanExec的doExecute方法：

我们可以看到doExecute方法的返回值是RDD[InternalRow], 这也是单个物理计划Node转化成RDD关键一步。到这里我们搞清楚了SparkPlan底层是依赖于RDD实现具体的逻辑，那么接下来我们分析一下Spark是如何将一个一个物理计划节点转换成一个一个RDD的。

首先Spark执行模型是火山模型（又叫迭代器模型），通过迭代器模型，Spark会先调用execute方法，execute方法会调用每个Node的doExecute，而从上面的分析我们可以得知每一个doExecute方法的返回类型都是RDD，因为就把每个单独的Node给串联起来了，具体的代码在SparkPlan.execute。

下面是一个简单查询对应的物理计划转换成RDD的大致逻辑：

到这里我们知道知道了多个物理计划Node会转换成多个RDD，而触发这个转换的则是下面的代码，调用了executedPlan.execute()，也就是触发executedPlan转换成RDD。
后续的逻辑就是以RDD来进行的，那么RDD又是如何计算的呢？我们知道RDD分为Transformation和Action两种类型的操作，而Transformation是惰性的，只有Action会触发计算，因此只有Action被调用的时候，RDD才会触发计算，对应的Spark的执行计划才会开始触发具体的逻辑执行。Action算子有很多中，我们可以以常见的show、take等作为入口去分析源码，被调用的地方大部分都在DataSet里面，可以一一对应地查看。

以上的逻辑仅仅是分析Spark地物理计划是如何触发执行的，还没到切分Stage以及调度Task的阶段。从这一部分的源码分析，我们可以清楚的了解到Spark的物理计划是被火山模型如何串联起来的，以及底层的RDD是如何把一一对应的，这对于理解每一个物理执行计划的Node至关重要。无论是SQL还是PySpark等DataFrame操作，最终都会转换成RDD的逻辑。

题外话：笔者之前都是一直只是知道Spark中RDD的概念，但是并没有很深刻的理解RDD的一个重要性，通过本文的分析，才清楚的认识到RDD在Spark当中扮演着如此重要的角色。