Spark Scheduler模块源码分析之TaskScheduler和SchedulerBackend

　　本文是Scheduler模块源码分析的第二篇，第一篇Spark Scheduler模块源码分析之DAGScheduler主要分析了DAGScheduler。本文接下来结合Spark-1.6.0的源码继续分析TaskScheduler和SchedulerBackend。

一、TaskScheduler和SchedulerBackend类结构和继承关系

　　之所以把这部分放在最前面，是想让大家在阅读后续文章时对TaskScheduler和SchedulerBackend是什么有一个概念。因为有些方法是从父类继承的，如果不先把类结构梳理清楚，到后面遇到多个XXXScheduler或者XXXBackend时迷失方向。

1、TaskScheduler

　　其实，严格来说TaskScheduler是一个trait，打开org.apache.spark.scheduler.TaskScheduler就可以看到。在源码中真正使用的还是TaskScheduler的实现类。至于使用的是哪个实现类，和Spark的部署模式有关，本文中使用的是yarn-client模式，对应YarnScheduler类，第二部分创建TaskScheduler时会有分析。

　　TaskScheduler及其子类的类结构和继承关系，以及重要的变量和方法都列举在下面的UML图中，下图中只列出有具体实现的方法。

　　

　　

2、SchedulerBackend

　　这里说到的org.apache.spark.scheduler.SchedulerBackend也是一个trait，根据第二节SchedulerBackend类创建过程中的分析，从yarn-client模式下使用的YarnClientSchedulerBackend往上分析，类结构图如下

　　

　　从上图中可以看出yarn-client模式下使用的YarnClientSchedulerBackend类继承自一个ExecutorAllocationClient的trait，所以YarnClientSchedulerBackend可以与cluster manager联系，用于请求和kill Executor。同时也继承自SchedulerBackend trait，所以YarnClientSchedulerBackend也可以用于请求资源。

　　其实每一个SchedulerBackend的具体实现起到的作用基本相同，就是向当前等待分配计算资源的Task分配计算资源（即Executors），并且在分配的Executor上启动Task，完成计算的资源调度过程。

二、TaskScheduler和SchedulerBackend的创建

1、SparkContext#createTaskScheduler创建实例

　　在DAGScheduler中已经提到TaskScheduler和SchedulerBackend都是在SparkContext中同时生成的。

val (sched , ts) = SparkContext.createTaskScheduler(this, master) // 这里的master是"spark.master"参数的值，String类型
_schedulerBackend = sched//生成 schedulerBackend
_taskScheduler = ts//生成 taskScheduler
_taskScheduler .start()

　　进入到SparkContext.createTaskScheduler方法中，该方法中根据master类型，生成不同的TaskScheduler和SchedulerBackend实例，下面仍然以“yarn-client”模式进行分析，其他模式请进入该方法中查看。

master match { // 获取master的类型
case "yarn-client" =>
  val scheduler = try {
    val clazz = Utils.classForName( "org.apache.spark.scheduler.cluster.YarnScheduler" )
    val cons = clazz.getConstructor( classOf[SparkContext])
    // yarn-client模式，生成一个YarnScheduler类型的scheduler实例
    cons.newInstance(sc).asInstanceOf[TaskSchedulerImpl]
  } catch {
    case e: Exception => {
      throw new SparkException( "YARN mode not available ?" , e)
    }
  }

  val backend = try {
    val clazz =
      Utils.classForName( "org.apache.spark.scheduler.cluster.YarnClientSchedulerBackend" )
      // yarn-client模式，生成一个YarnClientSchedulerBackend实例
    val cons = clazz.getConstructor( classOf[TaskSchedulerImpl] , classOf [SparkContext])
    cons.newInstance(scheduler, sc).asInstanceOf[CoarseGrainedSchedulerBackend]
  } catch {
    case e: Exception => {
      throw new SparkException( "YARN mode not available ?" , e)
    }
  }
  scheduler.initialize(backend)
  (backend, scheduler)
}

　　从上面代码中可以看到“yarn-client”模式下，scheduler的类型是org.apache.spark.scheduler.cluster.YarnScheduler，backend的类型是org.apache.spark.scheduler.cluster.YarnClientSchedulerBackend。

2、构建调度池

　　从上面代码中可以看到，在生成这两个对象后，接下来将backend传入scheduler的初始化方法中进行初始化，TaskSchedulerImpl.initialize方法中主要是根据调度模式初始化调度池，关于Spark调度模式，已经在Spark调度模式-FIFO和FAIR中有详细的分析。

3、Application的提交

