了解数据倾斜和常用手段

• 什么是数据倾斜
• 数据倾斜的原因
• Hadoop计算框架的特点
• 优化的常用手段
• 优化案例

1.什么是数据倾斜

我们在用hive取数的时候，有的时候只是跑一个简单的join语句，但是却跑了很长的时间，有的时候我们会觉得是集群资源不够导致的，但是很大情况下就是出现了"数据倾斜"的情况。

在了解数据倾斜之前，我们应该有一个常识，就是现实生活中的数据分布是不均匀的，俗话说"28定理"，80%的财富集中在20%的人手中之类的故事相信大家都看得不少。所以，在我们日常处理的现实数据中，也是符合这种数据分布的，数据倾斜一般有两种情况：

变量值很少： 单个变量值的占比极大，常见的字段如性别、学历、年龄等。
变量值很多： 单个变量值的占比极小，常见的字段如收入、订单金额之类的。
数据倾斜，在MapReduce编程模型中十分常见，就是大量的相同key被partition分配到一个分区里，造成了"一个人累死,其他人闲死"的情况，这违背了并行计算的初衷，整体的效率是十分低下的。

2.数据倾斜的原因

当我们看任务进度长时间维持在99%（或100%），查看任务监控页面就会发现只有少量（1个或几个）reduce子任务未完成。因为其处理的数据量和其他reduce差异过大，这就是数据倾斜的直接表现。

而导致这个的原因，大致可以分为下面几点：

key分布不均匀
业务数据本身的特性
建表时考虑不周
某些SQL语句本身就有数据倾斜

3.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亿数据。

4.优化的常用手段

说的是优化手段，但更多的是"踩坑"的经验之谈。

优化之道：

首先要了解数据分布，自己动手解决数据倾斜问题是个不错的选择；
增加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 中），最后完成最终的聚合操作。
SQL语句调节：

如何Join：
关于驱动表的选取，选用join key分布最均匀的表作为驱动表；
做好列裁剪和filter操作，以达到两表做join的时候，数据量相对变小的效果。
大小表Join：
使用map join让小的维度表（1000条以下的记录条数） 先进内存。在map端完成reduce。
大表Join大表：
把空值的key变成一个字符串加上随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，处理后并不影响最终结果。
count distinct大量相同特殊值：
count distinct时，将值为空的情况单独处理，如果是计算count distinct，可以不用处理，直接过滤，在最后结果中加1。如果还有其他计算，需要进行group by，可以先将值为空的记录单独处理，再和其他计算结果进行union。
group by维度过小：
采用sum() group by的方式来替换count(distinct)完成计算。
特殊情况特殊处理：
在业务逻辑优化效果的不大情况下，有些时候是可以将倾斜的数据单独拿出来处理。最后union回去。
看完上面的经验总结还是有点懵逼？说实话我也是的，太多的信息量冲击，不过我们可以收藏起来以后继续看多几次，加深印象。

接下来，我们将从一些具体的案例来讲讲SQL语句优化的技巧，非常常用，对我们日常写SQL很有帮助。

5.优化案例

场景1：RAC常用（real application clusters的缩写，译为“实时应用集群”）

有一张user表，为卖家每天收入表，user_id，dt(日期)为key，属性有主营类目（cat），指标有交易金额，交易比数。每天要取每个user的主营类目在过去10天的总收入，总比数。

常规做法：取每个user_id最近一天的主营类目，存入临时表t1，汇总过去10天的总交易金额，交易比数，存入临时表t2，连接t1,t2，得到最终的结果。

优化做法：

SELECT user_id