成品网站管理系统,网络工程和软件工程哪个好,做模型找三视图那些网站,超低价的锦州网站建设在前一篇Spark SQL 执行计划解析源码分析中#xff0c;笔者分析了Spark SQL 执行计划的解析#xff0c;很多文章甚至Spark相关的书籍在讲完执行计划解析之后就开始进入讲解Stage切分和调度Task执行#xff0c;每个概念之间没有强烈的关联#xff0c;因此这中间总感觉少了点…在前一篇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当中扮演着如此重要的角色。
