spark源码（三）spark 如何进行driver、executor任务的调度，以及executor向driver的注册_spark driver注册

上篇文章我们介绍到，SparkContext初始化的时候，在TaskScheduler启动阶段会向Master发送RegisterApplication事件，下面我们进入Master主类，从它接收到该事件后接着分析。

另外由于这里的代码不好远程debug，所以本篇文章的讲解不会涉及到debug过程，纯纯的是枯燥的

源码解析。

    case RegisterApplication(description, driver) =>
      // 如果当前master的状态是standby(备用的)，也就是当前master不是active master，那么application来请求注册，什么都不会干
      if (state == RecoveryState.STANDBY) {
        
      } else {
        logInfo("Registering app " + description.name)
        //根据 Driver( TaskScheduler 启动阶段生成的RPC节点 )传递过来参数创建ApplicationInfo对象
        val app = createApplication(description, driver)
        //重点一：将application注册到master上
        registerApplication(app)
        logInfo("Registered app " + description.name + " with ID " + app.id)
        //将application信息持久化存储下来
        persistenceEngine.addApplication(app)
        //重点二：向Driver( TaskScheduler 启动阶段生成的RPC节点 )发送Application注册的响应
        driver.send(RegisteredApplication(app.id, self))
        //重点三：调用master的调度方法
        schedule()
      }

可以看到master接收到RegisterApplication事件之后，会先注册application的信息，随后响应driver，最后调用master的任务调度方法。下面我们分别看一下：

重点一：将application注册到master上

这一步没什么难点，主要是将application相关的信息登记到master的各种集合中：

  private def registerApplication(app: ApplicationInfo): Unit = {
    //获取driver地址信息
    val appAddress = app.driver.address
    if (addressToApp.contains(appAddress)) {
      logInfo("Attempted to re-register application at same address: " + appAddress)
      return
    }
    //在application的度量系统中记录该application的信息
    applicationMetricsSystem.registerSource(app.appSource)
    //将application添加到各种信息记录的集合中
    apps += app
    idToApp(app.id) = app
    endpointToApp(app.driver) = app
    addressToApp(appAddress) = app
    //将application添加到等待队列中（重点）
    waitingApps += app
  }

注册代码很少，主要留心下最后一步将application加入等待队列即可，加入等待队列后，后面就会被master进行调度处理。这块的具体处理我们再重点三中进行讲述。

重点二：向Driver( TaskScheduler 启动阶段生成的RPC节点 )发送Application注册的响应

在看源码前，可以先留心下master中的driver rpc节点是指什么，通过前面的文章我们可以知道driver节点实际是TaskScheduler 启动阶段生成的RPC节点，对于我们的案例来说，其实就是StandaloneAppClient对象节点。了解了这些概念，后面我们看源码也会清晰很多。

就比如说这里向Driver发送RegisteredApplication响应，接收事件的处理逻辑是什么，我们如果想知道，就必须知道这个Driver节点到底是什么。发送事件没什么好说的，这里我们直接看下StandaloneAppClient的响应逻辑

case RegisteredApplication(appId_, masterRef) =>
        //记录appId
        appId.set(appId_)
        //标识app已被注册过
        registered.set(true)
        //存储master RPC节点的引用
        master = Some(masterRef)
        //通知LanchServer当前app的appid
        listener.connected(appId.get)

可以看到响应逻辑很简单，就是一些常见的标识修改，信息记录等，关键的是如何快速定位到所发送的RPC节点。本案例是StandaloneAppClient接收，如果是cluster部署，还是吗？答案肯定为不是。

重点三：调用master的调度方法（核心，重中之重）

master的schedule方法是master的核心方法，它为等待的Application安排当前可用的资源。 因此每次有新应用加入或资源可用性发生变化时，都会调用此方法。另外在阅读源码前，有几个小点留意下，这样更便于理解源码：

1）driver的调度一定要在executor之前，因为executor需要向driver创建过程中TaskScheduler注册自己的信息。

2）waitting driver遍历时，一开始会挑选ALIVE状态的worker并随机排列，随后则是依次查看worker是否可以启动driver。如果还有未启动的driver，且还有worker没有被遍历到则继续遍历worker尝试在其上启动driver。通过这个代码逻辑我们也可以看出来，每个worker默认是至多运行一个driver。

