大数据常见问题:数据倾斜

举报
不吃西红柿 发表于 2021/07/15 01:28:17 2021/07/15
【摘要】 offer收割系列介绍: 1、分享桥哥本人或小伙伴在面试大厂时遇到的真题,并给出参考答案!!如果能帮到大家,点赞、收藏、评论是对我最大的支持!! 2、涉及岗位:主要为大数据开发、数据仓库(桥哥干过的),其它岗位也可参考 3、涵盖技术:mysql、hadoop、hive、Spark、Flink、Kudu、Impala等...   推荐阅读: ★ ...

offer收割系列介绍

1、分享桥哥本人或小伙伴在面试大厂时遇到的真题,并给出参考答案!!如果能帮到大家,点赞、收藏、评论是对我最大的支持!!

2、涉及岗位:主要为大数据开发、数据仓库(桥哥干过的),其它岗位也可参考

3、涵盖技术:mysql、hadoop、hive、Spark、Flink、Kudu、Impala等...

 

推荐阅读

★ 数据仓库专栏:数仓方法论、实战经验、面试真题(https://blog.csdn.net/weixin_39032019/category_8871528.html

★ Python专栏:Python黑科技:爬虫、算法、小工具(https://blog.csdn.net/weixin_39032019/category_8974792.html

★ 大数据面试专栏:面试真题、开发经验、调优策略(https://blog.csdn.net/weixin_39032019/category_11048805.html

 

一、数据倾斜表现

1)hadoop中的数据倾斜表现:

  1. 有一个多几个Reduce卡住,卡在99.99%,一直不能结束。
  2. 各种container报错OOM
  3. 异常的Reducer读写的数据量极大,至少远远超过其它正常的Reducer
  4. 伴随着数据倾斜,会出现任务被kill等各种诡异的表现。

2)hive中数据倾斜

一般都发生在Sql中group by和join on上,而且和数据逻辑绑定比较深。

3)Spark中的数据倾斜

Spark中的数据倾斜,包括Spark Streaming和Spark Sql,表现主要有下面几种:

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

二、数据倾斜产生原因

我们以Spark和Hive的使用场景为例。

他们在做数据运算的时候会涉及到,count distinct、group by、join on等操作,这些都会触发Shuffle动作。一旦触发Shuffle,所有相同key的值就会被拉到一个或几个Reducer节点上,容易发生单点计算问题,导致数据倾斜。

一般来说,数据倾斜原因有以下几方面:

1)key分布不均匀

2)建表时考虑不周

我们举一个例子,就说数据默认值的设计吧,假设我们有两张表:

user(用户信息表):userid,register_ip

ip(IP表):ip,register_user_cnt

这可能是两个不同的人开发的数据表。如果我们的数据规范不太完善的话,会出现一种情况:

user表中的register_ip字段,如果获取不到这个信息,我们默认为null;

但是在ip表中,我们在统计这个值的时候,为了方便,我们把获取不到ip的用户,统一认为他们的ip为0。

两边其实都没有错的,但是一旦我们做关联了,这个任务会在做关联的阶段,也就是sql的on的阶段卡死。

3)业务数据激增

比如订单场景,我们在某一天在北京和上海两个城市多了强力的推广,结果可能是这两个城市的订单量增长了10000%,其余城市的数据量不变。

然后我们要统计不同城市的订单情况,这样,一做group操作,可能直接就数据倾斜了。

三、解决数据倾斜思路

很多数据倾斜的问题,都可以用和平台无关的方式解决,比如更好的数据预处理异常值的过滤等。因此,解决数据倾斜的重点在于对数据设计和业务的理解,这两个搞清楚了,数据倾斜就解决了大部分了

1)业务逻辑

我们从业务逻辑的层面上来优化数据倾斜,比如上面的两个城市做推广活动导致那两个城市数据量激增的例子,我们可以单独对这两个城市来做count,单独做时可用两次MR,第一次打散计算,第二次再最终聚合计算。完成后和其它城市做整合。

2)程序层面

比如说在Hive中,经常遇到count(distinct)操作,这样会导致最终只有一个Reduce任务。

我们可以先group by,再在外面包一层count,就可以了。比如计算按用户名去重后的总用户量:

(1)优化前

只有一个reduce,先去重再count负担比较大: select name,count(distinct name)from user;

(2)优化后

// 设置该任务的每个job的reducer个数为3个。Hive默认-1,自动推断。

set mapred.reduce.tasks=3;

// 启动两个job,一个负责子查询(可以有多个reduce),另一个负责count(1):

select count(1) from (select name from user group by name) tmp;

3)调参方面

Hadoop和Spark都自带了很多的参数和机制来调节数据倾斜,合理利用它们就能解决大部分问题。

详见:

1、hive 参数设置大全:https://blog.csdn.net/weixin_39032019/article/details/111912916

2、spark-submit 参数设置:https://blog.csdn.net/weixin_39032019/article/details/103371674

3、kudu 参数设置:https://blog.csdn.net/weixin_39032019/article/details/110534549

4)从业务和数据上解决数据倾斜

很多数据倾斜都是在数据的使用上造成的。我们举几个场景,并分别给出它们的解决方案。

  1. 数据有损的方法:找到异常数据,比如ip为0的数据,过滤掉
  2. 数据无损的方法:对分布不均匀的数据,单独计算
  3. hash法:先对key做一层hash,先将数据随机打散让它的并行度变大,再汇聚
  4. 数据预处理:就是先做一层数据质量处理,类似于数据仓库维度建模时,底层先处理数据质量

 

我是桥哥,专注分享大数据知识体系 & Python黑科技。

求点赞、求评论、求收藏!!

文章来源: notomato.blog.csdn.net,作者:kissme丶,版权归原作者所有,如需转载,请联系作者。

原文链接:notomato.blog.csdn.net/article/details/117199232

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。