Fork me on GitHub

Spark实践 -- 性能优化基础

  1. 性能调优相关的原理讲解、经验总结;
  2. 掌握一整套Spark企业级性能调优解决方案;而不只是简单的一些性能调优技巧。
  3. 针对写好的spark作业,实施一整套数据倾斜解决方案:实际经验中积累的数据倾斜现象的表现,以及处理后的效果总结。

调优前首先要对spark的作业流程清楚:

  • Driver到Executor的结构;
Master: Driver
    |-- Worker: Executor
            |-- job
                 |-- stage
                       |-- Task Task 
  • 一个Stage内,最终的RDD有多少个partition,就会产生多少个task,一个task处理一个partition的数据;
  • 作业划分为task分到Executor上,然后一个cpu core执行一个task;
  • BlockManager负责Executor,task的数据管理,task来它这里拿数据;

1.1 资源分配

性能调优的王道:分配更多资源。

  • 分配哪些资源? executor、cpu per executor、memory per executor、driver memory
  • 在哪里分配这些资源?
    在我们在生产环境中,提交spark作业时,用的spark-submit shell脚本,里面调整对应的参数
/usr/local/spark/bin/spark-submit \
--class cn.spark.sparktest.core.WordCountCluster \
--driver-memory 1000m \     #driver的内存,影响不大,只要不出driver oom
--num-executors 3 \         #executor的数量
--executor-memory 100m \    #每个executor的内存大小
--executor-cores 3 \        #每个executor的cpu core数量
/usr/local/SparkTest-0.0.1-SNAPSHOT-jar-with-dependencies.jar \

如何调节资源分配

  • 第一种,Spark Standalone 模式下资源分配。

假如说一共20台机器,每台机器能使用4G内存,2个cpu core。

executor = 20,对应worker节点数量;
executor-memory = 4G内存,对应每个worker能用的最大内存;
executor-cores = 2,对应每个worker给每个executor能用的最多个cpu core。
  • 第二种,Yarn模式资源队列下资源调度。

