Hive之bucket表使用场景

本文详细介绍了Hive中BucketTable的使用方法,包括如何通过CLUSTERED BY子句创建BucketTable,以及如何设置参数以确保数据均匀分布于多个文件中。通过示例展示了在大量数据处理场景下,BucketTable如何提高MapReduce任务的并行度,从而加速数据处理速度。

来源:https://www.cnblogs.com/duanxingxing/p/5156951.html

 

前言

bucket table(桶表)是对数据进行哈希取值,然后放到不同文件中存储;

 

应用场景

当数据量比较大,我们需要更快的完成任务,多个map和reduce进程是唯一的选择。
但是如果输入文件是一个的话,map任务只能启动一个。
此时bucket table是个很好的选择,通过指定CLUSTERED的字段,将文件通过hash打散成多个小文件。

 

create table test
(id int,
 name string
)
CLUSTERED BY(id) SORTED BY(name) INTO 32 BUCKETS
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ‘/t’;

 

 

执行insert前不要忘记设置

set hive.enforce.bucketing = true;

强制采用多个reduce进行输出

 

hive> INSERT OVERWRITE TABLE test select * from test09;
Total MapReduce jobs = 1
Launching Job 1 out of 1
Number of reduce tasks determined at compile time: 32
In order to change the average load for a reducer (in bytes):
  set hive.exec.reducers.bytes.per.reducer=<number>
In order to limit the maximum number of reducers:
  set hive.exec.reducers.max=<number>
In order to set a constant number of reducers:
  set mapred.reduce.tasks=<number>
Starting Job = job_201103070826_0018, Tracking URL = http://hadoop00:50030/jobdetails.jsp?jobid=job_201103070826_0018 
Kill Command = /home/hjl/hadoop/bin/../bin/hadoop job  -Dmapred.job.tracker=hadoop00:9001 -kill job_201103070826_0018
2011-03-08 11:34:23,055 Stage-1 map = 0%,  reduce = 0%
2011-03-08 11:34:27,084 Stage-1 map = 6%,  reduce = 0%
*************************************************
Ended Job = job_201103070826_0018
Loading data to table test
5 Rows loaded to test
OK
Time taken: 175.036 seconds

 

 

hive的sunwg_test11文件夹下面出现了32个文件,而不是一个文件

 

[hadoop@hadoop00 ~]$ hadoop fs -ls /ticketdev/test
Found 32 items
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:20 /ticketdev/test/attempt_201103070826_0018_r_000000_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:20 /ticketdev/test/attempt_201103070826_0018_r_000001_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:20 /ticketdev/test/attempt_201103070826_0018_r_000002_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:20 /ticketdev/test/attempt_201103070826_0018_r_000003_0
-rw-r–r–   3 ticketdev hadoop          8 2011-03-08 11:20 /ticketdev/test/attempt_201103070826_0018_r_000004_0
-rw-r–r–   3 ticketdev hadoop          9 2011-03-08 11:20 /ticketdev/test/attempt_201103070826_0018_r_000005_0
-rw-r–r–   3 ticketdev hadoop          8 2011-03-08 11:20 /ticketdev/test/attempt_201103070826_0018_r_000006_0
-rw-r–r–   3 ticketdev hadoop          9 2011-03-08 11:20 /ticketdev/test/attempt_201103070826_0018_r_000007_0
-rw-r–r–   3 ticketdev hadoop          9 2011-03-08 11:20 /ticketdev/test/attempt_201103070826_0018_r_000008_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:20 /ticketdev/test/attempt_201103070826_0018_r_000009_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:20 /ticketdev/test/attempt_201103070826_0018_r_000010_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:20 /ticketdev/test/attempt_201103070826_0018_r_000011_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:20 /ticketdev/test/attempt_201103070826_0018_r_000012_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:20 /ticketdev/test/attempt_201103070826_0018_r_000013_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000014_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000015_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000016_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000017_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000018_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000019_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000020_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000021_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000022_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000023_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000024_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000025_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000026_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000027_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000028_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000029_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000030_0
-rw-r–r–   3 ticketdev hadoop          0 2011-03-08 11:21 /ticketdev/test/attempt_201103070826_0018_r_000031_0

 

 

文件被打散后,可以启动多个mapreduce task
当执行一些操作的时候,你会发现系统启动了32个map任务

