数据百问系列之七: 在Hive中遇到了数据倾斜该如何处理?

本次讨论的主题是: 在Hive中遇到了数据倾斜该如何处理?

问题:

你在工作中有哪些小技巧或者套路来处理数据数据倾斜问题?

分析:

本话题是一个发散性的话题,并没有限制太多的内容,主要是想跟大家讨论一下当我们在工作中遇到数据倾斜的时候,大家都是怎么处理这一类问题的,有什么小技巧或者套路来处理这一块的问题?

对于这个话题,我觉得群友们的讨论已经很极致了,所以下面的文章中我就根据大家讨论的情况及个人的一些理解对这个话题进行一个整理与总结。

首先我觉得可能需要弄懂什么是数据倾斜?
有一句话叫“80%的利润是由20%的用户提供的”,通俗点理解的话,数据倾斜无非是大量的相同key被partition分配到一个分区里,造成了’一个人累死,其他人闲死’的情况,即当其他reducer的任务都完成了的时候,还有某一个或几个reducer还在不停地工作中。表现在任务进度条上则是长时间维持在99%左右而任务监控页面尚有一个或多个的reduce子任务还没完成。

其次是HIVE中为什么会产生数据倾斜?
HIve中的数据倾斜一般表现在group by、join和count(disctinct)等操作 上,和数据逻辑的绑定比较深。而在执行这些操作时会触发shuffle动作,一旦触发,所有相同的Key就会被拉到一个或几个节点上,就很容易发生单点问题。具体的原因可以归纳为:

  • 1、Key分布不均匀:如上所说,当执行shuffle操作时,相同的key会被拉到一个或几个节点上, 如果key分布不均匀的话,那么就会造成某些节点上的数据过多,其他节点上的数据较少的情况,并产生数据倾斜的现象;
  • 2、业务数据本身就是倾斜的:举个栗子,比如某城市的销售量是其他城市的10倍,那么在统计不同城市的销售订单的时候如果直接使用group操作,可能直接就发生数据倾斜了;

最后讲讲怎么解决hive中的数据倾斜问题:

  • 1、 业务逻辑,我们从业务逻辑的层面上来优化数据倾斜
    • 有损的方法:

      • 找到异常数据,比如 ip 为 0 的数据,直接过滤掉
    • 无损的方法:

      • 对分布不均匀的数据,单独计算
      • 先对 key 做一层 hash,先将数据打散让它的并行度变大,再汇集
    • 数据预处理

像上面的栗子我们就可以单独对这个城市来做count,最后和其它城市做整合。

  • 2、程序层面,可以通过sql调优的方式来处理数据倾斜,具体表现在:

    • join时驱动表的选取:关于驱动表的选取,选用join key分布最均匀的表作为驱动表,做好列裁剪和filter操作,以达到两表做join的时候,数据量相对变小的效果。

    • 大小表Join:使用map join让小的维度表 先进内存。在map端完成reduce.

    • 大表Join大表:把空值的key变成一个字符串加上随机数,把倾斜的数据分到不同的reduce上,由于null值关联不上,处理后并不影响最终结果。

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

    • group by维度过小:采用sum() group by的方式来替换count(distinct)完成计算。

    • 特殊情况特殊处理:在业务逻辑优化效果的不大情况下,有些时候是可以将倾斜的数据单独拿出来处理。最后union回去。

  • 3、调参方面,Hadoop 和 Spark都自带了很多的参数和机制来调节数据倾斜,合理利用它们就能解决大部分问题。下面列出来Hadoop上的一些方法和思路,具体的参数和用法在官网看就行了。

    • map join 方式

    • count distinct 的操作,先转成 group,再 count

    • 万能膏药:hive.groupby.skewindata=true

    • left semi join的使用

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值