分配更多资源：
性能调优的王道，就是增加和分配更多的资源，性能和速度上提升，是显而易见的，基本上，在一定范围内，增加资源与性能的提升，是成正比的，
写完一个复杂的spark作业之后，进行性能调优的时候
首先第一步，我决定就是要来调节最优的资源配置，在这个基础之上，如果说你的spark作业，能够分配的资源达到你的能力范围的顶端之后，无法分配更多资源了，公司资源有限，那么才是考虑去做后面的这些性能调优的点。
1.分配哪些资源？
2.在哪里分配资源？
3.调节到多大，算是最大呢？
4.为什么分配了这些资源以后，性能会得到提升？
答案：
1.分配哪些资源？
executor
cpu per executor
memory per executor
driver memory
2.在哪里分配资源？
在我们生产环境中，提交spark作业时，用的spark-submit shell脚本，里面调整对应的参数。 ``` /usr/local/spark/bin/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 \ ```
3.调节到多大，算是最大呢？
第一种
Spark Standalone 公司集群上，搭建一套spark 集群，你心里应该清楚每台机器能够给你使用的，大概有多少内存。 多少cpu core ，那么，设置的时候，就根据这个实际的情况，去调节每个spark作业的资源分配。 比如说你的
每台机器能够给你使用4G内存，2个cpu core； 20台机器； 总共： 80G内存，40core。
Executor 20个； 所以：80/ 20 = 4G 内存。。。。4G内存， 40/20 = 2 所以 2个cpu core，平均每个executor。
第二种
Yarn资源队列，资源调度。应该去查看你的spark作业要提交到的资源队列， 大概有多少资源？ 500G内存，100个cpu core；
executor 50； 因此 计算得到每个executor 10G内存； 2个 core；
时间记录“12.48‘
4.为什么分配了这些资源以后，性能会得到提升？
A.增加executor
如果executor 数量比较少，那么，能够并行执行task数量就比较少，就意味着，我们的Application的并行执行能力就很弱。
比如有3个executor ，每个executor有2个core 那么同时能够并行执行的task就是6个。6个执行完以后，再换下一批6个task。
增加了executor 数量以后，那么就意味着，能够并行执行的task数量，也就变多了。 比如 原先是6个，现在可能可以并行执行10个，甚至20个，100个，那么并行能力就比之前提升了数倍，数十倍。
相应的，性能（执行的速度），也能提升数倍，数十倍。
B.增加每个executor 的cpu core。
与上同理。20个executor，2个core/e 能够并行执行 40个task。 现在每个executor 增加到5个。能够并行执行100个task。提升2.5倍。
SparkContext DAGScheduler TaskScheduler 会将我们的算子，切割成大量的task，提交到Application的executor上面去执行！！
C.增加每个executor的内存量。2点提升：
1、如果需要对RDD进行cache，那么更多的内存，就可以缓存更多的数据，将更少的数据写入磁盘，甚至不写入磁盘。 减少磁盘IO。
2.对于shuffle操作，reduce端，会需要内存来存放拉去的数据，并进行聚合，如果内存不够，也会写入磁盘。 如果给executor 分配更多内存以后，就有更少的数据，需要写入磁盘，甚至不需要写入磁盘。减少了磁盘IO
3、对于task的执行，可能会创建很多对象。 如果内存比较小，可能会频繁导致JVM堆内存满，导致GC，minor GC和full GC。（速度很慢） 内存加大以后，带来更少的GC，避免了速度变慢，速度变快了！