Hive数据倾斜的原因以及常用解决方案

这篇具有很好参考价值的文章主要介绍了Hive数据倾斜的原因以及常用解决方案。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

在Hadoop平台的hive数据库进行开发的时候,数据倾斜也是比较容易遇到的问题,这边文章对数据倾斜的定义以及产生的原因、对应的解决方案进行学习。

一、数据倾斜的定义

数据倾斜:数据分布不均匀,造成数据大量的集中到一点,造成数据热点。主要表现为任务进度长时间维持在 99%或者 100%的附近,查看任务监控页面,发现只有少量 reduce 子任务未完成,因为其处理的数据量和其他的 reduce 差异过大。 单一 reduce 处理的记录数和平均记录数相差太大,通常达到好几倍之多,最长时间远大 于平均时长。

二、数据倾斜产生的原因

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

三、数据倾斜的类型以及对应解决方案

1,空值产生的数据倾斜

原理:使本身为 null 的所有记录不会拥挤在同一个 reduceTask 了,会由于有替代的 随机字符串值,而分散到了多个 reduceTask 中了,由于 null 值关联不上,处理后并不影响最终结果。

示例:在日志中,常会有信息丢失的问题,比如日志中的 user_id,如果取其中的 user_id 和用户表中的 user_id 相关联,就会碰到数据倾斜的问题。

常用解决方案:
(1)user_id 为空的不参与关联

select * from log a join user b on a.user_id is not null and a.user_id = b.user_id
union all
select * from log c where c.user_id is null;

(2)赋予空值新的 key 值
原理:把空值的 key 变成一个字符串加上一个随机数,就能把造成数据倾斜的 数据分到不同的 reduce 上解决数据倾斜的问题。

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

2,不同数据类型关联产生数据倾斜

示例:用户表中 user_id 字段为 int,log 表中 user_id 为既有 string 也有 int 的类型, 当按照两个表的 user_id 进行 join 操作的时候,默认的 hash 操作会按照 int 类型的 id 进 行分配,这样就会导致所有的 string 类型的 id 就被分到同一个 reducer 当中。

把数字类型 id 转换成 string 类型的 id

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

3,join 倾斜

map join 概念:将其中做连接的小表(全量数据)分发到所有 MapTask 端进行 Join,从 而避免了 reduceTask,前提要求是内存足以装下该全量数据。

自动开启 map join 优化,由两个参数控制:

set hive.auto.convert.join=true; //设置 MapJoin 优化自动开启
set hive.mapjoin.smalltable.filesize=25000000 //设置小表不超过多大时开启 mapjoin 优化

以大表 a 和小表 b 为例,所有的 maptask 节点都装载小表 b 的所有数据,然后大表 a 的 一个数据块数据比如说是 a1 去跟 b 全量数据做链接,就省去了 reduce 做汇总的过程。 所以相对来说,在内存允许的条件下使用 map join 比直接使用 MapReduce 效率还高些, 当然这只限于做 join 查询的时候。

select /* +mapjoin(a) */ a.id aid, name, age from a join b on a.id = b.id;
select /* +mapjoin(movies) */ a.title, b.rating from movies a join ratings b on a.movieid =
b.movieid;

注意:使用 map join 解决小表(记录数少)关联大表的数据倾斜问题,这个方法使用的频率非常 高,但如果小表很大,大到 map join 会出现 bug 或异常,这时就需要特别的处理

4,group by 倾斜

group by的维度太少,某值的数量太多(如性别sex,只有男和女,group by时只有两个维度,每个维度的数据量都很大),从而导致处理某个值数据的reduce处理非常耗时。

参数调整:

hive.map.aggr = true    // Map 端部分聚合,相当于Combiner;
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,count distinct 倾斜

某特殊值较多,数据将会在一个reduce中处理,处理此特殊值的reduce耗时。

count distinct时,将值为空的情况单独处理,如果是计算count distinct,可以不用处理,直接过滤,在最后结果中加1。如果还有其他计算,需要进行group by,可以先将值为空的记录单独处理,再和其他计算结果进行union。

四、数据倾斜解决方法总结

