大数据----“数据倾斜”的问题
一、Hadoop中的数据倾斜：
什么是数据倾斜？（见下图）
简单来说数据倾斜就是数据的key 的分化严重不均，造成一部分数据很多，一部分数据很少的局面。
举个 word count 的入门例子: 它的map 阶段就是形成 （“aaa”,1）的形式，然后在reduce 阶段进行 value 相加，得出 “aaa” 出现的次数。若进行 word count 的文本有100G，其中 80G 全部是 “aaa” 剩下 20G 是其余单词，那就会形成 80G 的数据量交给一个 reduce 进行相加，其余 20G 根据 key 不同分散到不同 reduce 进行相加的情况。如此就造成了数据倾斜，临床反应就是 reduce 跑到 99%然后一直在原地等着 那80G 的reduce 跑完。
这里如果详细的看日志或者和监控界面的话会发现：
有一个多几个reduce卡住
各种container报错OOM
读写的数据量极大，至少远远超过其它正常的reduce
伴随着数据倾斜，会出现任务被kill等各种诡异的表现。
二、导致的原因分为几种情况：
1.单个值有大量记录
单个值有大量记录, 这种值的所有纪录已经超过了分配给reduce 的内存，无论你怎么样分区这种情况都不会改变. 当然这种情况的限制也非常明显, 1.内存的限制存在，2.可能会对集群其他任务的运行产生不稳定的影响.
解决方法：(1)增加reduce 的jvm内存（效果可能不好）
或者（2）在 key 上面做文章，在 map 阶段将造成倾斜的key 先分成多组，例如 aaa 这个 key,map 时随机在 aaa 后面加上 1,2,3,4 这四个数字之一，把 key 先分成四组，先进行一次运算，之后再恢复 key 进行最终运算。
（在MapReduce/spark,该方法常用）
2.唯一值较多
唯一值较多，单个唯一值的记录数不会超过分配给reduce 的内存. 如果发生了偶尔的数据倾斜情况，增加reduce 个数可以缓解偶然情况下的某些reduce 不小心分配了多个较多记录数的情况.
解决办法： 增加reduce 个数
3.以上两种都无效的情况
一个固定的组合重新定义
解决办法：自定义partitioner
4.从业务和数据上解决数据倾斜
我们能通过设计的角度尝试解决它。
(1)有损的方法：
找到异常数据，比如ip为0的数据，过滤掉
(2)无损的方法：
对分布不均匀的数据，单独计算
先对key做一层hash，先将数据打散让它的并行度变大，再汇集
(3)数据预处理;
5.平台的优化方法
1.join 操作中，使用 map join 在 map 端就先进行 join ，免得到reduce 时卡住;
2.能先进行 group 操作的时候先进行 group 操作，把 key 先进行一次 reduce,之后再进行 count 或者 distinct count 操作;
3. 设置map端输出、中间结果压缩;