大数据篇(2-3)--Hive（3）Hive调优

hvie调优可以分为几个模块进行考虑，数据的压缩与存储，hive参数的优化，sql的优化，解决数据的倾斜等。

一，数据的压缩与存储格式

---

1）压缩方式

      压缩可以节约磁盘的空间，基于文本的压缩率可达40%+; 压缩可增加吞吐量和性能量(减小载入内存的数据量)，但是在压缩和解压过程中会增加CPU的开销。所以针对IO密集型的jobs(非计算密集型)可以使用压缩的方式提高性能。 几种压缩算法：

压缩方式	压缩后大小	压缩速度	是否可分割
GZIP	中	中	否
BZIP2	小	慢	是
LZO	大	快	是
Snappy	大	快	是

2）存储格式（行存与列存）

1. TextFile

2.Sequence Files

3. RCFile

4.ORCFile

5.Parquet

压缩算法	Text格式	Parquet格式	ORC	RCFile
不压缩	119.2G	54.1G	20.0G	98G
Snappy压缩	30.2G	23.6G	13.6G	27.0G
Gzip压缩	18.8G	14.1G	不支持	15.2G
ZLIB压缩	不支持	不支持	10.1G	不支持

建表中与mapreduce可以选择压缩的地方

设置方式：

1. map阶段输出数据压缩 ，在这个阶段，优先选择一个低CPU开销的算法。

set hive.exec.compress.intermediate=true

set mapred.map.output.compression.codec= org.apache.hadoop.io.compress.SnappyCodec

set mapred.map.output.compression.codec=com.hadoop.compression.lzo.LzoCodec;

2.hive.exec.compress.output：用户可以对最终生成的Hive表的数据通常也需要压缩。该参数控制这一功能的激活与禁用，设置为true来声明将结果文件进行压缩。 （也可以在建表的时候进行设置）

set hive.exec.compress.output=true

set mapred.output.compression.codec=org.apache.hadoop.io.compress.SnappyCodec

结论，一般选择orcfile/parquet + snappy 的方式

建表语句：

create table tablename (

 xxx,string

 xxx, bigint

)

ROW FORMAT DELTMITED FIELDS TERMINATED BY '\t'

STORED AS orc tblproperties("orc.compress" = "SNAPPY")

二、创建分区表，桶表

---

1）创建分区表：（分区表相当于hive的索引，加快查询速度）

2）创建桶表：

三、hive参数优化

---

1）fetch task 为执行hive时，不用执行MapReduce。如select * from emp；

将Hive.fetch.task.conversion属性设置为more（默认为minimal）

2）并行执行

当一个sql中有多个job时候，且这多个job之间没有依赖，则可以让顺序执行变为并行执行（一般为用到union all ）

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

3)jvm 重用

重用JVM可以减少JVM启动时带来的开销：

JVM重用对hive的性能具有非常大的 影响，特别是对于很难避免小文件的场景或者task特别多的场景，这类场景大多数执行时间都很短。jvm的启动过程可能会造成相当大的开销，尤其是执行的job包含有成千上万个task任务的情况。

set mapred.job.reuse.jvm.num.tasks=10;

备注：

        JVM的一个缺点是，开启JVM重用将会一直占用使用到的task插槽，以便进行重用，直到任务完成后才能释放。如果某个“不平衡“的job中有几个 reduce task 执行的时间要比其他reduce task消耗的时间多得多的话，那么保留的插槽就会一直空闲着却无法被其他的job使用，直到所有的task都结束了才会释放。

4）设置reduce的数目

调整reduce个数方法一： 调整hive.exec.reducers.bytes.per.reducer参数的值；

set hive.exec.reducers.bytes.per.reducer=500000000; （500M）

调整reduce个数方法二；

set mapred.reduce.tasks = number

reduce个数的设定极大影响任务执行效率，不指定reduce个数的情况下，Hive会猜测确定一个reduce个数，基于以下两个设定：

hive.exec.reducers.bytes.per.reducer
（每个reduce任务处理的数据量，在Hive 0.14.0版本之前默认值是1G(1,000,000,000)；

而从Hive 0.14.0开始，默认值变成了256M(256,000,000) ）

 hive.exec.reducers.max
（每个任务最大的reduce数，在Hive 0.14.0版本之前默认值是999；

而从Hive 0.14.0开始，默认值变成了1009 ）

 计算reducer数的公式很简单N=min(参数2，总输入数据量/参数1) 即，如果reduce的输入（map的输出）总大小不超过1G,那么只会有一个reduce任务；

reduce个数并不是越多越好； 同map一样，启动和初始化reduce也会消耗时间和资源； 另外，有多少个reduce,就会有多少个输出文件，如果生成了很多个小文件，那么如果这些小文件作为下一个任务的输入，则也会出现小文件过多的问题

