相信很多接触MapReduce的朋友对‘数据倾斜’这四个字并不陌生，那么究竟什么是数据倾斜？又改怎样解决这种该死的情况呢？
何为数据倾斜？
在弄清什么是数据倾斜之前，我想让大家看看数据分布的概念：
正常的数据分布理论上都是倾斜的，就是我们所说的2-8原理：80%的财富集中在20%的人手中，80%的用户只使用20%的功能，20%的用户贡献了80%的访问量，不同的数据字段的数据倾斜一般有两种情况：
一种是唯一值非常少，极少数值有非常多大记录值；
一种是唯一值比较多，这个字段的某些值有远远多于其他值的记录数，但是它的占比也小于百分之一或千分之一
数据倾斜：
数据倾斜在MapReduce编程模型中十分常见，用通俗易懂的话来说，数据倾斜无非就是大量的相同key被partition分配到一个分区里，造成了‘一个人累死，其他人闲死’的情况，这种情况是我们不能接受的，这也违背了并行计算的初衷，首先一个节点要承受着巨大的压力，而其他节点计算完毕后要一直等待这个忙碌的节点，也拖累了整体的计算时间，可以说效率是十分低下的。
解决方案“
1. 增加jvm内存，这适用于第一种情况（唯一值非常少，极少数值有非常多的记录值），这种情况下，往往只能通过硬件的手段来进行调优，增加jvm内存可以显著提高运行效率。
2. 增加reduce的个数，这适用于第二种情况（唯一值比较多，这个字段的某些值又远远多于其他值的记录数，但是它的占比也小于百分之一或千分之一），我们知道，这种情况下，最容易造成的结果就是大量相同的key被partition到一个分区，从而一个reduce执行了大量的工作，而如果我们增加了reduce的个数，这种情况相对来说会减轻很多，毕竟计算的节点多了，就算工作量还是不均匀，那也要小很多。
3.自定义分区，这需要用户自己继承partition类，指定分区策略，这种方式效果比较显著。
4. 重新设计key，有一种方案是在map阶段时给key加上一个随机数，有了随机数的key就不会被大量的分配到同一节点，待到reduce后再把随机数去掉即可。
5. 使用combinner合并，combinner是再map阶段，reduce之前的一个中间阶段，在这个阶段可以选择性的把大量的相同key数据先进行一个合并，可以看做是local reduce，然后再交给reduce来处理，这个做的好处很多，即减轻了map端和reduce端中间的shuffle阶段的数据拉取数量，推荐使用这种方法。
