Hadoop中的数据压缩

在集群处理大数据时，压缩数据可以带来两方面的好处：
1，减少存储磁盘空间，降低单节点的磁盘IO。
2，由于压缩后的数据占用的带宽更少，因此可以加快数据在Hadoop集群流动的速度。例如在不同节点创建3个replica的阶段，或是shuffling阶段。

压缩的是什么
1，压缩输入文件 -- 在后面的“压缩和输入分片”一节中我们可以看出，将输入文件做合理压缩后，Hadoop会将压缩后的文件切分为数据分片，分配给多个Mapper执行。Mapper会对每个数据分片先解压缩，然后处理。
2，压缩输出文件 -- 对输出文件做压缩一个目的是减少输出文件对HDFS的磁盘空间占用。如果输出文件需要被下游模块使用，也可以降低数据拷贝的网络传输成本。
3，压缩Mapper输出文件 -- MapReduce过程中，Map阶段完成后需要将大量中间结果写入磁盘并在partition和shuffling过程中在集群中来回拷贝，以供Reduce阶段使用。因此对Mapper输出的中间结果压缩可以降低partition和shuffling的网络传输成本。

是否应该使用压缩
使用压缩的好处上文已经说明，缺点则是需要花费额外的时间/CPU做压缩和解压缩计算。总的来说使用压缩可以提高效率，应尽可能的使用，尤其是以下场景：
1，数据更多的是被存储，而不是被处理。例如使用HDFS作为数据存储，且上层搭建了Hive数据仓库。
2，数据本身有不错的压缩率。例如输入文件是Parquet这样的列存储文件，或是RCFile，ORCFile这样的行列混合存储文件。对列存储文件和行列混合存储文件压缩可以获得极大的性能提升。

压缩和输入分片
在选择压缩算法时，理解各种压缩格式是否支持切分是非常重要的。以一个存储在HDFS且压缩前为1GB的flat file为例，如果HDFS的块大小设置为64MB，那么该文件被存储在1GB/64MB=16个块中(这里没有考虑数据副本的问题)，在MapReduce处理开始时，每个数据块作为一个map任务的输入。
现在考虑一个压缩后为1GB的gzip文件。与以前一样，HDFS将这个文件保存为16个数据块。但是将每个数据块单独作为一个输入分片是无法正常工作的，因为单独的压缩分片无法正常解压，所以让map任务独立于其他任务进行数据读取是行不通的。
在这种情况下，MapReduce会采用正确的做法，它不会尝试切分gzip压缩文件，因为它知道输入是gzip压缩文件(通过文件扩展名判断)且gzip不支持切分。但这样就无法发挥Map的优势--并行处理数据块。
因此在制订压缩策略时的重点之一就是如何实现数据分片。

压缩算法

常见的压缩算法如下表所示。这里我们并不详细解释这些算法，但是需要注意bzip2和LZO支持分片，也就是说这两种算法天然就解决了上文中的数据分片问题。

Compression format	Tool	Algorithm	File extension	Splittable
gzip	gzip	DEFLATE	.gz	No
bzip2	bizp2	bzip2	.bz2	Yes
LZO	lzop	LZO	.lzo	Yes if indexed
Snappy	N/A	Snappy	.snappy	No

 

容器文件格式
在Hadoop中，我们可以使用容器文件格式，例如 sequenceFile，RCFile或者Avro file。所有这些文件格式同时支持压缩和切分。因此使用这些文件也可以解决数据分片的问题。

压缩策略
以下压缩策略的效率从高到低排列：
1，使用容器文件格式，如sequenceFile，RCFile或者Avro file。通常最好与一个快速压缩工具联合使用，如LZO，LZ4或者Snappy。例如在Hive使用internal table时可以定义使用RCFile作为文件存储，同时可指定要使用的压缩算法。
2，使用支持切分的压缩格式，例如bzip2(尽管bzip2非常慢)，或者使用通过索引实现切分的压缩格式，例如LZO。
3，在应用中将文件切分成块，并使用任意一种压缩格式为每个数据块建立压缩文件(不论是否支持切分)。这种情况需要合理选择数据的大小，以确保压缩后数据块的大小近似与HDFS块的大小。

4，存储未经压缩的文件。

 

使用的API

Hadoop将上文常见的压缩算法包装在自己的API中,例如org.apache.hadoop.io.compress.GzipCodec。

对输入数据和输出数据压缩时，可直接调用相应的Codec。在对Map输出的中间数据压缩时，一般采用配置属性的方法：

mapred.compress.map.output -- 是否对Map输出进行压缩

mapred.map.output.compression.codec -- map输出所用的codec