Hadoop集群的优化方法

Hadoop优化

数据压缩

压缩前小思考

在学习这个数据压缩前,我们想想为什么要压缩?

压缩技术能够有效减少底层存储系统（HDFS）读写字节数。压缩提高了网络带宽和磁盘空间的效率。在运行MR程序时，I/O操作、网络数据传输、 Shuffle和Merge要花大量的时间，尤其是数据规模很大和工作负载密集的情况下，因此，使用数据压缩显得非常重要。

上面看到了压缩的好处,知道压缩可以节约很多的时间,但是所有的文件都适合压缩吗?

答案肯定是否定的,相信大多数人都和我一样的答案. 部分小文件压缩的话,肯定是得不偿失的.磁盘I/O和网络带宽是Hadoop的宝贵资源，数据压缩对于节省资源、最小化磁盘I/O和网络传输非常有帮助。可以在任意MapReduce阶段启用压缩。不过，尽管压缩与解压操作的CPU开销不高，其性能的提升和资源的节省并非没有代价。因此在压缩时也是需要想想是否利大于弊的.

看完上面两个问题过后,我们怎样去权衡压缩情况呢?或者说有哪些注意事项呢?

基本原则:

① 运算密集型的job，少用压缩

② IO密集型的job,多用压缩

注意：采用压缩技术减少了磁盘IO，但同时增加了CPU运算负担。所以，压缩特性运用得当能提高性能，但运用不当也可能降低性能。

MR支持的压缩编码

压缩格式	hadoop自带？	算法	文件扩展名	是否可切分	换成压缩格式后，原来的程序是否需要修改
DEFLATE	是，直接使用	DEFLATE	.deflate	否	和文本处理一样，不需要修改
Gzip	是，直接使用	DEFLATE	.gz	否	和文本处理一样，不需要修改
bzip2	是，直接使用	bzip2	.bz2	是	和文本处理一样，不需要修改
LZO	否，需要安装	LZO	.lzo	是	需要建索引，还需要指定输入格式
Snappy	是，直接使用	Snappy	.snappy	否	和文本处理一样，不需要修改

为了支持多种压缩/解压缩算法，Hadoop引入了编码/解码器，如下表所示。

压缩格式	对应的编码/解码器
DEFLATE	org.apache.hadoop.io.compress.DefaultCodec
gzip	org.apache.hadoop.io.compress.GzipCodec
bzip2	org.apache.hadoop.io.compress.BZip2Codec
LZO	com.hadoop.compression.lzo.LzopCodec
Snappy	org.apache.hadoop.io.compress.SnappyCodec

压缩性能的比较

压缩算法	原始文件大小	压缩文件大小	压缩速度	解压速度	优缺点
gzip	8.3GB	1.8GB	17.5MB/s	58MB/s	本身自带;效率较高高;但不支持split切分
bzip2	8.3GB	1.1GB	2.4MB/s	9.5MB/s	支持Split；具有很高的压缩率，比Gzip压缩率都高；本身自带;压缩速度慢;
LZO	8.3GB	2.9GB	49.3MB/s	74.6MB/s	压缩/解压速度也比较快，合理的压缩率；支持Split;压缩率比Gzip要低一些；本身不支持，需要安装；在应用中对Lzo格式的文件需要做一些特殊处理（为了支持Split需要建索引，还需要指定InputFormat为Lzo格式）。
Snappy	/	/	最快250MB/s	最快500MB/s	高速压缩速度和合理的压缩率;不支持Split；压缩率比Gzip要低；Hadoop本身不支持，需要安装。

MR选择压缩的地方

在学习MR的时候,我们有看到MR可以选择的压缩地方有很多,下面一起看看压缩的具体位置:

压缩的参数配置

要在Hadoop中启用压缩，可以配置如下参数：

参数	默认值	阶段	建议
io.compression.codecs （在core-site.xml中配置）	无，这个需要在命令行输入hadoop checknative查看	输入压缩	Hadoop使用文件扩展名判断是否支持某种编解码器
mapreduce.map.output.compress（在mapred-site.xml中配置）	false	mapper输出	这个参数设为true启用压缩
mapreduce.map.output.compress.codec（在mapred-site.xml中配置）	org.apache.hadoop.io