王家林谈Spark性能优化第一季！(DT大数据梦工厂)

Posted 2020-06-16

内容：

1、Spark性能优化需要思考的基本问题；

2、CPU和Memory；

3、并行度和Task；

4、网络；

==========王家林每日大数据语录============

王家林每日大数据语录Spark篇0080（2016.1.26于深圳）:如果Spark中CPU的使用率不够高，可以考虑为当前的程序分配更多的Executor，或者增加更多的Worker实例来充分的使用多核的潜能。

王家林每日大数据语录Spark篇0079（2016.1.26于深圳）:适当设置Partition分片数是非常重要的，过少的Partition分片数可能会因为每个Partition数据量太大而导致OOM以及频繁的GC，而过多的Partition分片数据可能会因为每个Partition数据量太小而导致执行效率低下。

王家林每日大数据语录Spark篇0078（2016.1.23于深圳）:提升Spark硬件尤其是CPU使用率的一个方式就是增加Executor的并行度，但是如果Executor过多的话，直接分配在每个Executor的内存就大大减少，在内存的操作就减少，基于磁盘的操作就越来越多，导致性能越来越差。

王家林每日大数据语录Spark篇0077（2016.1.23于深圳）:处理Spark Job时候如果发现比较容易内存溢出，另外一个比较有效的办法是减少并行的Executor数量，这样每个Executor就可以分配到更多的内存，进而增加每个Task使用的内存数量，降低OOM的风险。

王家林每日大数据语录Spark篇0076（2016.1.23于深圳）:处理Spark Job时候如果发现比较容易内存溢出，一个比较有效的办法就是增加Task的并行度，这样每个Task处理的Partition的数据量就变少了，减少了OOM的可能性。

王家林每日大数据语录Spark篇0075（2016.1.23于深圳）:处理Spark Job时候如果发现某些Task运行的特别慢另外一个处理办法是增加并行的Executor的个数，这样每个Executor分配的计算资源就变少了，可以提升硬件的整体使用效率。

王家林每日大数据语录Spark篇0074（2016.1.23于深圳）:处理Spark Job时候如果发现某些Task运行的特别慢，这个时候应该考虑增加任务的并行度，减少每个Partition的数据量来提高执行效率。

王家林每日大数据语录Spark篇0073（2016.1.23于深圳）:处理Spark Job的过程中如果出现特别多的小文件，这时候就可以通过coalesce来减少Partition的数量，进而减少并行运算的Task的数量来减少过多任务的开辟，从而提升硬件的使用效率

王家林每日大数据语录Spark篇0072（2016.1.22于深圳）:默认情况下Spark的Executor会尽可能占用当前机器上尽量多的Core，这样带来的一个好处就是可以最大化的提高计算的并行度，减少一个Job中任务运行的批次，但带来的一个风险就是如果每个Task占用内存比较大，就需要频繁的spill over或者有更多的OOM的风险。

王家林每日大数据语录Spark篇0071（2016.1.22于深圳）:Spark集群在默认情况每台host上只有一个Worker，而每个Worker默认只会为当前应用程序分配一个Executor来执行Task，但实际上通过配置spark-env.sh可以让每台host上有若干的Worker，而每个Worker下面又可以有若干个Executor。

王家林每日大数据语录Spark篇0070（2016.1.22于深圳）:Spark Stage内部是一组计算逻辑完全相同但处理数据不同的分布式并行运行的Task构成 ，Stage内部的计算都以Pipeline的方式进行，不同的Stage之间是产生Shuffle的唯一方式。

王家林每日大数据语录Spark篇0069（2016.1.21于深圳）:在Spark中可以考虑在Worker节点上使用固态硬盘以及把Worker的Shuffle结构保存到RAM Disk的方式来极大的提高性能。

==========Spark性能优化核心基石============

1、Spark是采用Master-Slaves的模型进行资源管理和任务执行的管理；

1）资源管理：Master-Workers，在一台机器上可以有多个Workers；

2）任务执行：Driver-Executors，当在一台机器上分配多个Workers的时候，那么默认情况下每个Worker都会为当前运行的应用程序分配一个Executor，但是我们可以修改配置来让每个Worker为我们当前的应用程序分配若干个Executor，程序运行的时候会被划分成为若干个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、处理Spark 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、实际执行Spark Job的时候要根据输入数据和每个Executor分配的Memory来决定执行时候的并行度，实际上几个简单的事实，每个core可以考虑分配2~3个Task；

13、默认情况下，Executor的60%的内存被用来作为RDD的缓存，40%的内存被用来作为对象的创建空间，设置是通过spark.storage.memoryFraction，默认是0.6；

14、假设数据是压缩的，4个Task每个是128M的数据来源，解压变成2倍，则内存是4*2*128M了，这样可能就会内存溢出，不能光看HDFS现有大小多少的；

14、GC一般不能超过CPU的2%的时间（注：钨丝计划解决的核心问题之一就GC），比如出现错误OutOfMemoryErro，gc overhead limit exceeded；

总结：性能调优的有效性是暂时的，例如在为当前的应用程序增加Executor，可能在一开始可以提高性能（例如CPU使用率提高等），但是随着Executor越来越多，性能可能会下降！！！因为Executor越来越多的时候，为每个Executor分配的内存就越来越少，Task在执行的时候可用的内存就越来越少，这个时候就要频繁的spill over到磁盘，此时自然而然的导致性能变差；

举例：

1、Job运行慢，CPU使用不是很高，这个时候考虑增加并行度或者分片数，其实也是增加CPU的利用率；

2、如果出现OOM，一般就是单个partition太大，考虑增大分片数；

3、一台机器上资源有限，如果为一台机器开辟过多的Executor，也有OOM的风险，这样为每个Task分配的内存就变大了，也会减少OOM的风险；

4、有大量小文件，导致效率低下，可以考虑减少文件分片数；

5、无论如何要数据本地化，不能说HDFS在一个集群，Spark在一个集群，这样就傻了。没办法只能这样的时候，中间加个Tachyon；

最影响CPU的，就是并行度

很少把数据persist到磁盘上，经过测试发现如果把数据persist到磁盘上，有时候还不如重新计算快

在正式交付之前，要在线上调试至少1周，把性能调到最优。

实际运行的时候会根据输入和Executor来确定使用的core。

==========Spark性能优化招式============

1、BroadCast，如果Task在运行的过程中使用超过20KB大小的静态大对象，这个时候一般都要考虑使用broadcast，例如一个大表jion一个小表，可以考虑把小表broadcast出去，这样大表只需要在自己的节点上待着静静等待小表的到来，这样就可以减少Shuffle了，可能提高几十倍的性能；

王家林老师名片：

中国Spark第一人

新浪微博：http://weibo.com/ilovepains

微信公众号：DT_Spark

博客：http://blog.sina.com.cn/ilovepains

手机：[phone]

QQ：1740415547

邮箱：[email protected]

本文出自 “一枝花傲寒” 博客，谢绝转载！