hive大数据倾斜总结

在做Shuffle阶段的优化过程中，遇到了数据倾斜的问题，造成了对一些情况下优化效果不明显。主要是因为在Job完成后的所得到的Counters是整个Job的总和，优化是基于这些Counters得出的平均值，而由于数据倾斜的原因造成map处理数据量的差异过大，使得这些平均值能代表的价值降低。Hive的执行是分阶段的，reduce处理数据量的差异取决于上一个stage的map输出，所以如何将数据均匀的分配到各个reduce中，就是解决数据倾斜的根本所在。规避错误来更好的运行比解决错误更高效。在查看了一些资料后，总结如下。

1数据倾斜的原因

1.1操作：

Join-1表示：表越小，那么均匀分配就越集中，就会造成关联到的大表分配不集中，那么也就说reduct分配的数据就会出现，一个很多，一个很少的现象。

Join-2表示：空值或0过多，那么它们的hash值一样，就会分配到同一个reduce上，造成数据倾斜

Group by（后面跟的字段，称为维度列），如果维度列越少，那么就像小表一样，分配比较集中，然后会很耗时。

Distinct特殊值过多，表示我专门求某一个字段，然后分发都一个reduce上，数据量越大，那么reduce处理的量就越大，就会很慢很耗时。

1.2原因：

1)、key分布不均匀

2)、业务数据本身的特性

3)、建表时考虑不周

4)、某些SQL语句本身就有数据倾斜

 

1.3表现：

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

单一reduce的记录数与平均记录数差异过大，通常可能达到3倍甚至更多。 最长时长远大于平均时长。

 

2数据倾斜的解决方案

2.1参数调节：

hive.map.aggr=true

Map 端部分聚合，相当于Combiner

（这个你们学了mapreduce底层的都懂，map-reduce传输数据受网络带宽限制）

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 中），最后完成最终的聚合操作。

（不设置负载均衡，就会出现在reduce处理很长时间，一条一条的汇总） 

设置负载均衡，在reduce阶段，先随机分发结果集，然后聚合操作部分，然后再通过groop by key最后进行总的汇总

就有点类似：（数据量越大，负载均衡优势越明显）

一个人工作，处理所有的结果，进行汇总

多个人分别汇总，然后最后交给同一个人对他们汇总的数据进行最后的汇总）

2.2 SQL语句调节：

如何Join：

关于驱动表的选取，选用join key分布最均匀的表作为驱动表

做好列裁剪和filter操作，以达到两表做join的时候，数据量相对变小的效果。

大小表Join：

使用map join让小的维度表（1000条以下的记录条数） 先进内存。在map端完成reduce.（就是所有汇总不是在reduce阶段勒，在map阶段就提前进行汇总）

大表Join大表：

把空值的key变成一个字符串加上随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，处理后并不影响最终结果。（join-2）

count distinct大量相同特殊值

count distinct时，将值为空的情况单独处理，如果是计算count distinct，可以不用处理，直接过滤，在最后结果中加1。如果还有其他计算，需要进行group by，可以先将值为空的记录单独处理，再和其他计算结果进行union all。(null值单独处理)

group by维度过小：

采用sum() group by的方式来替换count(distinct)完成计算。

案例：数据量（ 170855460）

select count(distinct uid ) from tmp_tbl_orders;  170855460

一直都在68%不动，怎么办？kill掉这个job

换一种方式：用group by   (结果：1 7085 5460)

select sum(t.totle)

from (

select

1 totle

from tmp_tbl_orders

group by uid

) t;

分为两个job，然后相对而言：速度会快很多

特殊情况特殊处理：

在业务逻辑优化效果的不大情况下，有些时候是可以将倾斜的数据单独拿出来处理。最后union all回去。

先join生成临时表，在union all还是写嵌套查询，这是个问题。比如以下例子：

Select *

From (select *

     From t1

     Uion all

     select *

     From t4

     Union all

     Select *

     From t2

     Join t3

     On t2.id = t3.id

     ) x

Group by c1,c2;

这个会有4个jobs。假如先join生成临时表的话t5,然后union all，会变成2个jobs。

Insert overwrite table t5

Select *

  From t2

  Join t3

   On t2.id = t3.id;

Select * from (t1 union all t4 union all t5) ;

hive在union all优化上可以做得更智能（把子查询当做临时表），这样可以减少开发人员的负担。出现这个问题的原因应该是union all目前的优化只局限于非嵌套查询。如果写MR程序这一点也不是问题，就是multi inputs。

 

3典型的业务场景

3.1空值产生的数据倾斜

