spark数据倾斜问题解决以及造成的spark OOM问题

朴灿烈づ我的快乐病毒、 2023-02-18 11:53 61阅读 0赞

> 参考资料  
> https://tech.meituan.com/2016/05/12/spark-tuning-pro.html （美团的文章，获益匪浅）  
> https://blog.csdn.net/yisun123456/article/details/86699502

# 前言 #

对于spark而言，出现倾斜之类的问题并不陌生。大部分task很快就能完成，但是极少部分的task耗费了大部分的时间，甚至会出现OOM的场景，今天来模拟这种场景并提出解决办法

# 模拟场景 #

##### 1、相关代码 #####

val session = SparkSession
          .builder().enableHiveSupport().getOrCreate()
    
        val frame = session.read.csv("/user/zgh/ceshi/data.csv")
    
        val value = frame.rdd.map(x=>(x,1)).groupByKey().map(w => (w._1, w._2.sum))
    
        value.saveAsHadoopFile("/user/zgh/result",classOf[Text],classOf[IntWritable],classOf[TextOutputFormat[Text,IntWritable]])
        session.close()

其实就是单纯的做了一个groupBykey并进行统计。

##### 2、数据模拟和情景 #####

我这边造了2种数据  
1、458M的数据，1条别的数据，1000W条其他相同的数据  
2、4个G的数据, 1条别的数据，8000W条其他相同的数据  
来模拟上述的情况

458M的数据很慢50S完成，shuffle write 38M，发生在stage2中，别的task都很快，而有一个耗时了26S，这就是数据倾斜造成的结果，数据的拉取和计算都发生在这个节点上。  
![image.png][]  
![image.png][image.png 1]

4个G的数据更甚，直接发生了报错，java.lang.OutOfMemoryError: Java heap space 这里不贴详细的图，就是所需的内存不够

# 解决方法 #

### 前提 ###

我们在解决之前先说一下shuffle write和shuffle read(主要针对UI界面)，我在https://stackoverflow.com/questions/27276884/what-is-shuffle-read-shuffle-write-in-apache-spark 找到了参考  
shuffle操作是spark stage阶段数据的重新分配  
Shuffle Write 是所有的executors 在一个stage结束时写入的所有序列化数据的总和  
Shuffle Read 是所有的executors在一个stage开始的时候读取到的所有序列化数据的总和

##### 1、提高shuffle操作的并行度 #####

提高shuffle操作的并行度其实就是相当于增加分区数，相当于每个task中处理的数据变少，自然而然的也就减少了倾斜的情况。比如如果原本有5个key，每个key对应10条数据，这5个key都是分配给一个task的，那么这个task就要处理50条数据。而增加了shuffle read task以后，每个task就分配到一个key，即每个task就处理10条数据，那么自然每个task的执行时间都会变短了。  
比如我将上述的代码

> val value = frame.rdd.map(x=>(x,1)).groupByKey().map(w => (w.\_1, w.\_2.sum))

变成了

> val value = frame.rdd.map(x=>(x,1)).repartition(200).groupByKey().map(w => (w.\_1, w.\_2.sum))

这样的话相当于将数据重分区为200个分区，每个task处理的数据相应变少。但是我发现加上了这个条件，相应的并没有得到优化，最后一步骤中，还是将最后的38M数据全部拉取到了一个task中执行。那其实说明一个问题，如果碰到我这种极端问题的话，单个Key对应了巨大的数据，增加并行度并不能解决这个问题。其实细想也能明白，重分区默认是hash分区，不管怎么分配，相同的数据还是到一个分区里面的。

##### 2、过滤掉少数导致数据倾斜的key值 #####

这种情况在我做电信项目的时候遇到过，使用的场景就是导致数据倾斜的key值本身没有用或者对数据分析没有影响，所以我们在使用前可以将key值过滤掉。  
之前电信的项目项目是使用spark sql 做的，经常会有join的操作，由于数据的不规范性，所以在两表关联的时候两边都会有""。这样的话，比如两表均有1W个"“的话，那么  
就会造成join完以后有突然有了1W\*1W行的数据，所以看UI界面，就会有task多了很大量的数据，造成了倾斜的现象。所以这种倾斜的情况可以通过提前过滤掉”" 字段来处理。

##### 3、两阶段聚合(前缀或者后缀) #####

**这种情况适合聚合操作**。这里我们采取的措施是给全部的数据加上前缀或者后缀。相当于在一阶段先进行一次聚合统计，然后再二阶段再对处理过的数据进行聚合操作。这样的话，进行两阶段聚合将能大大的减少数据被拉取到一个task的数据量。也就解决了数据倾斜的问题。

如果上述的代码被我改造成

val random=new Random()
    
        val value_linshi = frame.rdd.map(x=>(x+"_"+random.nextInt(10),1)).groupByKey().map(w => (w._1, w._2.sum))
    
        val value = value_linshi.map(x=>(x._1.split("_")(0),x._2)).groupByKey().map(w => (w._1, w._2.sum))

一项是UI的情况，改变明显，只需要18S的时间，比之前缩短了很多。

![image.png][image.png 2]

# 倾斜为什么会OOM #

倾斜会造成慢，为什么4G的数据会OOM呢，这激起了我的好奇心。

> /opt/beh/core/spark/bin/spark-submit --master yarn --class com.example.sparklearn.Test --num-executors 1 --executor-memory 2g --executor-cores 2 /home/hadoop/zgh/sparklearn-0.0.1-SNAPSHOT.jar

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plbmc2MzI1OTk4_size_16_color_FFFFFF_t_70]

这个是我的执行命令参数，每个core中相当于分配了1g的内存，而且shuffle write后写出了321M的序列化数据，这些数据将会被一个core自己独占拉取到一个task中(看我之前自己的造的4G数据的情况可知)  
然后报java.lang.OutOfMemoryError: Java heap space。这个和spark内存模型有关系，这块我会专门开一章讲解，这里简单说下原因  
**原因：**  
shuffer read去获取数据是会边拉取数据一边聚合，这边有一块聚合内存（executor memory \* 0.2）,也就是这块内存不够  
所以当我吧executor-memory 设置成4G 也就是一个core占用2g的时候就能跑成功任务了。因为2g\*0.2> 321M么

[image.png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xNDcyNzkzNi0yMzdiMDA5OTcwNDUwMThjLnBuZw?x-oss-process=image/format,png
[image.png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xNDcyNzkzNi0xNjkwNWY3YWEwMWI3N2FlLnBuZw?x-oss-process=image/format,png
[image.png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xNDcyNzkzNi05MzAzNmUzMzg1MTY1ODUzLnBuZw?x-oss-process=image/format,png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plbmc2MzI1OTk4_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200617171705798.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3plbmc2MzI1OTk4,size_16,color_FFFFFF,t_70