在介绍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.getSortedTaskSetQueue
for (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, ANY
for (taskSet <- sortedTaskSets) {
var launchedAnyTask = false
var launchedTaskAtCurrentMaxLocality = false
for (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 executors
private def makeOffers() {
// Filter out executors under killing
val activeExecutors = executorDataMap.filterKeys(executorIsAlive)
val workOffers = activeExecutors.map { case (id, executorData) =>
new WorkerOffer(id, executorData.executorHost, executorData.freeCores)
}.toIndexedSeq
launchTasks(scheduler.resourceOffers(workOffers))
}