场景：如日志中，常会有信息丢失的问题，比如日志中的 user_id，如果取其中的 user_id 和 用户表中的user_id 关联，会碰到数据倾斜的问题。

解决方法1： user_id为空的不参与关联（红色字体为修改后）

select * from log a join users b on a.user_id is not null and a.user_id = b.user_idunion allselect * from log a where a.user_id is null;       （join的说的第二种情况）

解决方法2 ：赋与空值分新的key值

select * from log a left outer join users b on case when a.user_id is null then concat(‘hive’,rand() ) else a.user_id end = b.user_id;

 （随机数，这样取hash值就负载均衡勒）

结论：方法2比方法1效率更好，不但io少了，而且作业数也少了。解决方法1中 log读取两次，jobs是2。解决方法2 job数是1 。这个优化适合无效 id (比如 -99 , ’’, null 等) 产生的倾斜问题。把空值的 key 变成一个字符串加上随机数，就能把倾斜的数据分到不同的reduce上 ,解决数据倾斜问题。

 

3.2不同数据类型关联产生数据倾斜

场景：用户表中user_id字段为int，log表中user_id字段既有string类型也有int类型。当按照user_id进行两个表的Join操作时，默认的Hash操作会按int型的id来进行分配，这样会导致所有string类型id的记录都分配到一个Reducer中。

解决方法：把数字类型转换成字符串类型

select * from users a left outer join logs b on a.usr_id = cast(b.user_id as string)

 

3.3小表不小不大，怎么用 map join 解决倾斜问题

使用 map join 解决小表(记录数少)关联大表的数据倾斜问题，这个方法使用的频率非常高，但如果小表很大，大到map join会出现bug或异常，这时就需要特别的处理。 以下例子:

select * from log a left outer join users b on a.user_id = b.user_id;

 

users 表有 600w+ 的记录，把 users 分发到所有的 map 上也是个不小的开销，而且 map join 不支持这么大的小表。如果用普通的 join，又会碰到数据倾斜的问题。

解决方法：

select /*+mapjoin(x)*/* from log a

left outer join

 ( select /*+mapjoin(c)*/d.*

from (select distinct user_id from log ) c

 join

users d

on c.user_id = d.user_id

) b

on a.user_id = b.user_id;

假如，log里user_id有上百万个，这就又回到原来map join问题。所幸，每日的会员uv不会太多，有交易的会员不会太多，有点击的会员不会太多，有佣金的会员不会太多等等。所以这个方法能解决很多场景下的数据倾斜问题。

4总结

使map的输出数据更均匀的分布到reduce中去，是我们的最终目标。由于Hash算法的局限性，按key Hash会或多或少的造成数据倾斜。大量经验表明数据倾斜的原因是人为的建表疏忽或业务逻辑可以规避的。在此给出较为通用的步骤：

1、采样log表，哪些user_id比较倾斜，得到一个结果表tmp1。由于对计算框架来说，所有的数据过来，他都是不知道数据分布情况的，所以采样是并不可少的。

2、数据的分布符合社会学统计规则，贫富不均。倾斜的key不会太多，就像一个社会的富人不多，奇特的人不多一样。所以tmp1记录数会很少。把tmp1和users做map join生成tmp2,把tmp2读到distribute file cache。这是一个map过程。

3、map读入users和log，假如记录来自log,则检查user_id是否在tmp2里，如果是，输出到本地文件a,否则生成<user_id,value>的key,value对，假如记录来自member,生成<user_id,value>的key,value对，进入reduce阶段。

4、最终把a文件，把Stage3 reduce阶段输出的文件合并起写到hdfs。

 (先把倾斜的数据单独整理出来(很穷或者很富)，然后与表users表关联，得到一个小表，进行判断，该用户是不是很穷或者很富，如果不就是就放到reduce继续处理，否则就是直接输出到本地文件a中去，最后reduce(普通的人)和a（很穷或者很富）写入到hdfs中)

如果确认业务需要这样倾斜的逻辑，考虑以下的优化方案：

1、对于join，在判断小表不大于1G的情况下，使用map join

（优点1.在map阶段就提前汇总，降低网络带宽的限制）

优点2.每日的会员uv不会太多，有交易的会员不会太多，有点击的会员不会太多，有佣金的会员不会太多等等(快速过滤的条件)

）

2、对于group by或distinct，设定 hive.groupby.skewindata=true（负载均衡）

就有点类似：（数据量越大，负载均衡优势越明显）

一个人工作，处理所有的结果，进行汇总

多个人分别汇总，然后最后交给同一个人对他们汇总的数据进行最后的汇总）

3、尽量使用上述的SQL语句调节进行优化