一招暴力优化Hive SQL

快速优化中间表过多的Job

分析师/运营不懂技术如何优化Hive sql？技术文章巴拉巴拉一大堆看不懂怎么办？某互联网资深数据开发写了一百页的PPT来科普SQL优化效果不佳，今天鸡眼兄就教你一招优化葵花宝典，一招变成分析师里优化的大哥大，往后无数分析师小姐姐拽着袖子让你帮忙。以防杠精，本葵花宝典前提是对技术并不深入，SQL也写的不是很熟，底层原理也不太懂的同学，且适用于集群资源充足的情况

首先讲解并行参数：set hive.exec.parallel=true; //开启任务并行执行

set hive.exec.parallel.thread.number=8; // 同一个sql允许并行任务的最大线程数

一条SQL可能会被解析成N个MR Job,如果没有开启并行的话，无论这N个MR Job之间的依赖关系如何，都要一个一个顺序执行，例：

select A from tableA union all

select B from tableB union all

select C from tableC

这条sql 是三个子查询union all起来，三个MR之间没有依赖关系，开启参数后可以并行，关闭就只能one by one，例2：

select a.* ,b.*,c.*

from tableA a

left join (select key_b,count(1) cn from tableB where dt =20200101 group by key_b) b on a.key_a=b.key_b

left join (select key_c,count(1) cn from tableC where dt =20200101 group by key_c) c on a.key_a=c.key_c

这条sql是三表关联，其中两个子查询并没有依赖关系，开参数可以b子查询和c子查询并行

再来讲解一下Create Table 与Create View。View和Table一样是数据库对象，但View只是一段逻辑，而Table是实体表。View我理解有两个作用，1.美化代码 2.控制权限

Job中的中间表大多也是为了逻辑清晰，简化/美化代码而存在的。一个Job的SQL是从上到下一条一条串行执行。例如：

create table A as select key_a ,count(1) cn from tableA group by key_a;

create table B as seelct key_b,count(1) cn from tableB group by key_b;

create table C as seelct key_c,count(1) cn from tableC group by key_c;

insert overwrite table ABC

select a.key_a,B.cn as b_cn ,C.cn as C_cn

from A

join B on A.key_a =B.key_b

join C on A.key_a =C.key_c;

如果把Create Table 改成Create View,再开启并行参数，可以在不大改代码，保持美观与清晰逻辑的同时，快速低成本的优化Job，串行变并行，两小时优化100个Job不在话下。注意，多次使用且计算成本很大的中间表，不宜改为Create View 会多次计算增加成本。

这种优化有没有什么风险呢？①并行会同时占用很多资源②本身中间表结果很小，可以自动MapJoin，被改成Create View后不会自动走MapJoin③一条SQl起过多MR，或扫描过多分区导致任务任务报错（70个MR或1000个左右分区）④多次使用的中间表不宜改为create view，重复计算浪费资源

最后编辑于：2020.03.31 19:34:43