Spark 资源调度及任务调度

1、  资源分配

         通过SparkSubmit进行提交应用后，首先会创建Client将应用程序(字节码文件.class)包装成Driver,并将其注册到Master。Master收到Client的注册请求后将其加入待调度队列waitingDrivers，并等待分配执行资源。

1．1 Dirver调度(分配Driver执行容器，1个)

         Master中调度程序执行时会为Driver分配一满足其执行要求的Worker, 并通知Worker启动将Driver。Worker接到执行Driver指令后创建DriverRunner执行Driver(应用程序mainClass，mainClass执行时其会创建Spark执行上下文环境：SparkContext。伴随SparkContext会创建DAGScheduler和TaskScheduler分别用于Stage调度和任务调度,并会触发RDD的Action算子提交job)。

1.2 APP调度(分配Executor， 多个)

         若想Job运行就需要得到执行资源，Dirver成功执行后，会通过SparkDeployScheduler-Backend创建AppClient(包装App信息，包含可以创建CoarseGrainedExecutorBackend实例Command)，用于向Master汇报资源需求。Master接到AppClient的汇报后，将其加入waittingApps队列，等待调度。

App调度时会为app分配满足条件的资源-----Worker（State是Alive，其上并没有该Application的executor，可用内存满足要求(spark.executor.memory指定，默认512), 核满足要求(spark.cores.max, 最大可用core数，若未指定，则为全部资源)），然后通知Woker启动Excutor. 及向AppClient发送ExecutorAdded消息。

进行调度时，调度程序会根据配制SpreadOutApps = spark.deploy.spreadOut情况决定资源分配方式，若

Master资源调度分配算法：

1.Application的调度算法有两种，一种是spreadOutApps，另一种是非spreadOutApps。

2.spreadOutApps，会将每个Application要启动的executor都平均分配到各个worker上去。（比如有10个worker，20个cpu core要分配，那么实际会循环两遍worker，每个worker分配一个core，最后每个worker分配了2个core，这里的executor数量可能会与spark-submit设置的不一致）

3.非spreadOutApps，将每个Application尽可能分配到尽量少的worker上去。（比如总共有10个worker，每个有10个core，app总共要分配20个core，其实只会分配到两个worker上，每个worker占满10个core，其余app只能分配到下一个worker，这里的executor数量可能会与spark-submit设置的不一致）

由分配过程可知， 分配的Excutor个数与CPU核心数有关。当指定完Worker节点后，会在Worker节点创建ExecutorRunner，并启动，执行App中的Command 去创建并启动CoarseGrainedExecutorBackend。CoarseGrainedExecutorBackend启动后，会首先通过传入的driverUrl这个参数向在CoarseGrainedSchedulerBackend::DriverActor(用于与Master通信，及调度任务)发送RegisterExecutor(executorId, hostPort, cores)，DriverActor会创建executorData（executor信息）加入executorDataMap供后续task使用，并回复RegisteredExecutor，此时CoarseGrainedExecutorBackend会创建一个org.apache.spark.executor.Executor。至此，Executor创建完毕。Executor是直接用于task执行， 是集群中的直接劳动者。

         至此，资源分配结束。当分配完资源后，就可以为依本地性为任务分配具体的执行资源。

        

2、Stage划分

         当执行mainClass时，执行到RDD的action算子时，会触发执行作业(sc.runJob)，最终通过调用DAGScheduler的runJob方法根据RDD信息及action算子要做的操作创建ResultStage(FinalStage)及ActiveJob。

         若ResultStage创建成功的话，根据配制信息及RDD特征可分为本地执行，集群执行。

