hive作业的优化策略

Mapreduce自身的特点：

1、IO和网络负载大；优化策略：减少IO和网络负载。

2、内存负载不大。优化策略：增大内存使用率；

3、CPU负载不大。优化策略：增大CPU使用率；

（hive的优化应当根据mapreduce的作业特点和自己的作业实际需求进行优化）

优化1、合并输入

淘宝一个大型项目，上万Hive作业进行合并输入。

A、单个作业

B、多个作业

作业间的血缘关系：作业间相同的查询，相同的源表。

优化2、源表归纳，常用复杂或低效统计统一给出，以避免上层作业过多计算

如低性能的UDF、低性能、高使用率的计算模块 等情况，在底层表统一处理。

3、合理设计表分区，静态分区和动态分区

比如如果对日志表等大表有较多按小时的查询，则设计为二级分区表，分区字段：日期、小时。

动态分区：

曾经一个案例，需要一天每个小时的数据。

方案一：统计24次，分别统计每个小时的。

方案二：动态分区，只需要统计一次就完成24个小时分区的加载。

需求：

按省份统计每小时的流量。

create table province_hour_visit(

provice_id int,

uv bigint,

pv bigint

) partitioned by (ds string,hour string);

insert overwrite table province_hour_visit partition(ds='2015-08-28',hour)

select provinceid,

count(distinct guid) uv ,

count(url) pv,

hour

from track_log where ds='2015-08-28'

group by ds,hour,provinceid;

一、压缩

Map读取文件（IO压力），shuffle阶段进行网络传输（网络压力），reduce落地结果（IO压力）。

压缩后，文件可以缩小70-75%，缓解网络传输压力。但需要压缩和解压增加了CPU负载，所以是把压力转到了CPU上。

二、不采取全局压缩方式，而是采取局部压缩方式。

原因：

1、数据量大的表才值得压缩，小表无所谓。

2、全局压缩会导致开发的MapReduce作业、Sqoop作业存在兼容性问题。

全局压缩的方式是：

修改mapreduce属性mapred-site.xml

<property>

<!-- 整个作业输出端(Reduce端)是否开启压缩->

<name>mapred.output.compress</name>

<value>false</value>

</property>

<property>

<!-- 整个作业输出端压缩算法->

<name>mapred.output.compression.codec</name>

<value>org.apache.hadoop.io.compress.DefaultCodec</value>

</property>

<property>

<!-- 压缩方式->

<name>mapred.output.compression.type</name>

<value>BLOCK</value>

</property>

<property>

<!-- map端输出压缩算法-->

<name>mapred.map.output.compression.codec</name>

<value>org.apache.hadoop.io.compress.SnappyCodec</value>

</property>

<property>

<!-- map端输出进行压缩-->

<name>mapred.compress.map.output</name>

<value>true</value>

</property>

三、压缩方式对比

算法	压缩后/压缩前	压缩速度	解压速度
GZIP	13.4%	21 MB/s	118 MB/s
LZO	20.5%	135 MB/s	410 MB/s
DefaultCodec	24.2%	155MB/s	390MB/s
Snappy	22.2%	172 MB/s	409 MB/s

曾经用LZO压缩，CDH没集成，需要手工安装，且常导致个别老机器down机，故废弃。

CDH4 集成了Snappy，也推荐用该方式。

Snappy 网站：http://code.google.com/p/snappy/

Snappy的前身是Zippy。虽然只是一个数据压缩库，它却被Google用于许多内部项目程，其中就包括BigTable，MapReduce和RPC。Google宣称它在这个库本身及其算法做了数 据处理速度上的优化，作为代价，并没有考虑输出大小以及和其他类似工具的兼容性问题。Snappy特地为64位x86处理器做了优化，在单个Intel Core i7处理器内核上能够达到至少每秒250MB的压缩速率和每秒500MB的解压速率。

四、局部压缩的方式，以Snappy为例

Hive作业或cli里设置会话域参数:

set hive.exec.compress.output=true;

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

set mapred.output.compression.type=BLOCK;

举例对比压缩前后的大小，计算压缩比。

测试1：TEXTFILE+默认压缩算法DefaultCodec

压缩前：6669210

压缩后：1991772

压缩比：压缩后/压缩前 = 29.9%

测试2：TEXTFILE+压缩算法SnappyCodec

压缩前：6669210

压缩后：3549226

压缩比：压缩后/压缩前 = 53.2%

测试3：RCFile+压缩算法SnappyCodec

压缩前：6669210

压缩后：3520648

压缩比：压缩后/压缩前 = 51.2%

测试4：RCFile+压缩算法DefaultCodec

压缩前：6669210

压缩后：1938476

压缩比：压缩后/压缩前 = 29.1%

五、hive表的存储格式

TEXTFILE：文本文件，默认

SEQENCEFILE：序列化文件

RCFile

orc

http://blog.csdn.net/lxpbs8851/article/details/18553961

从存储和压缩上组合考虑，用RCFile+DefaultCodec 组合效果最好。

用RCFile存储的话，在hive.exec.compress.output=false情况下无压缩效果，为true时才压缩。默认压缩算法是set mapred.output.compression.codec查看为DefaultCodec

如：

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

create table test_rcfile(

url string,

referer string,

ip string)  stored as RCFile;

六、分布式缓存

如果你有个jar想引用，有种方式：

Add jar

或

通过设置hive的配置文件hive-site.xml 加入

<property>

<name>hive.aux.jars.path</name>

<value>file:///opt/software/lib/UDF.jar,file:///opt/software/lib/hiveF.jar</value>

</property>

劣势：不灵活，设置之后需要重启hive服务才生效。

像UDF这种更新频繁的情况不适用。

像固定型的如hiveF，适合。