private def schedule(): Unit = {
    //如果当前节点不是ALIVE活跃状态，则直接退出
    if (state != RecoveryState.ALIVE) {
      return
    }
    // 将spark集群中可用的worker随机打乱排列
    val shuffledAliveWorkers = Random.shuffle(workers.toSeq.filter(_.state == WorkerState.ALIVE))
    //记录活跃Worker的数量
    val numWorkersAlive = shuffledAliveWorkers.size
    var curPos = 0
    //遍历所有等待的driver，在资源足够时发起driver的启动构建
    //对于每个driver，我们依次遍历可用的worker,尝试在worker上发起driver的运行
    for (driver <- waitingDrivers.toList) { 
      var launched = false
      var isClusterIdle = true
      //记录已经访问过的worker数
      var numWorkersVisited = 0
      //当还有剩余worker没有遍历到，且当前driver没有被发起时，进入while循环
      while (numWorkersVisited < numWorkersAlive && !launched) {
        //从可用worker列表中依据顺序取出下一个没有被访问到的worker
        val worker = shuffledAliveWorkers(curPos)
        //判断当前worker是不是driver和worker都没有启动过的空节点
        isClusterIdle = worker.drivers.isEmpty && worker.executors.isEmpty
        //访问的worker记录数加1
        numWorkersVisited += 1
        //重点一：如果worker节点的资源（内存、cpu等）满足driver的发起条件，则尝试在该worker上启动driver
        if (canLaunchDriver(worker, driver.desc)) {
          val allocated = worker.acquireResources(driver.desc.resourceReqs)
          driver.withResources(allocated)
          //重点二：在该worker上发起driver运行
          launchDriver(worker, driver)
          //driver发起后，将该driver从等待调度的队列中移除
          waitingDrivers -= drive
          launched = true
        }
        //移动可用worker数组的下标
        curPos = (curPos + 1) % numWorkersAlive
      }
      //如果存在worker节点既没运行driver也没运行executor，但是资源仍不符合driver运行要求，说明driver需要的资源很多，我们需要调整所有worker的资源配给
      if (!launched && isClusterIdle) {
        logWarning(s"Driver ${driver.id} requires more resource than any of Workers could have.")
      }
    }
    //重点三：启动executor
    startExecutorsOnWorkers()
  }

schedule方法中又有三处比较关键的点，分别是driver启动资源的判断、driver调度的发起、worker调度的发起。下面分别看一下：

重点一：如果worker节点的资源（内存、cpu等）满足driver的发起条件，则尝试在该worker上启动driver

  private def canLaunchDriver(worker: WorkerInfo, desc: DriverDescription): Boolean = {
    canLaunch(worker, desc.mem, desc.cores, desc.resourceReqs)
  }
 
  private def canLaunch(
      worker: WorkerInfo,
      memoryReq: Int, // driver的内存需求
      coresReq: Int,  //driver的cpu需求
      resourceRequirements: Seq[ResourceRequirement]) //driver的resource需求
    : Boolean = {
    val enoughMem = worker.memoryFree >= memoryReq
    val enoughCores = worker.coresFree >= coresReq
    val enoughResources = ResourceUtils.resourcesMeetRequirements(
      worker.resourcesAmountFree, resourceRequirements)
    enoughMem && enoughCores && enoughResources
  }

 可以看到资源判断逻辑很简单，就是判断worker的内存、cpu、resource数三个指标是否同时符合driver的启动要求。这里留意下memoryFree 、coresFree 、resourcesAmountFree三个变量名，在后续讲解executor具体创建时还会涉及该变量。

重点二：在该worker上发起driver运行

在worker上发起driver绝对是重中之重，虽然我们的WordCount案例走的是client模式，不会有driver的调度和运行发起。但是由于这块实在太核心，所以这里也介绍下：

  private def launchDriver(worker: WorkerInfo, driver: DriverInfo): Unit = {
    logInfo("Launching driver " + driver.id + " on worker " + worker.id)
    //将driver加入worker内存的缓存结构
    //将worker内使用的内存和cpu数量，都加上driver需要的内存和cpu数量
    worker.addDriver(driver)
    //把worker加入到driver内部的缓存结构中
    driver.worker = Some(worker)
    //向worker发送LaunchDriver事件，让worker来启动driver
    worker.endpoint.send(LaunchDriver(driver.id, driver.desc, driver.resources))
    //将driver状态设置为RUNNING
    driver.state = DriverState.RUNNING
  }

