Spark源码分析-spark集群启动及任务执行

注： 因为基于Akka的Actor的RPC版本相对容易理解一点，本文分析使用的Spark版本如下：

<dependency>
    <groupId>org.apache.spark</groupId>
    <artifactId>spark-core_2.10</artifactId>
    <version>1.3.1</version>
</dependency>

集群启动过程分析

Master

Master进程通过start-master.sh启动一个后台进程，程序入口是Master类的main方法
该main方法的作用是创建一个ActorSystem，并创建一个master的actor，创建master的actor时，执行Master的构造方法做一些初始化的工作，同时执行Actor生命周期的prestart()方法

Worker

Worker过程也同Master，同时由于spark-env.sh的配置文件中有Master启动的服务器地址和端口，Worker在prestart()方法中会获取Master的AkkaSystem的URL并创建master actor的引用，并向Master注册自己
大体过程如下图：

Spark-Submit提交任务

我们以提交简单的WordCount任务为例：

object WordCount {

  def main(args: Array[String]) {
    val conf = new SparkConf().setAppName("WordCount")
    val sc = new SparkContext(conf);
    sc.textFile("hdfs://xxxx/input").flatMap(_.split(" ")).map((_,1)).reduceByKey(_+_).saveAsTextFile("hdfs://xxxx/output");
    sc.stop()
  }

}

并通过如下方式提交任务：

spark-submit.sh --class com.xxx.xxx.WordCount --master spark://127.0.0.1:7070 —executor-memory 2G —total-executor-cores 4 /xxx/xxx/xxx/wordcount.jar

spark-submit.sh脚本会启动进程调用SparkSubmit类的入口main方法，SparkSubmit的main方法中主要通过反射实际任务类，在本线程中执行该任务类的main方法，从而进入到用户任务逻辑中

用户的任务逻辑中，SparkConf是初始化相关的参数，核心逻辑在SparkContext中

SparkContext初始化逻辑

1.Executor调度及启动过程分析

SparkContext是Spark功能的入口，在new SparkContext对象是，SparkContext做了很多初始化的工作，最主要的是创建taskScheduler和dagScheduler

整个过程简单描述：

1. sparkcontext创建taskSchedulerImpl对象，然后根据不同的资源调度模型初始化不同的schedulerBackend及调度模型
2. 创建DAGScheduler对象，dagScheduler在初始化过程中创建一个DAGSchedulerEventProcessLoop对象，该对象内部包含一个阻塞队列，dagScheduler初始化的最后一行调用eventprocessloop.start()方法，该方法执行启动一个守护线程不断监控队列的元素取出处理。
3. 执行taskSchedulerImpl对象的start方法，同时执行对应的backend的start，此处以SparkDeploySchedulerBackend为例，backend将需要启动的executor类名及相关的executor的启动参数封装到ApplicationDescription对象中，同时创建一个AppClient对象，AppClient里有一个ClientActor，在AppClient执行start时会初始化ClientActor并给Master发送RegisterApplication的消息，同时把ApplicationDesc带过去。
4. Master处理Application注册的消息后返回注册完成的消息给ClientActor，并调用自己的scheduler()方法开始按照策略给worker分配该Application的执行Executor，并把对应的消息发送给worker让worker启动Executor
5. Worker接收到Master发送的LaunchExecutor命令后，根据appDesc的描述信息初始化相关的启动参数，然后启动一个线程，通过fetchAndRunExecutor()方法启动一个Executor的子进程，同时向Master汇报当前启动的Executor的状态

至此，由Master调度，分配给Worker启动Executor消息请求工作完成，下面开始分析Executor进程真正启动过程中做了哪些事情。

Executor子进程启动过程分析

以Spark Standalone集群为例，Spark集群启动的Executor是CoarseGrainedExecutorBackend的实例，在执行任务时jps对应的worker机器查看进程，能看到名为CoarseGrainedExecutorBackend的进程名，CoarseGrainedExecutorBackend进程启动的入口自然也是对应的main方法。

CoarseGrainedExecutorBackend启动初始化过程步骤如下：

1. 入口main方法首先构建自己的ActorSystem，然后根据启动参数传进来的dirverUrl构建对应的DriverActor的ActorRef引用，然后向driver发送RegisterExecutor注册自己。
2. driver收到消息后返回给ExecutorBackend确认注册消息后，ExecutorBackend创建一个Executor类的对象，内部构造方法构建一个线程池用于任务(TaskRunner封装)的执行，并持续向driver端的TaskScheduler和DAGScheduler发送任务心跳信息。
3. 创建一个WorkerWatcher的Actor向Worker发送心跳信息。

