Hive与Oracle表关联语句对比

本文探讨了在从ORACLE迁移至HIVE过程中遇到的表关联语法差异,详细比较了内关联、左关联、右关联、全外关联和笛卡尔积的实现方式。在HIVE中,关联条件不能用where表达,左、右关联和全外关联需明确指定,且不存在类似ORACLE中的某些语法结构。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在将ORACLE存储过程迁移到HIVE平台时,不可避免地会遇到表关联的相应语法问题。

本文详细对比了ORALCE和HIVE的各种表关联语法,包括内关联,左,右关联,全外关联和笛卡尔积。

 

一.创建表

ORACLE:

create table a
(
a1  number(10),
a2 varchar2(50)
);

create table b
(
b1  number(10),
b2 varchar2(50)
); 


HIVE:

CREATE TABLE IF NOT EXISTS a (
a1 STRING,
a2 STRING)
COMMENT 'TABLE A'
ROW FORMAT DELIMITED
FIELDS TERMINATED BY '|'
LINES TERMINATED BY '\n'
STORED AS TEXTFILE
TBLPROPERTIES ( 'created_at'='2014-04-28','creator'='HENRY' );

 

二.插入数据

ORACLE:

insert into a(a1,a2) values(1,'X');
insert into a(a1,a2) values(2,'Y');
insert into a(a1,a2) values(3,'Z');

insert into b(b1,b2) values(1,'X');
insert into b(b1,b2) values(2,'Y');
insert into b(b1,b2) values(4,'Z');


HIVE:

hive (default)> load data local inpath './data1' into table a;
Copying data from file:/home/hadoop/roger/sql/renguihe/data
Copying file: file:/home/hadoop/roger/sql/renguihe/data
Loading data to table default.a
Table default.a stats: [num_partitions: 0, num_files: 1, num_rows: 0, total_size: 12, raw_data_size: 0]
OK
Time taken: 1.961 seconds
hive (default)> load data local inpath './data1' into table b;
Copying data from file:/home/hadoop/roger/sql/renguihe/data
Copying file: file:/home/hadoop/roger/sql/renguihe/data
Loading data to table default.b
Table default.b stats: [num_partitions: 0, num_files: 1, num_rows: 0, total_size: 12, raw_data_size: 0]
OK
Time taken: 0.392 seconds

其中data1数据文件内容为:

1|X
2|Y
3|Z

data2数据文件内容为:

1|X
2|Y
4|Z


三.等值关联

ORACLE:

select * from a,b where a.a1 = b.b1;

或:

select * from a join b on a.a1 = b.b1;

结果如下图所示:

 

HIVE:

select * from a join b on a.a1 = b.b1;

注意HIVE中不能使用where来表示关联条件。

执行过程及结果如下图所示:

