16、Hive数据倾斜与解决方案

数据倾斜

1、什么是数据倾斜

由于数据分布不均匀,造成数据大量的集中到一点,造成数据热点

2、数据倾斜的现象

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

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

3、数据倾斜的情况

4、数据倾斜的原因

1)、key分布不均匀

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

3)、建表时考虑不周

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

5、数据倾斜的解决方案

5.1 map端聚合

--Map 端部分聚合,相当于Combiner
hive.map.aggr = true;
--有数据倾斜的时候进行负载均衡
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 中),最后完成最终的聚合操作。

5.2 SQL语句调节

  • 如何Join

    关于驱动表的取,用join key分布最均匀的表作为驱动表
    做好列裁剪和filter操作,以达到两表做join的时候,数据量相对变小的效果。
  • 大小表Join
    使用map join让小的维度表(1000条以下的记录条数) 先进内存。在map端完成reduce.
  • 大表Join大表
    把空值的key变成一个字符串加上随机数,把倾斜的数据分到不同的reduce上,由于null值关联不上,处理后并不影响最终结果。
  • count distinct大量相同特殊值
    count distinct时,将值为空的情况单独处理,如果是计算count distinct,可以不用处理,直接过滤,在最后结果中加1。如果还有其他计算,需要进行group by,可以先将值为空的记录单独处理,再和其他计算结果进行union。
  • group by维度过小
    采用sum() group by的方式来替换count(distinct)完成计算。
  • 特殊情况特殊处理
    在业务逻辑优化效果的不大情况下,一些时候是可以将倾斜的数据单独拿出来处理。最后union回去

5.3 典型的业务场景

  • 空值产生的数据倾斜

    • 场景
    如日志中,常会有信息丢失的问题,比如日志中的 user_id,如果取其中的 user_id 和 用户表中的user_id 关联,会碰到数据倾斜的问题。
    • 解决办法
    --user_id为空的不参与关联
    
    select * from log a
    join users b
    on a.user_id is not null
    and a.user_id = b.user_id
    union all
    select * from log a
    where a.user_id is null;
    
    --赋与空值分新的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;
    
  • 不同数据类型关联产生数据倾斜
    • 场景
    用户表中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);
    

原文地址:https://blog.51cto.com/10312890/2469997

时间: 2024-10-08 04:47:55

16、Hive数据倾斜与解决方案的相关文章

Spark 数据倾斜及其解决方案

本文首发于 vivo互联网技术 微信公众号 https://mp.weixin.qq.com/s/lqMu6lfk-Ny1ZHYruEeBdA 作者简介:郑志彬,毕业于华南理工大学计算机科学与技术(双语班).先后从事过电子商务.开放平台.移动浏览器.推荐广告和大数据.人工智能等相关开发和架构.目前在vivo智能平台中心从事 AI中台建设以及广告推荐业务.擅长各种业务形态的业务架构.平台化以及各种业务解决方案. 本文从数据倾斜的危害.现象.原因等方面,由浅入深阐述Spark数据倾斜及其解决方案.

HIVE数据倾斜问题

HIVE数据倾斜问题问题状态: 未解决 背景:HDFS对文件进行了压缩,而且不添加索引.主要用HIVE进行开发. 发现的现象:sqoop从Mysql导入数据,根据ID进行平均分割,但是ID分部及其不均匀(我也不知道业务系统怎么搞得).所以导致reduce出来的文件大小严重不均匀,就是所谓的数据倾斜. 导致的问题:写HQL从该表中读取数据,发现整个job很慢.后来我查日志发现,有几个map读取数据非常慢,1G的文件大概需要1个多小时才能读取完毕. 问题分析: 由于hadoop对文件进行了lzo格式

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 的输

Hive数据倾斜的原因及主要解决方法

数据倾斜产生的原因 数据倾斜的原因很大部分是join倾斜和聚合倾斜两大类 Hive倾斜之group by聚合倾斜 原因: 分组的维度过少,每个维度的值过多,导致处理某值的reduce耗时很久: 对一些类型统计的时候某种类型的数据量特别多,其他的数据类型特别少.当按照类型进行group by的时候,会将相同的group by字段的reduce任务需要的数据拉取到同一个节点进行聚合,而当其中每一组的数据量过大时,会出现其他组的计算已经完成而这个reduce还没有计算完成,其他的节点一直等待这个节点的

[Hive]Hive数据倾斜(大表join大表)

业务背景 用户轨迹工程的性能瓶颈一直是etract_track_info,其中耗时大户主要在于trackinfo与pm_info进行左关联的环节,trackinfo与pm_info两张表均为GB级别,左关联代码块如下: from trackinfo a left outer join pm_info b on (a.ext_field7 = b.id) 使用以上代码块需要耗时1.5小时. 优化流程 第一次优化 考虑到pm_info表的id是bigint类型,trackinfo表的ext_fiel

hive大数据倾斜总结

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

hive高级操作(优化,数据倾斜优化)

2019/2/21 星期四 hive高级操作(优化,数据倾斜优化) 分区表/桶表应用,skew,map-join //见hive的基本语法行列转换 hive 优化hive 优化思想Explain 的使用经典案例(distinct count) 数据倾斜的原因操作:关键词 情形 后果1.Join 其中一个表较小,但是key 集中分发到某一个或几个Reduce 上的数据远高于平均值 :2.大表与大表,但是分桶的判断字段0 值或空值过多这些空值都由一个reduce 处理,非常慢:3.group by

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

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