深入浅出Hive数据倾斜

我们日常使用HSQL的时候经常会遇到这样一个令人苦恼的场景：执行一个非常简单的SQL语句，任务的进度条长时间卡在99%，不确定还需多久才能结束，这种现象称之为数据倾斜。这一现象经常出现的原因在于分析师主要关注分析逻辑和数据结果的正确性，却很少关注SQL语句的执行过程与效率。

在处理海量数据的实践中，个推分析师需要解决各种困难，以高效、准确地使用SQL语句进行数据处理，在此过程中，也积累了丰厚的实战经验。本文将为你深入浅出地讲解Hive数据倾斜的原因以及解决的方法，从而帮你快速完成工作！

数据倾斜在MapReduce计算框架中经常发生。通俗理解，该现象指的是在整个计算过程中，大量相同的key被分配到了同一个任务上，造成“一个人累死、其他人闲死”的状况，这违背了分布式计算的初衷，使得整体的执行效率十分低下。

Hive的底层计算模型和框架是MapReduce。我们只有理解了MapReduce的工作原理，才能更好地对HSQL进行优化，写出高效的查询语句。

下图是 MapReduce 原理图。

我们通过对以下三条数据中的单词进行计数，来解释整个MapReduce的执行过程。

hive|spark|hive|hbase  
hadoop|hive|spark|hive
sqoop|flume|scala|scala

具体步骤如下：

1.1  MapReduce读取HDFS中的文件并进行切割，将每一行解析成一个<k,v>（初始的k值是根据偏移量来的）。

（0,"hive spark hive hbase"）
（21,"hadoop hive spark hive"）
（39,"sqoop flume scala scala"）

1.2 Map任务将1.1产生的 <k,v>值转换为新的<k,v>值，并将这个结果存入环形缓冲内存中（溢出的部分存入磁盘），具体数据如下：

(hive,1),(spark,1),(hive,1),(hbase,1);
(hadoop,1),(hive,1),(spark,1), (hive,1);
(sqoop,1),(flume,1),(scala,1), (scala,1);

1.3  Map任务将不同分区中的数据进行排序、分组，相同的 k 放到同一个集合中（溢出部分的数据存入本地磁盘），结果如下：

(hive,[1,1,1,1]),(spark,[1,1]),(hbase,[1]),(hadoop,[1]),(sqoop,[1]),(flume,[1]),(scala,[1,1])

1.4  Map任务对分组后的数据进行归约（可选）。

2.1 Reduce任务先处理多个Map任务的输出结果，再根据分区将其分配到不同的Reduce节点上（这个过程就是shuffle）；

2.2  Reduce任务对多个Map的输出结果进行合并、排序、计算，生成新的 (k,v)  值，具体如下：

(hive,4),(spark,2), (scala,2) ,(hbase,1),(hadoop,1),(sqoop,1),(flume,1)

2.3  Reduce任务会将上一步输出的<k,v>写到HDFS中，生成文件。

通过上面的介绍，相信大家已经了解了MapReduce的解析原理。日常工作中数据倾斜主要发生在Reduce阶段，而很少发生在 Map阶段，其原因是Map端的数据倾斜一般是由于HDFS数据存储不均匀造成的（公司的日志存储几乎都是均匀分块存储，每个文件大小基本固定），而Reduce阶段的数据倾斜几乎都是因为分析师没有考虑到某种key值数据量偏多的情况而导致的。

Reduce阶段最容易出现数据倾斜的两个场景分别是Join和Count Distinct。有些博客和文档将Group By也纳入其中，但是我们认为如果不使用Distinct，仅仅对分组数据进行Sum和Count操作，并不会出现数据倾斜。如果发生数据倾斜，我们首先需要调整参数，再进行负载均衡处理：

set hive.map.aggr=true；(默认为ture) （map端的Combiner ）

set hive.groupby.skewindata=true （默认为false）

解决数据倾斜首先要进行负载均衡操作，将上面两个参数设定为 true，而MapReduce进程则会生成两个额外的 MR Job，这两个任务的主要操作如下：