hive.groupby.skewindata为

如果设置hive.map.aggr为true,hive.groupby.skewindata为true,执行流程如下:

会生成两个job来执行group by,第一个job中,各个map是平均读取分片的,在map阶段对这个分片中的数据根据group by 的key进行局部聚合操作,这里就相当于Combiner操作。
在第一次的job中,map输出的结果随机分区,这样就可以平均分到reduce中
在第一次的job中,reduce中按照group by的key进行分组后聚合,这样就在各个reduce中又进行了一次局部的聚合。
因为第一个job中分区是随机的,所有reduce结果的数据的key也是随机的,所以第二个job的map读取的数据也是随机的key,所以第二个map中不存在数据倾斜的问题。
在第二个job的map中,也会进行一次局部聚合。
第二个job中分区是按照group by的key分区的,这个地方就保证了整体的group by没有问题,相同的key分到了同一个reduce中。
经过前面几个聚合的局部聚合,这个时候的数据量已经大大减少了,在最后一个reduce里进行最后的整体聚合。
————————————————
版权声明:本文为CSDN博主「鸣宇淳」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/chybin500/article/details/80988089

原文地址:https://www.cnblogs.com/jeasonit/p/12053734.html

时间: 2024-08-30 17:38:51

hive.groupby.skewindata为的相关文章

hive.groupby.skewindata环境变量与负载均衡

HiveQL 去重操作 和SQL一样,HiveQL中同样支持DISTINCT操作,如下示例:(1) SELECT count(DISTINCT uid) FROM log(2) SELECT ip, count(DISTINCT uid) FROM log GROUP BY ip(3) SELECT ip, count(DISTINCT uid, uname) FROMlog GROUP BY ip(4) SELECT ip, count(DISTINCTuid), count(DISTINCT

hive Groupby 输出未包含在groupby的字段

今天帮同事测试,发现代码里有个好用的hive 函数: collect_set 可以输出未包含在groupby里的字段.条件是,这个字段值对应于主键是唯一的. select a, collect_set(b)[0], count(*) -- 同时想输出每个主键对应的b字段 from ( select 'a' a, 'b' b from test.dual )a group by a; -- 根据a group by

Hive数据倾斜总结

倾斜的原因: 使map的输出数据更均匀的分布到reduce中去,是我们的最终目标.由于Hash算法的局限性,按key Hash会或多或少的造成数据倾斜.大量经验表明数据倾斜的原因是人为的建表疏忽或业务逻辑可以规避的. 解决思路: Hive的执行是分阶段的,map处理数据量的差异取决于上一个stage的reduce输出,所以如何将数据均匀的分配到各个reduce中,就是解决数据倾斜的根本所在 具体办法: 内存优化和I/O优化: 驱动表:使用大表做驱动表,以防止内存溢出:Join最右边的表是驱动表:

Hive优化总结

优化时,把hive sql当做map reduce程序来读,会有意想不到的惊喜. 理解hadoop的核心能力,是hive优化的根本.这是这一年来,项目组所有成员宝贵的经验总结. 长期观察hadoop处理数据的过程,有几个显著的特征: 1.不怕数据多,就怕数据倾斜. 2.对jobs数比较多的作业运行效率相对比较低,比如即使有几百行的表,如果多次关联多次汇总,产生十几个jobs,没半小时是跑不完的.map reduce作业初始化的时间是比较长的. 3.对sum,count来说,不存在数据倾斜问题.

Hive基本语法操练

建表规则如下: CREATE [EXTERNAL] TABLE [IF NOT EXISTS] table_name [(col_name data_type [COMMENT col_comment], ...)] [COMMENT table_comment] [PARTITIONED BY (col_name data_type [COMMENT col_comment], ...)] [CLUSTERED BY (col_name, col_name, ...) [SORTED BY (

hive里的优化和高级功能

在一些特定的业务场景下,使用hive默认的配置对数据进行分析,虽然默认的配置能够实现业务需求,但是分析效率可能会很低. Hive有针对性地对不同的查询进行了优化.在Hive里可以通过修改配置的方式进行优化. 以下,几种方式调优的属性. 1.列裁剪 在通过Hive读取数据的时候,并不是所有的需求都要获取表内的所有的数据.有些只需要读取所有列中的几列,而忽略其他列的的数据. 例如,表Table1包含5个列Column1.Column2.Column3.Column4.Column5.下面的语句只会在

hive\hadoop 常用命令

-1------ 后台跑程序语句: 在shell下输入: nohup hive -f  aaa.sql >bbb.log 2>&1 & 然后把sql 的脚本导入服务器上:Transfer-Zmodem upload List 相关命令:jobs:可以看到运行的任务,:cat bbb.log 可以看到这个任务运行情况 ====2================ 文件传输: 打印列名语句:set hive.cli.print.header=true; set hive.groupb

Hive优化

概述: 一个Hive查询生成多个map reduec job,一个map reduce job又有map,reduce,spill,Shuffle,sort等几个阶段,所以针对Hive查询的优化可以大致分为针对MR中单个步骤的优化(其中又会分细节),针对MR全局的优化,和针对整个查询(多MR job)的优化,下文会分别阐述. 在开始之前先把MR的流程图贴出来(摘自Hadoop权威指南),方便后面对照.另外要说明的是,这个优化知识针对Hive0.9版本,而不是后来Hortonwork发起Sting

Hive数据倾斜

map/reduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为某一个key的条数比其他key多很多(有时是百倍或者千倍之多),这条key所在的reduce节点所处理的数据量比其他节点就大很多,从而导致某几个节点迟迟运行不完,此称之为数据倾斜. 1.万能膏药:hive.groupby.skewindata=true 当选项设定为 true,生成的查询计划会有两个 MR Job. 第一个 MR Job 中,Map 的输