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，适合。
