stage 的计算模式，资源调度，资源调度的结论，spark基于standalone与yarn模式提交任务，集群高可用的原理，shuffle调优中调节参数的集中方式： 配置这些参数有两种方式

stage 的计算模式

原文链接：https://blog.csdn.net/wyqwilliam/article/details/81123227

stage 的计算模式就是：pipeline 模式，即计算过程中数据不会落地，也就是不会存到 磁盘，而是放在内存中直接给下一个函数使用，stage 的计算模式类似于 1+1+1 = 3，而 MapReduce 的计算模式类似于 1+1=2、2+1=3，就是说 MR 的中间结果都会写到磁盘上

管道中的数据在以下情况会落地：

1.对某一个 RDD 执行控制算子(比如对 mapRDD 执行了 foreach()操作)

2.在每一个 task 执行完毕后，数据会写入到磁盘上，这就是 shuffle write 阶段

粗粒度和细粒度的资源调度

粗粒度的资源调度：

Spark 在 Application 执行之前，将所有的资源申请完毕，然后再进行任务调度，直到最后一 个 task 执行完毕，才会释放资源

优点：每一个 task 执行之前不需要自己去申请资源，直接使用资源就可以，每一个 task 的启动时间就变短了，task 执行时间缩短，使得整个 Application 执行的速度较快

缺点：无法充分利用集群的资源，比如总共有 10 万的 task，就要申请 10 万个 task 的 资源，即使只剩下一个 task 要执行，也得等它执行完才释放资源，在这期间 99999 个 task 的资源没有执行任何 task，但也不能被其他需要的进程或线程使用

细粒度的资源调度：

MapReduce 在 Application 执行之前，不需要申请好资源，直接进行任务的调度，在每一个 task 执 行之前，自己去申请资源，申请到就执行，申请不到就等待，每一个 task 执行完毕后就立 马释放资源。

优点：可以充分的利用集群的资源

缺点：每一个 task 的执行时间变长了，导致整个 Application 的执行的速度较慢

资源调度的三个结论

1) 在默认情况下（没有使用--executor --cores 这个选项）时，每一个 Worker 节点为当前 的 Application 只启动一个 Executor，这个 Executor 会使用这个 Worker 管理的所有的 core(原因：assignedCores(pos) += minCoresPerExecutor)

2) 默认情况下，每个 Executor 使用 1G 内存

3) 如果想要在一个 Worker 节点启动多个 Executor，需要使--executor --cores 这个选项

4) spreadOutApps 这个参数可以决定 Executor 的启动方式，默认轮询方式启动，这样有利于数据的本地化。

spark基于standalone模式提交任务

https://blog.csdn.net/wyqwilliam/article/details/81123227

spark基于yarn模式提交任务

https://blog.csdn.net/wyqwilliam/article/details/81123191

spark集群高可用的原理

spark集群高可用的原理：实际上就是搭建了一个主备模式，当主挂了的时候，备会借助zookeeper启动

高可用验证的方式：先启动主节点，然后去webUI端分别验证active和standby； 然后jps,kill -9杀死master，之后去检查原来的standby变成了active的状态。

shuffle调优中调节参数的集中方式：

配置这些参数有两种方式

1. 在程序中硬编码 例如 sparkConf.set("spark.shuffle.file.buffer","64k")

2. 提交 application 时在命令行指定 例如 spark-submit --conf spark.shuffle.file.buffer=64k --conf 配置信息=配置值 ...

3. 修改 SPARK_HOME/conf/spark-default.conf 配置文件

推荐使用第 2 种方式