可以看到driver的发起其实比较简单，主要是将worker和driver相互引用，更新worker的资源使用情况，然后通过RPC节点，向对应的worker节点发送LaunchDriver事件，接下来我们到worker上看下其接收到LaunchDriver事件后的处理逻辑：

case LaunchDriver(driverId, driverDesc, resources_) =>
      logInfo(s"Asked to launch driver $driverId")
      //构建并启动DriverRunner线程（该线程会启动一个Driver进程）
      val driver = new DriverRunner(
        conf,
        driverId,
        workDir,
        sparkHome,
        driverDesc.copy(command = Worker.maybeUpdateSSLSettings(driverDesc.command, conf)),
        self,
        workerUri,
        securityMgr,
        resources_)
      drivers(driverId) = driver
      //启动DriverRunner
      driver.start()
      //当前worker加上driver运行需要的内存和cpu等资源
      coresUsed += driverDesc.cores
      memoryUsed += driverDesc.mem
      addResourcesUsed(resources_)

我们接着看下DriverRunner的start方法：

private[worker] def start() = {
    //启动一个java线程
    new Thread("DriverRunner for " + driverId) {
      override def run(): Unit = {
        //设置线程执行结束的钩子处理函数
        var shutdownHook: AnyRef = null
        try {
          shutdownHook = ShutdownHookManager.addShutdownHook { () =>
            logInfo(s"Worker shutting down, killing driver $driverId")
            kill()
          }
 
          //重点：准备driver需要的jar文件并运行driver
          val exitCode = prepareAndRunDriver()
 
          //对driver的状态做一些封装处理
          finalState = if (exitCode == 0) {
            Some(DriverState.FINISHED)
          } else if (killed) {
            Some(DriverState.KILLED)
          } else {
            Some(DriverState.FAILED)
          }
        } catch {
          case e: Exception =>
            kill()
            finalState = Some(DriverState.ERROR)
            finalException = Some(e)
        } finally {
          if (shutdownHook != null) {
            ShutdownHookManager.removeShutdownHook(shutdownHook)
          }
        }
 
        // 这个DriverRunner线程，向它所属的worker，发送一个DriverStateChanged事件
        worker.send(DriverStateChanged(driverId, finalState.get, finalException))
      }
    }.start()
  }

在driverRunner中会单独启动一个线程准备driver运行环境和运行driver，并将运行结果封装后发送给当前worker节点，接着我们在看下worker如何准备driver运行环境与发起driver运行的。

  private[worker] def prepareAndRunDriver(): Int = {
    //创建工作目录
    val driverDir = createWorkingDirectory()
    //下载用户上传的jar（我们编写完spark应用程序，打包成的jar）
    val localJarFilename = downloadUserJar(driverDir)
    //准备额外的资源文件
    val resourceFileOpt = prepareResourcesFile(SPARK_DRIVER_PREFIX, resources, driverDir)
 
    def substituteVariables(argument: String): String = argument match {
      case "{{WORKER_URL}}" => workerUrl
      case "{{USER_JAR}}" => localJarFilename
      case other => other
    }
    val javaOpts = driverDesc.command.javaOpts ++ resourceFileOpt.map(f =>
      Seq(s"-D${DRIVER_RESOURCES_FILE.key}=${f.getAbsolutePath}")).getOrElse(Seq.empty)
    //构建ProcessBuilder，传入了driver启动命令，需要的内存大小等信息
    val builder = CommandUtils.buildProcessBuilder(driverDesc.command.copy(javaOpts = javaOpts),
      securityManager, driverDesc.mem, sparkHome.getAbsolutePath, substituteVariables)
    //通过ProcessBuilder启动driver进程
    runDriver(builder, driverDir, driverDesc.supervise)
  }

可以看到worker会为了driver先创建对应的工作目录，随后通过命令调用的方式调度driver的运行，这里就不进一步的研究运行的命令具体是什么了，这个跟我们阅读源码的初衷偏离了很多。所以关于driver的启动暂时先介绍到这，我们回归主线，接着介绍worker创建任务的调度过程。

