（二）Spark学习系列

（一）讲到了stage划分好了，这一章我开始学习任务是如何下发并且执行的。

在spark计算出了哪些partition是需要重新计算的后，便开始各个partition生成计算的task，然后封装成为taskset，然后提交给taskscheduler。一个taskset里面存的是一组逻辑 完全相同的task。

每个taskscheduler对应了一个 schedulerBackend，schedulerBackend 负责和clustermaster交互，取得该application分配到的资源，并且将这些资源传给taskscheduler，由taskscheduler将资源给task

首先，createTaskScheduler动作创建了不同的taskscheduler还有schedulerBackend，创建的依据是目前所用的资源管理平台，例如standalone，mesos，Yarn

task的提交

task是被提交到TaskScheduler，最后层层的调用，最后将任务下发到executor上面执行。

一个taskset会被加载到一个tasksetmanager里面，然后tasksetmanager会被加到schedulerbuilder里面。

schedulerbuilder里面有多重实现方式，以FIFO的实现方式为例，这个实现的就是FIFO调度方式。那么任务是按照什么顺序被调度的呢？

FIFO--->根据taskID的大小来调度，JobID小的先调度，如果JobID相同，那么，stageID小的先调度（同一个Job中多个stage可以并行执行的）

task运算结果的处理

task在executor执行完后，executor会回传结果给driver。会通过Driver发送StatusUpdate更新好了消息通知Driver任务的状态更新为TaskFinished。Driver又要将任务更新转台通知TaskScheduler，然后会在这个executor上面分配新的计算任务。

executor端回传结果有三种策略：

（1）太大（当然，就是超过门限 maxResultSize，可配置）就丢弃

（2）较大将其以tid为key存到BlockManager里面，也就是传元数据

（3）不大，直接回传结果给Driver

（*Question：为什么要以两种方式进行数据的获得呢?哈哈观了论文：key来啦参看论文里面提到的是：Spark提供了三种对持久化RDD的存储策略：未序列化Java对象存于内存中、序列化后的数据存于内存及磁盘存储。第一个选项的性能表现是最优秀的，因为可以直接访问在JAVA虚拟机内存里的RDD对象。在空间有限的情况下，第二种方式可以让用户采用比JAVA对象图更有效的内存组织方式，代价是降低了性能。
8第三种策略适用于RDD太大难以存储在内存的情形，但每次

重新计算该RDD会带来额外的资源开销，额，后面又和DSJ讨论了下，DSJ的观点是：“数据量大了，不能够盲目的发，只能够先存起来，然后需要的时候再去取。”后来想了下，貌似有道理，确实，executor并不晓得driver能够容纳多大的数据，这个时候如果盲目的发送数据的话，内存崩溃了怎么办。 然后等待driver取数据的时候，自己去取数据，那么自己内存多大，能够容得下多少数据自己也是自己知道的，自己把自己搞蹦了，就不怪executor了。）

Driver端对结果的处理是:

首先启动一个线程item来取结果，线程item做的如下动作，通过本地读取或者的远程读取获得。

Run（）{
取得结果的类型：
case 直接的计算结果：
result = 本地结果反序列化
case 远程的结果{
连接远程的机器
result = 远程结果反序列化
将结果上面的Blockid删除
}
handleSuccessFulTask（taskSetManager，tid ，result）//负责处理获取到的计算结果
}

对于resultTask，通过调用JobWaiter来告知调用者任务已经结束。

如果这个task是resulttask，下来就会运行用户自定义的函数。

如果这个task是shuffleMapTask，首先需要把结果保存到stage中，

如果这个stage的所有的task都完成了，需要将整体结果注册到MapOutPutTrackerMaster中，然后，下一个stage就可以通过它来取得Shuffle结果的元数据。

如果这个stage对应的是laststage，那么当这个stage执行完毕后，这个Job就执行完毕了。

=============the end================