若“spark.localExecution.enable”指定允许本地运行（默认为：false，不允许），具RDD的action算了允许本地运行allowLocal=true,且RDD只有一个partition的话可以直接以本地线程执行job,无需划分stage。否则要将job分成多个Stage提交到集群去执行（通过提交ResultStage进行）。

         因为ResultStage提交时，首先会去判断其是否存在缺失的ParentStage（也就是说是否存在未完成的父Stage）。若有，则其需要等待其父Stage执行完成，才能进行提交执行。
       判断是否存在Stage的标准是看是否存在ShuffeDependency（Stage的分界线）。提交ResultStage时会根据其finalRDD 的依赖递归的寻找其DAG图中是否存在ShuffeDependency, 若存在，则创建ShuffleMapStage做为finalStage的父Stage以此类似。但至此，只能说存在父Stage并不能说存在缺失的父Stage. 判断缺失的标准是看其结果成功的输出信息（status）个数与其处理的分区个数是否相同，如若相同，则说明父Stage已经执行完成, 不存在missing；否则，说明还未完成，存在missing.  因为将ShuffleMapStage划分成maptask时，每个Partition对应一个maptask, 每个task会得到一个status输出结果信息，并在执行结束时将输出结果上报mapOutputTracker，并更新shuffleStage状态(将status增加进行其outputLocs列表，并将numAvailableOutputs加1)，若numAvailableOutputs 与 Stage所要处理的partitions一致，说明所有的task都已经执行完成，即Stage执行完成；否则，说明还有task未完成，即Stage未完成。
       由上述分析可知，存在依赖关系的两个Stage，如果父Stage未执行完成，子Stage不能提交，也就是不能转变为Taskset加入任务调度队列。因此其先后顺序是严格控制的。我们知道只有存在ShuffleDependency时，才会划分Stage，这也就是说两个Stage之间是要做Shuffle操作的。根据上述分析可知Shuffle时ShuffleWrite做不完，ShuffleRead不能进行.

3． Task调度

         当Stage不存在缺失的ParentStage时，会将其转换为TaskSet并提交。转换时依Stage类型进行转换：将ResultStage转换成ResultTask, ShuffleMapStage转换成ShuffleMapTask. Task个数由Stage中finalRDD 的分区数决定。

         当转换成的TaskSet提交之后，将其通过taskScheduler包装成TaskSetManager并添加至调度队列中（Pool）,等待调度。在包装成TaskSetManager时，根据task的preferredLocatitions将任务分类存放在pendingTasksForExecutor, pendingTaskForHost, pendingTasksForRack, pendingTaskWithNoPrefs及allPendingTasks中， 前三个列表是是包含关系（本地性越来越低），范围起来越大，例如：在pendingTasksForExecutor也在pendingTaskForHost，pendingTasksForRack中， 分类的目的是在调度时，依次由本地性高à低的查找task。

         在进行Task调度时，首先根据调度策略将可调度所有taskset进行排序，然后对排好序的taskset待调度列表中的taskset，按序进行分配Executor。再分配Executor时，然后逐个为Executor列表中可用的Executor在此次选择的taskset中按本地性由高到低查找适配任务。此处任务调度为延迟调度，即若本次调度时间距上一任务结束时间小于当前本地性配制时间则等待，若过了配制时间，本地性要求逐渐降低，再去查找适配的task。当选定某一task后后将其加入runningtask列表，当其执行完成时会加入success列表，下次调度时就会过滤过存在这两个列表中的任务，避免重复调度。

         当一个任务执行结束时，会将其从runningtask中移除，并加入success,并会适放其占用的执行资源,供后序task使用， 将判断其执行成功的task数与此taskset任务总数相等时，意为taskset中所有任务执行结束，也就是taskset结束。此时会将taskset移除出可调度队列。

         重复上述过程直到taskset待调度列表为空。即所有作业（job）执行完成。

Spark中的调度模式主要有两种：FIFO和FAIR。默认情况下Spark的调度模式是FIFO（先进先出），谁先提交谁先执行，后面的任务需要等待前面的任务执行。而FAIR（公平调度）模式支持在调度池中为任务进行分组，不同的调度池权重不同，任务可以按照权重来决定执行顺序。对这两种调度模式的具体实现，接下来会根据spark-1.6.0的源码来进行详细的分析。使用哪种调度器由参数spark.scheduler.mode来设置，可选的参数有FAIR和FIFO，默认是FIFO