大数据-Spark调优(一)

                                    大数据-Spark调优(一)

分配更多的资源

分配更多的资源是性能优化调优的王道,就是增加和分配更多的资源,这对于性能和速度上的提升是显而易见的,基本上,在一定范围之内,增加资源与性能的提升,是成正比的;写完了一个复杂的spark作业之后,进行性能调优的时候,首先第一步,就是要来调节最优的资源配置;

在这个基础之上,如果说你的spark作业,能够分配的资源达到了你的能力范围的顶端之后,无法再分配更多的资源了,公司资源有限;那么才是考虑去做后面的这些性能调优的点。

相关问题:
(1)分配哪些资源?
(2)在哪里可以设置这些资源?
(3)剖析为什么分配这些资源之后,性能可以得到提升?

分配哪些资源

executor-memory、executor-cores、driver-memory

在哪里可以设置这些资源

在实际的生产环境中,提交spark任务时,使用spark-submit shell脚本,在里面调整对应的参数。

 提交任务的脚本:
 spark-submit \
 --master spark://node1:7077 \
 --class com.kaikeba.WordCount \
 --num-executors 3 \    配置executor的数量
 --driver-memory 1g \   配置driver的内存(影响不大)
 --executor-memory 1g \ 配置每一个executor的内存大小
 --executor-cores 3 \   配置每一个executor的cpu个数
 /export/servers/wordcount.jar

参数调节到多大,算是最大

  • Standalone模式

先计算出公司spark集群上的所有资源 每台节点的内存大小和cpu核数,比如:一共有20台worker节点,每台节点8g内存,10个cpu。实际任务在给定资源的时候,可以给20个executor、每个executor的内存8g、每个executor的使用的cpu个数10。

  • Yarn模式

先计算出yarn集群的所有大小,比如一共500g内存,100个cpu;这个时候可以分配的最大资源,比如给定50个executor、每个executor的内存大小10g,每个executor使用的cpu个数为2。

  • 使用原则

在资源比较充足的情况下,尽可能的使用更多的计算资源,尽量去调节到最大的大小。

为什么调大资源以后性能可以提升

大数据-Spark调优(一)_第1张图片

提高并行度

Spark的并行度指的是什么

spark作业中,各个stage的task的数量,也就代表了spark作业在各个阶段stage的并行度!

当分配完所能分配的最大资源了,然后对应资源去调节程序的并行度,如果并行度没有与资源相匹配,那么导致你分配下去的资源都浪费掉了。同时并行运行,还可以让每个task要处理的数量变少(很简单的原理。合理设置并行度,可以充分利用集群资源,减少每个task处理数据量,而增加性能加快运行速度。)

如何提高并行度

可以设置task的数量,至少设置成与spark Application 的总cpu core 数量相同。最理想情况,150个core,分配150task,一起运行,差不多同一时间运行完毕。官方推荐,task数量,设置成spark Application 总cpu core数量的2~3倍 。

比如150个cpu core ,基本设置task数量为300~500. 与理想情况不同的,有些task会运行快一点,比如50s就完了,有些task 可能会慢一点,要一分半才运行完,所以如果你的task数量,刚好设置的跟cpu core 数量相同,可能会导致资源的浪费。

因为比如150个task中10个先运行完了,剩余140个还在运行,但是这个时候,就有10个cpu core空闲出来了,导致浪费。如果设置2~3倍,那么一个task运行完以后,另外一个task马上补上来,尽量让cpu core不要空闲。同时尽量提升spark运行效率和速度。提升性能。

如何设置task数量来提高并行度

设置参数spark.defalut.parallelism  
   默认是没有值的,如果设置了值为10,它会在shuffle的过程才会起作用。
   比如 val rdd2 = rdd1.reduceByKey(_+_) 
   此时rdd2的分区数就是10
   
可以通过在构建SparkConf对象的时候设置,例如:
   new SparkConf().set("spark.defalut.parallelism","500")

给RDD重新设置partition的数量

使用rdd.repartition 来重新分区,该方法会生成一个新的rdd,使其分区数变大。
此时由于一个partition对应一个task,那么对应的task个数越多,通过这种方式也可以提高并行度。

提高sparksql运行的task数量

通过设置参数 spark.sql.shuffle.partitions=500  默认为200;
可以适当增大,来提高并行度。 比如设置为 spark.sql.shuffle.partitions=500

RDD的重用和持久化

大数据-Spark调优(一)_第2张图片

如上图所示的计算逻辑:
(1)当第一次使用rdd2做相应的算子操作得到rdd3的时候,就会从rdd1开始计算,先读取HDFS上的文件,然后对rdd1做对应的算子操作得到rdd2,再由rdd2计算之后得到rdd3。同样为了计算得到rdd4,前面的逻辑会被重新计算。

(2)默认情况下多次对一个rdd执行算子操作,去获取不同的rdd,都会对这个rdd及之前的父rdd全部重新计算一次。
这种情况在实际开发代码的时候会经常遇到,但是我们一定要避免一个rdd重复计算多次,否则会导致性能急剧降低。

总结:可以把多次使用到的rdd,也就是公共rdd进行持久化,避免后续需要,再次重新计算,提升效率。

大数据-Spark调优(一)_第3张图片

 

如何对rdd进行持久化

可以调用rdd的cache或者persist方法。

(1)cache方法默认是把数据持久化到内存中 ,例如:rdd.cache ,其本质还是调用了persist方法
(2)persist方法中有丰富的缓存级别,这些缓存级别都定义在StorageLevel这个object中,可以结合实际的应用场景合理的设置缓存级别。例如: rdd.persist(StorageLevel.MEMORY_ONLY),这是cache方法的实现。

rdd持久化的时可以采用序列化

