任务调度机制
- Spark-submit启动进程，初始化创建SparkContext
- SparkContext构建DAGSchedular和TaskSchedular
- 客户端连接master申请注册application
- master接收application注册申请，根据资源调度算法（FIFO、FAIR）在worker节点上启动多个executor
- 通知worker启动executor
- 所有启动好的executor，反向注册到TaskSchedular
- 此时各方面资源都准备好了，结束SparkContext初始化
- SparkContext开始执行处理业务逻辑，每执行到一个action算子，即创建一个job，并且把job提交给DAGSchedular
- DAGSchedular将job划分成多个stage，划分依据：宽依赖。每个stage对应一个TaskSet。并提交给TaskSchedular
- TaskSchedular将task任务，分发到Executor执行
Spark调度模式 FIFO和FAIR
【1】Spark中的调度模式主要有两种：FIFO和FAIR。
【2】默认情况下Spark的调度模式是FIFO（先进先出），谁先提交谁先执行，后面的任务需要等待前面的任务执行。而FAIR（公平调度）模式支持在调度池中为任务进行分组，不同的调度池权重不同，任务可以按照权重来决定执行顺序。
【3】设置方式
val conf =new SparkConf().setMaster(...).setAppName(...)
conf.set("spark.scheduler.mode","FAIR")
val sc =newSparkContext(conf)
资源分配概述
- spark的分配资源主要就是 executor、cpu per executor、memory per executor、driver memory 等的调节，在我们的生产环境中，提交spark作业时，用的spark-submit shell脚本，里面调整对应的参数：
spark-submit \
--class cn.spark.sparktest.core.WordCountCluster \
--num-executors 3 \ 配置executor的数量
--driver-memory 100m \ 配置driver的内存（影响不大）
--executor-memory 100m \ 配置每个executor的内存大小
--executor-cores 3 \ 配置每个executor的cpu core数量
/usr/local/SparkTest-0.0.1-SNAPSHOT-jar-with-dependencies.jar \如何分配资源
- 首先要了解你的机子的资源，多大的内存，多少个cpu core，就根据这个实际情况去设置，能使用多少资源，就尽量去调节到最大的大小（executor的数量，几十个到上百个不等；executor内存；executor cpu core）。一个cpu对应2-3task合理
- Standalone 模式
- 如果每台机器可用内存是4G，2个cpu core，20台机器，
- 那可以设置：20个executor，每个executor4G内存，2个cpu core（资源最大化利用）。
- yarn 模式下
- 根据spark要提交的资源队列资源来考虑，如果所在队列资源为500G内存，100个cpu core。
- 可以设置50个executor；每个executor10G内存2个cpu
- Standalone 模式
- 调节资源后，SparkContext，DAGScheduler，TaskScheduler，会将我们的算子，切割成大量的task，提交到Application的executor上面去执行。
分配资源策略
给application分配资源选择worker（executor），现在有两种策略：
- 尽量的打散，即一个Application尽可能多的分配到不同的节点。这个可以通过设置spark.deploy.spreadOut来实现。默认值为true，即尽量的打散。（默认）
- 尽量的集中，即一个Application尽量分配到尽可能少的节点。
分配资源分析
- 增加每个executor的cpu core，也是增加了执行的并行能力。原本20个executor，每个才2个cpu core。能够并行执行的task数量，就是40个task。
- 如果现在每个executor的cpu core，增加到了5个。能够并行执行的task数量，就是100个task。执行的速度，提升了2.5倍。
- 如果executor数量比较少，那么能够并行执行的task数量就比较少，就意味着，我们的Application的并行执行的能力就很弱。
- 比如有3个executor，每个executor有2个cpu core，那么同时能够并行执行的task就是6个。6个执行完以后，再换下一批6个task。
- 增加了executor数量以后，那么就意味着能够并行执行的task数量，也就变多了。比如原先是6个，现在可能可以并行执行10个，甚至20个，100个。那么并行能力就比之前提升了数倍，数十倍。相应的，性能（执行的速度），也能提升数倍~数十倍。
- 增加每个executor的内存量。增加了内存量以后，对性能的提升有几点：
- 如果需要对RDD进行cache，那么更多的内存，就可以缓存更多的数据，将更少的数据写入磁盘，甚至不写入磁盘。减少了磁盘IO。
- 对于shuffle操作，reduce端，会需要内存来存放拉取的数据并进行聚合。如果内存不够，也会写入磁盘。如果给executor分配更多内存以后，就有更少的数据，需要写入磁盘，甚至不需要写入磁盘。减少了磁盘IO，提升了性能。
- 对于task的执行，可能会创建很多对象。如果内存比较小，可能会频繁导致JVM堆内存满了，然后频繁GC，垃圾回收， GC和full GC。（速度很慢）。内存加大以后，带来更少的GC，垃圾回收，避免了速度变慢，速度变快了。
