hive之数据倾斜

本文深入探讨了数据倾斜现象在Hadoop和Spark中的表现及影响,如reduce阶段卡顿、内存溢出等问题,并提出了从业务逻辑、程序层面及系统参数调整等角度的解决策略,包括聚合数据源、提高shuffle并行度、随机key双重聚合等方法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

hive之数据倾斜

如果大量数据都为空会导致数据倾斜放到同一个reduce执行影响效率
• 有数据倾斜的时候进行负载均衡
• hive.groupby.skewindata = false
--表现
1剩下几个task,执行的特别特别慢,前面的task,一般1s可以执行完5个;最后发现1000个task,998,999 task,要执行1个小时,2个小时才能执行完一个task。
2有的task,就是会突然间,啪,报了一个OOM,JVM Out Of Memory,内存溢出
--
计算数据的时候,数据的分散度不够,导致大量的数据集中到了一台或者几台机器上计算,这些数据的计算速度远远低于平均计算速度,导致整个计算过程过慢。
关键因素是数据量大,可以达到千亿级
 用Hive算数据的时候reduce阶段卡在99.99%
 用SparkStreaming做实时算法时候,一直会有executor出现OOM的错误,但是其余的executor内存使用率却很低。
 
1、Hadoop中的数据倾斜
 Hadoop中的数据倾斜主要表现在ruduce阶段卡在99.99%,一直99.99%不能结束。
这里如果详细的看日志或者和监控界面的话会发现:

有一个多几个reduce卡住
各种container报错OOM
读写的数据量极大,至少远远超过其它正常的reduce
伴随着数据倾斜,会出现任务被kill等各种诡异的表现
经验: Hive的数据倾斜,一般都发生在Sql中Group和On上,而且和数据逻辑绑定比较深。

2、Spark中的数据倾斜

    Spark中的数据倾斜也很常见,这里包括Spark Streaming和Spark Sql,表现主要有下面几种:

Executor lost,OOM,Shuffle过程出错
Driver OOM
单个Executor执行时间特别久,整体任务卡在某个阶段不能结束
正常运行的任务突然失败

解决数据倾斜
    解决数据倾斜有这几个思路:
 1.业务逻辑,我们从业务逻辑的层面上来优化数据倾斜,比如上面的例子,我们单独对这两个城市来做count,最后和其它城市做整合。
2.程序层面,比如说在Hive中,经常遇到count(distinct)操作,这样会导致最终只有一个reduce,我们可以先group 再在外面包一层count,就可以了。
3.调参方面,Hadoop和Spark都自带了很多的参数和机制来调节数据倾斜,合理利用它们就能解决大部分问题。


二、解决方法一:聚合数据源
三、解决方法二:提高shuffle操作reduce并行度

四、解决方法之三:随机key实现双重聚合

五、解决方法之四:将reduce join 转换为map join

六、解决方法之五:sample采样倾斜key进行两次join

七、解决方法之六:使用随机数以及扩容表进行join
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值