　　回到SparkContext，在TaskScheduler和SchedulerBackend的具体实例构建后，调用TaskSchedulerImpl.start方法，启动taskScheduler。如果启动了speculative功能(即设置spark.speculation=true)的话，会后台启动一个线程检查符合speculation条件的task。在TaskSchedulerImpl.start方法中，调用backend.start方法，启动schedulerBackend。在YarnClientSchedulerBackend.start方法中，根据配置参数生成一个Client类型的对象，然后调用Client.submitApplication方法，提交该Application.

　　YarnClientSchedulerBackend#start方法

  override def start() {
    val driverHost = conf.get("spark.driver.host") // 获取driver的IP地址
    val driverPort = conf.get("spark.driver.port") // 获取driver的端口号
    val hostport = driverHost + ":" + driverPort
    sc.ui.foreach { ui => conf.set("spark.driver.appUIAddress", ui.appUIAddress) } // 为对应UI地址绑定ui对象

    val argsArrayBuf = new ArrayBuffer[String]() // 获取启动参数
    argsArrayBuf += ("--arg", hostport)
    argsArrayBuf ++= getExtraClientArguments

    logDebug("ClientArguments called with: " + argsArrayBuf.mkString(" "))
    val args = new ClientArguments(argsArrayBuf.toArray, conf)
    totalExpectedExecutors = args.numExecutors // 获取启动时指定的Executor个数
    client = new Client(args, conf) // 生成driver端的client
    appId = client.submitApplication() // 通过client提交application

    super.start() // 最终调用了CoarseGrainedSchedulerBackend中的start方法

    waitForApplication() // 等待Application开始运行

    if (conf.contains("spark.yarn.credentials.file")) {
      YarnSparkHadoopUtil.get.startExecutorDelegationTokenRenewer(conf)
    }
    // 启动一个监控线程，当SparkContext结束或者该Application在Yarn上运行结束，这个线程才会结束
    monitorThread = asyncMonitorApplication()
    monitorThread.start()
  }

　　有关Application的提交与监控，有兴趣的话，可以从YarnClientSchedulerBackend#start方法开始进一步的分析。

三、Task的提交

　　在Spark Scheduler模块源码分析之DAGScheduler中提到，DAGScheduler完成对Stage的划分后，会提交Stage。从这里开始，继续从上一篇文章最后的四.3 DAGScheduler.submitMissingTasks方法开始进行分析。

1、DAGScheduler#submitMissingTasks

　　这个方法比较长，这里只列举出源代码中的主要逻辑，搞清楚DAGScheduler提交Stage时如何开始对Task的提交的。

  private def submitMissingTasks(stage: Stage, jobId: Int) {
    //取得当前Stage需要计算的partition
    val partitionsToCompute: Seq[Int] = stage.findMissingPartitions()
    ...
    // 将当前stage存入running状态的stage列表中
    runningStages += stage
    // 判断当前stage是ShuffleMapStage还是ResultStage
    stage match {
      case s: ShuffleMapStage =>
        outputCommitCoordinator.stageStart(stage = s.id, maxPartitionId = s.numPartitions - 1)
      case s: ResultStage =>
        outputCommitCoordinator.stageStart(
          stage = s.id, maxPartitionId = s.rdd.partitions.length - 1)
    }
    ...
    // 向listenerBus提交StageSubmitted事件
    listenerBus.post(SparkListenerStageSubmitted(stage.latestInfo, properties))
    ...
    // 根据stage的类型获取其中包含的task
    val tasks: Seq[Task[_]] = try {
      stage match {
        // ShuffleMapStage中对应的是ShuffleMapTask
        case stage: ShuffleMapStage =>
          partitionsToCompute.map { id =>
            val locs = taskIdToLocations(id)
            val part = stage.rdd.partitions(id)
            new ShuffleMapTask(stage.id, stage.latestInfo.attemptId,
              taskBinary, part, locs, stage.internalAccumulators)
          }
        // ResultStage中对应的是ResultTask
        case stage: ResultStage =>
          val job = stage.activeJob.get
          partitionsToCompute.map { id =>
            val p: Int = stage.partitions(id)
            val part = stage.rdd.partitions(p)
            val locs = taskIdToLocations(id)
            new ResultTask(stage.id, stage.latestInfo.attemptId,
              taskBinary, part, locs, id, stage.internalAccumulators)
          }
      }
    }
    ...
  if (tasks.size > 0) { // 如果当前Stege中有task
      logInfo("Submitting " + tasks.size + " missing tasks from " + stage + " (" + stage.rdd + ")")
      stage.pendingPartitions ++= tasks.map(_.partitionId)
      logDebug("New pending partitions: " + stage.pendingPartitions)
      // 根据tasks生成TaskSet，然后通过TaskScheduler.submitTasks方法提交TaskSet
      taskScheduler.submitTasks(new TaskSet(
        tasks.toArray, stage.id, stage.latestInfo.attemptId, jobId, properties))
      stage.latestInfo.submissionTime = Some(clock.getTimeMillis())
    } else { // 如果当前Stege中不包含task
      // 由于前面已经向listenerBus中提交了StageSubmitted事件，现在这个Stege中没有task运行
      // 则正常流程时，该stage不会被标记为结束。那么需要手动指定该stege为finish状态。
      markStageAsFinished(stage, None)
      // log中的显示信息
      val debugString = stage match {
        case stage: ShuffleMapStage =>
          s"Stage ${stage} is actually done; " +
            s"(available: ${stage.isAvailable}," +
            s"available outputs: ${stage.numAvailableOutputs}," +
            s"partitions: ${stage.numPartitions})"
        case stage : ResultStage =>
          s"Stage ${stage} is actually done; (partitions: ${stage.numPartitions})"
      }
      logDebug(debugString)
    }
  }