重点三：在worker上启动executor

还记得我们前一章讲解的executor构建命令拼装吗，其最后都封装在了application中，因此我们在创建启动executor的时候可以直接到application中获取相关的信息。

在worker上调度和启动executor的源码如下：

  private def startExecutorsOnWorkers(): Unit = {
    for (app <- waitingApps) {
      //获取每个executor的cpu需求数，默认是1
      val coresPerExecutor = app.desc.coresPerExecutor.getOrElse(1)
      // 如果app需要的core大于等于每个executor需要的core，则接着处理，如果app剩余需要的cpu数据，小于executor构建需要的cpu数，则不在进行新executor的构建（节省资源）
      if (app.coresLeft >= coresPerExecutor) {
        // 过滤出ALIVE状态且资源符合executor创建的worker节点
        val usableWorkers = workers.toArray.filter(_.state == WorkerState.ALIVE)
          .filter(canLaunchExecutor(_, app.desc))
          .sortBy(_.coresFree).reverse
        //如果只有一个app等待创建executor，但是仍没有可用worker创建executor，说明集群资源不够，打印warn警告
        val appMayHang = waitingApps.length == 1 &&
          waitingApps.head.executors.isEmpty && usableWorkers.isEmpty
        if (appMayHang) {
          logWarning(s"App ${app.id} requires more resource than any of Workers could have.")
        }
        //重点一：计算每个worker要分配出去的cpu数，该方法返回的是一个数组
        val assignedCores = scheduleExecutorsOnWorkers(app, usableWorkers, spreadOutApps)
 
        //重点二：根据上一步计算的每个worker要分配出去的cpu数，遍历可用worker，如果该worker需要分配的cpu数大于0，则向该worker发送对应的LaunchExecutor事件
        for (pos <- 0 until usableWorkers.length if assignedCores(pos) > 0) {
          allocateWorkerResourceToExecutors(
            app, assignedCores(pos), app.desc.coresPerExecutor, usableWorkers(pos))
        }
      }
    }
  }

这里有一个比较绕的逻辑点，就是当application剩余需要的cpu数大于单个executor需要的cpu数据才进行新executor的创建，这一步的目的个人猜测是节省资源，要知道，如果application的剩余需求cpu小于单executor需要的cpu数，要么是已经存在了运行的executor，要么就是配置有问题，正常情况下很少出现application需求cpu数小于executor创建需求cpu数的情况。

整体来看，这块有两个重要的步骤，我们分别看下：

重点一：计算每个worker要分配出去的cpu数

