Spark源码系列（三）作业运行过程

作业执行
上一章讲了RDD的转换，但是没讲作业的运行，它和Driver Program的关系是啥，和RDD的关系是啥？

官方给的例子里面，一执行collect方法就能出结果，那我们就从collect开始看吧，进入RDD，找到collect方法。

def collect(): Array[T] = {
val results = sc.runJob(this, (iter: Iterator[T]) => iter.toArray)
Array.concat(results: _*)
}
它进行了两个操作：

1、调用SparkContext的runJob方法，把自身的引用传入去，再传了一个匿名函数（把Iterator转换成Array数组）

2、把result结果合并成一个Array，注意results是一个Array[Array[T]]类型，所以第二句的那个写法才会那么奇怪。这个操作是很重的一个操作，如果结果很大的话，这个操作是会报OOM的，因为它是把结果保存在Driver程序的内存当中的result数组里面。

我们点进去runJob这个方法吧。

val callSite = getCallSiteval cleanedFunc = clean(func)dagScheduler.runJob(rdd, cleanedFunc, partitions, callSite, allowLocal, resultHandler, localProperties.get)rdd.doCheckpoint()

追踪下去，我们会发现经过多个不同的runJob同名函数调用之后，执行job作业靠的是dagScheduler，最后把结果通过resultHandler保存返回。

DAGScheduler如何划分作业
好的，我们继续看DAGScheduler的runJob方法，提交作业，然后等待结果，成功什么都不做，失败抛出错误，我们接着看submitJob方法。

val jobId = nextJobId.getAndIncrement()val func2 = func.asInstanceOf[(TaskContext, Iterator[_]) => _]// 记录作业成功与失败的数据结构，一个作业的Task数量是和分片的数量一致的，Task成功之后调用resultHandler保存结果。val waiter = new JobWaiter(this, jobId, partitions.size, resultHandler)eventProcessActor ! JobSubmitted(jobId, rdd, func2, partitions.toArray, allowLocal, callSite, waiter, properties)

走到这里，感觉有点儿绕了，为什么到了这里，还不直接运行呢，还要给eventProcessActor发送一个JobSubmitted请求呢，new一个线程和这个区别有多大？

不管了，搜索一下eventProcessActor吧，结果发现它是一个DAGSchedulerEventProcessActor，它的定义也在DAGScheduler这个类里面。它的receive方法里面定义了12种事件的处理方法，这里我们只需要看

JobSubmitted的就行，它也是调用了自身的handleJobSubmitted方法。但是这里很奇怪，没办法打断点调试，但是它的结果倒是能返回的，因此我们得用另外一种方式，打开test工程，找到scheduler目录下的DAGSchedulerSuite这个类，我们自己写一个test方法，首先我们要在import那里加上import org.apache.spark.SparkContext._ ，然后加上这一段测试代码。

View Code
这个例子的重点还是shuffle那块，另外也包括了map的多个转换，大家可以按照这个例子去测试下。

我们接着看handleJobSubmitted吧。

View Code
从上面这个方法来看，我们应该重点关注newStage方法、submitStage方法和submitWaitingStages方法。

我们先看newStage，它得到的结果叫做finalStage，挺奇怪的哈，为啥？先看吧

val id = nextStageId.getAndIncrement()val stage = new Stage(id, rdd, numTasks, shuffleDep, getParentStages(rdd, jobId), jobId, callSite)stageIdToStage(id) = stageupdateJobIdStageIdMaps(jobId, stage)stageToInfos(stage) = StageInfo.fromStage(stage)stage

可以看出来Stage也没有太多的东西可言，它就是把rdd给传了进去，tasks的数量，shuffleDep是空，parentStage。

那它的parentStage是啥呢？

View Code
它是通过不停的遍历它之前的rdd，如果碰到有依赖是ShuffleDependency类型的，就通过getShuffleMapStage方法计算出来它的Stage来。

那我们就开始看submitStage方法吧。

View Code
这个提交stage的过程是一个递归的过程，它是先要把父stage先提交，然后把自己添加到等待队列中，直到没有父stage之后，就提交该stage中的任务。等待队列在最后的submitWaitingStages方法中提交。

这里我引用一下上一章当中我所画的那个图来表示这个过程哈。

从getParentStages方法可以看出来，RDD当中存在ShuffleDependency的Stage才会有父Stage, 也就是图中的虚线的位置！

所以我们只需要记住凡是涉及到shuffle的作业都会至少有两个Stage，即shuffle前和shuffle后。

TaskScheduler提交Task
那我们接着看submitMissingTasks方法，下面是主体代码。

