Hive优化

优化手段

合理控制Map和Reduce数

合并小文件

避免数据倾斜，解决数据倾斜

减少job数（合并Job、大Job分拆……）

 

一、  Map数和Reduce数

Hive官方：

https://cwiki.apache.org/confluence/display/Hive/Home

 

1.1、Map数

Map数过大

    Map阶段输出文件太小，产生大量小文件

     初始化和创建Map的开销很大

 

Map数太小

         文件处理或查询并发度小，Job执行时间过长

         大量作业时，容易堵塞集群

 

通常情况下，作业会通过input文件产生一个或者多个map数

主要的决定因素有： input的文件数，input的文件大小。

 

•举例

   a) 假设input目录下有1个文件a,大小为780M,那么hadoop会将该文件a分隔成7个块（6个128m的块和1个12m的块，Block是128M），从而产生7个map数

b) 假设input目录下有3个文件a,b,c,大小分别为10m，20m，130m，那么hadoop会分隔成4个块（10m,20m,128m,2m）,从而产生4个map数

 

 

两种方式控制Map数：即减少map数和增加map数

减少map数可以通过合并小文件来实现，这点是对文件源

增加map数的可以通过控制上一个job的reduer数来控制(一个sql中join多个表会分解为多个mapreduce)

 

 

小文件进行合并：

Map阶段Hive（0.7版本之后）自动对小文件合并

 

对应参数和默认值：

set hive.merge.mapfiles = true #在Map-only的任务结束时合并小文件

set hive.merge.mapredfiles = true #默认是false，true时在Map-Reduce的任务结束时合并小文件

set hive.merge.size.per.task= 256*1000*1000 #合并文件的大小

set mapred.max.split.size=256000000;  #每个Map最大分割大小

 

setmapred.min.split.size.per.node=100000000; #一个节点上split的最少值

set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;  #执行Map前进行小文件合并

 

set的作用域是Session级

 

 

在开启了org.apache.hadoop.hive.ql.io.CombineHiveInputFormat后，一个data node节点上多个小文件会进行合并，合并文件数由mapred.max.split.size限制的大小决定。

mapred.min.split.size.per.node决定了多个datanode上的文件是否需要合并~

 

1.1.2 、参数：mapred.map.tasks

Hive中setmapred.map.tasks=100;  当文件小于

 

案例：

环境如下：

hive.merge.mapredfiles=true (默认是false，可以在hive-site.xml里配置)

hive.merge.mapfiles=true

hive.merge.size.per.task=256000000

mapred.map.tasks=2

 

因为合并小文件默认为true，而dfs.block.size与hive.merge.size.per.task的搭配使得合并后的绝大部分文件都在256MB左右。

 

Case 1：

 

现在我们假设有3个300MB大小的文件，

整个JOB会有6个map，其中3个map分别处理256MB的数据，还有3个map分别处理44MB的数据。

木桶效应就来了，整个JOB的map阶段的执行时间不是看最短的1个map的执行时间，而是看最长的1个map的执行时间。所以，虽然有3个map分别只处理44MB的数据，可以很快跑完，但它们还是要等待另外3个处理256MB的map。显然，处理256MB的3个map拖了整个JOB的后腿。

 

Case 2：

 

如果我们把mapred.map.tasks设置成6，再来看一下有什么变化：

goalsize = min(900MB/6,256MB) = 150MB

整个JOB同样会分配6个map来处理，每个map处理150MB的数据，非常均匀，谁都不会拖后腿，最合理地分配了资源，执行时间大约为CASE 1的59%(150/256)

 

1.2、reduce数

Reduce数过大

生成了很多个小文件（最终输出文件有reduce决定，一个reduce一个文件），那么如果这些小文件作为下一个Job输入，则也会出现小文件过多需要进行合并的问题。

启动和初始化reduce也会消耗时间和资源；有多少个reduce就会有多少个输出文件

 

Reduce数过低

执行耗时

可能出现数据倾斜

 

 

 

 

Reducer个数的决定

默认下，Hive分配reducer个数基于以下：

    参数1：hive.exec.reducers.bytes.per.reducer（默认为1G)

