Hive数据倾斜

最新推荐文章于 2024-05-21 00:00:00 发布

日月交辉

最新推荐文章于 2024-05-21 00:00:00 发布

阅读量765

点赞数 23

分类专栏： Hive 文章标签： hive hadoop 数据仓库 big data mapreduce 大数据

本文链接：https://blog.csdn.net/weixin_45705483/article/details/135834446

版权

Hive 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

数据倾斜

what

“倾斜”来自于统计学里的的偏态分布
数据分布不均匀，大量数据集中到一点，造成数据热点

怎么判断/主要表现

查看日志/任务监控页面，reduce节点大部分执行完毕，少数几个运行很慢或卡在某个进度（例如reduce = 80%/99%），导致整个任务的处理时间很长

因为reduce处理的记录数比平均记录数大几倍，最长时间远大于平均时长
某一个key的条数比其他key多很多(百倍、千倍)

why

key分布不均匀
业务数据本身的特性
建表考虑不周全
某些 HQL 语句本身就存在数据倾斜

map端：一般不会。对应一个逻辑切片
reduce端：很容易产生数据倾斜

本质：MR的数据倾斜
不患多而患不均

小表join大表

倾斜场景

如果小表的数据量比较少但key却比较集中，这就会导致分发到某一个或几个reduce上的数据比其他reduce多很多，造成数据倾斜

优化

使用map join将小表装入内存，在map端完成join操作，这样就避免了reduce操作

map join不能解决的

动态一分为二：不倾斜的键值正常join，倾斜的键值把它们找出来，做map join，最后union all其结果

缺点：这种解决方案比较麻烦，代码会变得复杂而且需要一个临时表存放倾斜的键值

大表join大表

不同数据类型关联

倾斜场景

int join int、string，默认的hash操作会按照int类型的id进行分配，这样就会导致所有的string类型的id被分到同一个reducer当中

优化

select * 
from user a left outer join log b 
on b.user_id = cast(a.user_id as string);

异常值（null/0）

倾斜场景：一张表异常值比较多（阈值），容易shuffle给一个reduce，造成运行慢
优化：对异常值赋值来分散key
Example
比如日志中缺失信息的user_id和用户表user_id关联
null赋值成string +随机数
1）分配给多个reduce去执行
2）null值关联不上，处理后并不影响最终结果

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

group by

倾斜场景：group by字段的某些值特别多，会将相同值拉到同一个reduce任务进行聚合

优化

开启map端聚合：hive.map.aggr=true（Hive 0.3默认）
在map端聚合的条目：set hive.groupby.mapaggr.checkinterval=100000（默认）
group by有数据倾斜时进行负载均衡：hive.groupby.skewindata=true（默认false）

distinct转group by

why

count(distinct)是用一个reduce任务完成，如果是大数量就会导致整个job很难完成
distinct本身会有一个全局排序的过程，导致计算效率很低

优化：group by替代distinct

-- 问题
select 
  count(distinct city) as cnt 
from user_list_detail 
where city is not null;

-- 解决
select count(*) cnt
from
  (select city
  from user_list_detail
  where city is not null
  group by city)tmp