hive优化

深藏阁楼爱情的钟 2022-04-18 02:33 292阅读 0赞

Map优化

1.  通过调整脚本的参数来设置map的个数，和设置block大小，block是影响map个数的关键因素

直接设置map个数：set mapred.map.tasks=10

2.为了任务加快，有一些任务可以考虑开启compiners:

Hive.map.aggr=true

Reduce优化：

1.提交sql，设置的参数

原因：有一个reduce个数的计算公式，这个公式依赖于这个参数

Reduce个数=InputFileSize(整个文件数据的大小)/bytes per reducer(每一个reduce处理的大小)

这个参数就是设置分母

2.直接设置reduce的个数：![20181107121240478.png][]

In order to change the average load for a reducer (in bytes):  
  set hive.exec.reducers.bytes.per.reducer=<number>   
  如果大于<number>，就会多生成一个reduce  
  <number> =1024    <1k 一个reduce  
  1m 10个reduce  
    
  set hive.exec.reducers.bytes.per.reducer=20000;  
  select user\_id,count(1) as order\_cnt   
  from orders group by user\_id limit 10;  
\--结果number of mappers: 1; number of reducers: 1009    
    
    
In order to limit the maximum number of reducers:  
  set hive.exec.reducers.max=<number>  
  set hive.exec.reducers.max=10;  
 -- number of mappers: 1; number of reducers: 10   
   
In order to set a constant number of reducers:  
  set mapreduce.job.reduces=<number>  
  set mapreduce.job.reduces=5;  
  --number of mappers: 1; number of reducers: 5  
  set mapreduce.job.reduces=15;  
  --number of mappers: 1; number of reducers: 15  
  对你当前窗口，或者执行任务（脚本）过程中生效

3.对于没有group by，又做了count这样聚合的函数的时候它最后跑出来的reduce个数就是一个![2018110712114130.png][]

4.分区优化：

![20181107122309335.png][]减少不必要的数据过滤。

5.笛卡尔积优化：

![20181107122539652.png][]

用where取代on

6.map join优化：

Map join：类似一种检索配置文件的形式

例如：A是一个文件，B是一个文件，A.join B

如果A是小表，考虑是否可以将A放入内存，只遍历大表B，大表可以帮忙做一个性能的提升。

如何知道哪个是小表和大表：

MAPJOIN(tablelist)明确mapjoin里是小表

/\*+ STREAMTABLE(a) \*/ a是大表

类似map join 放到select中的，区别：它是指定大表  
select /\*+STREAMTABLE(pr)\*/ ord.order\_id,pr.product\_id,pro.aisle\_id  
from orders ord  
join priors pr on ord.order\_id=pr.order\_id  
join products pro on pr.product\_id=pro.product\_id  
limit 10;

7.union/union all优化：

union all / distinct   == union  
\--运行时间：74.712 seconds 2job  
select count(distinct \*)   
from (  
select order\_id,user\_id,order\_dow from orders where order\_dow='0' union all  
select order\_id,user\_id,order\_dow from orders where order\_dow='0' union all   
select order\_id,user\_id,order\_dow from orders where order\_dow='1'  
)t;

\--运行时间122.996 seconds 3 job  
select count(\*)   
from(  
select order\_id,user\_id,order\_dow from orders where order\_dow='0' union   
select order\_id,user\_id,order\_dow from orders where order\_dow='0' union   
select order\_id,user\_id,order\_dow from orders where order\_dow='1')t;

8.两个不同任务来自一张表的优化：

从公共表取数据写到另外一张表里，例如：

![20181107123934529.png][]

9.执行hive任务的时候会产生一些临时中间文件，中间小的文件比较多，如何对多个小文件进行合并：

配置参数：map阶段，reduce结果做合并，每个任务预期合并的size大小

![20181107124316845.png][]

10.数据倾斜问题优化：

假设数据源存在数据倾斜问题（有的key的记录多，有的key的记录少，记录多的跑到同一个

Reduce里，会导致一个reduce特别慢，key的分布不均匀）

优化方法：

10.1.Mr：对key做改写来解决类似问题

10.2.Hive：hive.groupby.skewindata这个参数会帮你完成一定的负载均衡

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4Mjg2MDI3_size_16_color_FFFFFF_t_70][]

如果在不导致reduce一直失败起不来的时候，就不用这个变量  
如果确实出现了其中一个reduce的处理数据量太多，导致任务一直出问题，运行时间长。这种情况需要设置这个变量。

10.3 '-' ,where age<>'-' 直接丢掉这个数据  
select age,count(1) group by age where age<>'-'

怎么定位具体哪几个key发生倾斜？  
sample（简单采样）

10.4 空间换时间

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4Mjg2MDI3_size_16_color_FFFFFF_t_70 1][]

避免通过之前用distinct把所有数据用在一个reduce上。

11.sql语句优化

例如如下两个sql语句：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4Mjg2MDI3_size_16_color_FFFFFF_t_70 2][]

第一条sql语句在join后再进行过滤，相当于做了两步。

第二条sql语句在join过程中就对条件进行了预先过滤。

12.并行执行MapReduce优化，如下图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4Mjg2MDI3_size_16_color_FFFFFF_t_70 3][]

例如每个圆形就是一个MapReduce，橙色部分需要依赖别人，蓝色部分没有相互依赖关系的节点就可以尽可能地单独执行。

那么蓝色的MapReduce就可以同时执行，就是并行。设置并行执行的方法：

开启并行的方法：Set hive.exec.parallel设置为true

![20181107162023170.png][]

13.两个大表情况的优化：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4Mjg2MDI3_size_16_color_FFFFFF_t_70 4][]

![2018110716233847.png][]

将绝大部分没用的用户的基础信息过滤掉。

结合业务的特点，将大表变成小表

[20181107121240478.png]: /images/20220418/d64adf9c663e496d93f9b3643e794207.png
[2018110712114130.png]: /images/20220418/dbe14f9e9ee048c7bf75b1e02d49df03.png
[20181107122309335.png]: /images/20220418/1c6d8873151b441380a0dafe34c5aad3.png
[20181107122539652.png]: /images/20220418/7da559cc556745c1b9c00ed83f7b7282.png
[20181107123934529.png]: /images/20220418/12e96f4275eb4b80bc70c0ae8967354c.png
[20181107124316845.png]: /images/20220418/d9b116c027cb49b7a8a897b1adc40aa4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4Mjg2MDI3_size_16_color_FFFFFF_t_70]: /images/20220418/f5a2605cb4b648f4b2444c3089567bd3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4Mjg2MDI3_size_16_color_FFFFFF_t_70 1]: /images/20220418/cee4d3b3eb774fbaae423f08a1a86954.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4Mjg2MDI3_size_16_color_FFFFFF_t_70 2]: /images/20220418/ae03ea5dba8e4fb7a822f0686b295b21.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4Mjg2MDI3_size_16_color_FFFFFF_t_70 3]: /images/20220418/4d0e90f6c7af4cc0bdafef19f5015dd2.png
[20181107162023170.png]: /images/20220418/be73cd0e5f364d16bc3dcc3575f87bec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4Mjg2MDI3_size_16_color_FFFFFF_t_70 4]: /images/20220418/2bc6f3b57def408b9b087af4ff5190bd.png
[2018110716233847.png]: /images/20220418/f801e3a969414c06b3da1b946539cf80.png