Hive MapJoin 优化

1、Hive本地MR

  如果在hive中运行的sql本身数据量很小,那么使用本地mr的效率要比分布式的快很多。但是hive本地MR对内存使用很敏感,查询的数据不能太大,否则本地内存是吃不消的。

So the query processor will launch this task in a child jvm, which has the same heap size as the Mapper's. Since the Local Task may run out of memory, the query processor will measure the memory usage of the local task very carefully. Once the memory usage of the Local Task is higher than a threshold number. This Local Task will abort itself and tells the user that this table is too large to hold in the memory. User can change this threshold byset  hive.mapjoin.localtask.max.memory.usage = 0.999

查询处理器会在一个子的jvm里运作这个任务,jvm堆大小跟Mapper的堆大小一样。本地MR可能内存消耗殆尽,查询处理器用精确的计算本地MR的内存大小,一旦内存超过了设定的值,那么这个MR就会自动kill掉。可以通过设置hive.mapjoin.localtask.max.memory.usage =0.9,这个值太保守。

set hive.exec.mode.local.auto=true;  //开启本地mr

 

//设置local mr的最大输入数据量,当输入数据量小于这个值的时候会采用local  mr的方式

set hive.exec.mode.local.auto.inputbytes.max=50000000;

//设置local mr的最大输入文件个数,当输入文件个数小于这个值的时候会采用local mr的方式

set hive.exec.mode.local.auto.tasks.max=10;

当这三个参数同时成立时候,才会采用本地mr

2、Mapjoin使用

  就是把小的表加入内存,可以配置以下参数,是hive自动根据sql,选择使用common join或者map join

set hive.auto.convert.join = true;

hive.mapjoin.smalltable.filesize 默认值是25mb

link:http://blog.youkuaiyun.com/xqy1522/article/details/6699740

MapJoin

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

select f.a,f.b from A t join B f  on ( f.a=t.a and f.ftime=20110802)  

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

 

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

MAPJION会把小表全部读入内存中,在map阶段直接拿另外一个表的数据和内存中表数据做匹配,由于在map是进行了join操作,省去了reduce运行的效率也会高很多

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

select /*+ mapjoin(A)*/ f.a,f.b from A t join B f  on ( f.a=t.a and f.ftime=20110802) 

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

 

mapjoin还有一个很大的好处是能够进行不等连接的join操作,如果将不等条件写在where中,那么mapreduce过程中会进行笛卡尔积,运行效率特别低,如果使用mapjoin操作,在map的过程中就完成了不等值的join操作,效率会高很多。

例子:

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

 

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

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

2.不等值的链接操作


参考自:https://cwiki.apache.org/confluence/display/Hive/MapJoinOptimization

refer to :http://blog.youkuaiyun.com/liuxianbing119/article/details/8668635


MapJoin,顾名思义,会在Map端完成Join操作。这需要将Join操作的一个或多个表完全读入内存。

MapJoin的用法是在查询/子查询的SELECT关键字后面添加/*+ MAPJOIN(tablelist) */提示优化器转化为MapJoin(目前Hive的优化器不能自动优化MapJoin)。其中tablelist可以是一个表,或以逗号连接的表的列表。tablelist中的表将会读入内存,应该将小表写在这里。

PS:有用户说MapJoin在子查询中可能出现未知BUG。在大表和小表做笛卡尔积时,规避笛卡尔积的方法是,给Join添加一个Join key,原理很简单:将小表扩充一列join key,并将小表的条目复制数倍,join key各不相同;将大表扩充一列join key为随机数。



<think>嗯,用户想了解HiveMap Join的工作原理,并且希望用图表来展示。首先,我需要回忆一下HiveMap Join相关知识。记得Map Join主要是为了优化小表和大表的连接操作,避免Shuffle和Reduce阶段的开销。根据用户提供的引用内容,MapJoin是在Map阶段将小表加载到内存中,生成HashTableFiles,然后处理大表的数据进行连接。 接下来,我需要整理Map Join的工作步骤。首先,驱动表应该是小表,对吧?Hive会自动识别小表的大小,如果符合条件就会启用Map Join。然后,在Map阶段,小表的数据会被读取到内存,并构建成哈希表。之后处理大表的每个记录,用连接键去哈希表里查找匹配项,合并结果直接输出。整个过程不需要Shuffle和Reduce,这样效率更高。 用户提到需要图解,虽然文本形式无法画图,但可以通过文字描述图表的结构。例如,流程图分Map阶段和可能的Distributed Cache步骤。需要确保每个步骤对应引用中的内容,比如引用[1]和[3]提到的小表加载和分布式缓存的作用。可能还需要比较Common JoinMap Join的区别,如引用[2]和[4]中的Common Join流程,涉及Shuffle和Reduce阶段。 另外,用户可能对优化细节感兴趣,比如为什么使用分布式缓存,或者小表的大小限制。根据引用[3],当大量Mapper同时读取小表时,可能会有性能问题,所以用分布式缓存来缓解。这部分需要解释清楚,避免用户混淆。 然后,生成相关问题时要考虑用户可能的后续疑问,比如如何配置小表大小、Map Join的限制,或者性能调优的方法。这些问题需要基于已有的引用内容,确保答案的相关性和准确性。 最后,确保整个回答符合格式要求:行内公式用$,独立公式用$$,正确的中文回答,结构清晰。同时,引用标识要正确对应,比如引用[1]对应MapJoin的基本原理,引用[3]对应分布式缓存的作用,引用[4]对比Common Join的流程。 总结一下,回答的结构应该是先解释工作原理,分步骤描述,然后对比Common Join,再用文字图表展示流程,最后列出相关问题。需要确保每个关键点都有对应的引用支持,并且语言简洁明了,便于用户理解。</think>### Hive Map Join 工作原理图解说明 #### 一、核心原理 MapJoinHiveMap 阶段完成表连接的一种优化手段,**适用于小表(维度表)与大表(事实表)的 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`)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值