在介绍Spark中的任务和资源之前先解释几个名词：

Dirver Program：运行Application的main函数(用户提交的jar包中的main函数)并新建SparkContext实例的程序，称为驱动程序，通常用SparkContext代表驱动程序(任务的驱动程序)。

Cluster Manager：集群管理器是集群资源管理的外部服务。Spark上现在主要有Standalone、YARN、Mesos3种集群资源管理器。Spark自带的Standalone模式能满足绝大部分

　　　　　　　　Spark计算环境中对集群资源管理的需求，基本只有在集群中运行多套计算框架时才考虑使用YARN和Mesos。通常说的Spark on YARN或者Standalone指的就是

　　　　　　　　不同的集群资源管理方式(资源管理器)。

Worker Node：集群中可以运行Application代码的工作节点(计算资源)。

Executor：　　在Worker Node上为Application启动的一个工作进程，在进程中负责任务(Task)的运行，并且负责将数据存放在内存或者磁盘上，在Excutor内部通过多线程(线程池)

　　　　　　　并发处理应用程序的具体任务(在计算资源上运行的工作进程)。

　　　　　　　每个Application都有各自独立的Executors，因此应用程序之间是相互隔离的。

Task：　　　　任务是指被Driver送到Executor上的工作单元。通常一个任务会处理一个Partition的数据，每个Partition一般是一个HDFS的Block块的大小(在工作进程中运行的任务

　　　　　　　线程)。

Application：　是创建了SparkContext实例对象的Spark用户程序，包含一个Driver Program和集群中的多个Executor(运行在Spark集群上的应用程序)。

Job：　　　　和Spark的action对应，每个action都会对应一个Job实例，每个Job会拆分成多个Stage，一个Stage包含一个任务集(TaskSet)，任务集中的各个任务通过一定的

　　　　　　  调度机制发送到工作单位(Executor)上并行执行(Application中进行任务切分的粒度)。

0. 资源的调度管理YARN vs Standalone：

Standalone：此模式下由Master节点负责，Worker节点是在Master节点的调度下启动的Executor。此时集群的部署为典型的Master/Slave架构。

Spark on YARN：yarn-cluster模式提交，首先它会和ResourceManager通信，发送请求给ResourceManager，请求启动ApplicationMaster，ResourceManager接收到请求之后，

　　　　　会给它分配一个Container，然后在某个NodeManager上启动ApplicationMaster。ApplicationMaster启动之后，会和ResourceManager通信，ApplicationMaster(AM)

　　　　　就相当于Driver。AM找RM，请求container，启动Executor，RM会给它分配一批Container，用于启动Exectutor。此时AM会去连接其他NM，去启动Executor，NM

　　　　　就相当于Worker。Executor启动之后，向AM反向注册。与standalone相比，AM就相当于Driver，NM相当于Worker，RM相当于Master。NM上启动Executor之后还是

　　　　　会反向向AM注册，后面的流程与之前的结构是一样的，这就是yarn-cluster提交模式。

参考：https://zhuanlan.zhihu.com/p/61902619

1. Standalone模式下任务与资源的关系

从上文可知，Spark集群中的资源主要为计算资源，在YARN模式下对应的是Container，Standalone模式下对应的是Worker，Application是用户开发的Spark应用程序，提交到

集群上运行，运行开始时集群给Application分配资源，运行结束后集群会回收资源(Application会释放资源)；同一个集群上可以同时运行多个Application，Application之间相互隔离，每个Application对应一个SparkContext对象，由该SparkContext维护与集群之间的关系。

Worker的资源由Master进行管理，Application任务注册到Master之后，由Master根据集群当前Worker的工作状况进行资源分配。分配的资源由SparkContext创建的三个核心对象DAGScheduler，TaskScheduler，SchedulerBackend根据Application进行相应的任务划分和调度。SparkContext创建核心对象及获取计算资源的流程如下图

2. DAGScheduler

DAGSchedule是针对Application对任务进行规划。

DAGScheduler是面向Stage的高层级调度器，DAGScheduler把DAG拆分成很多Task，每组Task都是一个Stage，解析时以Shuffle(宽依赖进行数据同步时会产生Shuffle)为边界反向解析构建Stage；每次遇到Shuffle会产生新的Stage，然后以一个个TaskSet(每个Stage中的Tasks会封装成一个TaskSet)的形式提交给底层的任务调度器TaskScheduler。DAGScheduler需要记录那些RDD被存入磁盘，寻求Task的最优化调度(如Stage内部数据的本地性)，监视Shuffle跨节点数据的状态，失败重新提交该Stage。

DAGScheduler的核心工作是进行Stage的划分，Stage划分的依据是RDD的宽窄依赖，父RDD的一个分区同时被多个子RDD分区依赖称为宽依赖，父RDD分区只被一个子RDD分区依赖称为窄依赖。

Spark Application因为不同的Action出发多个Job，每个Job由一个或多个Stage组成，后面的Stage依赖于前面的Stage。Spark在在Job的提交过程中进行Stage的划分以及确定Task的最佳位置，Stage划分以后才进行计算；Task的最佳位置及利用本地数据进行计算，本地数据即为数据就在当前内存中。DAGScheduler利用RDD自身的getPreferedLocations中的数据计算数据的本地性，getPreferedLocations中标明了每个Partition的数据本地性。

 3.TaskScheduler