View Code
Task也是有两类的，一种是ShuffleMapTask，一种是ResultTask，我们需要注意这两种Task的runTask方法。最后Task是通过taskScheduler.submitTasks来提交的。

我们找到TaskSchedulerImpl里面看这个方法。

复制代码
override def submitTasks(taskSet: TaskSet) {
val tasks = taskSet.tasksthis.synchronized {
val manager = new TaskSetManager(this, taskSet, maxTaskFailures)
activeTaskSets(taskSet.id) = manager
schedulableBuilder.addTaskSetManager(manager, manager.taskSet.properties)
hasReceivedTask = true
}
backend.reviveOffers()
}
复制代码
调度器有两种模式，FIFO和FAIR，默认是FIFO, 可以通过spark.scheduler.mode来设置，schedulableBuilder也有相应的两种FIFOSchedulableBuilder和FairSchedulableBuilder。

那backend是啥?据说是为了给TaskSchedulerImpl提供插件式的调度服务的。

它是怎么实例化出来的，这里我们需要追溯回到SparkContext的createTaskScheduler方法，下面我直接把常用的3中类型的TaskScheduler给列出来了。

mode Scheduler Backend

cluster TaskSchedulerImpl SparkDeploySchedulerBackend

yarn-cluster YarnClusterScheduler CoarseGrainedSchedulerBackend

yarn-client YarnClientClusterScheduler YarnClientSchedulerBackend

好，我们回到之前的代码上，schedulableBuilder.addTaskSetManager比较简单，把作业集添加到调度器的队列当中。

我们接着看backend的reviveOffers，里面只有一句话driverActor ! ReviveOffers。真是头晕，搞那么多Actor，只是为了接收消息。。。

照旧吧，找到它的receive方法，找到ReviveOffers这个case，发现它调用了makeOffers方法，我们继续追杀！

def makeOffers() {
launchTasks(scheduler.resourceOffers(executorHost.toArray.map {case (id, host) => new WorkerOffer(id, host, freeCores(id))}))
}
从executorHost中随机抽出一些来给调度器，然后调度器返回TaskDescription，executorHost怎么来的，待会儿再说，我们接着看resourceOffers方法。

View Code
resourceOffers主要做了3件事：

1、从Workers里面随机抽出一些来执行任务。

2、通过TaskSetManager找出和Worker在一起的Task，最后编译打包成TaskDescription返回。

3、将Worker–>Array[TaskDescription]的映射关系返回。

我们继续看TaskSetManager的resourceOffer，看看它是怎么找到和host再起的Task，并且包装成TaskDescription。

通过查看代码，我发现之前我解释的和它具体实现的差别比较大，它所谓的本地性是根据当前的等待时间来确定的任务本地性的级别。

它的本地性主要是包括四类：PROCESS_LOCAL, NODE_LOCAL, RACK_LOCAL, ANY。

View Code
等待时间是可以通过参数去设置的，具体的自己查下面的代码。

View Code
下面继续看TaskSetManager的resourceOffer的方法，通过findTask来从Task集合里面找到相应的Task。