1,参数调节:hive.map.aggr = true 在map端部分聚合。
2,参数调节:hive.groupby.skewindata=true 数据倾斜时负载均衡。
3,sql语句调节:join时选择key值分布较均匀的表作为驱动表,同时做好列裁剪和分区裁剪,以减少数据量。
4,sql语句调节:大小表join时,小表先进内存。
5,sql语句调节:大表join大表时,把key值为空的key变成一个字符串加上随机数,把倾斜的数据分到不同的reduce上,由于null值关联不上,因此处理后不影响最终结果。

五、数据倾斜解决其他方法

1,调整mapper数

mapper数量与输入文件的split数息息相关,在Hadoop源码org.apache.hadoop.mapreduce.lib.input.FileInputFormat类中可以看到split划分的具体逻辑。这里不贴代码,直接叙述mapper数是如何确定的。

可以直接通过参数mapred.map.tasks(默认值2)来设定mapper数的期望值,但它不一定会生效,下面会提到。

设输入文件的总大小为total_input_size。HDFS中,一个块的大小由参数dfs.block.size指定,默认值64MB或128MB。在默认情况下,mapper数就是:
default_mapper_num = total_input_size / dfs.block.size。
参数mapred.min.split.size(默认值1B)和mapred.max.split.size(默认值64MB)分别用来指定split的最小和最大大小。split大小和split数计算规则是:
split_size = MAX(mapred.min.split.size, MIN(mapred.max.split.size, dfs.block.size));
split_num = total_input_size / split_size。

得出mapper数:
mapper_num = MIN(split_num, MAX(default_num, mapred.map.tasks))。
可见,如果想减少mapper数,就适当调高mapred.min.split.size,split数就减少了。如果想增大mapper数,除了降低mapred.min.split.size之外,也可以调高mapred.map.tasks。
一般来讲,如果输入文件是少量大文件,就减少mapper数;如果输入文件是大量非小文件,就增大mapper数;至于大量小文件的情况,

2,调整reducer数

reducer数量的确定方法比mapper简单得多。使用参数mapred.reduce.tasks可以直接设定reducer数量,不像mapper一样是期望值。但如果不设这个参数的话,Hive就会自行推测,逻辑如下:

参数hive.exec.reducers.bytes.per.reducer用来设定每个reducer能够处理的最大数据量,默认值1G(1.2版本之前)或256M(1.2版本之后)。

参数hive.exec.reducers.max用来设定每个job的最大reducer数量,默认值999(1.2版本之前)或1009(1.2版本之后)。

得出reducer数:
reducer_num = MIN(total_input_size / reducers.bytes.per.reducer, reducers.max)。
reducer数量与输出文件的数量相关。如果reducer数太多,会产生大量小文件,对HDFS造成压力。如果reducer数太少,每个reducer要处理很多数据,容易拖慢运行时间或者造成OOM。

3,合并小文件

(1)输入阶段合并
需要更改Hive的输入文件格式,即参数hive.input.format,默认值是org.apache.hadoop.hive.ql.io.HiveInputFormat,我们改成org.apache.hadoop.hive.ql.io.CombineHiveInputFormat。
这样比起上面调整mapper数时,又会多出两个参数,分别是mapred.min.split.size.per.node和mapred.min.split.size.per.rack,含义是单节点和单机架上的最小split大小。如果发现有split大小小于这两个值(默认都是100MB),则会进行合并。具体逻辑可以参看Hive源码中的对应类。

(2)输出阶段合并
直接将hive.merge.mapfiles和hive.merge.mapredfiles都设为true即可,前者表示将map-only任务的输出合并,后者表示将map-reduce任务的输出合并。
另外,hive.merge.size.per.task可以指定每个task输出后合并文件大小的期望值,hive.merge.size.smallfiles.avgsize可以指定所有输出文件大小的均值阈值,默认值都是1GB。如果平均大小不足的话,就会另外启动一个任务来进行合并。

参考文档:https://www.jianshu.com/p/deb4a6f91d3b文章来源地址https://www.toymoban.com/news/detail-551927.html