TaskScheduler针对Task具体的执行过程，也是针对任务而言。

TaskScheduler的核心任务是提交TaskSet到集群进行运算并汇报结果。

　　a. 为TaskSet创建和维护一个TaskSetManager，并追踪任务的本地性以及错误信息

　　b. 遇到Straggle任务时，会放到其他节点重试

　　c. 向DAGScheduler汇报任务执行情况，包括在Shuffle输出丢失的时候报告fetch failed错误等信息。

TaskSchduler需要确定Task任务使用的计算资源，即需要根据计算本地性原则确定Task具体要运行在哪个ExecutorBackend中。

TaskScheduler是从具体计算的角度考虑本地性，区别于DAGScheduler从数据层面考虑的本地性。

TaskSchedulerImpl是TaskScheduler的子类，通过resourceOffers方法确定Task任务具体运行的ExecutorBackend，具体过程如下：

　　1. 通过Random.shuffle方法重新洗牌所有计算资源，以寻求计算的负载均衡；

　　2. ExecutorBackend的cores个数声明类型为TaskDescription的ArrayBuffer数组；

　　3. 如果有新的ExecutorBackend分配给我们的Job，此时会调用executorAdded来获得新的完整的可用计算资源；

　　4. 寻求最高级别的优先级本地性；

 /*** Called by cluster manager to offer resources on slaves. We respond by asking our active task* sets for tasks in order of priority. We fill each node with tasks in a round-robin manner so* that tasks are balanced across the cluster.*/def resourceOffers(offers: IndexedSeq[WorkerOffer]): Seq[Seq[TaskDescription]] = synchronized {...// Randomly shuffle offers to avoid always placing tasks on the same set of workers.
    val shuffledOffers = Random.shuffle(offers)
    // Build a list of tasks to assign to each worker.val tasks = shuffledOffers.map(o => new ArrayBuffer[TaskDescription](o.cores))
    val availableCpus = shuffledOffers.map(o => o.cores).toArray
    val sortedTaskSets = rootPool.getSortedTaskSetQueuefor (taskSet <- sortedTaskSets) {logDebug("parentName: %s, name: %s, runningTasks: %s".format(taskSet.parent.name, taskSet.name, taskSet.runningTasks))if (newExecAvail) {
        taskSet.executorAdded()
      }}//以下代码计算最高级别的优先级本地性// Take each TaskSet in our scheduling order, and then offer it each node in increasing order// of locality levels so that it gets a chance to launch local tasks on all of them.// NOTE: the preferredLocality order: PROCESS_LOCAL, NODE_LOCAL, NO_PREF, RACK_LOCAL, ANYfor (taskSet <- sortedTaskSets) {var launchedAnyTask = falsevar launchedTaskAtCurrentMaxLocality = falsefor (currentMaxLocality <- taskSet.myLocalityLevels) {do {launchedTaskAtCurrentMaxLocality = resourceOfferSingleTaskSet(taskSet, currentMaxLocality, shuffledOffers, availableCpus, tasks)launchedAnyTask |= launchedTaskAtCurrentMaxLocality} while (launchedTaskAtCurrentMaxLocality)}if (!launchedAnyTask) {taskSet.abortIfCompletelyBlacklisted(hostToExecutors)}}if (tasks.size > 0) {hasLaunchedTask = true}return tasks}

　　5. 通过调用TaskSetManager的resourceOffer最终确定每个Task具体运行的ExecutorBackend的Locality Level；

　　6. 通过launchTasks把任务发送给ExecutorBackend执行。launchTasks首先会进行序列化，序列化的大小不能超过默认设置128M，否则报错。由参数　　　　

　　    spark.rpc.message.maxSize设置。

 4. SchedulerBackend

　　SchedulerBackend针对资源，所以该接口在不同的部署模式下会创建不同的子类对象(YarnSchedulerBackend)来进行资源管理，如StandaloneSchedulerBackend是在Standalone模式下的管理对象，负责收集和分配资源给Task使用。

　　StandaloneSchedulerBackend在接收到TaskSchedulerImpl的submitTasks后，会调用父类CoarseGrainedSchedulerBackend中的reviveOffers方法，最终调用makOffers方法分配资源执行Task。

　　makOffers方法的执行过程：

　　1. 首先过滤出Active状态的Executor，然后构建代表Executor资源可用的WorkerOffer(此处为构建可用的资源)；

　　2. 调用TaskSchedulerImpl的resourceOffers得到TaskDescrition的二维数组，包含Task ID、Executor ID、Task Index等Task执行需要的信息；

　　3. 回调DriverEndPoint的launchTask给每个Task对应的Executor发执行Task的LaunchTask信息。

    // Make fake resource offers on all executorsprivate def makeOffers() {// Filter out executors under killingval activeExecutors = executorDataMap.filterKeys(executorIsAlive)val workOffers = activeExecutors.map { case (id, executorData) =>new WorkerOffer(id, executorData.executorHost, executorData.freeCores)}.toIndexedSeqlaunchTasks(scheduler.resourceOffers(workOffers))}