大数据IMF传奇行动绝密课程第45课:Spark性能优化第一季

原创 2016年08月30日 19:42:11

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

版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

大数据IMF传奇行动绝密课程第44课:真正的Spark功力:性能优化!

真正的Spark功力:性能优化!1、Spark性能优化的重要性 2、Spark性能问题在哪里? 3、什么样的Spark人才会年薪50万以上一、Spark性能优化的重要性 快速解决生产问题、性能优...

大数据IMF传奇行动绝密课程第50课:Spark性能优化第六季

大数据IMF传奇行动绝密课程第50课:Spark性能优化第六季 1、关于Shuffle的再次说明 2、Shuffle性能优化 一、Shuffle性能调优 1、问题:Shuffle output...

大数据IMF传奇行动绝密课程第48课:Spark性能优化第四季

Spark性能优化第四季1、序列化 2、JVM性能调优 一、Spark性能调优之序列化 1、之所以进行序列化,最重要的原因是内存空间有限(减少GC的压力,最大化的避免Full GC的产生,因为一...

大数据IMF传奇行动绝密课程第51课:Spark性能优化第七季

Spark性能优化第七季1、“钨丝计划”产生的根本背景 2、“钨丝计划”内幕详解 3、“钨丝计划”下的Shuffle 一、“钨丝计划”产生的本质原因 1、Spark作为一个一体化多元化的(大)...

大数据IMF传奇行动绝密课程第54课:Spark性能优化第十季之Spark统一内存管理

Spark性能优化第十季之Spark统一内存管理1、传统的Spark内存管理的问题 2、Spark统一内存管理 3、展望Spark内存分为三部分:Execution、Sotrage、Other; ...

大数据IMF传奇行动绝密课程第53课:Spark性能优化第九季 Spark Tungsten内存使用彻底解密

Spark Tungsten内存使用彻底解密1、到底什么是Page 2、Page具体的两种实现方式 3、Page的使用的源码详解一、Tungsten中到底什么是Page? 1、在Spark中其实...

大数据IMF传奇行动绝密课程第120课:Spark Streaming性能优化:如何在End-to-End生产环境下安全高效地把结果数据存入HBase中

Spark Streaming性能优化:如何在End-to-End生产环境下安全高效地把结果数据存入HBase中1、生产环境下End-to-End的流处理程序 2、Spark Streaming安全...

大数据IMF传奇行动绝密课程第116课:Spark Streaming性能优化:如何在毫秒内处理大吞吐量和数据波动比较大的流计算

Spark Streaming性能优化:如何在毫秒内处理大吞吐量和数据波动比较大的流计算Spark Streaming的处理模式是按照Batch Duration进行Micro Batch Compu...

大数据IMF传奇行动绝密课程第33课:Spark Executor内幕彻底解密

Spark Executor内幕彻底解密一、Spark Executor工作原理图 二、ExecutorBackend注册源码揭秘 三、Executor实例化内幕 四、Executor具体是如何...

大数据IMF传奇行动绝密课程第35课:打通Spark系统运行内幕机制流程循环图

打通Spark系统运行内幕机制流程循环图 一、TaskScheduler原理解密 1、DAGScheduler在提交TaskSet给底层调度器的时候是面向接口TaskScheduler的,这符合面...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)