应该去查看spark作业,要提交到的资源队列,大概有多少资源?
一个原则,你能使用的资源有多大,就尽量去调节到最大的大小(executor的数量,几十个到上百个不等;

为什么调节资源以后,性能可以提升?

  • num-executors:增加executor个数

    如果executor数量比较少,能够并行执行的task就少,Application的并行执行的能力就很弱。

  • executor-cores:增加每个executor的cpu core,增加了执行的并行能力

    原本20个executor,各有2个cpu core。能够并行40个task。
    现在每个executor的cpu core,增加到了5个。就能够并行执行100个task。
    执行的速度,提升了2.5倍。
    但不超过服务器的cpu core数,不然会waiting

  • executor-memory:增加每个executor的内存量

    增加了内存量以后,对性能的提升有以下几点,但是不超过分配各每个worker的内存

    1. 如果需要对RDD进行cache,可以缓存更多的数据,将更少的数据写入磁盘。
    2. 对于shuffle操作减少了磁盘IO,reduce端需要内存来存放拉取的数据并进行聚合。如果内存不够,会写入磁盘。
    3. 对于task的执行,会创建很多对象。如果内存比较小,可能会频繁导致JVM堆内存满了,然后频繁GC,垃圾回收,minor GC和full GC。速度变慢。

1.2 调节并行度

并行度:Spark作业中根据宽窄依赖拆成多个stage,各个stage的task数量,也就代表了job在各个阶段(stage)的并行度。

SparkConf conf = new SparkConf()
  .set("spark.default.parallelism", "500")

spark自己的算法给task选择Executor,Execuotr进程里面包含着task线程
举例(wordCount):
map阶段:每个task根据去找到自己需要的数据写到文件去处理。生成的文件一定是存放相同的key对应的values,相同key的values一定是进入同一个文件。
reduce阶段:每个stage1的task,会去上面生成的文件拉取数据;拉取到的数据,一定是相同key对应的数据。对相同的key,对应的values,才能去执行我们自定义的function操作(_ + _)

假设资源调到上限了,如果不调节并行度,导致并行度过低,会怎么样?

假设task设置了100个task。有50个executor,每个executor有3个cpu core。
则Application任何一个stage运行的时候,都有总数在150个cpu core,可以并行运行。
同时在运行的task只有100个。每个executor剩下的一个cpu core,并行度没有与资源相匹配,就浪费掉了。

合理的并行度的设置,应该要设置到可以完全合理的利用你的集群资源;
比如上面的例子,总共集群有150个cpu core,可以并行运行150个task。
即可以同时并行运行,还可以让每个task要处理的数据量变少。
最终,就是提升你的整个Spark作业的性能和运行速度。

官方是推荐,task数量,设置成spark application总cpu core数量的2~3倍,比如150个cpu core,基本要设置task数量为300~500;

因为有些task会运行的快一点,比如50s就完了,有些task,可能会慢一点,要1分半才运行完,如果task数量设置成cpu core总数的2~3倍,那么一个task运行完了以后,另一个task马上可以补上来,就尽量不让cpu core空闲,尽量提升spark作业运行的效率和速度,提升性能。

1.3 重构RDD架构以及RDD持久化

  1. RDD架构重构与优化:尽量复用RDD,差不多的RDD抽取为一个共同的RDD,供后面的RDD计算时,反复使用。
  2. 公共RDD一定要实现持久化,将RDD的数据缓存到内存中/磁盘中,(BlockManager),以后无论对这个RDD做多少次计算,那么都是直接取这个RDD的同一份数据。
  3. 持久化是可以进行序列化的,如果正常将数据持久化在内存中,可能会导致内存的占用过大,导致OOM。
  4. 为了数据的高可靠性,而且内存充足,可以使用双副本机制,进行持久化。

1.4 大变量进行广播,使用Kryo序列化,本地化等待时间

广播变量
session分析模块中随机抽取部分,time2sessionsRDD.flatMapToPair(),取session2extractlistMap中对应时间的list。
task执行的算子flatMapToPair算子,使用了外部的变量session2extractlistMap,每个task都要通过网络的传输获取一份变量的副本占网络资源占内存。

  • 在driver上会有一份初始的副本。
  • task在运行的时候,想要使用广播变量中的数据,此时首先会在自己本地的Executor对应的BlockManager中(负责管理某个Executor对应的内存和磁盘上的数据),尝试获取变量副本;
  • 如果本地没有,那么就从Driver远程拉取变量副本,并保存在本地的BlockManager中;
  • 此后这个executor上的task,都会直接使用本地的BlockManager中的副本。
  • BlockManager除了从driver上拉取,也可能从其他节点的BlockManager上拉取变量副本,距离越近越好。

==============

优化序列化格式
默认情况下,Spark内部是使用Java的对象输入输出流序列化机制,ObjectOutputStream / ObjectInputStream
这种默认序列化机制的好处在于,处理起来比较方便;也不需要我们手动去做什么事情,只是,你在算子里面使用的变量,必须是实现Serializable接口的,可序列化即可。
但是默认的序列化机制的效率不高速度慢;序列化数据占用的内存空间大。

Spark支持使用Kryo序列化机制。
Kryo序列化机制,比默认的Java序列化机制,速度要快,序列化后的数据要更小,大概是Java序列化机制的1/10。让网络传输的数据变少;耗费的内存资源大大减少。

Kryo序列化机制,一旦启用以后,会生效的几个地方:
1、算子函数中使用到的外部变量
2、持久化RDD时进行序列化,StorageLevel.MEMORY_ONLY_SER
3、shuffle

第一步:

SparkConf.set("spark.serializer", "org.apache.spark.serializer.KryoSerializer")

第二步,注册你使用到的,需要通过Kryo序列化的自定义类。

SparkConf.registerKryoClasses(new Class[]{CategorySortKey.class});

Kryo要求,如果要达到它的最佳性能的话,那么就一定要注册你自定义的类(比如,你的算子函数中使用到了外部自定义类型的对象变量,就要求必须注册你的类,否则Kryo达不到最佳性能)。

============

fastutil优化
由于java的集合类型在每个数据中除了数据,还有元素的位置长度等都要占用了空间,所以一般不推荐使用集合,而是使用java数组。

fastutil是扩展了Java标准集合框架(Map、List、Set;HashMap、ArrayList、HashSet)的类库,提供了特殊类型的map、set、list和queue;能够提供更小的内存占用,更快的存取速度。

Spark中应用fastutil的场景:
1、如果算子函数使用了外部变量是某种比较大的集合,那么可以考虑使用fastutil改写外部变量,首先从源头上就减少内存的占用,通过广播变量进一步减少内存占用,再通过Kryo序列化类库进一步减少内存占用。
2、在你的算子函数里,也就是task要执行的计算逻辑里面,要创建比较大的Map、List等集合,可以考虑将这些集合类型使用fastutil类库重写,减少task创建出来的集合类型的内存占用。

fastutil的使用,在pom.xml中引用fastutil的包

基本都是类似于IntList的格式,前缀就是集合的元素类型;特殊的就是Map,Int2IntMap,代表了key-value映射的元素类型。

==============

调节数据本地化等待时长

背景:所谓任务跟着数据跑,Driver对Application的每一个stage的task进行分配之前,都会计算出每个task要计算的是哪个分片数据。
分配算法会希望每个task正好分配到它要计算的数据所在的节点。
但是可能某task要分配过去的那个节点的计算资源和计算能力都满了,Spark会等待一段时间,默认情况下是3s。
超过时间了会选择一个比较差的本地化级别,将task分配到离要计算的数据所在节点比较近的一个节点,然后进行计算。

task会通过其所在节点的BlockManager来获取数据,BlockManager发现自己本地没有数据,
会通过一个getRemote()方法,通过TransferService(网络数据传输组件)从数据所在节点的BlockManager中,获取数据,通过网络传输回task所在节点。

所以我们可以调节等待时长就是让spark再等待多一下,不要到低一级的本地化级别。

spark.locality.wait.process
spark.locality.wait.node
spark.locality.wait.rack

new SparkConf()
  .set("spark.locality.wait", "10")

先用client模式,在本地就直接可以看到比较全的日志。
观察日志,spark作业的运行日志显示,观察大部分task的数据本地化级别。
如果是发现,好多的级别都是NODE_LOCAL、ANY,那么最好就去调节一下数据本地化的等待时长。
看看大部分的task的本地化级别有没有提升,spark作业的运行时间有没有缩短。
如果spark作业的运行时间反而增加了,那就还是不要调节了。

本地化级别

  • PROCESS_LOCAL:进程本地化,代码和数据在同一个进程中,也就是在同一个executor中;计算数据的task由executor执行,数据在executor的BlockManager中;性能最好
  • NODE_LOCAL:节点本地化,代码和数据在同一个节点中;比如说,数据作为一个HDFS block块,就在节点上,而task在节点上某个executor中运行;或者是,数据和task在一个节点上的不同executor中;数据需要在进程间进行传输
  • NO_PREF:对于task来说,数据从哪里获取都一样,没有好坏之分
  • RACK_LOCAL:机架本地化,数据和task在一个机架的两个节点上;数据需要通过网络在节点之间进行传输
  • ANY:数据和task可能在集群中的任何地方,而且不在一个机架中,性能最差

1.5 JVM调优

首先估计GC的影响

GC调优的第一步就是去统计GC发生的频率和GC消耗时间。
通过添加:

./bin/spark-submit \
--name "My app" \
--master local[4] \
--conf spark.eventLog.enabled=false \
--conf "spark.executor.extraJavaOptions=-XX:+PrintGCDetails -XX:+PrintGCTimeStamps" \
myApp.jar

在作业运行的时候能够看到worker的日志里面在每次GC的时候就打印出GC信息。

使用jvisualvm来监控Spark应用程序

可以看到Spark应用程序堆,线程的使用情况,看不到GC回收的次数时间什么的,从而根据这些数据去优化您的程序。

  • 在$SPARK_HOME/conf目录下配置spark-default.conf文件,加入如下配置:
    spark.driver.extraJavaOptions   -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
    
  • 启动Spark应用程序
  • 打开jvisualvm.exe监控
    在JDK安装的bin目录下有个jvisualvm.exe,双击它,然后进行配置,依次选择 文件-> 添加JMX连接,在连接文本框填上Driver机器的地址和端口

了解GC相关原理

了解更多GC调优方法前我们需要了解JVM内存管理:

  • Java堆空间被分成 Young 和 Old 两个regions。Young generation 顾名思义保存短期使用的对象,而 Old generation 用于保存有更长使用周期的对象。

  • Young generation 被细分成三个regions:[Eden, Survivor1, Survivor2]。

  • 简述GC:

    1. 当 Eden 空间满了, Eden 会进行一次较小的minor GC,依然存活的对象会从Eden and Survivor1 复制到 Survivor2。
    2. 当Survivor2的 Object 足够老或者 Survivor2 空间满了, 对象就会被移到 Old。最后当 Old 空间也接近使用完,就会发生full GC。
    3. Eden的内存太小会频繁的进行minor gc,导致有些短生命周期对象在没有被回收掉,年龄变大放到老年代了,导致full gc。
      minor gc后会将存活下来的对象,放入之前空闲的那一个survivor区域中。默认eden、survior1和survivor2的内存占比是8:1:1。如果存活下来的对象是1.5,一个survivor区域放不下。
  • GC调优的目标

    1. 保证在Old generation只存储有长期存活的RDD;
    2. Young generation有足够的空间存储短期的对象,避免full GC将作业执行时创建的短期的对象也回收掉
    3. 避免Young generation频繁minor GC
  • GC调优做法:

    1. 通过收集GC状态检查是否有大量的垃圾回收,如果在作业完成前有多次 full GC,意味着没有足够的内存给执行的task。
    2. 如果进行了多次 minorGC,分配更多的内存给Eden也许会有帮助。只要将Eden的内存E设置成大于每个task需要的内存大小,Young generation 则设置成 -Xmn=4/3*E。
    3. 如果OldGen将要完全占满,可以减少spark.memory.fraction。改变JVM的NewRatio参数,默认设置是2,表示Old generation占用了 2/3的 heap内存,应该设置得足够大超过并超过spark.memory.fraction。另外可以考虑减少Young generation的大小通过调低 -Xmn。
    4. 尝试使用G1GC 收集器 通过配置 -XX:+UseG1GC 。如果executor需要大的堆内存,那么通过配置-XX:G1HeapRegionSize来提高G1 region size 是很重要的。
    5. 如果作业从HDFS中读取数据,可通过作业使用的block大小推测使用的内存大小,读取出来的block通常是存储大小的2-3倍。如果有4个作业去使用一个HDFS的128MB的block,我们预估Eden需要43128MB。

spark-submit脚本里面,去用--conf的方式,去添加配置:

--conf spark.memory.fraction,0.6 -> 0.5 -> 0.4 -> 0.2
--conf spark.shuffle.memoryFraction=0.3

调节executor堆外内存

有时候,如果你的spark作业处理的数据量特别特别大;
然后spark作业一运行,时不时的报错,shuffle file cannot find,executor、task lost,out of memory(内存溢出);
可能是说executor的堆外内存不太够用,导致executor在运行的过程中会内存溢出;
然后导致后续的stage的task在运行的时候,可能要从一些executor中去拉取shuffle map output文件,但是executor可能已经挂掉了,关联的Block manager也没有了;spark作业彻底崩溃。

上述情况下,就可以去考虑调节一下executor的堆外内存。避免掉某些JVM OOM的异常问题。
此外,堆外内存调节的比较大的时候,对于性能来说,也会带来一定的提升。

spark-submit脚本里面,去用--conf的方式,去添加基于yarn的提交模式配置;

--conf spark.yarn.executor.memoryOverhead=2048

默认情况下,这个堆外内存上限大概是300多M;真正处理大数据的时候,这里都会出现问题,导致spark作业反复崩溃,无法运行;此时就会去调节这个参数到至少1G(1024M),甚至说2G、4G。

调节连接等待时长

我们知道 Executor,优先从自己本地关联的BlockManager中获取某份数据。
如果本地block manager没有的话,那么会通过TransferService,去远程连接其他节点上executor的block manager去获取。
正好碰到那个exeuctor的JVM在垃圾回收,就会没有响应,无法建立网络连接;
spark默认的网络连接的超时时长,是60s;
就会出现某某file。一串file id。uuid(dsfsfd-2342vs--sdf--sdfsd)。not found。file lost。
报错几次,几次都拉取不到数据的话,可能会导致spark作业的崩溃。也可能会导致DAGScheduler,反复提交几次stage。TaskScheduler,反复提交几次task。大大延长我们的spark作业的运行时间。

可以考虑在spark-submit脚本里面,调节连接的超时时长:

--conf spark.core.connection.ack.wait.timeout=300

OOM相关

Spark中的OOM问题不外乎两种情况:

  • map执行中内存溢出
  • shuffle后内存溢出,shuffle后内存溢出的shuffle操作包括join,reduceByKey,repartition等操作。

可以先理一下Spark内存模型,再总结各种OOM的情况相对应的解决办法和性能优化方面的总结。

  • map过程产生大量对象导致内存溢出

这种溢出的原因是在单个map中产生了大量的对象导致的,

例如:rdd.map(x=>for(i <- 1 to 10000) yield i.toString)

这个操作在rdd每个对象都产生了10000个对象,这肯定很容易产生内存溢出的问题。
针对这种问题,在不增加内存的情况下,可以通过减少每个Task的大小,让Executor的内存也能够装得下。
具体做法可以在会产生大量对象的map操作之前调用repartition方法,分区成更小的块传入map。

例如:rdd.repartition(10000).map(x=>for(i <- 1 to 10000) yield i.toString)。

面对这种问题注意,不能使用rdd.coalesce方法,这个方法只能减少分区,不能增加分区,不会有shuffle的过程。

  • 数据不平衡导致内存溢出

也可如上面进行repartition

  • coalesce减少分区导致内存溢出

因为hdfs中不适合存小文件,所以Spark计算后如果产生的文件太小,会调用coalesce合并文件再存入hdfs中。
这会导致一个问题:有100个文件,现在调用coalesce(10),意味着能够有100个Task,最后只产生10个文件,
因为coalesce并不是shuffle操作,意味着coalesce并不是先执行100个Task,再将Task的执行结果合并成10个,
而是从头到位只有10个Task在执行,每个Task同时一次读取10个文件,使用的内存是原来的10倍,这导致了OOM。

解决这个问题的方法是令程序按照我们想的先执行100个Task再将结果合并成10个文件,
可以通过repartition解决,调用repartition(10),
因为这就有一个shuffle的过程,shuffle前后是两个Stage,一个100个分区,一个是10个分区,就能按照我们的想法执行。

  • shuffle后内存溢出:

shuffle内存溢出的情况可以说都是shuffle后,单个文件过大导致的。
在Spark中,join,reduceByKey这一类型的过程,都会有shuffle的过程,在shuffle的使用,需要传入一个partitioner,
默认的partitioner都是HashPatitioner,默认值是父RDD中最大的分区数,这个参数通过spark.default.parallelism控制(在spark-sql中用spark.sql.shuffle.partitions) ,
spark.default.parallelism参数只对HashPartitioner有效,所以如果是别的Partitioner或者自己实现的Partitioner就不能使用spark.default.parallelism这个参数来控制shuffle的并发量了。
如果是别的partitioner导致的shuffle内存溢出,就需要从partitioner的代码增加partitions的数量。

1.6 Suffle调优

1.6.1 shuffle流程

shuffle,一定是分为两个stage来完成的。
因为这其实是个逆向的过程,不是stage决定shuffle,是shuffle决定stage。
在某个action触发job的时候,DAGScheduler会负责划分job为多个stage。划分的依据,就是如果发现有会触发shuffle操作的算子(reduceByKey)。

每一个shuffle的前半部分stage的task,每个task都会创建下一个stage的task数量相同的文件
比如下一个stage会有10个task,那么当前stage每个task都会创建10份文件;
会将同一个key对应的values,写入同一个文件中的;
不同节点上的task,也一定会将同一个key对应的values,写入下一个stage的同一个task对应的文件中。

shuffle的后半部分stage的task,每个task都会从各个节点上的task写的属于自己的那一份文件中,拉取key, value对;
然后task会有一个内存缓冲区,然后会用HashMap,进行key, values的汇聚;
task会用我们自己定义的聚合函数reduceByKey(+),把所有values进行一对一的累加;聚合出来最终的值。

1.6.2 合并map端输出文件(优化的hashShuffle)

sparConf().set("spark.shuffle.consolidateFiles", "true")

开启了map端输出文件的合并机制之后:

第一个stage,同时运行cpu core个task,比如cpu core是2个,并行运行2个task;每个task都创建下一个stage的task数量个文件;

第一个stage,并行运行的2个task执行完以后;就会执行另外两个task;另外2个task不会再重新创建输出文件;而是复用之前的task创建的map端输出文件,将数据写入上一批task的输出文件中

第二个stage,task在拉取数据的时候,就不会去拉取上一个stage每一个task为自己创建的那份输出文件了;而是拉取少量的输出文件,每个输出文件中,可能包含了多个task给自己的map端输出。

1.6.3 调节map端内存缓冲与reduce端内存占比

深入一下shuffle原理:
shuffle的map task:
输出到磁盘文件的时候,统一都会先写入每个task自己关联的一个内存缓冲区。
这个缓冲区大小,默认是32kb。当内存缓冲区满溢之后,会进行spill溢写操作到磁盘文件中去
数据量比较大的情况下可能导致多次溢写。

shuffle的reduce端task:
在拉取到数据之后,会用hashmap的数据格式,来对各个key对应的values进行汇聚的时候。
使用的就是自己对应的executor的内存,executor(jvm进程,堆),默认executor内存中划分给reduce task进行聚合的比例,是0.2。
要是拉取过来的数据很多,那么在内存中,放不下;就将在内存放不下的数据,都spill(溢写)到磁盘文件中去。
数据大的时候磁盘上溢写的数据量越大,后面在进行聚合操作的时候,很可能会多次读取磁盘中的数据,进行聚合。

怎么调节?
看Spark UI,shuffle的磁盘读写的数据量很大,就意味着最好调节一些shuffle的参数。进行调优。

set(spark.shuffle.file.buffer,64)      // 默认32k  每次扩大一倍,看看效果。
set(spark.shuffle.memoryFraction,0.2)  // 每次提高0.1,看看效果。

很多资料都会说这两个参数,是调节shuffle性能的不二选择,实际上不是这样的。
以实际的生产经验来说,这两个参数没有那么重要,shuffle的性能不是因为这方面的原因导致的。

1.6.4 HashShuffleManager与SortShuffleManager

上面我们所讲shuffle原理是指HashShuffleManager,是很过时的shuffle manager。
之前讲解的一些调优的点,比如consolidateFiles机制、map端缓冲、reduce端内存占比。这些对任何shuffle manager都是有用的。

在spark 1.5.x后,又出来了一种tungsten-sort shuffleMnager。效果跟sort shuffle manager是差不多的。
唯一的不同之处在于tungsten-sort shuffleMnager,是使用了自己实现的一套内存管理机制以及堆内存,性能上有很大的提升可以避免shuffle过程中产生的大量的OOM,GC。

SortShuffleManager与HashShuffleManager两点不同:

  1. SortShuffleManager会对每个reduce task要处理的数据,进行排序(默认的)。
  2. SortShuffleManager会一个task,只会写入一个磁盘文件,不同reduce task的数据,用offset来划分界定。

hash、sort、tungsten-sort。如何来选择?

  1. 需不需要数据默认就让spark给你进行排序?就好像mapreduce,默认就是有按照key的排序。
    如果不需要的话,其实还是建议搭建就使用最基本的HashShuffleManager,因为最开始就是考虑的是不排序,换取高性能;

2、什么时候需要用sort shuffle manager?如果你需要你的那些数据按key排序了,那么就选择这种吧。
而且要注意,reduce task的数量应该是超过200的,这样sort、merge(多个文件合并成一个)的机制,才能生效把。
但是这里要注意,你一定要自己考量一下,有没有必要在shuffle的过程中,就做这个事情,毕竟对性能是有影响的。

3、如果你不需要排序,而且你希望你的每个task输出的文件最终是会合并成一份的,你自己认为可以减少性能开销;
可以去调节bypassMergeThreshold这个阈值,比如你的reduce task数量是500,默认阈值是200,所以默认还是会进行sort和直接merge的;
可以将阈值调节成550,不会进行sort,按照hash的做法,每个reduce task创建一份输出文件,最后合并成一份文件。
(一定要提醒大家,这个参数,其实我们通常不会在生产环境里去使用,也没有经过验证说,这样的方式,到底有多少性能的提升)

4、如果你想选用sort based shuffle manager,而且你们公司的spark版本比较高,
是1.5.x版本的,那么可以考虑去尝试使用tungsten-sort shuffle manager。
看看性能的提升与稳定性怎么样。(唉,开源出来的项目都是落后了快五年了的)

总结:
1、在生产环境中,不建议大家贸然使用第三点和第四点:
2、如果你不想要你的数据在shuffle时排序,那么就自己设置一下,用hash shuffle manager。
3、如果你的确是需要你的数据在shuffle时进行排序的,那么就默认不用动,默认就是sort shuffle manager;或者是什么?如果你压根儿不care是否排序这个事儿,那么就默认让他就是sort的。调节一些其他的参数(consolidation机制)。(80%,都是用这种)

new SparkConf().set("spark.shuffle.manager", "hash")  // hash、tungsten-sort、默认为sort
new SparkConf().set("spark.shuffle.sort.bypassMergeThreshold", "550")   // 默认200

当reduce task数量少于等于200;map task创建的输出文件小于等于200的;会将所有的输出文件合并为一份文件。且不进行sort排序,节省了性能开销。

1.7 算子调优

1.7.1 MapPartitions提升Map类操作性能

这里需要稍微讲一下RDD和DataFrame的区别。
RDD强调的是不可变对象,每个RDD都是不可变的,当调用RDD的map类型操作的时候,都是产生一个新的对象。
这就导致如果对一个RDD调用大量的map类型操作的话,每个map操作会产生一个到多个RDD对象,
这虽然不一定会导致内存溢出,但是会产生大量的中间数据,增加了gc操作。
另外RDD在调用action操作的时候,会出发Stage的划分,但是在每个Stage内部可优化的部分是不会进行优化的,
例如rdd.map(+1).map(+1),这个操作在数值型RDD中是等价于rdd.map(_+2)的,但是RDD内部不会对这个过程进行优化。

DataFrame则不同,DataFrame由于有类型信息所以是可变的,并且在可以使用sql的程序中,都有除了解释器外,都会有一个sql优化器Catalyst,

上面说到的这些RDD的弊端,有一部分就可以使用mapPartitions进行优化,
mapPartitions可以同时替代rdd.map,rdd.filter,rdd.flatMap的作用,
所以在长操作中,可以在mapPartitons中将RDD大量的操作写在一起,避免产生大量的中间rdd对象,
另外是mapPartitions在一个partition中可以复用可变类型,这也能够避免频繁的创建新对象。

普通的mapToPair,当一个partition中有1万条数据,function要执行和计算1万次。
但是,使用MapPartitions操作之后,一个task仅仅会执行一次function,function一次接收所有的partition数据。只要执行一次就可以了,性能比较高。
但是MapPartitions操作,对于大量数据来说,一次传入一个function以后,可能一下子内存不够而且又没法腾出内存空间的话,可能就OOM!

在项目中,自己先去估算一下RDD的数据量,以及每个partition的量,还有自己分配给每个executor的内存资源,看看一下子内存容纳所有的partition数据。

1.7.2 使用coalesce减少分区数量

repartition 是 coalesce

从源码中可以看出repartition方法其实就是调用了coalesce方法,shuffle为true的情况. 现在假设RDD有X个分区,需要重新划分成Y个分区.
1.如果x<y,说明x个分区里有数据分布不均匀的情况,利用HashPartitioner把x个分区重新划分成了y个分区,此时,需要把shuffle设置成true才行,因为如果设置成false,不会进行shuffle操作,此时父RDD和子RDD之间是窄依赖,这时并不会增加RDD的分区.

2.如果x>y,需要先把x分区中的某些个分区合并成一个新的分区,然后最终合并成y个分区,此时,需要把coalesce方法的shuffle设置成false.

总结:如果想要增加分区的时候,可以用repartition或者coalesce+true。但是一定要有shuffle操作,分区数量才会增加。

RDD这种filter之后,RDD中的每个partition的数据量,可能都不太一样了。
问题:
1、每个partition数据量变少了,但是在后面进行处理的时候,还跟partition数量一样数量的task,来进行处理;有点浪费task计算资源。
2、每个partition的数据量不一样,会导致后面的每个task处理每个partition的时候,每个task要处理的数据量就不同,处理速度相差大,导致数据倾斜。。。。

针对上述的两个问题,能够怎么解决呢?

1、针对第一个问题,希望可以进行partition的压缩吧,因为数据量变少了,那么partition其实也完全可以对应的变少。
比如原来是4个partition,现在完全可以变成2个partition。
那么就只要用后面的2个task来处理即可。就不会造成task计算资源的浪费。

2、针对第二个问题,其实解决方案跟第一个问题是一样的;也是去压缩partition,尽量让每个partition的数据量差不多。
那么这样的话,后面的task分配到的partition的数据量也就差不多。
不会造成有的task运行速度特别慢,有的task运行速度特别快。避免了数据倾斜的问题。

主要就是用于在filter操作之后,添加coalesce算子,针对每个partition的数据量各不相同的情况,来压缩partition的数量。
减少partition的数量,而且让每个partition的数据量都尽量均匀紧凑。

1.7.3 foreachPartition优化写数据库性能

默认的foreach的性能缺陷在哪里?

  1. 对于每条数据,都要单独去调用一次function,task为每个数据都要去执行一次function函数。如果100万条数据,(一个partition),调用100万次。性能比较差。
  2. 浪费数据库连接资源。

在生产环境中,都使用foreachPartition来写数据库
1、对于我们写的function函数,就调用一次,一次传入一个partition所有的数据,但是太多也容易OOM。
2、主要创建或者获取一个数据库连接就可以
3、只要向数据库发送一次SQL语句和多组参数即可

local模式跑的时候foreachPartition批量入库会卡住,可能资源不足,因为用standalone集群跑的时候不会出现。

1.7.4 repartition 解决Spark SQL低并行度的性能问题

并行度:可以这样调节:
1、spark.default.parallelism 指定为全部executor的cpu core总数的2~3倍
2、textFile(),传入第二个参数,指定partition数量(比较少用)
但是通过spark.default.parallelism参数指定的并行度,只会在没有Spark SQL的stage中生效
Spark SQL自己会默认根据hive表对应的hdfs文件的block,自动设置Spark SQL查询所在的那个stage的并行度。

比如第一个stage,用了Spark SQL从hive表中查询出了一些数据,然后做了一些transformation操作,接着做了一个shuffle操作(groupByKey),这些都不会应用指定的并行度可能会有非常复杂的业务逻辑和算法,就会导致第一个stage的速度,特别慢;下一个stage,在shuffle操作之后,做了一些transformation操作才会变成你自己设置的那个并行度。

解决上述Spark SQL无法设置并行度和task数量的办法,是什么呢?

repartition算子,可以将你用Spark SQL查询出来的RDD,使用repartition算子时,去重新进行分区,此时可以分区成多个partition,比如从20个partition分区成100个。
就可以避免跟Spark SQL绑定在一个stage中的算子,只能使用少量的task去处理大量数据以及复杂的算法逻辑。

1.7.5 reduceByKey本地聚合介绍

reduceByKey,相较于普通的shuffle操作(比如groupByKey),它有一个特点:底层基于CombineByKey,会进行map端的本地聚合。
对map端给下个stage每个task创建的输出文件中,写数据之前,就会进行本地的combiner操作,也就是说对每一个key,对应的values,都会执行你的算子函数。

用reduceByKey对性能的提升:
1、在本地进行聚合以后,在map端的数据量就变少了,减少磁盘IO。而且可以减少磁盘空间的占用。
2、下一个stage,拉取数据的量,也就变少了。减少网络的数据传输的性能消耗。
3、在reduce端进行数据缓存的内存占用变少了,要进行聚合的数据量也变少了。

reduceByKey在什么情况下使用呢?
1、简单的wordcount程序。
2、对于一些类似于要对每个key进行一些字符串拼接的这种较为复杂的操作,可以自己衡量一下,其实有时,也是可以使用reduceByKey来实现的。
但是不太好实现。如果真能够实现出来,对性能绝对是有帮助的。

1.8 troubleshooting调优

1.8.1 控制shuffle reduce端缓冲大小以避免OOM

map端的task是不断的输出数据的,数据量可能是很大的。
但是,在map端写过来一点数据,reduce端task就会拉取一小部分数据,先放在buffer中,立即进行后面的聚合、算子函数的应用。
每次reduece能够拉取多少数据,就由buffer来决定。然后才用后面的executor分配的堆内存占比(0.2),hashmap,去进行后续的聚合、函数的执行。

reduce端缓冲默认是48MB(buffer),可能会出什么问题?
缓冲达到最大极限值,再加上你的reduce端执行的聚合函数的代码,可能会创建大量的对象。reduce端的内存中,就会发生内存溢出的问题。
这个时候,就应该减少reduce端task缓冲的大小。我宁愿多拉取几次,但是每次同时能够拉取到reduce端每个task的数量,比较少,就不容易发生OOM内存溢出的问题。

另外,如果你的Map端输出的数据量也不是特别大,然后你的整个application的资源也特别充足,就可以尝试去增加这个reduce端缓冲大小的,比如从48M,变成96M
这样每次reduce task能够拉取的数据量就很大。需要拉取的次数也就变少了。
最终达到的效果,就应该是性能上的一定程度上的提升。
设置
spark.reducer.maxSizeInFlight

1.8.2 解决JVM GC导致的shuffle文件拉取失败

比如,executor的JVM进程,内存不够了,发生GC,导致BlockManger,netty通信都停了。
下一个stage的executor,可能是还没有停止掉的,task想要去上一个stage的task所在的exeuctor,去拉取属于自己的数据,结果由于对方正在GC,就导致拉取了半天没有拉取到。
可能会报错shuffle file not found。
但是,可能下一个stage又重新提交了stage或task以后,再执行就没有问题了,因为可能第二次就没有碰到JVM在gc了。
有的时候,出现这种情况以后,会重新去提交stage、task。重新执行一遍,发现就好了。没有这种错误了。

spark.shuffle.io.maxRetries 3
spark.shuffle.io.retryWait 5s

针对这种情况,我们完全可以进行预备性的参数调节。
增大上述两个参数的值,达到比较大的一个值,尽量保证第二个stage的task,一定能够拉取到上一个stage的输出文件。
尽量避免因为gc导致的shuffle file not found,无法拉取到的问题。

1.8.3 yarn-cluster模式的JVM内存溢出无法执行问题

总结一下yarn-client和yarn-cluster模式的不同之处:
yarn-client模式,driver运行在本地机器上的;yarn-cluster模式,driver是运行在yarn集群上某个nodemanager节点上面的。
yarn-client的driver运行在本地,通常来说本地机器跟yarn集群都不会在一个机房的,所以说性能可能不是特别好;yarn-cluster模式下,driver是跟yarn集群运行在一个机房内,性能上来说,也会好一些。

实践经验,碰到的yarn-cluster的问题:

有的时候,运行一些包含了spark sql的spark作业,可能会碰到yarn-client模式下,可以正常提交运行;yarn-cluster模式下,可能是无法提交运行的,会报出JVM的PermGen(永久代)的内存溢出,会报出PermGen Out of Memory error log。

yarn-client模式下,driver是运行在本地机器上的,spark使用的JVM的PermGen的配置,是本地的spark-class文件(spark客户端是默认有配置的),JVM的永久代的大小是128M,这个是没有问题的;但是在yarn-cluster模式下,driver是运行在yarn集群的某个节点上的,使用的是没有经过配置的默认设置(PermGen永久代大小),82M。

spark-submit脚本中,加入以下配置即可:
--conf spark.driver.extraJavaOptions="-XX:PermSize=128M -XX:MaxPermSize=256M"

另外,sql有大量的or语句。可能就会出现一个driver端的jvm stack overflow。
基本上就是由于调用的方法层级过多,因为产生了非常深的,超出了JVM栈深度限制的,递归。spark sql内部源码中,在解析sqlor特别多的话,就会发生大量的递归。
建议不要搞那么复杂的spark sql语句。
采用替代方案:将一条sql语句,拆解成多条sql语句来执行。
每条sql语句,就只有100个or子句以内;一条一条SQL语句来执行。

1.9 数据倾斜条调优

1.9.1 数据倾斜的原理、现象、产生原因与定位

原因
在执行shuffle操作的时候,是按照key,来进行values的数据的输出、拉取和聚合的。
同一个key的values,一定是分配到一个reduce task进行处理的。
假如多个key对应的values,总共是90万。
可能某个key对应了88万数据,分配到一个task上去面去执行,执行很慢。而另外两个task,可能各几十个key分配到了1万数据,出现数据倾斜。
定位:在自己的程序里面找找,哪些地方用了会产生shuffle的算子,groupByKey、countByKey、reduceByKey、join。
看log,看看是执行到了第几个stage。
哪一个stage,task特别慢或者只有一部分task在工作,就能够从spark代码的stage划分,通过stage定位到你的代码,哪里发生了数据倾斜。

第一个方案:聚合源数据
做一些聚合的操作:groupByKey、reduceByKey,说白了就是对每个key对应的values执行一定的计算。

spark作业的数据来源如果是hive,可以直接在生成hive表的hive etl中,对数据进行聚合。
比如按key来分组,将key对应的所有的values,全部用一种特殊的格式,拼接到一个字符串里面去,每个key就只对应一条数据。比如

key=sessionid, value: action_seq=1|user_id=1|search_keyword=火锅|category_id=001;action_seq=2|user_id=1|search_keyword=涮肉|category_id=001”。

然后在spark中,拿到key=sessionid,values<Iterable>。

或者在hive里面就进行reduceByKey计算。
spark中就不需要再去执行groupByKey+map这种操作了。
直接对每个key对应的values字符串进行map进行你需要的操作即可。也就根本不可能导致数据倾斜。

具体怎么去在hive etl中聚合和操作,就得根据你碰到数据倾斜问题的时候,你的spark作业的源hive表的具体情况,具体需求,具体功能,具体分析。

具体对于我们的程序来说,完全可以将aggregateBySession()这一步操作,放在一个hive etl中来做,形成一个新的表。
对每天的用户访问行为数据,都按session粒度进行聚合,写一个hive sql。

在spark程序中,就不要去做groupByKey+mapToPair这种算子了
直接从当天的session聚合表中,用SparkSQL查询出来对应的数据,即可。
这个RDD在后面就可以使用了。

第二个方案:过滤导致倾斜的key
如果你能够接受某些数据,在spark作业中直接就摒弃掉,不使用。
比如说,总共有100万个key。只有2个key,是数据量达到10万的。其他所有的key,对应的数量都是几十。
这个时候,你自己可以去取舍,如果业务和需求可以理解和接受的话,在你从hive表查询源数据的时候,直接在sql中用where条件,过滤掉某几个key。
那么这几个原先有大量数据,会导致数据倾斜的key,被过滤掉之后,那么在你的spark作业中,自然就不会发生数据倾斜了。

1.9.2 提高shuffle操作的reduce并行度

将reduce task的数量,变多,就可以让每个reduce task分配到更少的数据量。
这样的话,也许就可以缓解,或者甚至是基本解决掉数据倾斜的问题。
提升shuffle reduce端并行度,怎么来操作?
在调用shuffle算子的时候,传入进去一个参数。
就代表了那个shuffle操作的reduce端的并行度。那么在进行shuffle操作的时候,就会对应着创建指定数量的reduce task。
按照log,找到发生数据倾斜的shuffle操作,给它传入一个并行度数字,这样的话,原先那个task分配到的数据,肯定会变少。就至少可以避免OOM的情况,程序至少是可以跑的。

但是没有从根本上改变数据倾斜的本质和问题。
不像第一个和第二个方案(直接避免了数据倾斜的发生)。
原理没有改变,只是说,尽可能地去缓解和减轻shuffle reduce task的数据压力,以及数据倾斜的问题。

实际生产环境中的经验。
1、如果最理想的情况下,提升并行度以后,减轻了数据倾斜的问题,那么就最好。就不用做其他的数据倾斜解决方案了。
2、不太理想的情况下,就是比如之前某个task运行特别慢,要5个小时,现在稍微快了一点,变成了4个小时;或者是原先运行到某个task,直接OOM,现在至少不会OOM了,但是那个task运行特别慢,要5个小时才能跑完。
那么,如果出现第二种情况的话,各位,就立即放弃第三种方案,开始去尝试和选择后面的方案。

1.9.3 使用随机key实现双重聚合

1、原理
第一轮聚合的时候,对key进行打散,将原先一样的key,变成不一样的key,相当于是将每个key分为多组;比如原来是

(5,44)、(6,45)、(7,45)
就可以对key添加一个随机数
(1_5,44)、(3_6,45)、(2_7,45)
针对多个组,进行key的局部聚合;
接着,再去除掉每个key的前缀,恢复成
(5,44)、(6,45)、(7,45)
然后对所有的key,进行全局的聚合。

对groupByKey、reduceByKey造成的数据倾斜,有比较好的效果。

2、使用场景
(1)groupByKey
(2)reduceByKey

1.9.4 将导致倾斜的key单独进行join

这个方案关键之处在于:
将发生数据倾斜的key,单独拉出来,放到一个RDD中去;
用这个原本会倾斜的key RDD跟其他RDD,单独去join一下,
key对应的数据,可能就会分散到多个task中去进行join操作。
这个key跟之前其他的key混合在一个RDD中时,肯定是会导致一个key对应的所有数据,都到一个task中去,就会导致数据倾斜。

这种方案什么时候适合使用?

针对你的RDD的数据,你可以自己把它转换成一个中间表,或者是直接用countByKey()的方式,你可以看一下这个RDD各个key对应的数据量;
RDD有一个或少数几个key,是对应的数据量特别多;
此时可以采用咱们的这种方案,单拉出来那个最多的key;
单独进行join,尽可能地将key分散到各个task上去进行join操作。

1.9.5 使用随机数以及扩容表进行join

这个方案是没办法彻底解决数据倾斜的,更多的,是一种对数据倾斜的缓解。
局限性:
1、因为join两个RDD都很大,就没有办法去将某一个RDD扩的特别大,一般是10倍。
2、如果就是10倍的话,那么数据倾斜问题,只能说是缓解和减轻,不能说彻底解决。

步骤:
1、选择一个RDD,要用flatMap,进行扩容,将每条数据,映射为多条数据,每个映射出来的数据,都带了一个n以内的随机数,通常来说,会选择10。
2、将另外一个RDD,做普通的map映射操作,每条数据,都打上一个10以内的随机数。
3、最后,将两个处理后的RDD,进行join操作。
4、join完以后,可以执行map操作,去将之前打上的随机数给去掉,然后再和另外一个普通RDD join以后的结果,进行union操作。

sample采样倾斜key并单独进行join
将key,从另外一个RDD中过滤出的数据,可能只有一条,或者几条,此时,咱们可以任意进行扩容,扩成1000倍。
将从第一个RDD中拆分出来的那个倾斜key RDD,打上1000以内的一个随机数。
打散成100份,甚至1000份去进行join,那么就肯定没有数据倾斜的问题了吧。
这种情况下,还可以配合上,提升shuffle reduce并行度,join(rdd, 1000)。

posted @ 2019-03-22 10:18  stillcoolme  阅读(1598)  评论(0编辑  收藏  举报