<think>嗯,用户的问题是关于Hive是否支持索引,使用场景以及未开启优化时Join的执行过程。首先,我需要回忆一下Hive的索引机制。记得Hive确实有索引,但和传统关系型数据库相比可能有限。根据引用[2]和引用[3],Hive的索引主要用于提高特定列的查询速度,比如在WHERE子句中频繁使用的列。不过,Hive的索引功能并不像主键那样强大,而且使用场景有限。 接下来,用户问到了使用场景。引用[2]提到,索引适合在数据量大的情况下减少全扫描,比如等值查询。而引用[3]还提到了行组索引和布隆过滤索引,尤其是布隆过滤索引适用于等值连接字段,比如JOIN操作中的关联字段。所以可能需要分情况讨论,比如大的特定列查询或者JOIN优化。 然后是未开启优化时的Join执行过程。根据引用[4],Hive在未开启优化的情况下,比如没有使用分桶或Map Join时,执行Join可能会进行笛卡尔积操作,导致性能低下。特别是大Join大时,如果没有优化措施,Hive使用普通的Reduce Side Join,导致大量的数据移动和计算,效率很低。引用[1]还提到了CBO优化未开启时,Hive可能无法智能选择最佳执行计划,导致执行过程不够高效。 需要确认Hive索引的支持情况,是否默认开启,以及不同版本是否有差异。比如Hive早期版本可能支持索引,但后续版本可能被弃用,转而推荐使用其他优化手段如分桶或物化视图。引用[2]和引用[3]都提到了索引的实现原理,比如行组索引和布隆过滤,但用户需要注意实际应用中是否仍然适用。 另外,关于Join的执行过程,未开启优化时,Hive可能会将两个的数据全部加载,进行全扫描和笛卡尔积,这在引用[1]中提到的笛卡尔积部分有涉及。需要解释具体的步骤,比如Map阶段读取数据,Shuffle阶段根据Join键分发,Reduce阶段进行合并,这会导致大量的网络和磁盘IO。 最后,用户可能需要了解如何开启优化,比如分桶Join或SMB Join,这些在引用[4]中有详细参数设置。但用户的问题主要是未开启时的执行过程,所以需要对比说明,突出优化的重要性。 总结回答的结构:先说明Hive是否支持索引,然后讨论使用场景,接着详细描述未开启优化时Join的执行步骤,并引用相关文献支持。同时,生成相关问题引导用户进一步学习优化方法。</think>### Hive索引支持与查询优化分析 #### 一、Hive索引支持情况 1. **支持但有限** Hive支持索引功能,但其实现与关系型数据库有本质差异。Hive索引主要针对特定列的查询加速,而非主键约束或唯一性保证[^2][^3]。 - **索引类型**: - **行组索引**(Row Group Index):默认常开,用于快速定位数据块 - **布隆过滤索引**(Bloom Filter Index):适用于等值连接字段(如JOIN条件列)[^3] - **语法示例**: ```sql CREATE INDEX idx_name ON TABLE table_name (column_name) AS 'COMPACT' WITH DEFERRED REBUILD; ``` 2. **索引使用场景** - 高频的等值查询(如`WHERE col=value`) - JOIN操作中作为关联键的字段 - 数据过滤条件稳定的场景(如固定时间范围查询)[^2] #### 二、未开启优化时的JOIN执行过程 当未启用分桶优化(Bucket Join)或CBO(Cost-Based Optimization)时,Hive执行JOIN的典型流程如下: 1. **Map阶段** - 读取所有参与JOIN的数据 - 对每条数据打标记(标识来源) 2. **Shuffle阶段** - 根据JOIN键进行哈希分区 - 将相同键的数据分发到同一个Reducer 3. **Reduce阶段** - 对接收到的数据执行笛卡尔积计算 - 输出匹配结果[^1][^4] $$ \text{执行效率公式:} T \propto O(n \times m) \quad (\text{n,m为数据量}) $$ #### 三、对比优化与非优化场景 | 特征 | 未开启优化 | 开启优化(如Bucket Join) | |--------------------|---------------------------|---------------------------------| | 数据移动量 | 全量数据Shuffle | 仅匹配桶数据移动[^4] | | 计算复杂度 | 笛卡尔积(高消耗) | 局部数据匹配(低消耗) | | 典型参数 | 无特殊配置 | `hive.optimize.bucketmapjoin=true`[^4] | #### 四、索引与优化的组合应用 建议在以下场景组合使用索引和优化策略: 1. **大JOIN大**:启用分桶索引+SMB Join[^4] 2. **高频过滤查询**:对WHERE条件列建立布隆过滤索引[^3] 3. **ETL过程优化**:在数据写入阶段预建索引
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值