5) 推测执行

  什么是推测执行？

        所谓的推测执行，就是当所有task都开始运行之后，Job Tracker会统计所有任务的平均进度，如果某个task所在的task node机器配置比较低或者CPU load很高（原因很多），导致任务执行比总体任务的平均执行要慢，此时Job Tracker会启动一个新的任务（duplicate task），原有任务和新任务哪个先执行完就把另外一个kill掉

怎么配置推测执行参数？

推测执行需要设置Job的两个参数：

    mapred.map.tasks.speculative.execution

    mapred.reduce.tasks.speculative.execution

两个参数的默认值均为true.

四、优化sql

---

（1）where条件优化

优化前（关系数据库不用考虑会自动优化）：

select m.cid,u.id from order m join customer u on( m.cid =u.id )where m.dt='20180808';

优化后(where条件在map端执行而不是在reduce端执行）：

select m.cid,u.id from （select * from order where dt='20180818'） m join customer u on( m.cid =u.id);

（2）union优化

尽量不要使用union （union 去掉重复的记录）而是使用 union all 然后在用group by 去重

（3）count distinct优化

不要使用count (distinct   cloumn) ,使用子查询

select count(1) from (select id from tablename group by id) tmp;

（4） 用in 来代替join

如果需要根据一个表的字段来约束另为一个表，尽量用in来代替join .

select id,name from tb1  a join tb2 b on(a.id = b.id);

select id,name from tb1 where id in(select id from tb2); in 要比join 快

（5）消灭子查询内的 group by 、 COUNT(DISTINCT)，MAX，MIN。 可以减少job的数量。

（6） join 优化：

优化Map join 、Reduce join：

set hive.auto.convert.join=true;

   Common/shuffle/Reduce JOIN 连接发生的阶段，发生在reduce 阶段， 适用于大表 连接 大表(默认的方式)

Map join ： 连接发生在map阶段 ， 适用于小表 连接 大表

            大表的数据从文件中读取

            小表的数据存放在内存中（hive中已经自动进行了优化，自动判断小表，然后进行缓存）

SMB join：

   Sort -Merge -Bucket Join  对大表连接大表的优化，用桶表的概念来进行优化。在一个桶内发送生笛卡尔积连接（需要是两个桶表进行join）

set hive.auto.convert.sortmerge.join=true; 

set hive.optimize.bucketmapjoin = true; 

set hive.optimize.bucketmapjoin.sortedmerge = true; 

set hive.auto.convert.sortmerge.join.noconditionaltask=true;

五、数据倾斜

---

某个reduce的数据输入量远远大于其他reduce数据的输入量

（比如：任务进度长时间维持在99%（或100%），查看任务监控页面，发现只有少量（1个或几个）reduce子任务未完成。因为其处理的数据量和其他reduce差异过大。）

原因：

1)、key分布不均匀

2)、业务数据本身的特性

3)、建表时考虑不周

4)、某些SQL语句本身就有数据倾斜

关键词	情形	后果
join	其中一个表较小，但是key集中	分发到某一个或几个Reduce上的数据远高于平均值
join	大表与大表，但是分桶的判断字段0值或空值过多	这些空值都由一个reduce处理，非常慢
group by	group by 维度过小，某值的数量过多	处理某值的reduce非常耗时
count distinct	某特殊值过多	处理此特殊值reduce耗时

解决方案：

(1)参数调节

set hive.map.aggr=true

set hive.groupby.skewindata=true

(2) 熟悉数据的分布，优化sql的逻辑，找出数据倾斜的原因。

六、合并小文件

---

小文件的产生有三个地方，map输入，map输出，reduce输出，小文件过多也会影响hive的分析效率：

设置map输入的小文件合并

set mapred.max.split.size=256000000; 

//一个节点上split的至少的大小(这个值决定了多个DataNode上的文件是否需要合并)

set mapred.min.split.size.per.node=100000000;

//一个交换机下split的至少的大小(这个值决定了多个交换机上的文件是否需要合并) 

set mapred.min.split.size.per.rack=100000000;

//执行Map前进行小文件合并

set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;

设置map输出和reduce输出进行合并的相关参数：

//设置map端输出进行合并，默认为true

set hive.merge.mapfiles = true

//设置reduce端输出进行合并，默认为false

set hive.merge.mapredfiles = true

//设置合并文件的大小

set hive.merge.size.per.task = 256*1000*1000

//当输出文件的平均大小小于该值时，启动一个独立的MapReduce任务进行文件merge。

set hive.merge.smallfiles.avgsize=16000000

更多Hive内容：

大数据篇(2-1)--Hive（1）简介

大数据篇(2-2)--Hive（2）Hive分区表和分桶表

大数据篇(2-3)--Hive（3）Hive调优