浅谈Hive与Spark数据倾斜

Spark中数据倾斜的现象，原因，后果？
答：
现象：
多数Task任务执行速度较快，少数Task执行时间很长，或者等待很长时间后提示你内存不足，执行失败。
原因：
1.数据问题
a.数据本身key分布不均衡，大量key值为空
b.key值设置不合理
2.spark的使用问题
a.shuffle时，task任务的并发度不够
b.设置计算方式可能有错误.
后果：
1.Spark中的stage执行时间受制于最后执行完成的Task，因此单个Task进度缓慢会拖慢整个任务的运行时间。木桶效应，短板。
2.过多的数据在同一个Task中运行，会造成executor内存溢出。

处理方案
1.针对数据问题：
a.找出异常的key值
如果任务长时间卡在最后一个或者几个任务，首先要对key值进行抽样分析，判断是由哪些key造成的。选取key，对数据进行抽样，统计出现的次数，根据出现次数大小排序取前几
例如：
df.select(“key”).sample(false,0.1).(k=>(k,1)).reduceBykey(+).map(k=>(k._2,k._1)).sortByKey(false).take(10)
如果发现多数数据分布都比较平均，个别数据比其他数据大若干个数量级，则说明有倾斜
经过分析，数据倾斜主要包括三种情况
1.null值，或者一些无意义的值，大多由这个原因引起。
2.无效数据，大量重复的测试数据或对结果影响不大的有效数据
3.有效数据，业务导致的正常数据分布

解决方案：
针对1,2，首先对数据进行过滤
针对3，需要特殊操作
a.隔离执行，将异常key过滤单独处理，处理好后和正常数据进行union操作
b.对key先添加随机值，进行操作后，去掉随机值，再执行一次操作
c.使用reduceByKey 代替 groupByKey(reduceByKey用于对每个key对应的多个value进行merge操作，最重要的是它能够在本地先进行merge操作，并且merge操作可以通过函数自定义
d.使用map join。

案例：
如果使用reduceByKey因为数据倾斜造成运行失败的问题。具体操作流程如下:
(1) 将原始的 key 转化为 key + 随机值(例如Random.nextInt)
(2) 对数据进行 reduceByKey(func)
(3) 将 key + 随机值 转成 key（使用随机数生成方法）
(4) 再对数据进行 reduceByKey(func)

案例流程分析
假设说有倾斜的key，我们给所有的key加上一个随机数，然后进行reduceByKey操作；此时同一个Key会有不同的随机数前缀，在进行reduceByKey操作的时候原来的一个非常大的倾斜的Key就分而治之变成若干个更小的Key，不过此时结果和原来不一样，怎么破？进行map操作，目的是把随机数前缀去掉，然后再次进行reduceByKey操作。（当然，如果你很无聊，可以再次做随机数前缀），这样我们就可以把原本倾斜的Key通过分而治之方案分散开来，最后又进行了全局聚合
注意1: 如果此时依旧存在问题，建议筛选出倾斜的数据单独处理。最后将这份数据与正常的数据进行union即可。
注意2: 单独处理异常数据时，可以配合使用Map Join解决。

2.针对Spark使用造成的问题
1.提高shuffle并行度
dataFrame和sparkSql可以设置spark.sql.shuffle.partitions参数控制shuffle的并发度，默认为200。
rdd操作可以设置spark.default.parallelism控制并发度，默认参数由不同的Cluster Manager控制。
局限性: 只是让每个task执行更少的不同的key。无法解决个别key特别大的情况造成的倾斜，如果某些key的大小非常大，即使一个task单独执行它，也会受到数据倾斜的困扰。

2.使用map join 代替reduce join
在小表不是特别大(取决于你的executor大小)的情况下使用，可以使程序避免shuffle的过程，自然也就没有数据倾斜的困扰了.（详细见http://blog.csdn.net/lsshlsw/article/details/50834858、http://blog.csdn.net/lsshlsw/article/details/48694893）
局限性: 因为是先将小数据发送到每个executor上，所以数据量不能太大。