hadoop 优化配置（Hadoop之常见压缩格式以及性能对比）

为什么会出现需要对文件进行压缩？

在Hadoop中，文件需要存储、传输、读取磁盘、写入磁盘等等操作，而文件的大小，直接决定了这些这些操作的速度。

好处

• 减少存储磁盘空间
• 降低io(网络的IO和磁盘的IO)
• 加快数据在磁盘和网络中的传输速度，从而提高系统的处理速度

坏处

• 由于使用数据时，需要先将数据解压，加重CPU负荷。而且压缩的越狠，耗费的时间越多。

支持native表示，hadoop自己提供了功能的实现，而不是依赖外部，如bzip2是不支持native，则表示物理机要另行安装支持bzip2压缩的软件。

一个简单的案例对于集中压缩方式之间的压缩比和压缩速度进行一个感观性的认识

压缩比

压缩时间/解压时间

可以看出，压缩比越高，压缩时间越长，压缩比：Snappy<LZ4<LZO<GZIP<BZIP2

a. gzip

优点：压缩比在四种压缩方式中较高；hadoop本身支持，在应用中处理gzip格式的文件就和直接处理文本一样；有hadoop native库；大部分linux系统都自带gzip命令，使用方便

缺点：不支持split

b. lzo

优点：压缩/解压速度也比较快，合理的压缩率；支持split，是hadoop中最流行的压缩格式；支持hadoop native库；需要在linux系统下自行安装lzop命令，使用方便

缺点：压缩率比gzip要低；hadoop本身不支持，需要安装；lzo虽然支持split，但需要对lzo文件建索引，否则hadoop也是会把lzo文件看成一个普通文件（为了支持split需要建索引，需要指定inputformat为lzo格式）

c. snappy

优点：压缩速度快；支持hadoop native库

缺点：不支持split；压缩比低；hadoop本身不支持，需要安装；linux系统下没有对应的命令

d. bzip2

优点：支持split；具有很高的压缩率，比gzip压缩率都高；hadoop本身支持，但不支持native；在linux系统下自带bzip2命令，使用方便

缺点：压缩/解压速度慢；不支持native

1. 第一次传入压缩文件，应选用可以切片的压缩方式，否则整个文件将只有一个Map执行。Use Compressd Map Input:从HDFS中读取文件进行Mapreuce作业，如果数据很大，可以使用压缩并且选择支持分片的压缩方式（Bzip2,LZO），可以实现并行处理，提高效率，减少磁盘读取时间，同时选择合适的存储格式例如Sequence Files，RC,ORC等。
2. 第二次压缩应选择压缩解压速度快的压缩方式，生产中，Map阶段数据落盘通常使用snappy压缩格式（快速压缩解压）。Compress Intermediate Data:Map输出作为Reducer的输入，需要经过shuffle这一过程，需要把数据读取到一个环形缓冲区，然后读取到本地磁盘，所以选择压缩可以减少了存储文件所占空间，提升了数据传输速率，建议使用压缩速度快的压缩方式，例如Snappy和LZO。
3. 第三次压缩有两种场景分别是：一.当输出文件为下一个job的输入，选择可切分的压缩方式例如：BZip2。二.当输出文件直接存到HDFS，作为归档，选择压缩比高的压缩方式。reduce阶段数据落盘通常使用gzip或bzip2进行压缩（减少磁盘使用）。Compress Reducer Output:进行归档处理或者链接Mapreduce的工作（该作业的输出作为下个作业的输入），压缩可以减少了存储文件所占空间，提升了数据传输速率，如果作为归档处理，可以采用高的压缩比（Gzip,Bzip2），如果作为下个作业的输入，考虑是否要分片进行选择。

不同的场景选择不同的压缩方式，肯定没有一个一劳永逸的方法，如果选择高压缩比，那么对于cpu的性能要求要高，同时压缩、解压时间耗费也多；选择压缩比低的，对于磁盘io、网络io的时间要多，空间占据要多；对于支持分割的，可以实现并行处理。

☆若该压缩格式不支持文件分割，则后续无法实现并行处理，生产优化核心是让每个文件大小略微低于块大小，如块128M文件怎样为125M。未压缩的文件是支持文件分割的

一般在HDFS 、Hive、HBase中会使用；

当然一般较多的是结合Spark 来一起使用。