至此，new SparkContext()的过程就处理完成了，下面开始执行具体的任务。

Task执行过程分析

下面着重分析一下这一行语句的执行过程

sc.textFile("hdfs://xxxx/input").flatMap(_.split(" ")).map((_,1)).reduceByKey(_+_).saveAsTextFile("hdfs://xxxx/output");

构建RDD及关系过程

1. textFile()会构建一个HadoopRDD利用Hadoop中的FileInputFormat对输入文件进行分片处理，然后调用map()方法生成一个MapPartitionsRDD对每个分片的数据进行迭代读取到内存。所以textFile()方法会构建两个RDD：HadoopRDD和MapPartitionsRDD
2. flatMap()方法会对前面获取的数据按照分区做Scala的flatMap压平操作，所以也是通过MapPartitionsRDD读取并处理数据。该方法构建一个MapPartitionsRDD
3. map()方法获取压平后的数据进行进一步迭代处理，也是构建一个MapPartitionsRDD
4. reduceByKey()方法调用时会先通过implicit
   conversion（隐式转换）把普通的RDD扩展成PairRDDFunctions，进而调用扩展的reduceByKey方法，reduceByKey调用底层的combineByKey方法，生成一个ShuffledRDD返回，ShuffleRDD类重载了父类的getDependencies()方法，返回一个ShuffleDependency，也就是常说的宽依赖
5. saveAsTextFile()方法会调用RDD的mapPartitions()方法迭代分片处理数据，内部会构建一个MapPartitionsRDD。到目前还只是构建RDD及对应的依赖关系，构建完成RDD及对应关系后开始真正的提交任务并执行的操作。

任务调度及提交执行

正如spark手册描述的，Transform方法是定义RDD的操作逻辑和关系，并没有做任何实际的数据操作；Action方法才开始做真正的任务调度和提交。本例中的saveAsTextFile就是一个Action方法，前面构建RDD部分逻辑暂时忽略，从提交任务逻辑开始分析。

具体逻辑如下：

1. 以PairRDDFunctions的saveAsHadoopDataset作为任务提交的入口，调用RDD内部成员SparkContext的runJob()方法。
2. 调用对应dagScheduler的runJob()方法，最终是通过在submitJob中实例化一个JobSubmitted的事件对象，扔到DAGSchedulerEventProcessLoop的阻塞队列，DAGSchedulerEventProcessLoop在创建SparkContext时已经启动了一个线程循环处理接收到的事件，事件处理逻辑通过模式匹配，最终调用dagScheduler的handleJobSubmitted方法。
3. handleJobSubmitted内通过迭代RDD的父依赖的递归调用，判断父依赖是否为ShuffleDependency来划分stage，同时生成stage的依赖关系。
4. 提交stage，迭代从第一个stage开始处理并构建stage对应的task：根据stage是否包含shuffle操作确认是ShuffleMapTask任务还是普通的ResultTask，并根据分区数生成对应多个task。然后把该stage分解成的一组tasks封装到一个taskset并提交给TaskSchedulerImpl处理。
5. taskScheduler将taskset封装成TaskSetManager并添加到activeTaskSets的HashMap结构中，然后通过CoarseGrainedSchedulerBackend调用reviveOffers方法向其内部类DriveActor发送ReviveOffers消息，触发DriveActor的makeOffers操作进行Executor的任务分配；makeOffers内先调用taskScheduler的resourceOffers基于数据就近原则，给每个task分配合适的executor（基于每个task对应partition的位置信息及executor向给DriverActor上报的信息）。
6. 根据前面计算的调度结果，序列化task，并向相应executor发送对应的LaunchTask信息
7. ExecutorBackend接收到LaunchTask的消息，反序列化task描述信息，并初始化一个TaskRunner的线程对象，交给内部executor的线程池处理task；线程执行task的run方法，对应到Task具体实现类ShuffleMapTask或ResultTask的runTask()方法，执行具体的业务逻辑。
8. executorBackend获取到task的执行情况，并通过StatusUpdate消息发送给DriverActor。

至此，任务的提交及执行过程分析完成。

个人学习，经验原因可能部分有误，欢迎指正
转载请注明出处：http://blog.csdn.net/jamesjxin/article/details/74958908