Hive数据倾斜及解决方法

1 相似网址

本人博客为日常笔记直接粘贴，未整理排版，可参考相似内容的博客。
Hive学习之路 （十九）Hive的数据倾斜

2 个人光环大数据学习

Hive面试常问：
hq语句
优化
sort by order by distribute by
分区表 分桶表的区别
内部表 外部表的区别
数据倾斜：数据分布不均匀
hive底层的执行引擎 mr：mapreduce 由两部分组成：map 、 reduce
归根结底：底层mr的数据倾斜。

map端：一个maptask处理一个切片split，不会相差太大。
reduce端：处理所有map的输出结果。reduce端的并行度：结点个数*0.95 。数据量特别大时，reduce端的并行度不高，很容易产生数据倾斜。
怎么判断程序发生了数据倾斜？
reduce停留在一个阶段很长时间不动。（如下例，一直停留在30%）
2019-06-25 17:39:34,801 Stage-1 map = 0%, reduce = 0%
2019-06-25 17:39:34,801 Stage-1 map = 50%, reduce = 0%
2019-06-25 17:39:34,801 Stage-1 map = 75%, reduce = 0%
2019-06-25 17:39:45,661 Stage-1 map = 100%, reduce = 0%, Cumulative CPU 2.76 sec
2019-06-25 17:39:45,661 Stage-1 map = 100%, reduce = 10%, Cumulative CPU 2.76 sec
2019-06-25 17:39:45,661 Stage-1 map = 100%, reduce = 20%, Cumulative CPU 2.76 sec
2019-06-25 17:39:45,661 Stage-1 map = 100%, reduce = 30%, Cumulative CPU 2.76 sec
2019-06-25 17:39:45,661 Stage-1 map = 100%, reduce = 30%, Cumulative CPU 2.76 sec
2019-06-25 17:39:45,661 Stage-1 map = 100%, reduce = 30%, Cumulative CPU 2.76 sec
2019-06-25 17:39:45,661 Stage-1 map = 100%, reduce = 30%, Cumulative CPU 2.76 sec
2019-06-25 17:39:45,661 Stage-1 map = 100%, reduce = 30%, Cumulative CPU 2.76 sec
2019-06-25 17:40:03,198 Stage-1 map = 100%, reduce = 100%, Cumulative CPU 8.55 sec

数据倾斜与 1）数据量； 2）map端key的设置；有关
hive中哪些操作容易造成数据倾斜：
join操作：

1. join关联时有null值
   select a.,b. from a join b on a.id = b.id;
   日志数据，a.id许多null值，所有null值最终都会到同一个分区中，null值特别多，会造成有null关联的那个分区数据特别多。
   如何解决：
   1) null值不参与关联，单独进行union all
   select *
   from user join log on user.id = log.userid and log.userid is not null
   union all
   select *
   from log
   where userid is null
   2)给null值加一个随机数，散列null
   null — null123
   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;
   结论：方法2比方法1效率更好，不但io少了，而且作业数也少了。解决方法1中 log读取两次，jobs是2。解决方法2 job数是1 。这个优化适合无效 id (比如 -99 , ’’, null 等) 产生的倾斜问题。把空值的 key 变成一个字符串加上随机数，就能把倾斜的数据分到不同的reduce上 ,解决数据倾斜问题。

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. 小表 关联 大表 造成数据倾斜
   这个join到底是map端的join还是reduce端的join
   map端的join效率高 并行度高 不容易产生数据倾斜
   map端的join擅长大小表关联

   set hive.auto.convert.join = true; //设置mapjoin优化自动开启

   //在设置map端join的小表的大小，只要小表的大小不超过这个值，默认都走map端的join
   set hive.mapjoin.smalltable.filesize = 25000000

   在进行关联操作的时候，两个表就类似于mr程序中 FileInputFormat.addInputPaths()
   就可以获取数据的长度—大小 如果两个表中最小表的大小不超过25M大小 默认会把小表放在缓存中 走mapjoin 如果最小表大于设置的值 默认走reduce端的join

   大表*大表关联
   切分其中一个大表 一对多 切分多的表大小25M

   表a:26M 表b:1G 默认走reduce端的jooin 这个时候可以强制走map端的join
   select
   /*+mapjoin(a)*/ #强制执行map端的join ()中代表需要加载到缓存中的数据
   a.*,b.* from a join b on a.id = b.id;

   map端的join：
   首先将小表加载到缓存中， join.addcachefile()
   在setup中读取缓存中的数据放在容器中
   在map端进行关联 不需要reduce