正常的数据分布理论上都是倾斜的，就是我们所说的20-80原理：80%的财富集中在20%的人手中, 80%的用户只使用20%的功能 , 20%的用户贡献了80%的访问量。
Mapreduce程序在运行的时候，运行了大部分，但是还有部分reduce还在运行，甚至长时间运行，最终导致整个程序运行时间很长才结束。
reduce程序处理的key的条数比其他key的条数大很多，这也就造成了分配到数据巨大的key的节点长时间运行。本质讲数据倾斜就是数据分布不均。
不同的数据字段可能的数据倾斜一般有两种情况:
一种是唯一值非常少，极少数值有非常多的记录值(唯一值少于几千)
一种是唯一值比较多，这个字段的某些值有远远多于其他值的记录数，但是它的占比也小于百分之一或千分之一
1. 增加reduce 的jvm内存
2. 增加reduce 个数
3. customer partition
4. 其他优化的讨论.
5. reduce sort merge排序算法的讨论
6. 正在实现中的hive skewed join.
7. pipeline
8. distinct
9. index 尤其是bitmap index
方式1：增加reduce 的jvm内存
http://blog.csdn.net/jiewuyou/article/details/50592233
既然reduce 本身的计算需要以合适的内存作为支持，在硬件环境容许的情况下，增加 reduce 的内存大小显然有改善数据倾斜的可能，这种方式尤其适合数据分布第一种情况，单个值有大量记录, 这种值的所有纪录已经超过了分配给reduce 的内存，无论你怎么样分区这种情况都不会改变。
方式2: 增加reduce 个数
这个对于数据分布第二种情况有效，唯一值较多，单个唯一值的记录数不会超过分配给 reduce 的内存. 如果发生了偶尔的数据倾斜情况，增加reduce 个数可以缓解偶然情况下的某些reduce 不小心分配了多个较多记录数的情况. 但是对于第一种数据分布无效。
方式3：自定义partition
如果map输出键的单词来源于一本书。其 中大部分必然是省略词（stopword： a，the，or）。那么就可以将自定义分区将这部分省略词发送给固定的一部分reduce实例。而将其他的都发送给剩余的reduce实例。
方式4:设定combiner
减少流向reduce的文件数量，从而减轻reduce数据倾斜。