　　这个方法的主要过程和逻辑都已经在源码注释中进行了分析，在提交Stage时，对于不同的ShuffleMapStage和ResultStage，有不同的处理逻辑。最终根据Stage对于的rdd partition生成tasks组，然后通过TaskScheduler.submitTasks方法，将tasks生成的TaseSet进行提交。

　　这里面有一点需要注意的是，在Stage提交时，会向LiveListenerBus发送一个SparkListenerStageSubmitted事件，正常情况下，随着Stage中的task运行结束，会最终将Stage设置成完成状态。但是，对于空的Stage，不会有task运行，所以该Stage也就不会结束，需要在提交时手动将Stage的运行状态设置成Finished。

2、TaskSchedulerImpl#submitTasks

　　上一步中生成的TaskSet对象传入该方法中，那么首先看一下TaskSet的结构。在TaskSet中，有一个Task类型的数组包含当前Stage对应的Task，然后就是一些stageId，stageAttemptId，以及priority等信息。从前面代码中可以看到，这里传入的优先级是jobId，越早提交的job越优先运行。

private[spark] class TaskSet(
    val tasks: Array[Task[_]],
    val stageId: Int,
    val stageAttemptId: Int,
    val priority: Int,
    val properties: Properties) {
  val id: String = stageId + "." + stageAttemptId

  override def toString: String = "TaskSet " + id
}

　　接下来进入TaskScheduler.submitTasks方法，主要的过程都在注释中。这里需要再分析一些TaskSetManager的zombie状态。isZombie的默认值为false，进入true状态有两种情况：TaskSetManager中的tasks都执行成功了，或者这些tasks不再需要执行(比如当前stage被cancel)。之所以在tasks都执行成功后将该TaskSetManager设置为zombie状态而不是直接清除该对象，是为了从TaseSetManager中获取task的运行状况信息。

　　那么对于isZombie为false的TaseSetManager，即表示其中的tasks仍然需要执行，如果对于当前stage，有一个taskSet正在执行，并且此次提交的taskSet和正在执行的那个不是同一个，那么就会出现同一个Stage执行两个不同的TaskSet的状况，这是不允许的。

  override def submitTasks(taskSet: TaskSet) {
    val tasks = taskSet.tasks
    logInfo("Adding task set " + taskSet.id + " with " + tasks.length + " tasks")
    this.synchronized {
      // 生成一个TaskSetManager类型对象，
      // task最大重试次数，由参数spark.task.maxFailures设置，默认为4
      val manager = createTaskSetManager(taskSet, maxTaskFailures)
      val stage = taskSet.stageId
      // key为stageId，value为一个HashMap，这个HashMap中的key为stageAttemptId，value为TaskSetManager对象
      val stageTaskSets =
        taskSetsByStageIdAndAttempt.getOrElseUpdate(stage, new HashMap[Int, TaskSetManager])
      stageTaskSets(taskSet.stageAttemptId) = manager
      // 如果当前这个stageId对应的HashMap[Int, TaskSetManager]中存在某个taskSet
      // 使得当前的taskSet和这个taskSet不是同一个，并且当前这个TaskSetManager不是zombie进程
      // 即对于同一个stageId，如果当前这个TaskSetManager不是zombie进程，即其中的tasks需要运行，
      // 并且对当前stageId，有两个不同的taskSet在运行
      // 那么就应该抛出异常，确保同一个Stage在正常运行情况下不能有两个taskSet在运行
      val conflictingTaskSet = stageTaskSets.exists { case (_, ts) =>
        ts.taskSet != taskSet && !ts.isZombie
      }
      if (conflictingTaskSet) {
        throw new IllegalStateException(s"more than one active taskSet for stage $stage:" +
          s" ${stageTaskSets.toSeq.map{_._2.taskSet.id}.mkString(",")}")
      }
      // 根据调度模式生成FIFOSchedulableBuilder或者FairSchedulableBuilder，将当前的TaskSetManager提交到调度池中
      schedulableBuilder.addTaskSetManager(manager, manager.taskSet.properties)

      if (!isLocal && !hasReceivedTask) {
        starvationTimer.scheduleAtFixedRate(new TimerTask() {
          override def run() {
            if (!hasLaunchedTask) {
              logWarning("Initial job has not accepted any resources; " +
                "check your cluster UI to ensure that workers are registered " +
                "and have sufficient resources")
            } else {
              this.cancel()
            }
          }
        }, STARVATION_TIMEOUT_MS, STARVATION_TIMEOUT_MS)
      }
      hasReceivedTask = true
    }
    // 向schedulerBackend申请资源
    backend.reviveOffers()
  }

