Hive 基础之:分区、桶、Sort Merge Bucket Join

Hive 已是目前业界最为通用、廉价的构建大数据时代数据仓库的解决方案了,虽然也有 Impala 等后起之秀,但目前从功能、稳定性等方面来说,Hive 的地位尚不可撼动。

其实这篇博文主要是想聊聊 SMB join 的,Join 是整个 MR/Hive 最为核心的部分之一,是每个 Hadoop/Hive/DW RD 必须掌握的部分,之前也有几篇文章聊到过 MR/Hive 中的 join,其实底层都是相同的,只是上层做了些封装而已,如果你还不了解究竟 Join 有哪些方式,以及底层怎么实现的,请参考如下链接:

http://my.oschina.net/leejun2005/blog/95186 MapReduce 中的两表 join 几种方案简介

http://my.oschina.net/leejun2005/blog/111963 Hadoop 多表 join:map side join 范例

http://my.oschina.net/leejun2005/blog/158491 Hive & Performance 学习笔记

在最后一篇链接中,有这么两副图:


前面两个很好理解,基本上每个人都会接触到,但最后一种,可能有同学还是比较陌生,SMB 存在的目的主要是为了解决大表与大表间的 Join 问题,分桶其实就是把大表化成了“小表”,然后 Map-Side Join 解决之,这是典型的分而治之的思想。在聊 SMB Join 之前,我们还是先复习下相关的基础概念。

1、Hive 分区

在Hive Select查询中一般会扫描整个表内容,会消耗很多时间做没必要的工作。有时候只需要扫描表中关心的一部分数据,因此建表时引入了partition概念。分区表指的是在创建表时指定的partition的分区空间。  

Hive可以对数据按照某列或者某些列进行分区管理,所谓分区我们可以拿下面的例子进行解释。  
当前互联网应用每天都要存储大量的日志文件,几G、几十G甚至更大都是有可能。存储日志,其中必然有个属性是日志产生的日期。在产生分区时,就可以按照日志产生的日期列进行划分。把每一天的日志当作一个分区。  
将数据组织成分区,主要可以提高数据的查询速度。至于用户存储的每一条记录到底放到哪个分区,由用户决定。即用户在加载数据的时候必须显示的指定该部分数据放到哪个分区。  
1.1 实现细节
1、一个表可以拥有一个或者多个分区,每个分区以文件夹的形式单独存在表文件夹的目录下。  
2、表和列名不区分大小写。  
3、分区是以字段的形式在表结构中存在,通过describe table命令可以查看到字段存在,   但是该字段不存放实际的数据内容,仅仅是分区的表示(伪列)    
1.2 语法
1. 创建一个分区表,以 ds 为分区列:  
create table invites (id int, name string) partitioned by (ds string) row format delimited fields terminated by 't' stored as textfile;  
2. 将数据添加到时间为 2013-08-16 这个分区中:  
load data local inpath '/home/hadoop/Desktop/data.txt' overwrite into table invites partition (ds='2013-08-16');  
3. 将数据添加到时间为 2013-08-20 这个分区中:  
load data local inpath '/home/hadoop/Desktop/data.txt' overwrite into table invites partition (ds='2013-08-20');  
4. 从一个分区中查询数据:  
select * from invites where ds ='2013-08-12';  
5.  往一个分区表的某一个分区中添加数据:  
insert overwrite table invites partition (ds='2013-08-12') select id,max(name) from test group by id;  
可以查看分区的具体情况,使用命令:  
hadoop fs -ls /home/hadoop.hive/warehouse/invites  
或者:  
show partitions tablename;

2、Hive 桶

对于每一个表(table)或者分区,   Hive可以进一步组织成桶,也就是说桶是更为细粒度的数据范围划分。Hive也是   针对某一列进行桶的组织。Hive采用对列值哈希,然后除以桶的个数求余的方式决定该条记录存放在哪个桶当中。

把表(或者分区)组织成桶(Bucket)有两个理由

(1)获得更高的查询处理效率。桶为表加上了额外的结构,Hive 在处理有些查询时能利用这个结构。具体而言,连接两个在(包含连接列的)相同列上划分了桶的表,可以使用 Map 端连接 (Map-side join)高效的实现。比如JOIN操作。对于JOIN操作两个表有一个相同的列,如果对这两个表都进行了桶操作。那么将保存相同列值的桶进行JOIN操作就可以,可以大大较少JOIN的数据量。