参数2 ：hive.exec.reducers.max（默认为999）

•计算reducer数的公式

•N=min(参数2，总输入数据量/参数1)

即默认一个reduce处理1G数据量

 

 

•什么情况下只有一个reduce

    很多时候你会发现任务中不管数据量多大，不管你有没有设置调整reduce个数的参数，任务中一直都只有一个reduce任务；

1、  除了数据量小于hive.exec.reducers.bytes.per.reducer参数值的情况外

2、没有group by的汇总

3、用了Order by。

 

1.2.1 、设置Reduce数

参数：mapred.reduce.tasks

默认：1

 

set mapred.reduce.tasks=10.. ;

作用域Session级

 

当某个Job的结果别后边Job多次引用时，设大该参数，以便增大访问的Map数。

 

以第一讲、第二讲的代码为例。

 

Reduce数决定中间或落地文件数，文件大小和Block大小无关。

 

 

二、数据倾斜

1、什么是数据倾斜？Hadoop框架的特性决定最怕数据倾斜

JobTracker  TaskTracker…..

老师          学生

 

•由于数据分布不均匀，造成数据大量的集中到一点，造成数据热点。

 

症状：map阶段快，reduce阶段非常慢；

     某些map很快，某些map很慢；

     某些reduce很快，某些reduce奇慢

 

如下情况：

A、数据在节点上分布不均匀

B、join时on关键词中个别值量很大（如null值）

C、count(distinct ),在数据量大的情况下，容易数据倾斜，因为count(distinct)是按group by 字段分组，按distinct字段排序。

 

其中A无法避免。B见后边的Join章节。C语法上有时无法避免

 

 

 

 

三、  Join、MapJoin、Group by

Join

按照join的key进行分发，而在join左边的表的数据会首先读入内存，如果左边表的key相对分散(或少，分散的意思是相同key的数据量小)，读入内存的数据会比较小，join任务执行会比较快；而如果左边的表key比较集中，而这张表的数据量很大，那么数据倾斜就会比较严重。

Map阶段同一Key数据分发给一个reduce。

 

Join原则：

小表 Join大表，原因是在 Join 操作的Reduce阶段（不是Map阶段），位于 Join左边的表的内容会被加载进内存，将条目少的表放在左边，可以有效减少发生内存溢出的几率。

多个表关联时，最好分拆成小段，避免大sql（无法控制中间Job）

 

多表 Join on条件相同时合并为一个 Map-Reduce，做 OUTER JOIN 的时候也是一样，查看执行计划explain

比如查询,3个表关联：

select pt.page_id,count(t.url) PV

 fromrpt_page_type pt

 join

 (select url_page_id,url from trackinfo whereds='2013-10-11') t

 onpt.page_id=t.url_page_id

 join

 (select page_id from rpt_page_kpi_new whereds='2013-10-11') r

 ont.url_page_id=r.page_id

 group by pt.page_id;

 

比较2个表关联：

select pt.page_id,count(t.url) PV

 fromrpt_page_type pt

 join

 (select url_page_id,url from trackinfo whereds='2013-10-11') t

 onpt.page_id=t.url_page_id

group by pt.page_id;

 

利用这个特性，可以把相同join on条件的放在一个job处理。

如果 Join 的条件不相同，如：

 

INSERT OVERWRITE TABLE page_pv

select pt.page_id,count(t.url) PV

 fromrpt_page_type pt

 join

 (select url_page_id,url,province_id fromtrackinfo where ds='2013-10-11') t

 onpt.page_id=t.url_page_id

 join

 (select page_id,province_id fromrpt_page_kpi_new where ds='2013-10-11') r

 ont.province_id=r.province_id

 group by pt.page_id;

 

大表Join大表

访户未登录时，日志中userid是空，在用user_id进行hash分桶的时候，会将日志中userid为空的数据分到一起，导致了过大空key造成倾斜。

 

解决办法：

         把空值的key变成一个字符串加上随机数，把倾斜的数据分到不同的 reduce上，由于null值关联不上，处理后并不影响最终结果

案例：

End_user  5000万，纬度表

Trackinfo  每日2亿，按日增量表

 

原写法：