　　schedulableBuilder.addTaskSetManager这部分是向调度池提交任务的，可以参考Spark调度模式-FIFO和FAIR。

3、CoarseGrainedSchedulerBackend#reviveOffers

　　这个方法比较简单，只有一行代码

  override def reviveOffers() {
    driverEndpoint.send(ReviveOffers)
  }

4、NettyRpcEnv#send

　　在NettyRpcEnv中有几个重载的send方法，最终进入的下面这个。由于该方法的逻辑比较简单，下面直接列出debug时该方法中各变量的内容。其中192.168.1.88是spark客户端，即提交Spark应用的机器，通过192.168.1.88:42060端口发送一个ReviveOffers的message。

　　

　　接下来代码会进入下一节中，执行CoarseGrainedSchedulerBackend.receive方法。

　　这一段主要会在第四节Task的运行和运行结果的处理中用到。在NettyRpcEnv中有一个重要的变量dispatcher，其类型为org.apache.spark.rpc.netty.Dispatcher，在Dispatcher中会生成一个ThreadPoolExecutor类型的threadpool变量。这个threadpool变量会在后续的Executor模块中进一步分析。

5、CoarseGrainedSchedulerBackend#receive

　　通过netty发送一个请求资源的消息后，CoarseGrainedSchedulerBackend的receive方法则会接收分配到的资源。

　　在该方法中，由于接收到的是ReviveOffers，会调用makeOffers方法开始生成资源。

    override def receive: PartialFunction[Any, Unit] = {
      case StatusUpdate(executorId, taskId, state, data) =>
        ...
      case ReviveOffers =>
        makeOffers()

      case KillTask(taskId, executorId, interruptThread) =>
        ...
    }

6、CoarseGrainedSchedulerBackend#makeOffers

　　在本次debug过程中，只启动了两个Executor，分别在m001和m002机器上。从下图中可以看出，workOffers中获取到了两个Executor，executorId分别为1和2。

　　

　　接下来会执行launchTasks方法，该方法接收的参数是schedulerBackend分配的计算资源，有关计算资源的分配，在后续的7-8-9-10小节中深入分析，关于launchTasks方法，会在第四节-Task的运行和运行结果的处理进一步分析。

7、TaskSchedulerImpl#resourceOffers

　　资源生成好封装成WorkerOffer类型的队列后，就开始进入SchedulerBackend中，由SchedulerBackend分配这些资源。

　　

  /**
   * 由cluster manager来调用，为task分配节点上的资源。
   * 根据优先级为task分配资源，
   * 采用round-robin方式使task均匀分布到集群的各个节点上。
   */
  def resourceOffers(offers: Seq[WorkerOffer]): Seq[Seq[TaskDescription]] = synchronized {
    var newExecAvail = false
    ...
    // 为避免多个Task集中分配到某些机器上，对这些Task进行随机打散.
    val shuffledOffers = Random.shuffle(offers)
    // .
    val tasks = shuffledOffers.map(o => new ArrayBuffer[TaskDescription](o.cores))  //存储分配好资源的task
    val availableCpus = shuffledOffers.map(o => o.cores).toArray
    // 从调度池中获取排好序的TaskSetManager，由调度池确定TaskSet的执行顺序
    val sortedTaskSets = rootPool.getSortedTaskSetQueue
    for (taskSet <- sortedTaskSets) { // 按顺序取出各taskSet
      logDebug("parentName: %s, name: %s, runningTasks: %s".format(
        taskSet.parent.name, taskSet.name, taskSet.runningTasks))
      if (newExecAvail) { // 如果该executor是新分配来的
        taskSet.executorAdded() // 重新计算TaskSetManager的就近原则
      }
    }

    // 为从rootPool中获得的TaskSetManager列表分配资源。就近顺序是：
    // PROCESS_LOCAL, NODE_LOCAL, NO_PREF, RACK_LOCAL, ANY
    var launchedTask = false
    // 对每一个taskSet，按照就近顺序分配最近的executor来执行task
    for (taskSet <- sortedTaskSets; maxLocality <- taskSet.myLocalityLevels) {
      do {
        // 将前面随机打散的WorkOffers计算资源按照就近原则分配给taskSet，用于执行其中的task
        launchedTask = resourceOfferSingleTaskSet(
            taskSet, maxLocality, shuffledOffers, availableCpus, tasks)
      } while (launchedTask)
    }

    if (tasks.size > 0) {
      hasLaunchedTask = true
    }
    return tasks
  }

