任务调度+资源调度整合（学习笔记）

任务调度+资源调度大体流程

1，Worker启动成功向master注册
2，提交App spark-submit --master --class jarPath
3，当TaskSchedule对象创建完成后，会向Master为Application申请资源
4，当waitingApps集合中的元素发生改变，会调用schedule（）方法。
5，当Excutor启动成功后，会向TaskSchedule反向注册，此时的TaskSchedule就会有一批Excutor的列表信息。
6，根据RDD的宽窄依赖，切割job，划分Stage，每一个task是pipline的计算模式。
7，TaskSchedule会根据数据的位置分发Task。
8，分发task，并且监控task的执行情况。
9，若task失败或者挣扎，会重试鉴定挣扎的Task。
10，重试Stage，只会重试失败的Task。

问题思考

Excutor的默认机制

1. 默认情况下，每一个worker为当前的Application只会启动一个Excutor（它默认使用当前Worker所管理的所有的核，1G运行内存）
2. 如果想要在一个worker上启动多个Excutor进程，再提交Application的时候，要指定Excutor使用的核数；

spark-submit --excutor -cores

3. 默认情况下，Excutor的启动，是轮训方式启动的，轮训的方式在一定程度上有利于数据的本地化。

轮训启动

启动Excutor的时候根本没有考虑数据的位置，但是启动方式有利于数据本地化（轮训启动，在每一个worker节点上都会启动一个Excutor）

为什么要用轮训启动这种设计模式？

1. 多个job：
   若是多个job都运行在一台节点上，此时计算的数据可能不在这个节点上，或者只有一部分在这个节点上，那么就要从别的节点上拉取数据，那么就要走网络传输，这就导致数据找计算，不是我们想要的。若是多个job都运行在一台节点上，此时计算的数据可能不在这个节点上，或者只有一部分在这个节点上，那么就要从别的节点上拉取数据，那么就要走网络传输，这就导致数据找计算，不是我们想要的。
2. task的执行效率以及时间
   若是多个task都运行在一台节点上，那么会采用阻塞执行的方式，这样只有等这个任务执行完才能行执行别的task，不能并行处理，效率也就大大降低，时间也随之加长。

轮训方式启动Executor的公式

–executor-cores：每个executor需要的核；ec
–executor-memory：每个executor需要内存；em
–total-executor-cores：这个Application一共需要多少个核；tec
worker num：Worker节点个数；wn
worker memory：Worker节点的内存；wm
worker core：Worker节点的核；wc

min(min(wm/em,wc/ec)*wn,tec/ec)

Works集合为什么要使用Hashset？

Driver进程是怎么启动起来的？

Driver进程的启动是通过执行我们用户写的Application程序启动的，通过源码分析，我们知道，是在创建上下文对象SparkCntext的时候启动的。源码分析请参考上篇博客
资源调度（学习笔记）。

挣扎的（掉队的）任务

比如1000个task中，有9999个任务执行完成，只有一个task正在执行，那么这个任务就叫挣扎的任务。
TaskSchedule遇到挣扎的任务也会重试，此时TaskSchedule会重新提交一个和挣扎的Task一模一样的Task到集群中运行，但挣扎的Task不会被kill掉，会让他们在集群中比赛执行，谁先执行完毕，就以谁的结果为准。

推测执行机制

用来判断哪些task是挣扎的。

推测执行机制的判断标准

当所有的task 75%以上都执行完毕，那么TaskSchedule才会每隔100ms计算一下哪些task需要推测执行。
例如：100个task中有76个task已经执行完毕，24个task没有执行完毕，此时它会计算出这24个task已经执行时间的中位数，然后将中位数*1.5得到最终的时间，拿到这个最终计算出来的时间，去查看哪一些task超时，此时这些task就是挣扎的task。

配置信息的使用

1. 在代码中SparkConf中修改。
2. 在提交Application的时候通过–conf来配置，如果要修改多个配置信息的值，那么需要多加一个–conf （常用）。
   比如说stage、spark的重试次数都要修改，此时需要加上两个–conf，分别来配置。

（spark-submit --master --conf k=v）

3. 在spark的配置文件中配置，修改spark-default.conf文件

重试机制

1. Taskschedule会实时跟踪每一个Task的执行情况，若是执行失败，Taskschedule会重试提交task，但是不会无休止的重试，默认是重试3次，若果重试3次依旧失败，那么这个task所在的stage就失败了，此时会向DAGSchedule汇报，任务执行失败。
2. DAGSchedule会重试提交stage，如果DAGSchedule重试了4次，依然失败，那么stage所在的job就失败了，job失败是不会重试的。

注意：每一次重试提交stage，已经成功执行的不会被再次分发到Excutor进程执行，只是提交重试失败的stage。

粗细粒度调度

粗粒度的资源调度

典型代表：Spark

描述：在任务执行前，会先将资源申请完毕，当所有的task执行完毕，才会释放这部分资源。

优点：每一个task执行之前，不需要自己去申请资源了，直接使用已经申请好的资源就行了，task启动的时间变快，task执行的时间缩短了，stage job application操作时间也短了。

缺点：需要所有的task都执行完毕才会使用资源 假设10000个task ，9999task执行完毕了，不会释放直到最后一个task执行完毕，才会释放资源，集群的资源就无法充分的利用了。

细粒度的资源调度

典型代表：MapReduce

描述：在任务提交的时候，每一个task自己去申请资源，申请到了才会执行，执行完立马释放资源。

优点：每一个task执行完毕后立马释放资源，下一个task执行前自己再去申请资源，这样有利于资源的充分利用。

缺点：由于需要每一个task自己去申请资源，导致task启动时间变长了，stage job application也相对变长了。

Spark在yarn集群上的两种提交方式

请参考下篇博客