hive调优记录

2,925次阅读

没有评论

共计 1502 个字符，预计需要花费 4 分钟才能阅读完成。

最近有场讲座是关于hive的一个培训，也去听了一下，其中的某些点还是自己的盲区，平时也没注意到这些地方的优化，这些还是比较重要的，特此记录一下。

set hive.exec.parallel=true; //开启任务并行执行

假设你有两个子查询然后需要join关联处理，并且两个子查询之间没有任何的关联，这个时候两个子查询可以并行执行，然后在join处理，可以加快代码的运行。

hive有的时候也会出现OOM的问题，这个还是比较复杂的，你要看是在map端还是reduce端出现的OOM问题，可以通过加大每个map的内存限制或者增加reduce的数量来一定程度上缓解，但是不一定绝对能解决。这个还是要看具体的情况。

A：key 分布不均匀

B：业务数据本身的特性

C：建表考虑不周全

D：某些 HQL 语句本身就存在数据倾斜

常见的触发语句有：

JOIN
GROUP BY
COUNT DISTINCT

下面简单介绍一下常见的数据倾斜处理办法：

解决方案 1：user_id 为空的不参与关联

select * from log a join user b on a.user_id is not null and a.user_id = b.user_id
union all
select * from log c where c.user_id is null;

解决方案 2：赋予空值新的 key 值

select * from log a left outer join user b on
case when a.user_id is null then concat('hive',rand()) else a.user_id end = b.user_id

注意：使用map join解决小表关联大表造成的数据倾斜问题。这个方法使用的频率很高。

map join 概念：将其中做连接的小表（全量数据）分发到所有 MapTask 端进行 Join，从而避免了 reduceTask，前提要求是内存足以装下该全量数据

这个在写sql的时候经常遇到

可以将其优化成两个查询

1、先distinct 子查询

2、在进行count 处理

以上这样的做法是避免只有一个reduce处理较慢的情况，这样如果的你的数据量很大，在只有一个reduce的情况下处理的速度是很慢的。

group by,使用Hive对数据做一些类型统计的时候遇到过某种类型的数据量特别多，而其他类型数据的数据量特别少。当按照类型进行group by的时候，会将相同的group by字段的reduce任务需要的数据拉取到同一个节点进行聚合，而当其中每一组的数据量过大时，会出现其他组的计算已经完成而这里还没计算完成，其他节点的一直等待这个节点的任务执行完成，所以会看到一直map 100% reduce 99%的情况。

解决方法：set hive.map.aggr=true

set hive.groupby.skewindata=true

原理：hive.map.aggr=true 这个配置项代表是否在map端进行聚合

hive.groupby.skwindata=true 当选项设定为 true，生成的查询计划会有两个 MR Job。第一个 MR Job 中，Map 的输出结果集合会随机分布到 Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中），最后完成最终的聚合操作。

正文完

请博主喝杯咖啡吧！