Spark数据倾斜解决方案

数据倾斜带来的后果

1、OOM，一般OOM都是由于数据倾斜所致
2、速度变慢

数据倾斜表现：

任务分配不均匀，个别Task处理大量数据（OOM）

数据倾斜如何定位

1.WebUI 可以清晰看出每个task执行多少数据量
2.log日志，可以精准定位OOM产生的数据行，同时也可以看出哪个stage出现了数据倾斜
3.走读代码，重点分析reducebykey,groupbykey,join等
4.分析数据分布

数据倾斜解决方案：

单一key，大小表（广播或者Mapsidejoin）
tachyon,复用RDD
大表jion大表
1、采样算法解决数据倾斜的思想
2、采样算法在Spark数据倾斜中的具体操作

某个或某几个Key的Value非常大，从而导致数据倾斜
RDD1和RDD2进行join操作，其中我们采用采样的方式发现RDD1中有严重的数据倾斜的Key
第一步:采用Spark RDD中提供的采样接口，我们可以很方便的对全体（例如100亿条数据）进行采样，然后基于采样的数据，我们可以计算出哪个（哪些）Key的Value个数最多；
第二步：把全体数据分成两部分，即把原来RDD1变成RDD11和RDD12，其中RDD11代表导致数据倾斜的Key，RDD12中包含的是不会产生数据倾斜的Key；
第三步：把RDD11和RDD2进行join操作，且把RDD12和RDD2进行join操作，然后把分别join操作后的结果进行Union操作，从而得出和RDD1与RDD2直接进行join操作相同的结果
思考：在上述过程中如果把倾斜的Key加上随机数，会怎么样？
增加随机数，并行Task数量可能增加，具体是如何操作的？
RDD11中倾斜的Key加上1000以内的随机数，然后和RDD2进行join操作？不行！此时一定需要把RDD11中的Key在RDD2中的相同的Key进行1000以内的随机数，然后再进行join操作，这样做的好处：让倾斜的Key更加不倾斜，在实际生产环境下，会极大的解决在两个进行join的RDD数量都很大且其中一个RDD有一个或者两三个明显倾斜的Key的情况下的数据倾斜问题。
并行度的深度使用
1、并行度的初级使用
2、并行度的高级使用

用并行度解决数据倾斜的基本应用：例如reduceByKey
改变并行度之所以能够改善数据倾斜的原因在于，如果某个Task有100个Key且数据量特别大，就极有可能导致OOM或者任务运行特别缓慢，此时如果把并行度变大，则可以分解该Task的数据量，例如把原本该Task的100个Key分解给10个Task，这个就可以减少每个Task的数据量，从而有可能解决OOM和任务慢的问题。
对于reduceByKey而言，你可以传入并行度的参数，也可以自定义Partitioner
增加Executor：改变计算资源，从仅仅数据倾斜的角度来看并不能够直接去解决数据倾斜的问题，但是也有好处，好处是可以同时并发运行更多的Task，结果是可能加快了运行速度。

用并行度解决数据倾斜的高级使用：例如reduceByKey
假设说有倾斜的Key，我们给所有的Key加上一个随机数，然后进行reduceByKey操作；此时同一个Key会有不同的随机数前缀，在进行reduceByKey操作的时候原来的一个非常大的倾斜的Key就分而治之变成若干个更小的Key，不过此时结果和原来不一样，怎么破？进行map操作，目的是把随机数前缀去掉，然后再次进行reduceByKey操作。（当然，如果你很无聊，可以再次做随机数前缀），这样我们就可以把原本倾斜的Key通过分而治之方案分散开来，最后又进行了全局聚合，在这里的本质还是通过改变并行度去解决数据倾斜的问题
1、数据倾斜解决方案总结
2、方案之外的方案
3、数据倾斜解决方案的“银弹”?

逃离Spark技术本身之外如何解决数据倾斜的问题？
之所以会有这样的想法，是因为从结果上来看，数据倾斜的产生来自于数据和数据的处理技术，前面几节课和大家分享都是数据的处理技术层面如何解决数据倾斜，因此，我们现在需要回到数据的层面去解决数据倾斜的问题。
数据本身就是Key-Value的存在方式，所谓的数据倾斜就是说某（几）个Key的Values特别多，所以如果要解决数据倾斜，实质上是解决单一的Key的Values的个数特别多的情况。新的数据倾斜解决方案由此诞生了。
1、把一个大的Key-Values数据分解成为Key-subKey-Values的方式
2、预先和其他的表进行join，将数据倾斜提前到上游的Hive ETL
3、可以把大的Key-Values中的Values组拼成为一个字符串，从而形成只有一个元素的Key-Value。
4、加一个中间适配层，当数据进来的时候进行Key的统计和动态排名，基于该排名动态调整Key分布