8、TaskSchedulerImpl#resourceOfferSingleTaskSet

　　这个方法主要是在分配的executor资源上，执行taskSet中包含的所有task。首先遍历分配到的executor，如果当前executor中的cores个数满足配置的单个task需要的core数要求(该core数由参数spark.task.cpus确定，默认值为1)，才能在该executor上启动task。

  private def resourceOfferSingleTaskSet(
      taskSet: TaskSetManager,
      maxLocality: TaskLocality,
      shuffledOffers: Seq[WorkerOffer],
      availableCpus: Array[Int],
      tasks: Seq[ArrayBuffer[TaskDescription]]) : Boolean = {
    var launchedTask = false
    for (i <- 0 until shuffledOffers.size) {  // 顺序遍历当前存在的Executor
      val execId = shuffledOffers(i).executorId // Executor ID
      val host = shuffledOffers(i).host   // Executor所在的host
      if (availableCpus(i) >= CPUS_PER_TASK) {  // 如果当前executor上的core数满足配置的单个task的core数要求
        try {
          for (task <- taskSet.resourceOffer(execId, host, maxLocality)) { // 为当前stage分配一个executor
            tasks(i) += task
            val tid = task.taskId
            taskIdToTaskSetManager(tid) = taskSet // 存储该task->taskSet的映射关系
            taskIdToExecutorId(tid) = execId // 存储该task分配到的executorId
            executorIdToTaskCount(execId) += 1 // 该executor上执行的task个数加一
            executorsByHost(host) += execId // 存储host->executorId的映射关系
            availableCpus(i) -= CPUS_PER_TASK // 该Executor可用core数减一
            assert(availableCpus(i) >= 0) // 如果启动task后，该executor上的core数大于等于0，才算正常启动。
            launchedTask = true
          }
        } catch {
          ...
        }
      }
    }
    return launchedTask
  }

9、TaskSetManager#resourceOffer

　　上面方法中，将executor分配给taskSet之后在这个方法中，最终启动一个个task，并未启动的task生成task描述对象TaskDescription。isZombie的值在上面已经讲过了，如果为false，则表示当前TaskSetManager中的task没有全部执行成功，可以继续执行剩余task。

　　每次分配一个executor给TaskSetManager，然后TaskSetManager从未执行的task队列中取出一个task分配到该executor上执行。

  def resourceOffer(
      execId: String,
      host: String,
      maxLocality: TaskLocality.TaskLocality)
    : Option[TaskDescription] =
  {
    if (!isZombie) {
      ...
      // 顺序取出TaskSetManager中未执行的task
      dequeueTask(execId, host, allowedLocality) match {
        case Some((index, taskLocality, speculative)) => {
          val task = tasks(index) // 取出一个task
          val taskId = sched.newTaskId() // 分配一个新的taskId
          copiesRunning(index) += 1
          val attemptNum = taskAttempts(index).size
          // 生成taskInfo对象存储当前task的相关信息
          val info = new TaskInfo(taskId, index, attemptNum, curTime,
            execId, host, taskLocality, speculative)
          taskInfos(taskId) = info // 记录taskId->taskInfo映射关系
          taskAttempts(index) = info :: taskAttempts(index)
          ...
          // 序列化并返回task
          val startTime = clock.getTimeMillis()
          val serializedTask: ByteBuffer = try {
            Task.serializeWithDependencies(task, sched.sc.addedFiles, sched.sc.addedJars, ser)
          } catch {
            ...
          }
          // 如果序列化后的task大小超过100KB时,直接抛出异常
          if (serializedTask.limit > TaskSetManager.TASK_SIZE_TO_WARN_KB * 1024 &&
              !emittedTaskSizeWarning) {
            emittedTaskSizeWarning = true
            logWarning(s"Stage ${task.stageId} contains a task of very large size " +
              s"(${serializedTask.limit / 1024} KB). The maximum recommended task size is " +
              s"${TaskSetManager.TASK_SIZE_TO_WARN_KB} KB.")
          }
          addRunningTask(taskId)

          // We used to log the time it takes to serialize the task, but task size is already
          // a good proxy to task serialization time.
          // val timeTaken = clock.getTime() - startTime
          val taskName = s"task ${info.id} in stage ${taskSet.id}"
          logInfo(s"Starting $taskName (TID $taskId, $host, partition ${task.partitionId}," +
            s"$taskLocality, ${serializedTask.limit} bytes)")
          // 为该task准备好执行环境后，开始执行task
          sched.dagScheduler.taskStarted(task, info)
          // 返回一个TaskDescription信息
          return Some(new TaskDescription(taskId = taskId, attemptNumber = attemptNum, execId,
            taskName, index, serializedTask))
        }
        case _ =>
      }
    }
    None
  }