(2)使取样(sampling)更高效。在处理大规模数据集时,在开发和修改查询的阶段,如果能在数据集的一小部分数据上试运行查询,会带来很多方便。

1. 创建带桶的 table :
create table bucketed_user(id int,name string) clustered by (id) sorted by(name) into 4 buckets row format delimited fields terminated by '\t' stored as textfile;  
首先,我们来看如何告诉Hive—个表应该被划分成桶。我们使用CLUSTERED BY 子句来指定划分桶所用的列和要划分的桶的个数:  

CREATE TABLE bucketed_user (id INT) name STRING)  
CLUSTERED BY (id) INTO 4 BUCKETS;  

在这里,我们使用用户ID来确定如何划分桶(Hive使用对值进行哈希并将结果除 以桶的个数取余数。这样,任何一桶里都会有一个随机的用户集合(PS:其实也能说是随机,不是吗?)。  

对于map端连接的情况,两个表以相同方式划分桶。处理左边表内某个桶的 mapper知道右边表内相匹配的行在对应的桶内。因此,mapper只需要获取那个桶 (这只是右边表内存储数据的一小部分)即可进行连接。这一优化方法并不一定要求 两个表必须桶的个数相同,两个表的桶个数是倍数关系也可以。用HiveQL对两个划分了桶的表进行连接,可参见“map连接”部分(P400)。  

桶中的数据可以根据一个或多个列另外进行排序。由于这样对每个桶的连接变成了高效的归并排序(merge-sort), 因此可以进一步提升map端连接的效率。以下语法声明一个表使其使用排序桶:  

CREATE TABLE bucketed_users (id INT, name STRING)  
CLUSTERED BY (id) SORTED BY (id ASC) INTO 4 BUCKETS;  

我们如何保证表中的数据都划分成桶了呢?把在Hive外生成的数据加载到划分成 桶的表中,当然是可以的。其实让Hive来划分桶更容易。这一操作通常针对已有的表。  

Hive并不检查数据文件中的桶是否和表定义中的桶一致(无论是对于桶 的数量或用于划分桶的列)。如果两者不匹配,在査询时可能会碰到错 误或未定义的结果。因此,建议让Hive来进行划分桶的操作。  

有一个没有划分桶的用户表:  
hive> SELECT * FROM users;  
0    Nat  
2    Doe  
B    Kay  
4    Ann  
2. 强制多个 reduce 进行输出:
要向分桶表中填充成员,需要将 hive.enforce.bucketing 属性设置为 true。①这   样,Hive 就知道用表定义中声明的数量来创建桶。然后使用 INSERT 命令即可。需要注意的是:   clustered by和sorted by不会影响数据的导入,这意味着,用户必须自己负责数据如何如何导入,包括数据的分桶和排序。  
'set hive.enforce.bucketing = true' 可以自动控制上一轮reduce的数量从而适配bucket的个数,当然,用户也可以自主设置mapred.reduce.tasks去适配bucket个数,推荐使用'set hive.enforce.bucketing = true'   
3. 往表中插入数据:
INSERT OVERWRITE TABLE bucketed_users SELECT * FROM users;  

物理上,每个桶就是表(或分区)目录里的一个文件。它的文件名并不重要,但是桶 n 是按照字典序排列的第 n 个文件。事实上,桶对应于 MapReduce 的输出文件分区:一个作业产生的桶(输出文件)和reduce任务个数相同。我们可以通过查看刚才 创建的bucketd_users表的布局来了解这一情况。运行如下命令:   
4. 查看表的结构:
hive> dfs -ls /user/hive/warehouse/bucketed_users;  
将显示有4个新建的文件。文件名如下(文件名包含时间戳,由Hive产生,因此 每次运行都会改变):  
attempt_201005221636_0016_r_000000_0  
attempt_201005221636_0016_r-000001_0  
attempt_201005221636_0016_r_000002_0  
attempt_201005221636_0016_r_000003_0  
第一个桶里包括用户IDO和4,因为一个INT的哈希值就是这个整数本身,在这里 除以桶数(4)以后的余数:②  
5. 读取数据,看每一个文件的数据:
hive> dfs -cat /user/hive/warehouse/bucketed_users/*0_0;  
0 Nat  
4 Ann  

用TABLESAMPLE子句对表进行取样,我们可以获得相同的结果。这个子句会将 查询限定在表的一部分桶内,而不是使用整个表:
6. 对桶中的数据进行采样:
hive> SELECT * FROM bucketed_users  
>    TABLESAMPLE(BUCKET 1 OUT OF 4 ON id);  
0 Nat  
4 Ann  

桶的个数从1开始计数。因此,前面的查询从4个桶的第一个中获取所有的用户。 对于一个大规模的、均匀分布的数据集,这会返回表中约四分之一的数据行。我们 也可以用其他比例对若干个桶进行取样(因为取样并不是一个精确的操作,因此这个 比例不一定要是桶数的整数倍)。例如,下面的查询返回一半的桶:
7. 查询一半返回的桶数:
hive> SELECT * FROM bucketed_users  
>    TABLESAMPLE(BUCKET 1 OUT OF 2 ON id);  
0 Nat  
4 Ann  
2 Joe  

因为查询只需要读取和TABLESAMPLE子句匹配的桶,所以取样分桶表是非常高效   的操作。如果使用rand()函数对没有划分成桶的表进行取样,即使只需要读取很   小一部分样本,也要扫描整个输入数据集:  

hive〉 SELECT * FROM users  
> TABLESAMPLE(BUCKET 1 OUT OF 4 ON rand());  
2 Doe  

①从Hive 0.6.0开始,对以前的版本,必须把mapred.reduce .tasks设为表中要填 充的桶的个数。如果桶是排序的,还需要把hive.enforce.sorting设为true。  
②显式原始文件时,因为分隔字符是一个不能打印的控制字符,因此字段都挤在一起。  

3、举个完整的小例子:

(1)建student & student1 表:
1 create table student(id INT, age INTname STRING)
2 partitioned by(stat_date STRING)
3 clustered by(id) sorted by(age) into 2 buckets
4 row format delimited fields terminated by ',';
5  
6 create table student1(id INT, age INTname STRING)
7 partitioned by(stat_date STRING)
8 clustered by(id) sorted by(age) into 2 buckets
9 row format delimited fields terminated by ',';
(2)设置环境变量:
set hive.enforce.bucketing = true;   
(3)插入数据:
01 cat bucket.txt
02  
03 1,20,zxm
04 2,21,ljz
05 3,19,cds
06 4,18,mac
07 5,22,android
08 6,23,symbian
09 7,25,wp
10  
11 LOAD DATA local INPATH '/home/lijun/bucket.txt' OVERWRITE INTO TABLE student partition(stat_date="20120802");
12  
13 from student
14 insert overwrite table student1 partition(stat_date="20120802")
15 select id,age,name where stat_date="20120802" sort by age;
(4)查看文件目录:
hadoop fs -ls /hive/warehouse/test.db/student1/stat_date=20120802  
Found 2 items  
-rw-r--r--   2 lijun supergroup         31 2013-11-24 19:16 /hive/warehouse/test.db/student1/stat_date=20120802/000000_0  
-rw-r--r--   2 lijun supergroup         39 2013-11-24 19:16 /hive/warehouse/test.db/student1/stat_date=20120802/000001_0  
(5)查看sampling数据:
hive> select * from student1 tablesample(bucket 1 out of 2 on id);

Total MapReduce jobs = 1
Launching Job 1 out of 1
.......
OK
4       18      mac     20120802
2       21      ljz     20120802
6       23      symbian 20120802
Time taken: 20.608 seconds

注:tablesample是抽样语句,语法:TABLESAMPLE(BUCKET x OUT OF y)
y必须是table总bucket数的倍数或者因子。hive根据y的大小,决定抽样的比例。例如,table总共分了64份,当y=32时,抽取(64/32=)2个bucket的数据,当y=128时,抽取(64/128=)1/2个bucket的数据。x表示从哪个bucket开始抽取。例如,table总bucket数为32,tablesample(bucket 3 out of 16),表示总共抽取(32/16=)2个bucket的数据,分别为第3个bucket和第(3+16=)19个bucket的数据。

4、Refer:

http://rdc.taobao.org/?p=1457  从MR到Hive – 一次迁移的过程

http://blog.573114.com/Blog/Html/A031/516857.html  Hadoop权威指南 第12章 Hive简介 P384

http://superlxw1234.iteye.com/blog/1545150  hive--Sort Merge Bucket Map Join

http://blog.csdn.net/yfkiss/article/details/7816916  

<think>嗯,用户现在问的是Hive中分Join为什么能减少数据倾斜。首先,我需要回忆一下Hive的分机制是什么,以及数据倾斜通常是如何产生的。分应该和数据的分布有关,而数据倾斜通常是因为某些键的值特别多,导致处理这些键的任务负载过重。 用户可能已经了解Hive基础知识,比如分区和分的区别。分是将数据按照哈希值分成多个文件,而分区是按目录划分。分Join应该是在两个表都按照相同的键分的情况下进行的,这样在Join时,相同键的数据会被分配到同一个里,这样可能减少Shuffle的数据量,从而减少倾斜。 不过用户的问题重点是为什么分能减少数据倾斜。数据倾斜通常发生在某些键的数据量远大于其他键,导致处理这些键的节点负载过重。分如果均匀分布的话,每个里的数据量应该比较接近。但如何确保分后的数据均匀呢?可能分的键选择合适的话,哈希函数会把数据均匀分布到各个里,这样即使某个键有很多数据,也会被分散到不同的中,从而减少单个节点的压力。 另外,分Join可能在执行时,每个可以直接进行Map端Join,而不需要经过Reduce阶段,这样减少了Shuffle过程,避免了在Shuffle阶段因为某些键数据量大导致的倾斜。比如如果两个表都按用户ID分,且的数量相同,那么Join时每个可以独立处理,相同用户ID的数据已经在同一个里,不需要跨节点传输,这样处理更均匀。 不过我需要确认分Join的具体机制。比如,分表在创建时需要CLUSTERED BY键,并且指定的数量。当两个表的分键相同,并且的数量成倍数关系时,Hive可以优化Join操作。这可能涉及到的对应,比如小表的每个可以和大表的对应进行Join,而无需全表扫描,从而减少数据传输。 但为什么这样能减少数据倾斜呢?可能是因为数据被预先分,每个的数据量比较均匀,这样在处理每个的时候,任务负载相对均衡。即使某个键的数据很多,由于分时被分散到多个中,每个处理的数据量不会太大,从而避免单个任务处理过多数据导致的倾斜。 此外,分可能结合了Map端Join,如表在Map阶段直接进行Join,避免了Shuffle阶段的Partitioning,而Shuffle阶段常常是数据倾斜发生的地方。如果数据在分时已经均匀分布,那么Join时的各个任务处理的数据量相近,自然减少了倾斜的可能性。 不过,如果分的键本身分布不均匀,比如某个键的值特别多,那么分可能并不能解决倾斜问题,反而可能加剧。因此,分键的选择非常重要,需要选择高基数的列,并且分布均匀的键。例如,用户ID可能是一个好的分键,如果它们分布均匀的话。 总结来说,分Join通过预先将数据按照Join键的哈希值分配到固定数量的中,确保相同键的数据落在同一个里,这样在Join时,每个可以独立处理,减少了Shuffle的数据量,并且由于数据分布更均匀,避免了单个节点处理大量数据的情况,从而减少数据倾斜。 还需要考虑分的数量是否合理,如果的数量太少,可能每个的数据量还是很大,无法有效避免倾斜。因此,合理设置的数量也是关键。另外,Hive的分Join是否自动处理数据倾斜,或者需要用户手动优化,这也是需要明确的点。 最后,可能需要举例说明,比如两个大表按用户ID分,当进行Join时,每个的数据独立处理,避免了将所有相同用户ID的数据集中到一个Reducer,从而减少倾斜。同时,分还可能启用更高效的Join算法,如Sort-Merge Bucket Join,进一步提高效率并减少倾斜的可能性。</think>在Hive中,**分Bucketing)** 是一种数据组织方式,而**分JoinBucket Join)** 通过预分区和哈希分布机制,能够有效减少数据倾斜。以下是分Join减少数据倾斜的核心原理和实现细节: --- ### **1.机制的本质** - **分定义**:将表数据按指定列的哈希值分配到固定数量的(文件)中。 - 语法示例: ```sql CREATE TABLE user_bucketed ( id INT, name STRING ) CLUSTERED BY (id) INTO 4 BUCKETS; ``` - 数据写入时,Hive根据`CLUSTERED BY`列的哈希值(如`hash(id) % 4`)决定数据落入哪个。 - **关键特性**: - 相同列值的记录**必定落入同一**。 - 的数量固定,数据分布由哈希函数决定。 --- ### **2.Join为什么能减少数据倾斜?** #### **(1) 数据均匀分布** - **哈希函数的作用**: 若分键选择合理(如高基数、分布均匀的列),哈希函数会将数据**均匀分散到各**,避免单个数据量过大。 - 例:用户ID作为分键,若ID分布均匀,则每个的数据量接近。 - **对比普通Join的倾斜场景**: 普通Join的Shuffle阶段需通过`Partitioner`分发数据,若某个键(如`city=北京`)数据量极大,会导致对应Reduce任务负载过重。 **分Join通过预分散数据,规避了Shuffle阶段的热点问题**。 #### **(2) Map端Join优化** 当两个分表满足以下条件时,Hive会启用**Map端Join**(无需Reduce阶段): 1. 两表的分键相同(如都是`user_id`)。 2.数量成倍数关系(如表A有4个,表B有8个)。 - **执行流程**: - 小表的每个直接加载到内存,与大表对应在Map阶段完成Join。 - 避免Shuffle和Reduce阶段,彻底规避数据倾斜。 #### **(3) Sort-Merge Bucket Join** 若分表同时按分键排序(`SORTED BY`),Hive可使用更高效的**Sort-Merge Bucket Join**: - **原理**: - 两表的分键相同、数量相同且排序一致时,直接按文件顺序合并,复杂度接近线性。 - **优势**: - 无需全表扫描或哈希表加载,内存压力小。 - 天然避免因数据分布不均导致的性能问题。 --- ### **3.Join vs. 普通Join的数据流转对比** #### **普通Join的倾斜场景** | 步骤 | 问题描述 | |--------------|--------------------------------------------------------------------------| | Shuffle阶段 | 热点键(如`user_id=1001`)对应的数据全部分发到同一Reduce任务,导致负载不均。 | | Reduce阶段 | 处理热点键的任务耗时远高于其他任务,整体作业时间被拖长。 | #### **分Join的优化效果** | 步骤 | 优化效果 | |--------------|--------------------------------------------------------------------------| | 数据写入时 | 热点键的数据被哈希分散到多个中(如`user_id=1001`可能分布在1和3)。 | | Map阶段 | 每个独立处理,单个内数据量可控,无跨节点数据传输。 | | Reduce阶段 | 若启用Map端Join,则完全跳过Reduce阶段,无倾斜风险。 | --- ### **4.Join适用场景与注意事项** #### **适用场景** - **大表Join大表**:通过分避免Shuffle。 - **高频Join键**:如用户行为表与用户画像表按`user_id`关联。 - **数据倾斜历史问题**:针对已知热点键的优化。 #### **注意事项** 1. **分键选择**: - 优先选择高基数(唯一值多)、分布均匀的列(如用户ID、订单ID)。 - 避免选择低基数或倾斜的列(如性别、省份)。 2. **数量设置**: - 建议数量与集群可用CPU核心数匹配(如1~4倍)。 - 过多会导致小文件问题,过少可能无法有效分散数据。 3. **数据倾斜依然存在?** - 若分键本身分布不均,分Join可能失效。此时需结合**盐析(Salting)**或**动态分**进一步优化。 --- ### **5. 实例演示** #### **场景**:两张大表`orders`和`users`按`user_id`分,解决Join倾斜问题。 ```sql -- 创建分表 CREATE TABLE orders_bucketed ( order_id INT, user_id INT, amount DOUBLE ) CLUSTERED BY (user_id) INTO 32 BUCKETS; CREATE TABLE users_bucketed ( user_id INT, name STRING ) CLUSTERED BY (user_id) INTO 32 BUCKETS; -- 启用分Join优化 SET hive.optimize.bucketmapjoin = true; -- 执行Join SELECT * FROM orders_bucketed o JOIN users_bucketed u ON o.user_id = u.user_id; ``` **效果**:相同`user_id`的数据已预分配到相同中,Map阶段直接完成Join,无Shuffle和Reduce阶段倾斜风险。 --- ### **6. 总结** 分Join通过**预分区、哈希分散、Map端执行**三方面机制,从根本上减少了数据倾斜的可能性: 1. **写入时分散**:哈希函数均匀分布数据。 2. **计算时本地化**:避免Shuffle,热点数据被多分担。 3. **算法优化**:Sort-Merge策略提升效率。 合理使用分Join,结合业务特点设计分键,是解决Hive大数据关联场景下性能问题的有效手段。
评论 8
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值