Spark图解如何全面性能调优?

1、GC对Spark性能影响的原理图解

在这里插入图片描述

  如果在Task执行期间发生大量的Full GC,那么说明年轻代的Eden区域给的空间不够大,可以通过一下方式进行调优:

  (1)降低Cache操作占用的内存比例,给Eden等区域更多的内存空间;

  (2)给Eden区域分配更大的空间,-Xmn参数即可调节,通常给Eden区域预计大小的4/3,如果使用的是HDFS文件存储且每个Executor有4个Task,然后每个HDFS块解压缩后是原来的三倍左右,每个块大小默认128MB,那么Eden区域的大小可以设置为4 * 3 * 128 * 4/3,一般对于垃圾回收的调优调节Executor的内存比例就可以满足需求了,除非到万不得已且自身对JVM较为了解的情况下可以再对JVM参数进行调节。

2、调节executor内存比例图解

在这里插入图片描述

3、JVM minor gc与full gc原理图解

在这里插入图片描述

4、提高并行度原理图解

在这里插入图片描述

5、广播共享数据原理图解

在这里插入图片描述

6、数据本地化原理图解

在这里插入图片描述

7、groupByKey原理图解

在这里插入图片描述

8、reduceByKey原理图解

在这里插入图片描述

9、没有开启consolidation机制的性能低下的原理剖析图解

在这里插入图片描述

10、开启consolidation机制之后对磁盘io性能的提升的原理图解

在这里插入图片描述

11、SparkSQL工作原理剖析图解

在这里插入图片描述

  Spark SQL性能调优:

  (1)设置Shuffle的并行度:SaprkConf.set( “spark.sql.shuffle.partitions” , “n” );

  (2)Hive建表过程中合理选择数据类型;

  (3)编写SQL时尽量写明列明,不要使用select * 的形式进行查询;

  (4)并行处理计算结果:如果数据量较大,比如超过1000条数据,就不要一次性的collect到Driver端再处理,而是使用foreachPartition算子并行处理数据;

  (5)缓存表:对于一条SQL语句的查询结果,如果可能多次使用则可以将表数据进行缓存,使用SQLContext.cacheTable(name)或者DataFrame.cache均可;

  (6)广播join表:通过参数spark.sql.autoBroadcastJoinThreshold调节广播表的阈值大小,默认为10MB,该参数表示一个表在Join时,在多大以内会被广播出去以优化性能;

  (7)开启钨丝计划:通过参数spark.sql.tungsten.enable开启Tungsten,实现集群自动管理内存;

12、大数据实时计算原理图解

在这里插入图片描述

13、Spark Streaming基本工作原理图解

在这里插入图片描述

  (1)如果使用的是本地模式,至少local[n]中的n设置为2,因为SparkStreaming底层至少有两条线程,一条线程分配给Receiver接收数据并存储在Spark内存中,SparkStreaming的任务也会独占一个CPU;在Master模式下也要求集群节点上有大于等于1个CPU Core,其次每个Executor分配的Core必须 ≥ 1,否则将只能接收数据,不会处理数据;

  集群节点上总共拥有的CPU Core必须大于Receiver的数量,一个SparkStreaming程序可以启动多个Receiver,即接收多个数据源;

   基于HDFS文件的数据源是没有Receiver的;

  (2)DStream中所有计算都是由output操作触发的,如print()、foreachRDD()、saveAsTextFile(prefix,[suffix])、saveAsObjectFile()、saveAsHadoopFile();

  (3)对于窗口操作如reduceByWindow、reduceByKeyAndWindow,以及基于状态的操作如updateStateByKey,默认隐式开启了持久化机制,将数据缓存到了内存中,所以不需要手动调用persist()方法,对于通过网络接收数据的输入流,如socket、Kafka、Flume等默认的持久化级别是Memory_only_ser_2;

  (4)何时启用CheckPoint机制?

  Ⅰ、使用了有状态的transfremation操作,如updateStateByKey、reduceByWindow或reduceByKeyAndWindow,则必须开启CheckPoint机制;

  Ⅱ、要保证Driver从失败中恢复 – 元数据CheckPoint需要启用(实现较为复杂,需要改写SparkStreaming程序);

  Ⅲ、可以将CheckPoint间隔设为窗口操作滑动时间的5–10倍;

  (5)SparkSteaming调优:

  Ⅰ、数据接收并行度调优 :通过网络接收数据(Kafka、Flume…)时,会将数据反序列化并存储在Saprk的内存中,如果数据接收称为系统瓶颈那么可以通过创建多个DStream接收不同数据源的数据,以更多的Receiver提升系统的吞吐量;

  Ⅱ、调节block interval : 通过参数spark.streaming.blockInterval(默认200s)调节每个block块的接收时长,对于大多数Receiver在将数据保存到BlockManager之前会将数据切分为一个一个的block,而每个batch中block的数量决定了该batch对应的Partitoion数量和对应的Task数量;

  Ⅲ、重分区 : DataStream.repartition(n)

  Ⅳ、任务启动调优 : 如果每秒钟启动的Task过多,比如每妙启动50个Task,那么分发Task去Worker节点上的Executor的性能开销较大,会导致很难达到毫秒级的响应延迟,可以通过以下方法进行调优:

	①Task序列化:使用Kryo序列化机制序列化Task;
	②在StandAlone模式下运行Spark程序,减少Task启停时间;

  Ⅴ、设置算子或者全局并行度;

  Ⅵ、默认情况下接收到输入数据是存储在Executor的内存中的,使用持久化级别是Memory_and_disk_ser_2,数据会进行序列化且有副本,所以可以通过启用Kryo序列化机制进行优化;

  Ⅶ、调节batch interval : 如果想让SparkStreaming任务在集群上稳定运行,应该让batch生成之后快速被处理掉,可以通过观察Spark UI上batch处理时间调节相应参数,batch处理时间必须小于batch interval时间;

14、Receiver和cpu core分配说明图解

在这里插入图片描述

15、RDD的基本容错原理图解

在这里插入图片描述

发布了57 篇原创文章 · 获赞 6 · 访问量 2581

猜你喜欢

转载自blog.csdn.net/qq_40640228/article/details/103801792
今日推荐