10、DAGScheduler#taskStarted

　　为task准备好执行环境和资源后，在TaskScheduler和SchedulerBackend中绕了一大圈后又再次回到了DAGScheduler中，调用taskStarted方法，最终将该task运行起来。

  def taskStarted(task: Task[_], taskInfo: TaskInfo) {
    eventProcessLoop.post(BeginEvent(task, taskInfo))
  }

　　在这个方法中通过eventProcessLoop的post方法提交一个BeginEvent事件到DAGSchedulerEventProcessLoop中。有关DAGSchedulerEventProcessLoop，在Spark Scheduler模块源码分析之DAGScheduler中已经分析过了。

四、Task的运行和运行结果的处理

　　这一部分主要分析Task运行起来后的过程，以及运行结束后的结果如何处理。第三节中讲到，一个Stage中包含一组Tasks，这些Task在分配的Executor上执行。

　　在三、6-CoarseGrainedSchedulerBackend#makeOffers的最后，调用了CoarseGrainedSchedulerBackend#launchTasks方法。

1、CoarseGrainedSchedulerBackend#launchTasks

　　在该方法中，会将当前task在driver上序列化后发送到executor上运行。序列化后的task大小，如果超过128MB-200KB，当前task不能执行，并且把task对应的taskSetManager设置成zombie模式，因此其中剩余的task都不再执行。如果不超过该限制，则会把task分发到executor上。

　　序列化后的Task发送到Executor上执行，是通过Akka来进行的。其实上面那个限制大小也是Akka决定的。在AkkaUtils类中可以看到，这个限制由两个参数来确定spark.akka.frameSize，默认值为128，经过处理后，最终计算成128MB，表示Akka最大能传递的消息大小。除了用于发送序列化后的task数据之外，Akka本身会使用到一部分空间存储一些额外的数据，这一部分的大小为200KB。所以在默认情况下，对Akka来说，一个消息最大能传递的数据大小为128MB - 200KB。这两个参数在后面Executor中也会用到。

    private def launchTasks(tasks: Seq[Seq[TaskDescription]]) {
      for (task <- tasks.flatten) {
        // 序列化当前task
        val serializedTask = ser.serialize(task)
        // 如果当前task序列化后的大小超过了128MB-200KB，跳过当前task，并把对应的taskSetManager置为zombie模式
        if (serializedTask.limit >= akkaFrameSize - AkkaUtils.reservedSizeBytes) {
          scheduler.taskIdToTaskSetManager.get(task.taskId).foreach { taskSetMgr =>
            try {
              var msg = "Serialized task %s:%d was %d bytes, which exceeds max allowed: " +
                "spark.akka.frameSize (%d bytes) - reserved (%d bytes). Consider increasing " +
                "spark.akka.frameSize or using broadcast variables for large values."
              msg = msg.format(task.taskId, task.index, serializedTask.limit, akkaFrameSize,
                AkkaUtils.reservedSizeBytes)
              taskSetMgr.abort(msg)
            } catch {
              case e: Exception => logError("Exception in error callback", e)
            }
          }
        }
        else { // 序列化后的task大小不超过限制时，将当前task发送到Executor上执行。
          // 获取当前task分配到的executor相关信息
          val executorData = executorDataMap(task.executorId)
          executorData.freeCores -= scheduler.CPUS_PER_TASK
          executorData.executorEndpoint.send(LaunchTask(new SerializableBuffer(serializedTask)))  //将tasks发送到Executor
        }
      }
    }

　　根据当前task所分配的executor信息，将该executor可用core减去配置的CPUS_PER_TASK，然后调用send方法发送一个LaunchTask消息。

　　

2、CoarseGrainedExecutorBackend#receive