select u.id,t.url,t.track_time

 fromend_user u

 join

 (select end_user_id,url,track_time fromtrackinfo where ds='2013-12-01') t

 onu.id=t.end_user_id limit 2;

 

调整为：

select u.id,t.url,t.track_time

 fromend_user u

 join

(select case whenend_user_id='null' or end_user_id is null

             then cast(concat('00000000_',floor(rand()*1000000)) as bigint)

             else end_user_id end end_user_id ,

       url,track_time

  from trackinfo where ds='2013-12-01') t

 onu.id=t.end_user_id limit 2;

 

MapJoin

Join 操作在 Map 阶段完成，如果需要的数据在Map 的过程中可以访问到则不再需要Reduce。

 

小表关联一个超大表时，容易发生数据倾斜，可以用MapJoin把小表全部加载到内存在map端进行join，避免reducer处理。

如：

INSERT OVERWRITETABLE page_pv

select /*+ MAPJOIN(pt) */

pt.page_id,count(t.url) PV

 from rpt_page_type pt

 join

 (select url_page_id,url from trackinfo whereds='2013-10-11') t

 on pt.page_id=t.url_page_id;

 

 

 

如果是小表，能否自动选择Mapjoin？

set hive.auto.convert.join= true; 默认为false

该参数为true时，Hive自动对左边的表统计量，如果是小表就加入内存，即对小表使用Map join

大表小表的阀值：

hive> set hive.mapjoin.smalltable.filesize;

hive.mapjoin.smalltable.filesize=25000000

默认值是25mb

 

 

hive.mapjoin.cache.numrows

•说明： mapjoin 存在内存里的数据量

•默认值：25000

 

hive.mapjoin.cache.numrows

•说明： mapjoin 存在内存里的数据量

•默认值：25000

 

hive.mapjoin.followby.gby.localtask.max.memory.usage

•说明：map join做group by 操作时，可以使用多大的内存来存储数据，如果数据太大，则不会保存在内存里

•默认值：0.55

hive.mapjoin.localtask.max.memory.usage

•说明：本地任务可以使用内存的百分比

•默认值： 0.90

 

 

 

 

 

Group By

 

   Map 端部分聚合：

       并不是所有的聚合操作都需要在 Reduce 端完成，很多聚合操作都可以先在 Map 端进行部分聚合，最后在 Reduce 端得出最终结果。

       基于 Hash

       参数包括：

           hive.map.aggr = true 是否在 Map 端进行聚合，默认为 True

           hive.groupby.mapaggr.checkinterval = 100000 在 Map 端进行聚合操作的条目数目

 

默认情况下，Map阶段同一Key数据分发给一个reduce，当一个key数据过大时就倾斜了

 

    有数据倾斜的时候进行负载均衡

        hive.groupby.skewindata = false

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

 

Count(distinct) 容易倾斜，当该字段存在大量值为NULL或空的记录

解决思路 

count distinct时，将值为空的数据在where里过滤调，在最后结果中加1

 

如：

         count(distinct end_user_id) as user_num

         修正为

         cast(count(distinctend_user_id)+1 as bigint) as user_num

where  end_user_id is not nulland query <> ''

 

 

 

笛卡尔积

尽量避免笛卡尔积，join的时候不加on条件，或者无效的on条件，Hive只能使用1个reducer来完成笛卡尔积

On中支持udf函数

 

 

 

三、减少job数

源表相同时，如下可以合并Job

 

union all

Multi-Insert（Multi-GroupBy一定会和Multi-Insert一起使用，同一源表，可按照不同where、不同group by ）

 

 

union all

对同一表的union all 只查一次源表，hive本身对这种union all做过优化。

但子查询不能group by

 

select url,session_id from

(select url,session_id

 fromtrackinfo where ds='2013-11-01'

union all

 select url,session_id

 fromtrackinfo where ds='2013-11-02'

) t ;

 

 

 

Multi-Insert

上方的sql等同于：

 

From trackinfo

 insertoverwrite table tmp_test partition(step=1)  

  selecturl,session_id where ds='2013-11-01'

 insertoverwrite table tmp_test partition(step=2)  

  selecturl,session_id  where ds='2013-11-02' ;