Spark性能优化第一季

Spark性能优化第一季
    Spark性能优化需要思考的基本问题
    CPU和Memory
    并行度和Task
    网络

一、Spark性能优化核心基石
    1.Spark是采用Master-Slaves的模式进行资源管理和任务执行的管理
    a）资源管理：Master-Worker，在一台机器上可以有多个Workers；
    b）任务执行：Driver-Executors，当在一台机器上分配多个Workers的时候，那么默认情况下每个Worker都会为当前运行的运用程序分配一个Executor，但是可以修改配置来让每个Worker为我们当前的应用程序分配如干戈Executors，程序在运行的时候被划分为若干个Stages（Stage内部没有Shuffle，遇到Shuffle的时候会划分Stage），每个Stage里面包含若干个处理逻辑完全一样，只是处理的数据不一样的Tasks，这些Tasks会被分配到Executor上去执行
    2.当经常发现机器频繁的OOM的时候，可以考虑的一种方式就是减少并行度，这样同样的内存空间并行运算的任务减少那么对内存的占用就更少了，那么就减少了OOM的可能性；
    3.处理 Spark Job 的过程中如果出现特别多的小文件，这时候就可以通过 coalesce 来减少 Partition 的数量，进而减少并行运算的 Task 的数量来减少过多任务的开辟，从而提升硬件的使用效率
    4.处理 Spark Job 时候如果发现某些 Task 运行的特别慢，这个时候应该考虑增加任务的并行度，减少每个Partition 的数据量来提高执行效率。
    5.处理 Spark Job 时候如果发现某些 Task 运行的特别慢另外一个处理办法是增加并行的 Executor 的个数，这样每个Executor分配的计算资源就变少了，可以提升硬件的整体使用效率。
    6.处理 Spark Job 时候如果发现比较容易内存溢出，另外一个比较有效的办法是减少并行的 Executor 数量，这样每个Executor 就可以分配到更多的内存，进而增加每Task 使用的内存数量，降低 OOM 的风险。
    7.提升 Spark 硬件尤其是 CPU 使用率的一个方式就是增加 Executor 的并行度，但是如果 Executor 过多的话，直接分配在每个 Executor 的内存就大大减少，在内存的操作就减少，基于磁盘的操作就越来越多，导致
    性能越来越差。
    8.适当设置 Partition 分片数是非常重要的，过少的 Partition 分片数可能会因为每个 Partition 数据量太大而导致 OOM以及频繁的 GC，而过多的 Partition 分片数据可能会因为每个 Partition 数据量太小而导
    致执行效率低下。
    9.如果 Spark 中 CPU 的使用率不够高，可以考虑为当前的程序分配更多的 Executor，或者增加更多的 Worker 实例来充分的使用多核的潜能。
    10.性能调优的有效性是暂时的，例如在为当前的应用程序增加Executor可能在一开始的时候可以提高性能，（例如CPU使用率提高），但是随着Executor越来越多，性能可能会下降，因为Executor越来越多的时候，为每一个Executor分配的内存就越来越少，Task执行过程中可用的内存就越来越少，这个时候就还要频繁spill over到磁盘，此时自然而然的会导致性能变差。
    11.实际执行Spark job的时候，要根据输入数据和每个Executor分配的memory来决定执行时候的并行度，实际上每个core可以考虑分配2-3个Task，
    12.默认情况下Executor的60%的内存被他用来作为RDD的缓存，40%的内存被用来作为对象的创建空间，设置是通过Spark.Storage.memoryFaction来进行的
    13.GC一般不能超过CPU的2%的时间，钨丝计划一部分就是来解决GC；
二、Spark性能调优
    1.Broadcast如果Task在运行的过程中使用超过20K大小的静态大对象，这个时候一般都要考虑使用Broadcast，例如一个大表Join一个小表，此时如果使用Broadcast把小表广播出去，这个时候大表就只需要静静的在自己的节点上等待小表的的数据到了；