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

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

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

1）压缩方式

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

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

1. TextFile

2.Sequence Files

3. RCFile

4.ORCFile

5.Parquet

建表中与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语句本身就有数据倾斜

解决方案：

(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调优???????