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

数据倾斜:数据分布不均匀,造成数据大量的集中到一点,造成数据热点;

由于数据并不是平均分配的,会导致各个节点上处理的数据量是不均衡的,所以数据倾斜是无法避免的;

造成数据倾斜的最根本原因:key分发不均匀造成的;

常见的数据倾斜的症状

1)  Map阶段快,reduce阶段非常慢;

2)  某些map很快,某些map很慢;

3)  某些reduce很快,某些reduce很慢;

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

造成数据倾斜的常见原因

1)   key分布不均匀

2)  某些sql语句本身就有数据倾斜;

  a)  join时on关键字中个别值量很大(如:null值),同key会被分发到同一个reduce去执行造成某个节点数据量很大;----需要重点研究并优化的部分

  b)  count(distinct)在数据量很大的情况下,容易数据倾斜,因为count(distinct)是按照group by字段分组,再按照distinct字段排序。(group by也是按照key进行分发的,有的分发的数据量很大,有的数据量很小,导致数据倾斜的发生); ----有时无法避免

3)  数据在节点上分布不均匀(集群需要及时扩容,会经常有上线/下线节点的)----无法避免的

Hive语法层面优化之一数据倾斜介绍,布布扣,bubuko.com

时间: 2024-08-04 16:26:31

Hive语法层面优化之一数据倾斜介绍的相关文章

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语法层面优化之四count(distinct)引起的数据倾斜

当该字段存在大量值为null或空的记录,容易发生数据倾斜: 解决思路: count distinct时,将值为空的情况单独处理,如果是计算count distinct,可以不用处理,直接过滤,在最后结果中加1: 如果还有其他计算,需要进行group by,可以先将值为空的记录单独处理,再和其他计算结果进行union. 案例: select count(distinct end_user_id) as user_num from trackinfo; 调整为: select cast(count(

Hive语法层面优化之五分析执行计划追踪导致数据倾斜的原因

count(distinct key)案例 explain select count(distinct session_id) from trackinfo where ds=' 2013-07-21' ; STAGE DEPENDENCIES: Stage-1 is a root stage Stage-0 is a root stage STAGE PLANS: Stage: Stage-1 Map Reduce Alias -> Map Operator Tree: trackinfo T

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

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

Hive参数层面优化之二控制Reduce数

Reduce数决定中间或落地文件数,文件大小和Block大小无关. 1.Reduce个数的决定因素 reduce个数的设定极大影响任务执行效率,不指定reduce个数的情况下,Hive会猜测确定一个reduce个数,基于以下两个设定: 参数1:hive.exec.reducers.bytes.per.reducer(每个reduce任务处理的数据量,默认为1000^3=1G) 参数2:hive.exec.reducers.max(每个作业最大的reduce数,默认为999) 计算reducer数

Hive架构层面优化之四 常用复杂/低效的统计从源上给出,以避免上层作业过多计算

案例一:trackinfo,基础表处理常用的低性能UDF 背景描述:日志信息10分钟加载一次到实时日志表trackreal中(按小时分区),为了保证实时性,在加载的过程中并没有做任何的过滤处理,加载到trackreal表后再过滤非法数据.爬虫数据等,生成按天增量日志表trackinfo,然后根据不同的page_type来统计流量. 解决方案如下: select '首页', count(*) pv, #每条记录就是一条pv count(distinct session_id) uv #根据sess

Hive架构层面优化之七压缩

常见的压缩有:对中间结果压缩.对输出结果压缩. 压缩对比: 算法 压缩前/压缩后 压缩速度 解压速度 GZIP 13.4% 21MB/s 118 MB/s LZO 20.5% 135 MB/s 410 MB/s Snappy 22.2% 172 MB/s 409 MB/s Snappy介绍: Snappy 网站:http://code.google.com/p/snappy/ Snappy的前身是Zippy.虽然只是一个数据压缩库,它却被Google用于许多内部项目程,其中就包括BigTable

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

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