计算worker分配cpu数的算法有两种，一种是spreadOutApps（默认）：遍历worker，一次只在worker上分配一个executor，另一种是非spreadOutApps：尽量在一个worker启动所有executor，直到分配结束或者资源不够。下面我们看下详细代码：

  private def scheduleExecutorsOnWorkers(
      app: ApplicationInfo,
      usableWorkers: Array[WorkerInfo],
      spreadOutApps: Boolean): Array[Int] = {
    // 获取app中设置或者默认的每个executor需要的cpu和内存数
    val coresPerExecutor = app.desc.coresPerExecutor
    val minCoresPerExecutor = coresPerExecutor.getOrElse(1)
    val oneExecutorPerWorker = coresPerExecutor.isEmpty
    val memoryPerExecutor = app.desc.memoryPerExecutorMB
    val resourceReqsPerExecutor = app.desc.resourceReqsPerExecutor
    //获取可用worker的数量
    val numUsable = usableWorkers.length
    //创建一个空数组，存储了每个worker要分配出去的cpu数量
    val assignedCores = new Array[Int](numUsable) 
    //创建一个空数组，存储了每个worker要创建的executor的数量（资源足够或者spark.executor.cores未设置的情况下，可以在一个worker上启动多个executor）
    val assignedExecutors = new Array[Int](numUsable) 
    //获取到底要分配多少cpu，取app剩余要分配的cpu数量和worker总共可用cpu数量的最小值
    var coresToAssign = math.min(app.coresLeft, usableWorkers.map(_.coresFree).sum)
 
    // 内部方法，用于判断worker的资源是否符合发起executor创建
    def canLaunchExecutorForApp(pos: Int): Boolean = {
      val keepScheduling = coresToAssign >= minCoresPerExecutor
      val enoughCores = usableWorkers(pos).coresFree - assignedCores(pos) >= minCoresPerExecutor
      val assignedExecutorNum = assignedExecutors(pos)
 
      val launchingNewExecutor = !oneExecutorPerWorker || assignedExecutorNum == 0
      if (launchingNewExecutor) {
        val assignedMemory = assignedExecutorNum * memoryPerExecutor
        val enoughMemory = usableWorkers(pos).memoryFree - assignedMemory >= memoryPerExecutor
        val assignedResources = resourceReqsPerExecutor.map {
          req => req.resourceName -> req.amount * assignedExecutorNum
        }.toMap
        val resourcesFree = usableWorkers(pos).resourcesAmountFree.map {
          case (rName, free) => rName -> (free - assignedResources.getOrElse(rName, 0))
        }
        val enoughResources = ResourceUtils.resourcesMeetRequirements(
          resourcesFree, resourceReqsPerExecutor)
        val underLimit = assignedExecutors.sum + app.executors.size < app.executorLimit
        keepScheduling && enoughCores && enoughMemory && enoughResources && underLimit
      } else {
        keepScheduling && enoughCores
      }
    }
 
    // 获取可以符合executor构建条件的workers
    var freeWorkers = (0 until numUsable).filter(canLaunchExecutorForApp)
    while (freeWorkers.nonEmpty) {
      //遍历worker进行分配
      freeWorkers.foreach { pos =>
        var keepScheduling = true
        while (keepScheduling && canLaunchExecutorForApp(pos)) {
          //待分配cpu数减去executor最小分配cpu数
          coresToAssign -= minCoresPerExecutor
          //记录当前worker分配出去的cpu数
          assignedCores(pos) += minCoresPerExecutor
 
          // 如果没设置executor需要的cpu数量，默认executor需要的cpu数为1，且可以再一个worker上启动该app的多个executor，该worker消耗总cpu数仍是1
          if (oneExecutorPerWorker) {
            assignedExecutors(pos) = 1
          } else {
            assignedExecutors(pos) += 1
          }
 
          //spreadOutApps调度模式一次只在一个worker上创建executor。非spreadOutApps调度模式，会尽可能在一个worker上启动所有的executor，直到资源不够再结束。
          if (spreadOutApps) {
            keepScheduling = false
          }
        }
      }
      //分配一轮后，再次过滤可以接着进行分配的worker
      freeWorkers = freeWorkers.filter(canLaunchExecutorForApp)
    }
    //返回每个worker分配的core数量
    assignedCores
  }

这里其实判断worker资源能否符合executor创建的逻辑是比较复杂和重要的，但是由于这块跟我们主线关联不是特别大，且逻辑不易梳理，所以这块并没有详细介绍，后面有时间在补上。

经过上述步骤我们拿到了每个worker要分配的cpu数，接下来我们看下如何发起executor构建事件。

 重点二：向worker发送对应的LaunchExecutor事件

通过上一步计算出了每个worker要分配出去的cpu数，这里接着遍历可用worker，如果该worker需要分配的cpu数大于0，则向该worker发送对应的LaunchExecutor事件。源码如下：

  private def allocateWorkerResourceToExecutors(
      app: ApplicationInfo,
      assignedCores: Int,
      coresPerExecutor: Option[Int],
      worker: WorkerInfo): Unit = {
    // 根据当前worker要分配的cpu总核数和每个executor需要的cpu数，计算出当前worker要分配的executor数
    val numExecutors = coresPerExecutor.map { assignedCores / _ }.getOrElse(1)
    // 获取当前worker要分配的cpu数
    val coresToAssign = coresPerExecutor.getOrElse(assignedCores)
    //循环创建指定数目的executor
    for (i <- 1 to numExecutors) {
      //从worker获取指定资源  
      val allocated = worker.acquireResources(app.desc.resourceReqsPerExecutor)
      //创建ExecutorDesc对象，并将其记录到application中
      val exec = app.addExecutor(worker, coresToAssign, allocated)
      //重点：发起executor的创建
      launchExecutor(worker, exec)
      //修改application的状态为running
      app.state = ApplicationState.RUNNING
    }
  }