　　Driver和Executor之间仍然使用Netty进行通信，在Driver端send一个LaunchTask的消息后，在Executor端会对应有一个receive方法接收消息。在下面代码中，可以看到Executor除了响应LaunchTask之外还能处理的其他事件。这些事件都继承自CoarseGrainedClusterMessage类。

  override def receive: PartialFunction[Any, Unit] = {
    // 注册Executor消息
    case RegisteredExecutor(hostname) =>
      logInfo("Successfully registered with driver")
      executor = new Executor(executorId, hostname, env, userClassPath, isLocal = false)

    case RegisterExecutorFailed(message) =>
      logError("Slave registration failed: " + message)
      System.exit(1)
    // 启动Task事件
    case LaunchTask(data) =>
      // 如果分配的executor为空，即当前task无分配的executor，则直接退出
      if (executor == null) {
        logError("Received LaunchTask command but executor was null")
        System.exit(1)
      } else {
        // 否则，反序列化Akka从driver端传输过来的task数据
        val taskDesc = ser.deserialize[TaskDescription](data.value)
        logInfo("Got assigned task " + taskDesc.taskId)
        // executor上启动task
        executor.launchTask(this, taskId = taskDesc.taskId, attemptNumber = taskDesc.attemptNumber,
          taskDesc.name, taskDesc.serializedTask)
      }
    // 杀死Task事件
    case KillTask(taskId, _, interruptThread) =>
      if (executor == null) {
        logError("Received KillTask command but executor was null")
        System.exit(1)
      } else {
        executor.killTask(taskId, interruptThread)
      }
    // 停止Executor事件
    case StopExecutor =>
      logInfo("Driver commanded a shutdown")
      // Cannot shutdown here because an ack may need to be sent back to the caller. So send
      // a message to self to actually do the shutdown.
      self.send(Shutdown)
    // 终止事件
    case Shutdown =>
      executor.stop()
      stop()
      rpcEnv.shutdown()
  }

3、Executor#launchTask

　　略。。

  def launchTask(
      context: ExecutorBackend,
      taskId: Long,
      attemptNumber: Int,
      taskName: String,
      serializedTask: ByteBuffer): Unit = {
    val tr = new TaskRunner(context, taskId = taskId, attemptNumber = attemptNumber, taskName,
      serializedTask)
    runningTasks.put(taskId, tr)
    threadPool.execute(tr)
  }

4、Executor#run

　　这个方法是Executor执行task的主要方法。Task在Executor中执行完成后，会通过向Driver发送StatusUpdate的消息来通知Driver任务的状态更新为TaskState.FINISHED。

　　在Executor运行Task时，得到计算结果会存入org.apache.spark.scheduler.DirectTaskResult。在将结果传回Driver时，会根据结果的大小有不同的策略：对于较大的结果，将其以taskId为key存入org.apache.storage.BlockManager，如果结果不大，则直接回传给Driver。回传是通过AKKA来实现的，所以能够回传的值会有一个由AKKA限制的大小，这里涉及到一个参数spark.akka.frameSize，默认为128，单位为Byte，在源码中最终转换成了128MB。表示AKKA最大能传递的消息大小为128MB，但是同时AKKA会保留一部分空间用于存储其他数据，这部分的大小为200KB，那么结果如果小于128MB - 200KB的话就可以直接返回该值，否则的话，在不大于1G的情况下（可以通过参数spark.driver.maxResultSize来修改，默认为1g），会通过BlockManager来传递。详细信息会在Executor模块中描述。完整情况如下：

（1）如果结果大于1G，直接丢弃

（2）如果结果小于等于1G，大于128MB - 200KB，通过BlockManager记录结果的tid和其他信息

（3）如果结果小于128MB - 200 KB，直接返回该值

    override def run(): Unit = {
      ...
      logInfo(s"Running $taskName (TID $taskId)")
      // 开始执行Task，
      // yarn-client模式下，调用CoarseGrainedExecutorBackend的statusUpdate方法
      // 将该Task的运行状态置为RUNNING
      execBackend.statusUpdate(taskId, TaskState.RUNNING, EMPTY_BYTE_BUFFER)
      ...
      try {
        // 反序列化task，获取该Task需要使用到的file和jar文件
        val (taskFiles, taskJars, taskBytes) = Task.deserializeWithDependencies(serializedTask)
        updateDependencies(taskFiles, taskJars)
        task = ser.deserialize[Task[Any]](taskBytes, Thread.currentThread.getContextClassLoader)
        task.setTaskMemoryManager(taskMemoryManager)

        // 判断如果该task被kill了，直接抛出异常
        if (killed) {
          throw new TaskKilledException
        }
        ...
        var threwException = true
        val (value, accumUpdates) = try {
          // 调用Task.run方法，开始运行task
          val res = task.run(
            taskAttemptId = taskId,
            attemptNumber = attemptNumber,
            metricsSystem = env.metricsSystem)
          threwException = false
          res
        } finally {
          ...
        }
        ...
        // 生成DirectTaskResult对象，并序列化Task的运行结果
        val directResult = new DirectTaskResult(valueBytes, accumUpdates, task.metrics.orNull)
        val serializedDirectResult = ser.serialize(directResult)
        val resultSize = serializedDirectResult.limit

        val serializedResult: ByteBuffer = {
          // 如果序列化后的结果比spark.driver.maxResultSize配置的还大，直接丢弃该结果
          if (maxResultSize > 0 && resultSize > maxResultSize) {
            logWarning(s"Finished $taskName (TID $taskId). Result is larger than maxResultSize " +
              s"(${Utils.bytesToString(resultSize)} > ${Utils.bytesToString(maxResultSize)}), " +
              s"dropping it.")
            ser.serialize(new IndirectTaskResult[Any](TaskResultBlockId(taskId), resultSize))
          }
          // 如果序列化后的结果小于上面的配置，而大于spark.akka.frameSize - 200KB
          // 结果通过BlockManager回传
          else if (resultSize >= akkaFrameSize - AkkaUtils.reservedSizeBytes) {
            val blockId = TaskResultBlockId(taskId)
            env.blockManager.putBytes(
              blockId, serializedDirectResult, StorageLevel.MEMORY_AND_DISK_SER)
            logInfo(
              s"Finished $taskName (TID $taskId). $resultSize bytes result sent via BlockManager)")
            ser.serialize(new IndirectTaskResult[Any](blockId, resultSize))
          }
          // 如果结果小于spark.akka.frameSize - 200KB，则可通过AKKA直接返回Task的该执行结果
          else {
            logInfo(s"Finished $taskName (TID $taskId). $resultSize bytes result sent to driver")
            serializedDirectResult
          }
        }
        // 更新当前Task的状态为finished
        execBackend.statusUpdate(taskId, TaskState.FINISHED, serializedResult)

      } catch {
        case ffe: FetchFailedException =>
          ...
        case _: TaskKilledException | _: InterruptedException if task.killed =>
          ...
        case cDE: CommitDeniedException =>
          ...
        case t: Throwable =>
          ...
      } finally {
        // 总runnint状态的task列表中将该task移除
        runningTasks.remove(taskId)
      }
    }
  }

