hive mapjoin 使用 和个人理解

本文介绍了如何通过Hive中的MapJoin技术解决大数据处理时的数据倾斜问题,提高查询效率,并探讨了MapJoin的适用场景及限制。

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

遇到一个hive的问题,如下hive sql:


select t1.a,t1.b from table t1 join table2 t2  on ( t1.a=t2.a and t1.datecol=20110802)

该语句中B表有30亿行记录,t1表只有100行记录,而且t2表中数据倾斜特别严重,有一个key上有15亿行记录,在运行过程中特别的慢,而且在reduece的过程中遇有内存不够而报错。


为了解决用户的这个问题,考虑使用mapjoin,mapjoin的原理:

MAPJION会把小表全部读入内存中,在map阶段直接拿另外一个表的数据和内存中表数据做匹配,而普通的equality join则是类似于mapreduce模型中的file join,需要先分组,然后再reduce端进行连接,使用的时候需要结合着场景;由于mapjoin是在map是进行了join操作,省去了reduce运行,效率也会高很多

这样就不会由于数据倾斜导致某个reduce上落数据太多而失败。于是原来的sql可以通过使用hint的方式指定join时使用mapjoin。

select /*+ mapjoin(t1)*/ t1.a,t1.b from table t1 join table2 t2  on ( t1.a=t2.a and f.ftime=20110802)


再运行发现执行的效率比以前的写法高了好多。



mapjoin还有一个很大的好处是能够进行不等连接的join操作,如果将不等条件写在where中,那么mapreduce过程中会进行笛卡尔积,运行效率特别低,这是由于equality join (不等值join操作有 >、<、like等如:a.x < b.y 或者 a.x like b.y) 需要在reduce端进行不等值判断,map端只能过滤掉where中等值连接时候的条件,如果使用mapjoin操作,在map的过程中就完成了不等值的join操作,效率会高很多。

例子:

select A.a ,A.b from A join B where A.a>B.a


Mapjoin 不能使用与 outer join

/work/tda/hive-0.9.0/bin/hive -e "use yunion; select  /*+ mapjoin(t1)*/ t2.juid from t_pvjoinvv t1 
left outer join
(select distinct juid from t_vvformat where start_date=20130306 and flag=1 and sourceid<3 ) t2
on t1.juid=t2.juid
where t1.start_date=20130306 
and  t1.pv_1stflag=1 
and t2.juid is null ;
" ;
抛出异常:
OK
Time taken: 1.957 seconds
FAILED: Error in semantic analysis: MAPJOIN cannot be performed with OUTER JOIN




简单总结一下,mapjoin的使用场景:

1. 关联操作中有一张表非常小

2.不等值的链接操作


结合着网上博客,加入自己理解。

<think>嗯,用户想了解Hive中Map Join的工作原理,并且希望用图表来展示。首先,我需要回忆一下Hive的Map Join相关知识。记得Map Join主要是为了优化小表大表的连接操作,避免ShuffleReduce阶段的开销。根据用户提供的引用内容,MapJoin是在Map阶段将小表加载到内存中,生成HashTableFiles,然后处理大表的数据进行连接。 接下来,我需要整理Map Join的工作步骤。首先,驱动表应该是小表,对吧?Hive会自动识别小表的大小,如果符合条件就会启用Map Join。然后,在Map阶段,小表的数据会被读取到内存,并构建成哈希表。之后处理大表的每个记录,用连接键去哈希表里查找匹配项,合并结果直接输出。整个过程需要ShuffleReduce,这样效率更高。 用户提到需要图解,虽然文本形式无法画图,但可以通过文字描述图表的结构。例如,流程图分Map阶段可能的Distributed Cache步骤。需要确保每个步骤对应引用中的内容,比如引用[1][3]提到的小表加载分布式缓存的作用。可能还需要比较Common JoinMap Join的区别,如引用[2][4]中的Common Join流程,涉及ShuffleReduce阶段。 另外,用户可能对优化细节感兴趣,比如为什么使用分布式缓存,或者小表的大小限制。根据引用[3],当大量Mapper同时读取小表时,可能会有性能问题,所以用分布式缓存来缓解。这部分需要解释清楚,避免用户混淆。 然后,生成相关问题时要考虑用户可能的后续疑问,比如如何配置小表大小、Map Join的限制,或者性能调优的方法。这些问题需要基于已有的引用内容,确保答案的相关性准确性。 最后,确保整个回答符合格式要求:行内公式用$,独立公式用$$,正确的中文回答,结构清晰。同时,引用标识要正确对应,比如引用[1]对应MapJoin的基本原理,引用[3]对应分布式缓存的作用,引用[4]对比Common Join的流程。 总结一下,回答的结构应该是先解释工作原理,分步骤描述,然后对比Common Join,再用文字图表展示流程,最后列出相关问题。需要确保每个关键点都有对应的引用支持,并且语言简洁明了,便于用户理解。</think>### Hive Map Join 工作原理图解说明 #### 一、核心原理 MapJoinHive 在 Map 阶段完成表连接的一种优化手段,**适用于小表(维度表)与大表(事实表)的 Join 操作**。其核心步骤如下: 1. **小表加载**:将小表数据从 HDFS 读取到内存,构建为 **哈希表(HashTable)**[^1]。 2. **大表处理**:顺序扫描大表,逐行用 Join Key 查询内存中的哈希表,匹配后直接输出结果[^3]。 3. **规避 Shuffle/Reduce**:整个过程仅在 Map 阶段完成,无需数据重分区 Reduce 阶段[^2]。 #### 二、流程对比(文字图表) ``` |---------------MapJoin 流程---------------| 1. 驱动表(小表) │ ├─ 从 HDFS 加载到内存 → 构建哈希表(Key: Join列,Value: 其他列) │ 2. 被驱动表(大表) │ ├─ 逐行扫描大表数据 │ ├─ 用 Join Key 查询内存哈希表 │ └─ 匹配成功则合并两表数据 → 直接输出结果 ``` #### 三、与 Common Join 对比 | **特性** | **MapJoin** | **Common Join** | |------------------|--------------------------------------|--------------------------------------| | **执行阶段** | 仅 Map 阶段 | Map + Shuffle + Reduce 阶段 | | **数据移动** | 无 Shuffle | 需按 Key 分区到 Reducer[^4] | | **适用场景** | 小表(几十MB内) | 大表间 Join | | **性能瓶颈** | 小表加载内存的并行度[^3] | Shuffle 网络开销 Reducer 计算压力 | #### 四、优化扩展 - **分布式缓存**:当小表较大时,通过分布式缓存(Distributed Cache)将哈希表分发给所有 Mapper,避免集中读取 HDFS 的性能瓶颈。 - **自动触发条件**:Hive 默认根据 `hive.auto.convert.join` 参数判断小表大小(如 `hive.mapjoin.smalltable.filesize=25MB`)。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值