什么是数据倾斜
我们在用hive取数的时候，有的时候只是跑一个简单的join语句，但是却跑了很长的时间，有的时候我们会觉得是集群资源不够导致的，但是很大情况下就是出现了"数据倾斜"的情况。
数据倾斜一般有两种情况：
变量值很少： 单个变量值的占比极大，常见的字段如性别、学历、年龄等。
变量值很多： 单个变量值的占比极小，常见的字段如收入、订单金额之类的。
数据倾斜，在MapReduce编程模型中十分常见，就是大量的相同key被partition分配到一个分区里，造成了"一个人累死,其他人闲死"的情况，这违背了并行计算的初衷，整体的效率是十分低下的。
数据倾斜的原因
当我们看任务进度长时间维持在99%（或100%），查看任务监控页面就会发现只有少量（1个或几个）reduce子任务未完成。因为其处理的数据量和其他reduce差异过大，这就是数据倾斜的直接表现。
而导致这个的原因，大致可以分为下面几点：
1）key分布不均匀
2）业务数据本身的特性
3）建表时考虑不周
4）某些SQL语句本身就有数据倾斜
具体可以体现在下面的常见操作：
Hadoop计算框架的特点
在了解如何避免数据倾斜之前，我们先来看看Hadoop框架的特性：
大数据量不是大问题，数据倾斜才是大问题；
jobs数比较多的作业效率相对比较低，比如即使有几百万的表，如果多次关联多次汇总，产生十几个jobs，耗时很长。原因是map reduce作业初始化的时间是比较长的；
sum，count，max，min等UDAF（User Defined Aggregate Function：自定义函数），不怕数据倾斜问题，hadoop在map端的汇总并优化，使数据倾斜不成问题；
count（distinct），在数据量大的情况下，效率较低，如果是多count（distinct）效率更低，因为count（distinct）是按group by字段分组，按distinct字段排序，一般这种分布式是很倾斜的，比如男uv，女uv，淘宝一天30亿的pv，如果按性别分组，分配2个reduce，每个reduce处理15亿数据。
优化的常用手段
首先要了解数据分布，自己动手解决数据倾斜问题是个不错的选择；
增加jvm（Java Virtual Machine：Java虚拟机）内存，这适用于变量值非常少的情况，这种情况下，往往只能通过硬件的手段来进行调优，增加jvm内存可以显著的提高运行效率；
增加reduce的个数，这适用于变量值非常多的情况，这种情况下最容易造成的结果就是大量相同key被partition到一个分区，从而一个reduce执行了大量的工作；
重新设计key，有一种方案是在map阶段时给key加上一个随机数，有了随机数的key就不会被大量的分配到同一节点(小几率)，待到reduce后再把随机数去掉即可；
使用combiner合并。combinner是在map阶段，reduce之前的一个中间阶段，在这个阶段可以选择性的把大量的相同key数据先进行一个合并，可以看做是local reduce，然后再交给reduce来处理，减轻了map端向reduce端发送的数据量(减轻了网络带宽)，也减轻了map端和reduce端中间的shuffle阶段的数据拉取数量(本地化磁盘IO速率)；（hive.map.aggr=true）
设置合理的map reduce的task数，能有效提升性能。（比如，10w+级别的计算，用160个reduce，那是相当的浪费，1个足够）；
数据量较大的情况下，慎用count(distinct)，count(distinct)容易产生倾斜问题；
hive.groupby.skewindata=true;
有数据倾斜的时候进行负载均衡，当选项设定为 true，生成的查询计划会有两个 MR Job。第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。