hive (default)> select * from a join b on a.a1 = b.b1;        
Total MapReduce jobs = 1
setting HADOOP_USER_NAME        hadoop
Execution log at: /tmp/hadoop/.log
2014-04-29 09:13:27     Starting to launch local task to process map join;      maximum memory = 1908932608
2014-04-29 09:13:27     Processing rows:        3       Hashtable size: 3       Memory usage:   110981704       rate:   0.058
2014-04-29 09:13:27     Dump the hashtable into file: file:/tmp/hadoop/hive_2014-04-29_09-13-25_273_8486588204512196396/-local-10002/HashTable-Stage-3/MapJoin-mapfile00--.hashtable
2014-04-29 09:13:27     Upload 1 File to: file:/tmp/hadoop/hive_2014-04-29_09-13-25_273_8486588204512196396/-local-10002/HashTable-Stage-3/MapJoin-mapfile00--.hashtable File size: 438
2014-04-29 09:13:27     End of local task; Time Taken: 0.339 sec.
Execution completed successfully
Mapred Local Task Succeeded . Convert the Join into MapJoin
Mapred Local Task Succeeded . Convert the Join into MapJoin
Launching Job 1 out of 1
Number of reduce tasks is set to 0 since there's no reduce operator
Starting Job = job_201404251509_0131, Tracking URL = http://
<think>嗯,用户的问题是关于数据库中处理小关联操作的查询优化,涉及join性能。我需要先回忆相关的优化方法,并结合提供的引用资料来组织回答。 首先,用户提到的是小关联,这可能涉及到不同的优化策略。比如,引用4中提到hive的mapjoin,适用于大关联,可以将小载到内存,减少shuffle。这可能是一个关键点。 然后,索引的使用也很重要。引用1引用2都提到合理使用索引能速查询,尤其是关联字段条件字段的索引。对于大来说,索引尤其重要,可以避免全扫描。 接下来,分区分桶策略,引用3提到关联法处理亿级大,可能涉及分区,比如按时间分区,这样查询时可以只扫描相关分区,减少数据量。 另外,过滤条件提前应用,减少数据集大小,这点在引用1引用5都有提到,比如在子查询中先过滤大的数据,再进行关联,避免处理不必要的数据。 还有临时的使用,比如将小的数据先处理成临时,或者用in代替join,但引用5提到in在value list大时可能效率低,这时候用join临时更好。 然后,执行计划分析也是关键,用户可能需要检查执行计划,确认是否走索引,是否有全扫描,从而调整查询或索引。 最后,不同的数据库系统可能有不同的优化手段,比如Oracle的优化器提示,Hive的mapjoin设置,需要根据具体数据库调整。 需要确保回答结构清晰,分点列出优化策略,并结合引用资料中的例子,比如引用4的mapjoin,引用3的分区,引用1的索引,引用5的临时等。同时,生成的相关问题要覆盖用户可能进一步询问的方向,如索引选择、执行计划分析、不同数据库的实现差异等。</think>### 数据库关联查询优化方法 #### 1. **优先选择小驱动大** - **优化原理**:在关联查询中,建议用小作为驱动(即放在`JOIN`语句左侧),大作为被驱动。这样可以利用索引快速匹配大中的数据,减少全扫描概率[^4]。 - **示例**: ```sql -- 小t1关联t2 SELECT * FROM small_table t1 JOIN large_table t2 ON t1.key = t2.key; ``` #### 2. **利用MapJoin或Broadcast Join(特定数据库适用)** - **适用场景**:Hive大数据平台中,若小可完全载到内存,可通过`MapJoin`将小广播到所有计算节点,避免Shuffle操作。 - **Hive实现**: ```sql SET hive.auto.convert.join=true; -- 启用MapJoin SELECT /*+ MAPJOIN(t1) */ * FROM small_table t1 JOIN large_table t2 ON t1.key = t2.key; ``` #### 3. **索引优化** - **关键字段索引**:为大关联字段(如`key`)建立索引,速匹配过程。例如,Oracle中对大关联字段创建B-tree索引[^1][^2]。 - **复合索引**:若查询包含过滤条件,可创建覆盖索引(如`(key, filter_column)`),减少回操作。 #### 4. **过滤前置数据裁剪** - **子查询过滤**:在大关联前,先通过子查询或临时过滤无关数据。 ```sql SELECT * FROM small_table t1 JOIN ( SELECT * FROM large_table WHERE date = '2023-10-01' -- 先过滤大数据 ) t2 ON t1.key = t2.key; ``` - **分区/分桶策略**:对大按时间、地区等字段分区,查询时仅扫描相关分区[^3]。 #### 5. **临时物化视图** - **预处理小**:对小去重或预计算,生成临时减少关联数据量[^5]。 - **物化视图**:Oracle数据库可将频繁关联的结果固化,速后续查询。 #### 6. **执行计划分析** - **查看执行计划**:通过`EXPLAIN`分析是否走索引、是否出现全扫描。 - **强制索引提示**(如Oracle): ```sql SELECT /*+ INDEX(t2 idx_key) */ * FROM small_table t1 JOIN large_table t2 ON t1.key = t2.key; ``` --- ### 性能对比场景 | 方法 | 适用场景 | 优点 | 缺点 | |---------------------|-------------------|--------------------------|--------------------------| | MapJoin | 小可完全载内存 | 避免Shuffle,速度极快 | 内存消耗高 | | 索引优化 | 大有高选择性字段 | 速单次查询 | 增删改操作变慢 | | 分区/分桶 | 时间或范围查询频繁 | 减少扫描数据量 | 管理复杂度高 | | 临时预处理 | 小数据可提前处理 | 简化关联逻辑 | 增ETL流程 | --- ### 相关问题 1. 如何判断关联字段是否需要创建复合索引? 2. 在MySQL中如何强制优化器使用指定索引? 3. Hive的MapJoin对小大小有什么限制? 4. 分区关联查询时如何避免全分区扫描? 5. 物化视图普通视图在关联查询中的性能差异?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值