到了这里,关于Hive数据倾斜的原因以及常用解决方案的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 第十六章 Hive生产环境优化&数据倾斜解决方案

    Hive调优作用:在保证业务结果不变的前提下,降低资源的使用量,减少任务的执行时间。 1、调优须知 (1)对于大数据计算引擎来说:数据量大不是问题, 数据倾斜是个问题。 (2)Hive的复 杂HQL底层会转换成多个MapReduce Job并行或者串行执行 ,Job数比较多的作业运行效 率相

    2024年02月12日
    浏览(25)
  • kafka千万级数据积压原因以及解决方案

    一、原因 kafka作为消息队列,其中数据积压也是经常遇到的问题之一。 我们都知道,数据积压的直接原因,一定是系统中的某个部分出现了性能问题,来不及处理上游发送的数据,才会导致数据积压。 那么我们就需要分析在使用kafka时,如何通过优化代码以及参数配置来最大

    2024年02月12日
    浏览(39)
  • 基于MapReduce的Hive数据倾斜场景以及调优方案

    通常认为当所有的map task全部完成,并且99%的reduce task完成,只剩下一个或者少数几个reduce task一直在执行,这种情况下一般都是发生了数据倾斜。 即为在整个计算过程中,大量相同的key被分配到了同一个reduce任务上造成。Hive的数据倾斜本质上是MapReduce计算引擎的数据倾斜,

    2024年02月12日
    浏览(26)
  • (15)Hive调优——数据倾斜的解决指南

    目录 前言 一、什么是数据倾斜 二、发生数据倾斜的表现 2.1 MapReduce任务 2.2 Spark任务 三、如何定位发生数据倾斜的代码 四、发生数据倾斜的原因 3.1 key分布不均匀 3.1.1 某些key存在大量相同值 3.1.2 存在大量异常值或空值 3.2 业务数据本身的特性 3.3 SQL语句本身就有数据倾斜

    2024年04月14日
    浏览(35)
  • Spark数据倾斜解决方案一:源数据预处理和过滤倾斜key

    为什么把源数据预处理和过滤掉倾斜的key两种处理倾斜的方式写到一起? 因为这两种方式在实际的项目中场景较少而且单一,对于数据源预处理,比如原本要在spark中进行聚合或join的操作,提前到hive中去做,这种方式虽然解决了spark中数据倾斜的问题,但是hive中依然也会存

    2024年02月09日
    浏览(33)
  • 万字解决Flink|Spark|Hive 数据倾斜

    此篇主要总结到Hive,Flink,Spark出现数据倾斜的表现,原因和解决办法。首先会让大家认识到不同框架或者计算引擎处理倾斜的方案。最后你会发现计算框架只是“异曲”,文末总结才是“同工之妙”。点击收藏与分享,工作和涨薪用得到!!! 数据倾斜最笼统概念就是数据的

    2024年02月03日
    浏览(28)
  • Kafka数据倾斜到某一个分区解决方案

    我们使用Kafka时,某时需要消息消费是有序的,因此在生产者投递消息时,可能会指定分区,或者指定Key,此时可能会导致数据倾斜到某一个分区。 由于Kafka消费的特性,即一个消费组,那怕此时消费组有2个以上消费者,此时同一个主分区,只能被一个消费者消费,当生产消

    2024年02月13日
    浏览(46)
  • #详细介绍!!! 造成死锁的原因以及解决方案!

    本篇主要是介绍什么是死锁,已经死锁产生的原因,如果避免死锁。根据上述的几个问题让我们来阅读本篇文章。 目录 1. 什么是死锁 2. 形成死锁的原因(四个必要条件) 3. 如果有效避免死锁   死锁主要是锁彼此间进行锁等待,导致每个锁都不能正常执行的情况 例子1:多个

    2023年04月20日
    浏览(30)
  • 浪涌电流Inrush Current产生原因以及解决方案

    1、对Inrush Current电流的直观感受 当电灯在电路中工作时,如果突然启动马达或者变压器时,会出现电灯暗一下,此时电灯出现暗的情况就是因为马达或者变压器启动时,在电路中产生较大Inrush Current,具体分析可以参考下图: 当马达刚开始上电时,转子是静止的,处于正要启

    2024年02月03日
    浏览(29)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包