Spark性能优化第一季
1、Spark性能优化需要思考的基本问题
2、CPU和Memory
3、并行度和Task
4、网络
一、Spark性能优化核心基石
1、Spark是采用Master-Slaves的模式进行资源管理和任务执行管理的，对于资源管理
a)资源管理：Master-Worders，在一台机器上可以有多个Workers；
b)任务执行：Driver-Executors，当在一台机器上分配多个Workers的时候那么默认情况下每个Worker都会为当前运行的应用程序分配一个Executor，但是我们可以修改配置来让每个Worker为我们当前的应用程序分配若干个Executors；程序运行的时候会被划分成若干个Stages（Stage内部没有Shuffle，遇到Shuffle的时候会划分Stage），每个Stage里面包含若干个处理逻辑完全一样只是处理的数据不一样的Tasks，这些Tasks会被分配到Executor上去并行执行
2、在Spark中可以考虑在Worker节点上使用固态硬盘以及把Worker的Shuffle结果保存到RAM Disk的方式来极大地提高性能
3、默认情况下Spark的Executor会尽可能占用当前机器上尽量多的Core，这样带来的一个好处就是可以最大化的提高计算的并行度，减少一个Job中任务运行的批次，但带来的一个风险就是如果每个Task占用内存比较大，就需要频繁的spill over或者有更多的OOM的风险。
4、当你经常发现机器频繁的OOM的时候，可以考虑的一种方式就是减少并行度，这样同样的内存空间并行运算的任务少了那么对内存的占用就更少了，也就减少了OOM的可能性；
5、处理Spark Job的过程中如果出现特别多的小文件，这时候就可以通过coalesce来减少Partition的数量，进而减少并行运算的Task的数量来减少过多任务的开辟，从而提升硬件的使用效率。
6、处理Spark Job时候如果发现某些Task运行的特别慢，这个时候应该考虑增加人物的并行度，减少每个Partition的数据量来提高执行效率。
7、Job时候如果发现某些Task运行的特别慢，另外一个处理办法是增加并行的Executor的个数，这样每个Executor分配的计算资源就变少了，可以提升硬件的整体使用效率。
8、处理Spark Job时候如果发现比较容易内存溢出，另外一个比较有效的办法是减少并行的Executor数量，这样每个Executor就可以分配到更多的内存，进而增加每个Task使用的内存数量，降低OOM的风险
9、提升Spark硬件尤其是CPU使用率的一个方式就是增加Executor的并行度，但是如果Executor过多的话，直接分配在每个Executor的内存就大大减少，在内存中的操作就减少，基于磁盘的操作就越来越多，导致性能越来越差
10、适当设置Partition分片数是非常重要的，过少的Partition分片数可能会因为每个Partition数据量太大而导致OOM以及频繁的GC，而过多的Partition分片数量可能会因为每个Partition数据量太小而导致执行效率低下。
11、如果Spark中CPU的使用率不够高，可以考虑为当前的程序分配更多的Executor，或者增加更多的Worker实例来充分的使用多核的潜能。
12、性能调优的有效性是暂时的。例如为当前的应用程序增加Executor可能在一开始可以提高性能（例如CPU使用率提高等），但是随着Executor越来越多，性能可能会下降。因为Executor越来越多的时候，为每个Executor分配的内存就越来越少，Task执行过程中可用的内存就越来越少，这个时候就要频繁Spill over到磁盘，此时自然而然的导致性能变差。
13、实际执行Spark Job的时候要根据输入数据和每个Executor分配的Memory来决定执行时候的并行度，实际上一个简单事实是每个Core可以考虑分配2-3个Task
14、默认情况下Executor的60%内存被用来作为RDD的缓存，40%的内存被用来作为对象的创建空间。设置是通过spark.memory.memoryFraction来进行的。
15、GC一般不能超过CPU的2%的时间
二、性能优化招式
1、Broadcast：如果Task在运行的过程使用超过20KB大小的静态大对象，这个时候一般都要考虑使用Broadcast，例如一个大表join一个小表，此时如果使用Broadcast把小表广播出去，这个时候大表就只需要在自己的节点上（不需要Shuffle）等待小表的数据到来。
不完全gc回收小对象，增加Eden（伊甸园）的区域空间，如果有很多任务从HDFS拷贝数据，128MB（默认BLOCK大小），4个Task的话解压的话，内存消耗就是4*2*128的。
钨丝计划解决的核心问题就是GC，GC overhead limit exceeded