山大软工实践hive(6)-逻辑优化(2)

关注

原创最新推荐文章于 2026-09-09 15:51:17 发布 1.2k 阅读 AI 写同款· GEO 优化 ›

HIVE面试别再死记硬背了！从内部表到数据倾斜，我用一个实战项目帮你理清思路本文通过电商用户行为分析实战项目，深入解析HIVE从数据仓库构建到性能调优的全链路实践。涵盖外部表设计、分区策略、存储格式选择、数据倾斜解决方案等核心面试考点，帮助求职者摆脱八股文死记硬背，掌握大数据面试实战技巧。阅读详情

2021SC@SDUSC

山大软工实践hive(6)-逻辑优化(2)

文章目录

山大软工实践hive(6)-逻辑优化(2)

以下接着上一次

GroupBy

预聚合

在map端使用combiner预聚合数据以减少shuffle数据量，这对大量数据处理有帮助

数据倾斜处理

为防止大量数据的key相同导致分配任务时的数据倾斜，两阶段聚合数据
原理是启动两个MapReduce任务，第一个任务mapper随机分发给reducer数据，然后reducer做聚合，然后第二MR任务就对预处理过的做聚合
对应的优化器为GroupByOptimizer

关于预聚合能否用于处理数据倾斜

值得注意的是，预聚合用Combiner实现。而关于它：
Combiner只应该用于那种Reduce的输入key/value与输出key/value类型完全一致，且不影响最终结果的场景。比如累加，最大/小值等。所以预聚合本身就无法随时使用，只有是如sum，count函数时才能运用。
Combiner最基本是实现本地key的归并，Combiner具有类似本地的reduce功能；Combiner的实现一般继承Reducer。
Combiner在Mapper之后Reducer之前运行。

虽然预聚合理论上能够用于处理数据倾斜，但它本身也是继承Reducer的一种实现，所以从概念上讲，数据倾斜处理本身是包含预聚合的

join优化

1.小表做hash表读入内存，可用于map join与Bucket map join（mapjoin会在map阶段完成join操作，不需要reduce）
2.多张表join时key相同，则会合并为一个MR任务，相关性优化器CorrelationOptimizer.

数据倾斜处理

1.Hive将计数超过阈值的倾斜key对应的行临时写进文件中，再启动map join，其它数据用common join，这就是skew join（创建表时指定某属性倾斜key）
2.优化HQL以解决倾斜

对于空值或者无意义的值，可以把它随机变成不可能的值
对于倾斜key可以将它们抽样出来，对应的行单独存入临时表中，key打上前缀如0-9，最后再聚合
不同数据类型之间，如int join string，会让其以int做hash，所有string类型key被分配在一个reducer上（应该是把所有string类型认为是相同key了吧），所以写sql时可以先把数据类型进行转换
map join小表太大，对小表做出限制筛选，但要两次map join，比如下面HQL（微改动了下原文语句）
```
 select /*+mapjoin(b)*/ a.uid
 from log a left outer join 
 (select /*+mapjoin(s)*/ t.uid
 from (select distinct uid from log where pt_date = 20190228) s 
 inner join user_info t on s.uid = t.uid) b on a.uid = b.uid 
 where a.pt_date = 20190228;
```
大概就是日志表和用户信息表join，获得当天进行某操作的用户数据，一个用户可以用多条log记录，所以先对log表去重地让获取当天的用户id（表s），然后与用户信息表join获取当天操作过的用户信息（表b），最后用log表(表a)与表b join
这里user_info 就是小表，但它不够小，所以要先筛选一次，总的来说，这种做法，进行了两次map join

MapReduce优化

mapper数

mapper数与文件分割数相关，在org.apache.hadoop.mapreduce.lib.input.FileInputFormat类可以看到相关逻辑
在这里插入图片描述
有参数（简化名字后）tasks, default_num, block_size, input_size, split_num, split_size, min_split, max_split, 以及最终的mapper_num，它们的关系如下

default_num=input_num/block_size（文件大小除以块大小，块大小默认值为为64/128MB）
split_size=MAX(min_split,MIN(max_split,block_size))，如果block_size在区间最小与最大值之间，则为block_size，否则为最小或最大值（min_split/max_split 默认值为1KB/64MB）。与上面类似，split_num=input_size/split_size
mapper_num=MIN(split_num, MAX(default_num, tasks)) 其中tasks为期望值，它只有在数量合适时会采用。可以看见调高max_split更可能会使mapper数减少（原文是调高min_split），调高tasks与max_split更可能增大mapper数(原文还是min_split)

输入：少量大文件则减少mapper数，大量文件则增加，大量小文件需要合并小文件

调整Reducer数

相关tasks参数能直接指定reducer数，而非建议，如果不启用，则按照 reducer_num=MIN（输入大小/reducer默认大小，reducer数的最大值）

JVM复用

MR任务中，默认每启动一个task就启动一个JVM，而如果task多而小，则会浪费开销在JVM启动与关闭。可以通过设定相关参数tasks为n，代表在同一MR任务中顺序执行的n个task可以重用一个JVM

并行与本地与严格执行

并行：如union语句前后可以并行执行
本地：如果任务量小可以直接在节点完成任务，而不提交到集群
严格执行：禁止使用高风险HQL

查询分区表时不限定分区列的语句
两表join产生了笛卡尔积的语句
用order by来排序但没有指定limit的语句（前面有提到order by会导致任务分给一个Reducer，如果不限制数量则很可能负载过大）

看一看源码

对于提到的两个优化器
GroupByOptimizer
在这里插入图片描述
进行group by优化，如果gb key包含bucket，sorting key,则可以直接join（SMBjoin，第4篇提到过，可以猜测此情况会产生SMB算子替代原join->rs->join）

CorrelationOptimizer
在这里插入图片描述
这个优化器的实现参考了一篇论文
让我注意的是，这里的query plan tree似乎与operator tree（DAG）相同，我以后可以认为这是一个东西

我又想到Transform
在这里插入图片描述
所有基于规则的优化都实现了这个接口。所有转换都是按顺序调用的。它们获取当前解析上下文（其中包含操作符树等），执行所有优化，然后返回更新的解析上下文。transform方法被所有继承类继承
这突然让我想到，我不必去找谁在调用了，反正估计Optimizer类initialize方法应该是调用优化器的方法的根，可以从这里把所有的优化器类根据注释与transform方法等把它们的功能罗列一遍，看一看情况