复制代码
findTask(execId, host, allowedLocality) match {
case Some((index, taskLocality)) => {
val task = tasks(index)
val serializedTask = Task.serializeWithDependencies(task, sched.sc.addedFiles, sched.sc.addedJars, ser)
　　val timeTaken = clock.getTime() - startTime
　　addRunningTask(taskId)
　　val taskName = “task %s:%d”.format(taskSet.id, index)
　　sched.dagScheduler.taskStarted(task, info)
　　return Some(new TaskDescription(taskId, execId, taskName, index, serializedTask))
}
复制代码
它的findTask方法如下：

View Code
从这个方面可以看得出来，Spark对运行时间还是很注重的，等待的时间越长，它就可能越饥不择食，从PROCESS_LOCAL一直让步到ANY，最后的最后，推测执行都用到了。

找到任务之后，它就调用dagScheduler.taskStarted方法，通知dagScheduler任务开始了，taskStarted方法就不详细讲了，它触发dagScheduler的BeginEvent事件，里面只做了2件事：

1、检查Task序列化的大小，超过100K就警告。

2、提交等待的Stage。

好，我们继续回到发布Task上面来，中间过程讲完了，我们应该是要回到CoarseGrainedSchedulerBackend的launchTasks方法了。

def makeOffers() {
launchTasks(scheduler.resourceOffers(executorHost.toArray.map {case (id, host) => new WorkerOffer(id, host, freeCores(id))}))
}
它的方法体是：

def launchTasks(tasks: Seq[Seq[TaskDescription]]) {  for (task <- tasks.flatten) {    freeCores(task.executorId) -= scheduler.CPUS_PER_TASK    executorActor(task.executorId) ! LaunchTask(task)  }}

通过executorId找到相应的executorActor，然后发送LaunchTask过去，一个Task占用一个Cpu。

注册Application
那这个executorActor是怎么来的呢？找呗，最后发现它是在receive方法里面接受到RegisterExecutor消息的时候注册的。通过搜索，我们找到CoarseGrainedExecutorBackend这个类，在它的preStart方法里面赫然找到了driver ! RegisterExecutor(executorId, hostPort, cores) 带的这三个参数都是在初始化的时候传入的，那是谁实例化的它呢，再逆向搜索找到SparkDeploySchedulerBackend！之前的backend一直都是它，我们看reviveOffers是在它的父类CoarseGrainedSchedulerBackend里面。

关系清楚了，在这个backend的start方法里面启动了一个AppClient，AppClient的其中一个参数ApplicationDescription就是封装的运行CoarseGrainedExecutorBackend的命令。AppClient内部启动了一个ClientActor，这个ClientActor启动之后，会尝试向Master发送一个指令actor ! RegisterApplication(appDescription) 注册一个Application。

别废话了，Ctrl +Shift + N吧，定位到Master吧。

复制代码
case RegisterApplication(description) => {
val app = createApplication(description, sender)
registerApplication(app)
persistenceEngine.addApplication(app)
sender ! RegisteredApplication(app.id, masterUrl)
schedule()
}
复制代码
它做了5件事：

1、createApplication为这个app构建一个描述App数据结构的ApplicationInfo。

2、注册该Application，更新相应的映射关系，添加到等待队列里面。

3、用persistenceEngine持久化Application信息，默认是不保存的，另外还有两种方式，保存在文件或者Zookeeper当中。

4、通过发送方注册成功。

5、开始作业调度。

关于调度的问题，在第一章《spark-submit提交作业过程》已经介绍过了，建议回去再看看，搞清楚Application和Executor之间的关系。

Application一旦获得资源，Master会发送launchExecutor指令给Worker去启动Executor。

进到Worker里面搜索LaunchExecutor。

复制代码
　　val manager = new ExecutorRunner(appId, execId, appDesc, cores_, memory_, self, workerId, host,
appDesc.sparkHome.map(userSparkHome => new File(userSparkHome)).getOrElse(sparkHome), workDir, akkaUrl, ExecutorState.RUNNING)
　executors(appId + “/” + execId) = manager
　 manager.start()
coresUsed += cores_
memoryUsed += memory_
masterLock.synchronized {
master ! ExecutorStateChanged(appId, execId, manager.state, None, None)
}
复制代码
原来ExecutorRunner还不是传说中的Executor，它内部是执行了appDesc内部的那个命令，启动了CoarseGrainedExecutorBackend，它才是我们的真命天子Executor。

启动之后ExecutorRunner报告ExecutorStateChanged事件给Master。

Master干了两件事：

1、转发给Driver，这个Driver是之前注册Application的那个AppClient

2、如果是Executor运行结束，从相应的映射关系里面删除

发布Task
上面又花了那么多时间讲Task的运行环境ExecutorRunner是怎么注册，那我们还是回到我们的主题，Task的发布。

发布任务是发送LaunchTask指令给CoarseGrainedExecutorBackend，接受到指令之后，让它内部的executor来发布这个任务。

这里我们看一下Executor的launchTask。

def launchTask(context: ExecutorBackend, taskId: Long, serializedTask: ByteBuffer) {
val tr = new TaskRunner(context, taskId, serializedTask)
runningTasks.put(taskId, tr)
threadPool.execute(tr)
}
TaskRunner是这里的重头戏啊！看它的run方法吧。

View Code
以上代码被我这些了，但是建议大家看看注释吧。

最后结果是通过statusUpdate返回的。

override def statusUpdate(taskId: Long, state: TaskState, data: ByteBuffer) {
driver ! StatusUpdate(executorId, taskId, state, data)
}
这回这个Driver又不是刚才那个AppClient，而是它的家长SparkDeploySchedulerBackend，是在SparkDeploySchedulerBackend的父类CoarseGrainedSchedulerBackend接受了这个StatusUpdate消息。

这关系真他娘够乱的。。

继续，Task里面走的是TaskSchedulerImpl这个方法。

scheduler.statusUpdate(taskId, state, data.value)
到这里，一个Task就运行结束了，后面就不再扩展了，作业运行这块是Spark的核心，再扩展基本就能写出来一本书了，限于文章篇幅，这里就不再深究了。

以上的过程应该是和下面的图一致的。

看完这篇文章，估计大家会云里雾里的，在下一章《作业生命周期》会把刚才描述的整个过程重新梳理出来，便于大家记忆，敬请期待！