68 lines
6.0 KiB
Markdown
68 lines
6.0 KiB
Markdown
1. common join(shuffle join/reduce join)
|
||
1. 概要：common join是hive的默认join类型，其在reduce阶段完成join工作，包含map、shuffle和reduce三个阶段；
|
||
2. 执行过程
|
||
1. map阶段：map阶段读取数据源表，以join中的条件列为key，若有多个条件列，则以多个条件列的组合作为key，value中包含tag和reduce阶段需要使用的列(如，select或where中需要使用的列)；
|
||
2. shuffle阶段：对key进行hash，推送至不同的reduce中，确保两个相同的key位于同一个reduce中；
|
||
3. reduce阶段：根据key值完成reduce，在此期间使用tag识别不同的来源表；
|
||
3. 实例：输入以下代码common join的流程如图
|
||
```sql
|
||
SELECT a.id,a.dept,b.age FROM a join b ON (a.id = b.id);
|
||
```
|
||
|
||
1. map join：
|
||
1. 概要：map join适用于小表join大表，hive在map阶段会先将小表读取到内存生成HashTableFiles上传至[Distributed Cache](obsidian://open?vault=%E7%9F%A5%E8%AF%86%E7%AE%A1%E7%90%86&file=%E7%BC%96%E7%A8%8B%E7%BB%8F%E9%AA%8C%2Fhadoop%2F%E5%88%86%E5%B8%83%E5%BC%8F%E7%BC%93%E5%AD%98)，在map阶段，大表会直接读取小表的缓存完成join过程，不涉及shuffle；
|
||
2. 执行过程：
|
||
- Local Task：
|
||
- hive将小表的数据发送到hive客户端；
|
||
- 客户端将小表的数据转换为HashTable的数据结构，并创建一个.gz的压缩文件；
|
||
- 客户端将HashTable的.gz压缩文件上传至hadoop的Distributed Cache中；
|
||
- MR：hive执行一个没有reduce的MR任务，在map阶段根据大表的每条记录与Distributed Cache中小表对应的HashTable进行关联；
|
||
- 返回：由于没有Reduce过程，map阶段直接返回结果，并且有多少个map就有多少个文件；
|
||
|
||
3. 适用范围：
|
||
1. 小表与大表的连接，其中小表应小到存入内存而不影响性能，否则可能导致oom；
|
||
2. 若连接中的大表存在数据倾斜，则更应该使用mapjoin；
|
||
3. map join适合进行不等式连接，这是因为在hive2.2之前，hive不支持在on之后写不等式，必须写在where语句中，这会导致必须先求笛卡尔积之后再进行过滤，使性能大幅下降，而map join在map阶段直接拿另外一个表的数据和内存中表数据做匹配。这种情况下即使笛卡尔积也不会对任务运行速度造成太大的效率影响。 而且hive的where条件本身就是在map阶段进行的操作，所以在where里写入不等值比对的话，也不会造成额外负担；**但在hive2.2之后，hive支持在on语句中执行不等式操作，所以2.2之后没有这个问题**;
|
||
|
||
3. Bucket Map Join
|
||
1. 概述：Bucket Map Join是对map join的改进，其解决了map join中要求一个表是小表的问题。其基本思想是利用分桶的表，只将符合连接条件的分桶数据发送到map端，之后再map段执行map join；
|
||
2. 条件：
|
||
1. 参与join的表均为大表；
|
||
2. 参与join的表都是[分桶表](obsidian://open?vault=%E7%9F%A5%E8%AF%86%E7%AE%A1%E7%90%86&file=%E7%BC%96%E7%A8%8B%E7%BB%8F%E9%AA%8C%2FHIVE%2F%E5%88%86%E5%8C%BA%E3%80%81%E5%88%86%E6%A1%B6)，并且都以join的key为分桶字段；
|
||
3. 参与join的表分桶数相同，或一个表的分桶数是其他表的倍数；
|
||
3. 执行过程：
|
||
1. hive将较小的表根据分桶，生成多个HashTable；
|
||
2. 根据较大表的分桶情况，将较小表中分桶情况对应的HashTable发送到较大表的map端，二者按map join的方式进行join，并返回结果；
|
||
|
||
4. 实例：
|
||
假设有两个大表，table1和table2，其中table2为较table1小；执行下述查询语句：
|
||
```sql
|
||
SELECT /*+ MAPJOIN(table2) */ table1.emp_id, table1.emp_name, table2.job_title FROM table1 JOIN table2 ON table1.emp_id = table2.emp_id;
|
||
```
|
||
|
||
|
||
|
||
|
||
4. Sort Merge Bucket Join(SMB join)
|
||
1. 概述：SMB join是对bucket join的进一步改进，在bucket join中，map端仍然至少需要存储较小表的一个桶的数据，同时，需要将较小的表转化为HashTable数据。而SMB join利用了排序且分桶的数据，每个map端只需要读取固定的对应key的row即可，且由于数据是排序的，不需要转换为HashTable结构，可以直接进行join；
|
||
2. 条件：
|
||
1. 参与join的表均为大表；
|
||
2. 参与join的表均以join的key作为分桶字段分桶，
|
||
3. 参与join的表均以join的key进行排序；
|
||
4. **参与join的表的分桶数必须相同**；
|
||
3. 执行过程：
|
||
1. maper读取较大表的数据；
|
||
2. maper读取较小表的数据；
|
||
3. 在maper中完成join；
|
||
4. 实例：
|
||
假设有两个表，table1和table2，其中table2较table1小；
|
||
|
||
|
||
***参考文献***
|
||
1. [Implementation Limitations of MapJoin in Hive 0.13 on MR](http://dmtolpeko.com/2014/10/01/implementation-limitations-of-mapjoin-in-hive-0-13-on-mr/);
|
||
2. [Map Join Limitations – Out of Memory in Local Task](http://dmtolpeko.com/2014/10/14/map-join-limitations-out-of-memory-in-local-task/);
|
||
3. [LanguageManual Joins](https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Joins)(https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Joins);
|
||
4. [【Hive】Hive中的MapJoin，CommonJoin，SMBJoin详细介绍](https://blog.csdn.net/qq_32727095/article/details/107803199);
|
||
5. [Bucket Map Join in Hive](https://www.clairvoyant.ai/blog/bucket-map-join-in-hive);
|
||
6. [Optimizing Your Apache Hive Queries: Bucketing and Sort Merge Bucket Map Join](https://www.linkedin.com/pulse/optimizing-your-apache-hive-queries-bucketing-sort-merge-varun-rao);
|
||
7. [Sort Merge Bucket Join in Hive – SMB Join](https://data-flair.training/blogs/hive-sort-merge-bucket-join/); |