Hive_数据倾斜处理

数据倾斜

使用join(map join/reduce join/group by等)聚合数据时,某一个特殊的key
(空值/特殊值)匹配到的记录过多而导致记录被分发到reduce的记录远大于平均值(总记录数平均配配到
各个reduce的值),这样在运行时reduce时某一reduce负载过大而导致运行效率远大于平均任务时常

操作导致

map join           其中一个表相对较小,但是key集中                 分配到某一个或几个reduce上的数据远高于平均值
reduce join        两个比较大的表使用分桶操作中,字段0或空值过多     这些空值都有一个reduce处理
group by           group by 维度过小,某值数量过多                处理某值的reduce非常耗时
count distinct     某特殊值过多                                 处理特殊值的reduce非常耗时

原因

1. key 值分配不均匀(业务数据本身问题)
2. 建表时考虑不周
3. 编写sql语句时使用某些聚合函数导致

表现

在运行HIVE任务时,发现少量reduce子任务迟迟未完成,原因就是数据分布,导致reduce负载不均衡

解决方案

参数调节
1. hive.map.aggr=true(提前对map部分聚合,相当于Conmbiner)
2.hive,groupby.skewindata=true
该选项生成的查询计划会有两个MR job,第一个MR job中,Map 的输出结果集被随机分布到Reduce中,每个Reduce做部分聚合操作,并输出结果,这样处理的结果是相同Group by Key 有
可能分发到不同的Reduce中,从而达到负载均衡的目的,第二个MR Job 再将预处理的数据按照Group By Key 分发到Reduce中,(这个过程可以保证相同的Group By key被分布到同一个Reduce
,最后完成最终的聚合操作)

转自: http://www.cnblogs.com/ggjucheng/archive/2013/01/03/2842860.html

时间: 2024-10-12 13:35:13

Hive_数据倾斜处理的相关文章

Hive数据倾斜总结

倾斜的原因: 使map的输出数据更均匀的分布到reduce中去,是我们的最终目标.由于Hash算法的局限性,按key Hash会或多或少的造成数据倾斜.大量经验表明数据倾斜的原因是人为的建表疏忽或业务逻辑可以规避的. 解决思路: Hive的执行是分阶段的,map处理数据量的差异取决于上一个stage的reduce输出,所以如何将数据均匀的分配到各个reduce中,就是解决数据倾斜的根本所在 具体办法: 内存优化和I/O优化: 驱动表:使用大表做驱动表,以防止内存溢出:Join最右边的表是驱动表:

Hive数据倾斜

map/reduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为某一个key的条数比其他key多很多(有时是百倍或者千倍之多),这条key所在的reduce节点所处理的数据量比其他节点就大很多,从而导致某几个节点迟迟运行不完,此称之为数据倾斜. 1.万能膏药:hive.groupby.skewindata=true 当选项设定为 true,生成的查询计划会有两个 MR Job. 第一个 MR Job 中,Map 的输

spark性能优化:数据倾斜调优

调优概述 有的时候,我们可能会遇到大数据计算中一个最棘手的问题--数据倾斜,此时Spark作业的性能会比期望差很多.数据倾斜调优,就是使用各种技术方案解决不同类型的数据倾斜问题,以保证Spark作业的性能. 数据倾斜发生时的现象 1.绝大多数task执行得都非常快,但个别task执行极慢.比如,总共有1000个task,997个task都在1分钟之内执行完了,但是剩余两三个task却要一两个小时.这种情况很常见. 2.原本能够正常执行的Spark作业,某天突然报出OOM(内存溢出)异常,观察异常

数据倾斜是多么痛?spark作业调优秘籍

目录视图 摘要视图 订阅 [观点]物联网与大数据将助推工业应用的崛起,你认同么?      CSDN日报20170703--<从高考到程序员--我一直在寻找答案>      [直播]探究Linux的总线.设备.驱动模型! 数据倾斜是多么痛?spark作业调优秘籍 2017-06-27 13:28 39人阅读 评论(0) 收藏 举报  分类: Spark(124)  原文:https://mp.weixin.qq.com/s?__biz=MzI5OTAwMTM1MQ==&mid=2456

hive大数据倾斜总结

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

Hive语法层面优化之一数据倾斜介绍

数据倾斜:数据分布不均匀,造成数据大量的集中到一点,造成数据热点: 由于数据并不是平均分配的,会导致各个节点上处理的数据量是不均衡的,所以数据倾斜是无法避免的: 造成数据倾斜的最根本原因:key分发不均匀造成的: 常见的数据倾斜的症状 1)  Map阶段快,reduce阶段非常慢: 2)  某些map很快,某些map很慢: 3)  某些reduce很快,某些reduce很慢: 4)  任务进度长时间维持在99%(或100%),查看任务监控页面,发现只有少量(1个或几个)reduce子任务未完成,

Hive语法层面优化之四count(distinct)引起的数据倾斜

当该字段存在大量值为null或空的记录,容易发生数据倾斜: 解决思路: count distinct时,将值为空的情况单独处理,如果是计算count distinct,可以不用处理,直接过滤,在最后结果中加1: 如果还有其他计算,需要进行group by,可以先将值为空的记录单独处理,再和其他计算结果进行union. 案例: select count(distinct end_user_id) as user_num from trackinfo; 调整为: select cast(count(

Spark性能优化之道——解决Spark数据倾斜(Data Skew)的N种姿势

原创文章,转载请务必将下面这段话置于文章开头处.本文转发自技术世界,原文链接 http://www.jasongj.com/spark/skew/ 摘要 本文结合实例详细阐明了Spark数据倾斜的几种场景以及对应的解决方案,包括避免数据源倾斜,调整并行度,使用自定义Partitioner,使用Map侧Join代替Reduce侧Join,给倾斜Key加上随机前缀等. 为何要处理数据倾斜(Data Skew) 什么是数据倾斜 对Spark/Hadoop这样的大数据系统来讲,数据量大并不可怕,可怕的是

Spark性能优化(2)——广播变量、本地缓存目录、RDD操作、数据倾斜

广播变量 背景 一般Task大小超过10K时(Spark官方建议是20K),需要考虑使用广播变量进行优化.大表小表Join,小表使用广播的方式,减少Join操作. 参考:Spark广播变量与累加器 Local Dir 背景 shuffle过程中,临时数据需要写入本地磁盘.本地磁盘的临时目录通过参数spark.local.dir配置. 性能优化点 spark.local.dir支持配置多个目录.配置spark.local.dir有多个目录,每个目录对应不同的磁盘,这样可以提升IO效率.另外,可以采