大数据优化之数据倾斜

数据倾斜

数据倾斜概念

在做计算的时候,数据的分散度不够(数据的Key分布不均),导致数据分布在一台或几台机器计算

症状:典型的现象就是数据reduce到99%很久不动了

数据倾斜原因

总原因:key分布不均

业务数据的特点(数据的幂律分布)

人为建表的疏忽

join、group by、count distinct等操作触发shuffle操作

一些数据倾斜解决方法

将数据均匀分配到各个reduce中是解决数据倾斜的根本所在

业务逻辑

根据业务特点,单独对特别的业务数据进行聚合

程序

count distinct操作,先转成group by,再count

left semi join使用

设置参数

hive.map.aggr = true

hive.groupby.skewindata=true

总结

如果玩大数据数据倾斜是绕不过去的一个东西,解决数据倾斜问题是大数据查询优化的一种方法

数据倾斜是key分布不均导致

把数据均匀分布到各个reduce是解决数据倾斜的根本所在

没有一劳永逸的方法,具体问题具体分析,并且需要不断调试

参考资料

漫谈千亿级数据优化实践:数据倾斜

hive大数据倾斜总结

006.hive语句优化

Hive优化总结

Changelog

181205创建

原文地址:https://www.cnblogs.com/junstudys/p/10162709.html

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

大数据优化之数据倾斜的相关文章

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

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

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

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

全闪存阵列为大数据优化

为了更好地支持大数据应用,富士通推出了针对大数据进行优化的全闪存阵列和大数据一体机,在保证整个系统高性能和高可靠的前提下,进一步提升了数据处理和分析的效率. 大数据是继云计算之后又一项将改变传统商业模式和IT应用方式的重要变革.从存储的角度看,富士通正逐渐将产品的重点向大数据倾斜,近日推出了最新的全闪存阵列ETERNUS DX200F和面向大数据的一体机MHA. 全闪存阵列ETERNUS DX200F是一款面向中小企业用户的入门级存储产品.虽然是一款入门级的产品,但是ETERNUS DX200F

Hive语法层面优化之六数据倾斜常见案例

常见案例一:空值产生的数据倾斜 日志表有一部分的user_id为空或者是0的情况,导致在用user_id进行hash分桶时,会将日志由user_id为0或者为空的数据分到一个reduce上,导致数据倾斜: 如:访户未登录时,日志中的user_id为空,用user_id和用户表的user_id进行关联的时候,会将日志中的user_id为空的数据分到一起,导致了过大的空key造成数据倾斜: 解决办法:随机函数解决数据倾斜 把空值的key变成一个字符串加上随机数(只要不与真正的end_user_id的

Hive语法层面优化之七数据倾斜总结

关键字 情形 后果 join 其中一个表较小,但key集中 分发到某一个或几个reduce上的数据远高于平均值 大表与大表关联,但是分桶的判断字段0值或空值过多 这些空值都由一个reduce处理,非常慢 group by Group by维度过小,某值的数量过多 处理某值的reduce非常耗时 count distinct 某特殊值过多 处理此特殊值的reduce耗时 Hive语法层面优化之七数据倾斜总结

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

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

MySQL大数据优化以及分解(下篇)

http://xiaorenwutest.blog.51cto.com MySQL大数据优化以及分解(下篇) 前言:在上一章的内容当中说过公司中的数据过大或者访问量过多都会导致数据库的性能降低,过多的损耗磁盘i/o和其他服务器的性能,严重会导致宕机.根据这种情况我们给出了解决方法,那么接下来我们继续: 上次说到了分表和分区:首先让我们回顾下分表和分区的区别: 分表: 将一个大表分解成若干个小表,每个小表都有独立的文件.MYD/.MYI/.frm三个文件 分区: 将存放数据的数据块变多了,表还是一

大数据开发实战:Hive优化实战3-大表join大表优化

5.大表join大表优化 如果Hive优化实战2中mapjoin中小表dim_seller很大呢?比如超过了1GB大小?这种就是大表join大表的问题.首先引入一个具体的问题场景,然后基于此介绍各自优化方案. 5.1.问题场景 问题场景如下: A表为一个汇总表,汇总的是卖家买家最近N天交易汇总信息,即对于每个卖家最近N天,其每个买家共成交了多少单,总金额是多少,假设N取90天,汇总值仅取成交单数.A表的字段有:buyer_id. seller_id.pay_cnt_90day. B表为卖家基本信

记录一次MySQL两千万数据的大表优化解决过程,提供三种解决方案

问题概述 使用阿里云rds for MySQL数据库(就是MySQL5.6版本),有个用户上网记录表6个月的数据量近2000万,保留最近一年的数据量达到4000万,查询速度极慢,日常卡死.严重影响业务. 问题前提:老系统,当时设计系统的人大概是大学没毕业,表设计和sql语句写的不仅仅是垃圾,简直无法直视.原开发人员都已离职,到我来维护,这就是传说中的维护不了就跑路,然后我就是掉坑的那个!!! 我尝试解决该问题,so,有个这个日志. 方案概述 方案一:优化现有mysql数据库.优点:不影响现有业务