5、CoarseGrainedExecutorBackend#statusUpdate

　　上面代码中，在Task开始时以及Task处理完毕后都会通过本方法更新Task的状态。这里的msg是StatusUpdate类型，通过调用driver的send方法将该msg发出。

  override def statusUpdate(taskId: Long, state: TaskState, data: ByteBuffer) {
    val msg = StatusUpdate(executorId, taskId, state, data)
    driver match {
      case Some(driverRef) => driverRef.send(msg)
      case None => logWarning(s"Drop $msg because has not yet connected to driver")
    }

6、CoarseGrainedSchedulerBackend#receive

　　这个方法最终获取到上面发出的msg，这个方法在三-5、CoarseGrainedSchedulerBackend#receive中已经分析过，当时是接收请求资源的消息。这里继续分析接收到StatusUpdate后的逻辑。

    override def receive: PartialFunction[Any, Unit] = {
      case StatusUpdate(executorId, taskId, state, data) =>
        // 调用TaskSchedulerImpl.statusUpdate方法处理task状态变更消息
        scheduler.statusUpdate(taskId, state, data.value)
        ...

      case ReviveOffers =>
        makeOffers()

      case KillTask(taskId, executorId, interruptThread) =>
        ...
    }

7、TaskSchedulerImpl#statusUpdate

　　在这个方法中，主要分析完成状态和失败状态的Task后续处理流程的入口。

  def statusUpdate(tid: Long, state: TaskState, serializedData: ByteBuffer) {
    var failedExecutor: Option[String] = None
    synchronized {
      try {
        ...
        taskIdToTaskSetManager.get(tid) match {
          case Some(taskSet) =>
            // 如果Task的状态为FINISHED或FAILED或KILLED或LOST，该task就被认为执行结束
            // 将运行完成的Task从相关记录器中移除
            if (TaskState.isFinished(state)) {
              taskIdToTaskSetManager.remove(tid)
              taskIdToExecutorId.remove(tid).foreach { execId =>
                if (executorIdToTaskCount.contains(execId)) {
                  executorIdToTaskCount(execId) -= 1
                }
              }
            }
            // 任务成功完成
            if (state == TaskState.FINISHED) {
              taskSet.removeRunningTask(tid)    // TaskSetManager标记该任务已经结束
              // 成功Task后续处理逻辑入口
              taskResultGetter.enqueueSuccessfulTask(taskSet, tid, serializedData)
            }
            // 如果TASK状态为FAILED或KILLED或LOST
            else if (Set(TaskState.FAILED, TaskState.KILLED, TaskState.LOST).contains(state)) {
              taskSet.removeRunningTask(tid)
              // 处理失败任务，加入到失败任务处理队列中
              taskResultGetter.enqueueFailedTask(taskSet, tid, state, serializedData)
            }
          case None =>
            ...
        }
      } catch {
        case e: Exception => logError("Exception in statusUpdate", e)
      }
    }
    // 如果当前Executor lost，则通知DAGScheduler该Executor已经lost。
    // SchedulerBackend申请新的Executor
    if (failedExecutor.isDefined) {
      dagScheduler.executorLost(failedExecutor.get)
      backend.reviveOffers()
    }
  }

7.1、成功执行的Task

7.2、执行失败的Task