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(distinct end_user_id)+1 as bigint) as user_num  from trackinfo where  end_user_id is not null and end_user_id <> ‘‘;

分析:把为空的过滤掉,在总的count上加1

Multi-Count Distinct

select pid, count(distinct acookie),count(distinct ip),count(wangwangid ip) from ods_p4ppv_ad_d where dt=20140305 group by pid;

必须设置参数:set hive.groupby.skewindata=true

Hive语法层面优化之四count(distinct)引起的数据倾斜,布布扣,bubuko.com

时间: 2024-10-09 01:59:31

Hive语法层面优化之四count(distinct)引起的数据倾斜的相关文章

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

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

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架构层面优化之四 常用复杂/低效的统计从源上给出,以避免上层作业过多计算

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

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

关键字 情形 后果 join 其中一个表较小,但key集中 分发到某一个或几个reduce上的数据远高于平均值 大表与大表关联,但是分桶的判断字段0值或空值过多 这些空值都由一个reduce处理,非常慢 group by Group by维度过小,某值的数量过多 处理某值的reduce非常耗时 count distinct 某特殊值过多 处理此特殊值的reduce耗时 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参数层面优化之一控制Map数

1.Map个数的决定因素 通常情况下,作业会通过input文件产生一个或者多个map数: Map数主要的决定因素有: input总的文件个数,input文件的大小和集群中设置的block的大小(在hive中可以通过set dfs.block.size命令查看,该参数不能自定义修改): 文件块数拆分原则:如果文件大于块大小(128M),那么拆分:如果小于,则把该文件当成一个块. 举例一: 假设input目录下有1个文件a,大小为780M,那么hadoop会将该文件a分隔成7个块(6个128m的块和

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架构层面优化之二合理利用中间结果集(单Job)

是针对单个作业,针对本job再怎么优化也不会影响到其他job: Hadoop的负载主要有两部分:CPU负载和IO负载: 问题:机器io开销很大,但是机器的cpu开销较小,另外map输出文件也较大,怎么办? 解决办法:通过设置map的中间输出进行压缩就可以了,这个不会影响最终reduce的输出. 集群中的机器一旦选定了,那么CPU就没的改变了,所以集群的最主要的负载还是IO负载: 压缩技术虽然可以降低IO负载,但是同时也加重了CPU负载,治标不治本,CPU加重了,整体性能还是上不去:如果当前CPU

Hive架构层面优化之一分表

场景:某个日志表数据量很大,而且访问该表的作业比较多,造成耗时比较长: 解决方案:将用的比较少/不常用的字段剥离出去: 案例: 日志表trackinfo,每天约有2亿数据量,有5000个作业按天访问,每天的日志数据量有可能会继续添加下去,那么很可能就满足不了要求(每添加10%的数据量作业大概要添加20分钟):如何解决数据的增长呢? 方案: 将邮件营销EDM,网盟Union从trackinfo表中剥离出来,trackinfo表大概能降到1.5亿左右,这样作业的执行时间大概可以减少40-50分钟时间