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

参考资料
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，这就是数据倾斜造成的结果，数据的拉取和计算都发生在这个节点上。

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的时间，比之前缩短了很多。

倾斜为什么会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

这个是我的执行命令参数，每个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么