14、master原理与源码分析
一、主备切换机制原理剖析
1、图解
Master实际上可以配置两个，那么Spark原生的standalone模式是支持Master主备切换的。也就是说，当Active Master节点挂掉时，可以将StandBy master节点切换
为Active Master。
Spark Master主备切换可以基于两种机制，一种是基于文件系统的，一种是基于Zookeeper的。基于文件系统的主备切换机制，需要在Active Master挂掉之后，由我们
手动切换到StandBy Master上；而基于Zookeeper的主备切换机制，可以自动实现切换Master。
所以这里说的主备切换机制，实际上指的是在Active Master挂掉之后，切换到StandBy Master时，Master会执行的操作。
首先，StandBy Master会使用持久化引擎去读取持久化的storedApps，storedDrivers，storedWorkers。持久化引擎有两种：
FileSystemPersistenceEngine和ZookeeperPersistentEngine。读取出来后，会进行判断，如果storedApps，storedDrivers，storedWorkers有任何一个是非空的，
继续向下执行，去启动master恢复机制，将持久化的Application，Driver，Worker信息重新进行注册，注册到Master内部的缓存结构中。注册完之后，
将Application和Worker的状态修改为UNKNOWN，然后向Application所对应的Driver，以及Worker发送StandBy Master的地址。Driver和Worker，理论上来说，
如果它们目前都在正常运行的话，那么在接收到Master发送来的地址之后，就会返回相应消息给新的Master。此时，Master在陆续接收到Driver和Worker发送
来的响应消息后，会使用completeRecovery()方法对没有发送响应消息的Driver和Worker进行处理，过滤掉它们的信息。最后，调用Master自己的schedule()方法，
对正在等待资源调度的Driver和Application进行调度，比如在某个worker上启动Driver，或者为Application在Worker上启动它需要的Executor。
2、部分源码
###master.scala中的completeRecovery方法： /* * 完成Master的主备切换 */ def completeRecovery() { // Ensure "only-once" recovery semantics using a short synchronization period. synchronized { if (state != RecoveryState.RECOVERING) { return } state = RecoveryState.COMPLETING_RECOVERY } /* * 将Application和worker，过滤出来目前的状态还是UNKNOW的 * 然后遍历，分别调用removeWorker和finishApplication方法， * 对可能已经出故障，或者甚至已经死掉的Application和Worker，进行清理 */ // Kill off any workers and apps that didn't respond to us. workers.filter(_.state == WorkerState.UNKNOWN).foreach(removeWorker) apps.filter(_.state == ApplicationState.UNKNOWN).foreach(finishApplication) // Reschedule drivers which were not claimed by any workers drivers.filter(_.worker.isEmpty).foreach { d => logWarning(s"Driver ${d.id} was not found after master recovery") if (d.desc.supervise) { logWarning(s"Re-launching ${d.id}") relaunchDriver(d) } else { removeDriver(d.id, DriverState.ERROR, None) logWarning(s"Did not re-launch ${d.id} because it was not supervised") } } state = RecoveryState.ALIVE schedule() logInfo("Recovery complete - resuming operations!") }
二、注册机制原理剖析与源码分析
1、图解
master 的注册流程：
1 worker.
当worker 启动之后，就会主动的向master 进行注册。
master接收到worker的注册请求之后，会将状态为DEAD的worker过滤掉。对于状态为UNKNOWN的worker 节点清理掉worker的信息替换为新的worker节点。
把worker 的注册信息写入到内存缓存中（hashmap）
用持久化引擎，将worker 信息进行持久化（文件系统，zookeeper）
调用schedule()方法；
2.Driver
用spark-submit 提交Application 首先会注册Driver
将Driver 信息写入到内存中
加入等待调度队列
用持久化引擎将driver信息写入到 文件系统/zookeeper
调用schedule()方法，进行资源调度；
Driver 启动好了之后 执行编写的application代码 执行 Sparkcontext 初始化 底层的 SparkDeploySchedulerBackend 会通过ClientActor
发送RegisterApplication,到master进行Application 注册。
将Application 信息写入内存。
将application 写入对面。
调用持久化将application 写入到文件系统/zookeeper
2、master.scala中的Application注册原理代码分析
case RegisterApplication(description) => { //如果master的状态是standby，就是当前的这个master，是standby master， //而不是Active Master，那么，当Application来请求注册时，会忽略请求。 if (state == RecoveryState.STANDBY) { // ignore, don't send response } else { logInfo("Registering app " + description.name) //用ApplicationDescription信息，创建ApplicationInfo val app = createApplication(description, sender) //注册Application //将Application加入缓存中，并将Application加入等待调度的队列中-waitingApps registerApplication(app) logInfo("Registered app " + description.name + " with ID " + app.id) //使用持久化引擎，将Application进行持久化 persistenceEngine.addApplication(app) //反向，向SparkDeploySchedulerBackend的APPClient的ClientActor，发送消息，也就是RegisterApplication sender ! RegisteredApplication(app.id, masterUrl) schedule() }
三、状态改变机制源码分析
1、Driver状态改变
###Master.scala case DriverStateChanged(driverId, state, exception) => { state match { // 如果Driver的状态是错误、完成、杀死、失败，就移除Driver case DriverState.ERROR | DriverState.FINISHED | DriverState.KILLED | DriverState.FAILED => removeDriver(driverId, state, exception) case _ => throw new Exception(s"Received unexpected state update for driver $driverId: $state") } // 删除driver def removeDriver(driverId: String, finalState: DriverState, exception: Option[Exception]) { //用Scala高阶函数find()根据driverId，查找到driver drivers.find(d => d.id == driverId) match { case Some(driver) => logInfo(s"Removing driver: $driverId") //将driver将内存缓存中删除 drivers -= driver if (completedDrivers.size >= RETAINED_DRIVERS) { val toRemove = math.max(RETAINED_DRIVERS / 10, 1) completedDrivers.trimStart(toRemove) } //将driver加入到已经完成的completeDrivers completedDrivers += driver //从持久化引擎中删除driver persistenceEngine.removeDriver(driver) //设置driver状态设置为完成 driver.state = finalState driver.exception = exception //从worker中遍历删除传入的driver driver.worker.foreach(w => w.removeDriver(driver)) //重新调用schedule schedule() case None => logWarning(s"Asked to remove unknown driver: $driverId") } }
2、Executor状态改变
###org.apache.spark.deploy.master/Master.scala case ExecutorStateChanged(appId, execId, state, message, exitStatus) => { // 找到Executor对应的Application，然后再反过来通过Application内部的Executor缓存获取Executor信息 val execOption = idToApp.get(appId).flatMap(app => app.executors.get(execId)) execOption match { case Some(exec) => { // 如果有值 val appInfo = idToApp(appId) exec.state = state if (state == ExecutorState.RUNNING) { appInfo.resetRetryCount() } // 向driver同步发送ExecutorUpdated消息 exec.application.driver ! ExecutorUpdated(execId, state, message, exitStatus) // 判断，如果Executor完成了 if (ExecutorState.isFinished(state)) { // Remove this executor from the worker and app logInfo(s"Removing executor ${exec.fullId} because it is $state") // 从Application缓存中移除Executor appInfo.removeExecutor(exec) // 从运行Executor的Worker的缓存中移除Executor exec.worker.removeExecutor(exec) // 判断 如果Executor的退出状态是非正常的 val normalExit = exitStatus == Some(0) // Only retry certain number of times so we don't go into an infinite loop. if (!normalExit) { // 判断Application当前的重试次数，是否达到了最大值，最大值是10 // 也就是说，Executor反复调度都是失败，那么认为Application也失败了 if (appInfo.incrementRetryCount() < ApplicationState.MAX_NUM_RETRY) { // 重新进行调度 schedule() } else { // 否则，进行移除Application操作 val execs = appInfo.executors.values if (!execs.exists(_.state == ExecutorState.RUNNING)) { logError(s"Application ${appInfo.desc.name} with ID ${appInfo.id} failed " + s"${appInfo.retryCount} times; removing it") removeApplication(appInfo, ApplicationState.FAILED) } } } } } case None => logWarning(s"Got status update for unknown executor $appId/$execId") } } ###removeApplication()方法: def removeApplication(app: ApplicationInfo, state: ApplicationState.Value) { if (apps.contains(app)) { logInfo("Removing app " + app.id) //从application队列(hashset)中删除当前application apps -= app idToApp -= app.id actorToApp -= app.driver addressToApp -= app.driver.path.address if (completedApps.size >= RETAINED_APPLICATIONS) { val toRemove = math.max(RETAINED_APPLICATIONS / 10, 1) completedApps.take(toRemove).foreach( a => { appIdToUI.remove(a.id).foreach { ui => webUi.detachSparkUI(ui) } applicationMetricsSystem.removeSource(a.appSource) }) completedApps.trimStart(toRemove) } //加入已完成的application队列 completedApps += app // Remember it in our history //从当前等待运行的application队列中删除当前APP waitingApps -= app // If application events are logged, use them to rebuild the UI rebuildSparkUI(app) for (exec <- app.executors.values) { //停止executor exec.worker.removeExecutor(exec) exec.worker.actor ! KillExecutor(masterUrl, exec.application.id, exec.id) exec.state = ExecutorState.KILLED } app.markFinished(state) if (state != ApplicationState.FINISHED) { //从driver中删除application app.driver ! ApplicationRemoved(state.toString) } //从持久化引擎中删除application persistenceEngine.removeApplication(app) //从新调度任务 schedule() // Tell all workers that the application has finished, so they can clean up any app state. //告诉所有的worker，APP已经启动完成了，所以他们可以清空APP state workers.foreach { w => w.actor ! ApplicationFinished(app.id) } } }
四、资源调度算法原理剖析与源码分析
1、剖析
首先判断，master状态不是ALIVE的话，直接返回，也就是说，standby master是不会进行Application等资源调度的； 首先调度Driver 只有用yarn-cluster模式提交的时候，才会注册driver，因为standalone和yarn-client模式，都会在本地直接启动driver，而不会来注册driver，就更不可能让master来调度driver了； Application的调度机制 首先，Application的调度算法有两种，一种是spreadOutApps，另一种是非spreadOutApps，默认是spreadOutApps； 通过spreadOutApps这种算法，其实会将每个Application，要启动的Executor，都平均分布到各个worker上去； 比如有20个cpu core要分配，有10个worker，那么实际上会循环两遍worker，每次循环，给每个worker分配一个core，最后每个worker分配了两个core； 所以，比如，spark-submit里，配置的是要10个executor，每个要2个core，那么总共是20个core，但这种算法下，其实总共只会启动2个executor，每个有10个core； 非spreadOutApps调度算法，将每一个application，尽可能少的分配到Worker上去，这种算法和spreadOutApps算法正好相反，每个application都尽可能分配到尽量 少的worker上去； 比如总共有10个worker，每个有10个core，Application总共要分配20个core， 那么其实只会分配到两个worker上，每个worker都占满10个core，那么其余的application，就只能分配到下一个worker了；
2、源码
###org.apache.spark.deploy.master/Master.scala private def schedule() { // 首先判断，master状态不是ALIVE的话，直接返回 // 也就是说，standby master是不会进行Application等资源调度的 if (state != RecoveryState.ALIVE) { return } // First schedule drivers, they take strict precedence over applications // Randomization helps balance drivers // Random.shuffle的原理，就是对传入的集合的元素进行随机的打乱 // 取出了Workers中所有之前注册上来的worker，进行过滤，必须状态位ALIVE的worker // 对状态为ALIVE的worker，调用Random.shuffle方法进行随机的打乱 val shuffledAliveWorkers = Random.shuffle(workers.toSeq.filter(_.state == WorkerState.ALIVE)) // 拿到worker数量 val numWorkersAlive = shuffledAliveWorkers.size var curPos = 0 // 首先调度Driver // 只有用yarn-cluster模式提交的时候，才会注册driver，因为standalone和yarn-client模式，都会在本地直接启动driver，而 // 不会来注册driver，就更不可能让master来调度driver了 // driver调度机制 // 遍历waitingDrivers ArrayBuffer for (driver <- waitingDrivers.toList) { // iterate over a copy of waitingDrivers // We assign workers to each waiting driver in a round-robin fashion. For each driver, we // start from the last worker that was assigned a driver, and continue onwards until we have // explored all alive workers. var launched = false var numWorkersVisited = 0 // while的条件 numWorkersVisited小于numWorkersAlive 只要还有活着的worker没有遍历到，就继续遍历 // 而且当前这个driver还没有被启动，也就是launched为false while (numWorkersVisited < numWorkersAlive && !launched) { val worker = shuffledAliveWorkers(curPos) numWorkersVisited += 1 // 如果当前这个worker的空闲内存量大于等于driver需要的内存 // 并且worker的空闲cpu数量大于等于driver所需要的CPU数量 if (worker.memoryFree >= driver.desc.mem && worker.coresFree >= driver.desc.cores) { // 启动driver launchDriver(worker, driver) // 将driver从waitingDrivers队列中移除 waitingDrivers -= driver // launched设置为true launched = true } // 将指针指向下一个worker curPos = (curPos + 1) % numWorkersAlive } } // Right now this is a very simple FIFO scheduler. We keep trying to fit in the first app // in the queue, then the second app, etc. // Application的调度机制 // 首先，Application的调度算法有两种，一种是spreadOutApps，另一种是非spreadOutApps // 默认是spreadOutApps if (spreadOutApps) { // Try to spread out each app among all the nodes, until it has all its cores // 首先，遍历waitingApps中的ApplicationInfo，并且过滤出Application还有需要调度的core的Application for (app <- waitingApps if app.coresLeft > 0) { // 从worker中过滤出状态为ALIVE的Worker // 再次过滤出可以被Application使用的Worker，Worker剩余内存数量大于等于Application的每一个Actor需要的内存数量，而且该Worker没有运行过该Application对应的Executor // 将Worker按照剩余cpu数量倒序排序 val usableWorkers = workers.toArray.filter(_.state == WorkerState.ALIVE) .filter(canUse(app, _)).sortBy(_.coresFree).reverse val numUsable = usableWorkers.length // 创建一个空数组，存储要分配给每个worker的cpu数量 val assigned = new Array[Int](numUsable) // Number of cores to give on each node // 获取到底要分配多少cpu，取app剩余要分配的cpu的数量和worker总共可用cpu数量的最小值 var toAssign = math.min(app.coresLeft, usableWorkers.map(_.coresFree).sum) // 通过这种算法，其实会将每个Application，要启动的Executor，都平均分布到各个worker上去 // 比如有20个cpu core要分配，有10个worker，那么实际上会循环两遍worker，每次循环，给每个worker分配一个core，最后每个worker分配了两个core // 所以，比如，spark-submit里，配置的是要10个executor，每个要2个core，那么总共是20个core，但这种算法下，其实总共只会启动2个executor，每个有10个core // while条件，只要 要分配的cpu，还未分配完，就继续循环 var pos = 0 while (toAssign > 0) { // 每一个Worker，如果空闲的cpu数量大于已经分配出去的cpu数量，也就是说worker还有可分配的cpu if (usableWorkers(pos).coresFree - assigned(pos) > 0) { // 将总共要分配的cpu数量-1，因为这里已经决定在这个worker上分配一个cpu了 toAssign -= 1 // 给这个worker分配的cpu数量，加1 assigned(pos) += 1 } // 指针移动到下一个worker pos = (pos + 1) % numUsable } // Now that we've decided how many cores to give on each node, let's actually give them // 给每个worker分配完Application要求的cpu core之后 遍历worker for (pos <- 0 until numUsable) { // 只要判断之前给这个worker分配到了core if (assigned(pos) > 0) { // 那么就在worker上启动Executor // 首先，在Application内部缓存结构中，添加Executor，并且创建ExecutorDesc对象，其中封装了，给这个Executor分配多少个cpu core // 这里，spark 1.3.0版本的Executor启动的内部机制 // 在spark-submit脚本中，可以指定要多少个Executor，每个Executor需要多少个cpu，多少内存 // 那么基于spreadOutApps机制，实际上，最终，Executor的实际数量，以及每个Executor的cpu，可能与配置是不一样的 // 因为我们这里是基于总的cpu来分配的，就是说，比如要求3个Executor，每个要三个cpu，有9个worker，每个有1个cpu // 那么根据这种算法，会给每个worker分配一个core，然后给每个worker启动一个Executor // 最后会启动9个Executor，每个Executor有一个cpu core val exec = app.addExecutor(usableWorkers(pos), assigned(pos)) // 在worker上启动Executor launchExecutor(usableWorkers(pos), exec) // 将application的状态设置为RUNNING app.state = ApplicationState.RUNNING } } } } else { // Pack each app into as few nodes as possible until we've assigned all its cores // 非spreadOutApps调度算法，将每一个application，尽可能少的分配到Worker上去 // 这种算法和spreadOutApps算法正好相反，每个application都尽可能分配到尽量少的worker上去 // 比如总共有10个worker，每个有10个core，Application总共要分配20个core // 那么其实只会分配到两个worker上，每个worker都占满10个core，那么其余的application，就只能分配到下一个worker了 // 遍历worker，并且状态为ALIVE。还有空闲空间的worker for (worker <- workers if worker.coresFree > 0 && worker.state == WorkerState.ALIVE) { // 遍历application，并且是还有需要分配的core的application for (app <- waitingApps if app.coresLeft > 0) { // 判断，如果当前这个worker可以被application使用 if (canUse(app, worker)) { // 取worker剩余cpu数量，与application要分配的cpu数量的最小值 val coresToUse = math.min(worker.coresFree, app.coresLeft) // 如果worker剩余cpu为0，那么就不分配了 if (coresToUse > 0) { // 给application添加一个executor val exec = app.addExecutor(worker, coresToUse) // 在worker上启动executor launchExecutor(worker, exec) // 将application的状态设置为RUNNING app.state = ApplicationState.RUNNING } } } } } } ###launchExecutor()方法 def launchExecutor(worker: WorkerInfo, exec: ExecutorDesc) { logInfo("Launching executor " + exec.fullId + " on worker " + worker.id) // 将Executor加入worker内部的缓存 worker.addExecutor(exec) // 向worker的actor发送LaunchExecutor消息 worker.actor ! LaunchExecutor(masterUrl, exec.application.id, exec.id, exec.application.desc, exec.cores, exec.memory) // 向Executor对应的application对应的driver，发送ExecutorAdded消息 exec.application.driver ! ExecutorAdded( exec.id, worker.id, worker.hostPort, exec.cores, exec.memory) } canUse()方法 def canUse(app: ApplicationInfo, worker: WorkerInfo): Boolean = { worker.memoryFree >= app.desc.memoryPerSlave && !worker.hasExecutor(app) }
