【超级有用】大数据的压缩格式

为什么map端用snappy压缩格式；而reduce用gzip或者bzip2的压缩格式呢？为什么每个reduce端压缩后的数据不要超过一个block的大小呢？      

检查Hadoop版本的压缩格式是否可用【我在Hadoop cdh 5.7版本中查看Hadoop压缩格式】

$ hadoop version

$ hadoop checknative

一、在解答上述问题以前，我们先说一下压缩的优缺点

【优点】

•   1.减少磁盘存储空间
•   2.降低IO（其中包括网络IO和磁盘IO）
•   3.加快数据在磁盘和网络中的传输速度，从而提高系统的处理速度

【缺点】

  1.由于使用数据时需要先解压，就会加重CPU的负荷

二、压缩格式

压缩格式	工具	算法	扩展名	是否支持分割	Hadoop编码/解码
DEFLATE	N/A	DEFLATE	.deflate	No	org.apache.hadoop.io.compress.DefalutCodec
gzip	gzip	DEFLATE	.gz	No	org.apache.hadoop.io.compress.GzipCodec
bzip2	bzip2	bzip2	.bz2	Yes	org.apache.hadoop.io.compress.Bzip2Codec
LZO	Lzop	LZO	.lzo	Yes(if index)	com.hadoop.compression.lzo.LzoCodec
LZ4	N/A	LZ4	.lz4	No	org.apache.hadoop.io.compress.Lz4Codec
Snappy	N/A	Snappy	.snappy	No	org.apache.hadoop.io.compress.SnappyCodec

                                

【压缩比】

 

 

从上图可以看出，压缩比越高，压缩速率越慢，压缩时间越长，压缩比：Snappy<LZ4<LZO<GZIP<BZIP2（注意，压缩比的大小不是通过数字的大小来看的，是数字越小，压缩比越大，所以snappy的压缩比是22.2%，数据最大，但是压缩比是最小的）

 三、各自压缩格式的优缺点

【gzip】

 优点：

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

缺点：

• 1@不支持split

【lzo】

优点：

• 1@压缩速率仅次于gzip，解压速率是最快的
• 2@支持split，是hadoop中最流行的压缩格式；
• 3@支持hadoop native库
• 4@需要在linux系统下自行安装lzop命令，使用方便

缺点：

• 1@压缩比要比gzip低
• 2@hadoop本身比支持，需要安装；
• 3@lzo虽然支持split，但是需要对lzo文件建索引，否则hadoop也是会把lzo文件看成一个普通文件（为了支持split需要建索引，需要制定inputformat为lzo格式）

【snappy】

优点：

• 1@压缩速度最快
• 2@支持hadoop native库

缺点

• 1@不支持split
• 2@压缩比最低
• 3@hadoop本身不支持，需要安装
• 4@linux系统下没有对应的命令

【bzip2】

优点：

• 1@支持split
• 2@压缩比最高，比gzip都高；
• 3@hadoop本身支持，但不支持native
• 4@在linux系统下自带bzip2命令，使用方便

缺点：

• 1@压缩解压速率慢
• 2@不支持native

四、总结和应用场景

【总结】

每一种压缩方式都有他的优缺点，讲求压缩效率，压缩比就会低，占用的网络io和磁盘io就多，讲求压缩比，对cpu的损耗就比较大，同时压缩和解压的耗时就比较多，

对于支持split的（lzo和bzip）可以实现并行处理。

【应用场景】

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

应用场景：

    input： Flume Sink HDFS <== Spark/MapReduce 比如flume采集到hdfs会使用到压缩
    temp:   Sink DISK  比如中间数据落地磁盘也可以使用压缩
    output: Spark/MapReduce ==> Sink Hadoop 比如spark/mr的输出会到hdfs使用到压缩

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

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

五、为什么map端和reduce端的应用压缩格式和大小的选择？

现在再让我们回过头来看我们刚刚开始提出的问题

【为什么map端用snappy压缩格式；而reduce用gzip或者bzip2的压缩格式呢？为什么每个reduce端压缩后的数据不要超过一个block的大小呢？】

这个问题可以结合前边老师提出的为什么MR的执行性能不理想来考虑？

当时这个问题的答案是因为每次都要落地到磁盘，

   1、Map压缩主要是增加mr运行的效率，我们就需要找压缩效率最高的压缩格式，snappy的压缩时间最快

    2、Reduce压缩就是输出文件压缩 ，故考虑占用磁盘空间的大小；选择高压缩比gzip或者bzip2；而考虑到会用reduce结果做二次运算；

          则对于选用不支持分割gzip或者bzip2原因有两个：

        （1）是这两个压缩格式高

        （2）对于不可分割我们采用每个reduce端压缩后的数据不要超过一个block的大小的方法；则对于后续的map清洗也就不会出现分割问题。

【压缩在hadoop中的应用】

 

参考博客：https://www.cnblogs.com/xuziyu/p/10678135.html

                  https://my.oschina.net/u/4005872/blog/3030869