(1)如果正常将数据持久化在内存中,那么可能会导致内存的占用过大,这样的话,也许会导致OOM内存溢出。
(2)当纯内存无法支撑公共RDD数据完全存放的时候,就优先考虑使用序列化的方式在纯内存中存储。将RDD的每个partition的数据,序列化成一个字节数组;序列化后,大大减少内存的空间占用。
(3)序列化的方式,唯一的缺点就是,在获取数据的时候,需要反序列化。但是可以减少占用的空间和便于网络传输
(4)如果序列化纯内存方式,还是导致OOM,内存溢出;就只能考虑磁盘的方式,内存+磁盘的普通方式(无序列化)。
(5)为了数据的高可靠性,而且内存充足,可以使用双副本机制,进行持久化
    持久化的双副本机制,持久化后的一个副本,因为机器宕机了,副本丢了,就还是得重新计算一次;
    持久化的每个数据单元,存储一份副本,放在其他节点上面,从而进行容错;
    一个副本丢了,不用重新计算,还可以使用另外一份副本。这种方式,仅仅针对你的内存资源极度充足。
     比如: StorageLevel.MEMORY_ONLY_2

广播变量的使用

场景描述

在实际工作中可能会遇到这样的情况,由于要处理的数据量非常大,这个时候可能会在一个stage中出现大量的task,比如有1000个task,这些task都需要一份相同的数据来处理业务,这份数据的大小为100M,该数据会拷贝1000份副本,通过网络传输到各个task中去,给task使用。这里会涉及大量的网络传输开销,同时至少需要的内存为1000*100M=100G,这个内存开销是非常大的。不必要的内存的消耗和占用,就导致了你在进行RDD持久化到内存,也许就没法完全在内存中放下;就只能写入磁盘,最后导致后续的操作在磁盘IO上消耗性能;这对于spark任务处理来说就是一场灾难。

由于内存开销比较大,task在创建对象的时候,可能会出现堆内存放不下所有对象,就会导致频繁的垃圾回收器的回收GC。GC的时候一定是会导致工作线程停止,也就是导致Spark暂停工作那么一点时间。频繁GC的话,对Spark作业的运行的速度会有相当可观的影响。

大数据-Spark调优(一)_第4张图片

 

广播变量引入

Spark中分布式执行的代码需要传递到各个executor的task上运行。对于一些只读、固定的数据,每次都需要Driver广播到各个Task上,这样效率低下。广播变量允许将变量只广播给各个executor。该executor上的各个task再从所在节点的BlockManager(负责管理某个executor对应的内存和磁盘上的数据)获取变量,而不是从Driver获取变量,从而提升了效率。

大数据-Spark调优(一)_第5张图片

广播变量,初始的时候,就在Drvier上有一份副本。通过在Driver把共享数据转换成广播变量。

task在运行的时候,想要使用广播变量中的数据,此时首先会在自己本地的Executor对应的BlockManager中,尝试获取变量副本;如果本地没有,那么就从Driver远程拉取广播变量副本,并保存在本地的BlockManager中;

此后这个executor上的task,都会直接使用本地的BlockManager中的副本。那么这个时候所有该executor中的task都会使用这个广播变量的副本。也就是说一个executor只需要在第一个task启动时,获得一份广播变量数据,之后的task都从本节点的BlockManager中获取相关数据。

executor的BlockManager除了从driver上拉取,也可能从其他节点的BlockManager上拉取变量副本,网络距离越近越好。

使用广播变量后的性能分析

比如一个任务需要50个executor,1000个task,共享数据为100M。

(1)在不使用广播变量的情况下,1000个task,就需要该共享数据的1000个副本,也就是说有1000份数需要大量的网络传输和内存开销存储。耗费的内存大小1000*100=100G.

(2)使用了广播变量后,50个executor就只需要50个副本数据,而且不一定都是从Driver传输到每个节点,还可能是就近从最近的节点的executor的blockmanager上拉取广播变量副本,网络传输速度大大增加;内存开销 50*100M=5G

总结:

不使用广播变量的内存开销为100G,使用后的内存开销5G,这里就相差了20倍左右的网络传输性能损耗和内存开销,使用广播变量后对于性能的提升和影响,还是很可观的。

广播变量的使用不一定会对性能产生决定性的作用。比如运行30分钟的spark作业,可能做了广播变量以后,速度快了2分钟,或者5分钟。但是一点一滴的调优,积少成多。最后还是会有效果的。

广播变量使用注意事项

  • (1)能不能将一个RDD使用广播变量广播出去?
  •        不能,因为RDD是不存储数据的。可以将RDD的结果广播出去。
  • (2)广播变量只能在Driver端定义,不能在Executor端定义。
  • (3)在Driver端可以修改广播变量的值,在Executor端无法修改广播变量的值。
  • (4)如果executor端用到了Driver的变量,如果不使用广播变量在Executor有多少task就有多少Driver端的变量副本。
  • (5)如果Executor端用到了Driver的变量,如果使用广播变量在每个Executor中只有一份Driver端的变量副本。

如何使用广播变量

例如

(1) 通过sparkContext的broadcast方法把数据转换成广播变量,类型为Broadcast,
    val broadcastArray: Broadcast[Array[Int]] = sc.broadcast(Array(1,2,3,4,5,6))
(2) 然后executor上的BlockManager就可以拉取该广播变量的副本获取具体的数据。
        获取广播变量中的值可以通过调用其value方法
     val array: Array[Int] = broadcastArray.value

此博文仅供学习参考,如有错误欢迎指正。

上一篇《大数据-SparkSQL(五)》

下一篇《大数据-Spark调优(二)》

你可能感兴趣的:(大数据,spark)