这块的逻辑主要是根据worker要分配的总cpu数和每个executor要分配的cpu数计算出要在该worker上创建的executor数据，随后封装executor的构建信息为ExecutorDesc对象，再通过launchExecutor进行处理。我们再深入看下：

  private def launchExecutor(worker: WorkerInfo, exec: ExecutorDesc): Unit = {
    logInfo("Launching executor " + exec.fullId + " on worker " + worker.id)
    //将executor加入worker内部的缓存
    worker.addExecutor(exec)
    //重点一：通知Worker节点启动executor
    worker.endpoint.send(LaunchExecutor(masterUrl, exec.application.id, exec.id,
      exec.application.desc, exec.cores, exec.memory, exec.resources))
    //重点二：发消息告诉该application对应Driver该worker上的executor已经启动
    exec.application.driver.send(
      ExecutorAdded(exec.id, worker.id, worker.hostPort, exec.cores, exec.memory))
  }

这块代码量不多，但是涉及到了两个RPC节点的通信，我们分别看下：

重点一：通知Worker节点启动executor

worker节点接收了LaunchExecutor事件后如何处理，这个我们放到下一章将，因为除了对executor如何构建感兴趣外，我们还想看看executor到底是个什么东西。所以这块准备单独开个文章讲。

重点二：将executor信息注册到Driver上

这里将executor注册进driver，在我们的WordCount案例中，因为我们是以client模式提交任务，所以实际上是将事件发送到TaskScheduler启动阶段创建的StandaloneAppClient节点上，下面我们到该节点对象上看下其接收后的处理逻辑：

      case ExecutorAdded(id: Int, workerId: String, hostPort: String, cores: Int, memory: Int) =>
        val fullId = appId + "/" + id
        logInfo("Executor added: %s on %s (%s) with %d core(s)".format(fullId, workerId, hostPort,
          cores))
        listener.executorAdded(fullId, workerId, hostPort, cores, memory)

这里的listenr是一个接口，我们这里直接看它的实现类方法：

  override def executorAdded(fullId: String, workerId: String, hostPort: String, cores: Int,
    memory: Int): Unit = {
    logInfo("Granted executor ID %s on hostPort %s with %d core(s), %s RAM".format(
      fullId, hostPort, cores, Utils.megabytesToString(memory)))
  }

可以看到driver接收到executor之后没有任何记录，那么它后续怎么下发task任务给executor呢？这里说实话我也不知道，先留个悬念，再讲解job、stage、task的任务切割时，我们再结合这里的代码好好理一下。同时也对这的问题进行解答。

临时解答一：CoarseGrainedExecutorBackend创建Executor即将完成时会向CoarseGrainedSchedulerBackend（StandaloneSchedulerBackend继承了它）发送RegisterExecutor事件，这个时候会存储executor的相关信息。所以driver中实际上是记录了executor的信息的，至于最后是不是使用的这些信息，我们还不得而知，这个在我们阅读task任务源码时再进行补充解答。

最终解答：TaskScheduler（TaskScheduler是泛成，具体是CoarseGrainedSchedulerBackend对象）向executor提交task任务时，会从executorDataMap集合中选取全部活跃的executor，随后再经过一系列的判断进而确定所用的executor。这里的executorDataMap则是在“临时解答一”中介绍的RegisterExecutor事件里被注入executor的对象信息。

本篇文章的内容到这里就算结束了，下面是一些上述内容的总结：

1、在master节点上，它认为的driver RPC节点实际上是在TaskScheduler启动阶段生成的StandaloneAppClient。

2、driver的调度优先于executor的创建（cluster部署模式driver需要调度，client模式则不需要）

3、每个worker默认仅运行一个driver在它上面

4、executor的启动信息存储在application中

5、如果application需要的core大于等于单个executor需要的core，则发起新executor的构建，如果application需要的cpu数据，小于executor构建需要的cpu数，则不在进行新executor的构建（节省资源，个人推测）

6、计算worker分配cpu数的算法有两种，一种是spreadOutApps：遍历worker，一次只在worker上分配一个executor，另一种是非spreadOutApps：尽量在一个worker启动所有executor，直到分配结束或者资源不够。

7、如果没设置executor需要的cpu数量，默认executor需要的cpu数为1，且可以再一个worker上启动该app的多个executor，该worker消耗总cpu数仍是1。