常见压缩格式

压缩优缺点

• 优点:
  • 减少存储磁盘空间
  • 降低 IO (网络的 IO 和磁盘的IO)
  • 加快数据在磁盘和网络中的传输速度, 从而提高系统的处理速度
• 缺点:
  • 由于使用数据时, 需要先将数据解压, 加重CPU负荷

常见压缩格式

压缩格式	工具	算法	文件扩展名	是否可切分	对应的编码/解码器(org.apache.hadoop.io.compress.)
DEFAULT	无	DEFAULT	.delete	否	DefaultCodec
Gzip	gzip	DEFAULT	.gz	否	GzipCodec
bzip2	bzip2*	bzip2*	.bz2	是	BZipCodec
LZO	lzop	LZO	.lzo	是(加索引)	LzopCodec
LZ4	无	LZ4	lz4	否	Lz4Codec
Snappy	无	Snappy	.snappy	否	SnappyCodec

压缩格式	codec类	算法	扩展名	多文件	splitable	native	工具	hadoop自带
gzip	GzipCodec	deflate	.gz	否	否	是	gzip	是
bzip2	Bzip2Codec	bzip2	.bz2	是	是	否	bzip2	是
lzo	LzopCodec	lzo	.lzo	否	是	是	lzop	否
snappy	SnappyCodec	snappy	.snappy	否	否	是	无	否

• 说明

  • gzip
    • 算法 hadoop 内置支持, 使用时直接处理文本数据一样, 使用方便, 压缩比高, 缺点就是不支持split。
    • 如果压缩后文件与块大小相当，可以考虑使用gzip压缩，比如：小时原始日志压缩成gzip文件，使用方便。
  • bzip2
    • Ÿ bzip2 支持split，压缩比高，支持多文件，缺点就是慢。
  • lzo
    • 压缩/解压速度也比较快，合理的压缩率
    • 支持split(需要建索引，文件修改后需要重新建索引)
    • 支持hadoop native库，需要自己安装。
  • snappy
    • 压缩/解压速度也比较快，合理的压缩率,不支持split
    • 支持hadoop native库，需要自己安装。

• 对比

  压缩格式	优点	缺点
  gzip	压缩比在四种压缩方式中较高；hadoop本身支持，在应用中处理gzip格式的文件就和直接处理文本一样；有hadoop native库；大部分linux系统都自带gzip命令，使用方便。	不支持split
  lzo	压缩/解压速度也比较快，合理的压缩率；支持split，是hadoop中最流行的压缩格式；支持hadoop native库；需要在linux系统下自行安装lzop命令，使用方便	压缩率比gzip要低；hadoop本身不支持，需要安装；lzo虽然支持split，但需要对lzo文件建索引，否则hadoop也是会把lzo文件看成一个普通文件（为了支持split需要建索引，需要指定inputformat为lzo格式）
  snappy	压缩速度快；支持hadoop native库	不支持split；压缩比低；hadoop本身不支持，
  bzip2	支持split；具有很高的压缩率，比gzip压缩率都高；hadoop本身支持，但不支持native；在linux系统下自带bzip2命令，使用方便	支持split,压缩/解压速度慢；不支持native

压缩比

压缩格式	压缩比	压缩速率	解压速率
gzip/deflate	13.4%	21 MB/s	118 MB/s
bzip2	13.2%	2.4 MB/s	9.5 MB/s
lzo	20.5%	135 MB/s	410 MB/s
snappy	22.2%	172 MB/s	409 MB/s

• gzip在时间和空间上的取舍比较折中，bzip2压缩比gzip更有效，但是速度更慢。
• bzip2的解压速度比它的压缩速度要快。
• 但是和其他压缩格式比又是最慢的，但是压缩效果明显是最好的。
• 我咋觉得bzip很鸡肋啊, 压缩比也就比gzip低一点, 压缩速率和解压速率慢那么多, 感觉只有追求极致的磁盘空间的时候才会用吧。
• 从理上来说, 压缩比越低, 压缩速率和解压速率就越慢, 但是这个百分之0.2真的应该造成这么大的压缩解压速率差别吗? 怀疑底层算法的有效性。

Hadoop配置压缩

• core-site.xml

  
     io.compression.codecs
     
  org.apache.hadoop.io.compress.GzipCodec,
  org.apache.hadoop.io.compress.DefaultCodec,
  org.apache.hadoop.io.compress.BZip2Codec,
    
    

• mapred-site.xml

  
      mapreduce.output.fileoutputformat.compress
    true
  
  
   
    mapreduce.output.fileoutputformat.compress.codec
    org.apache.hadoop.io.compress.BZip2Codec
     
   
       mapreduce.map.output.compress
       true
  
  
     mapreduce.map.output.compress.codec 
     org.apache.hadoop.io.compress.SnappyCodec                      

场景

• 为什么map端用snappy压缩格式；而reduce用gzip或者bzip2的压缩格式呢？
  • Map压缩主要是增加MapReduce运行的效率，我们就需要找压缩效率最高的压缩格式，snappy的压缩时间最快
  • 选择高压缩比gzip或者bzip2的原因有二:
    • 这两个压缩格式高
    • 对于不可分割我们采用每个reduce端压缩后的数据不要超过一个block的大小的方法
    • 对于后续的map清洗也就不会出现分割问题。
• 为什么每个reduce端压缩后的数据不要超过一个block的大小呢？
  • Reduce压缩就是输出文件压缩 ，故考虑占用磁盘空间的大小

Splitable

• splitable表示压缩格式是否可以被分割，也就是说是否支持随即读。
• 压缩数据是否能被mapreduce使用，关键得看压缩数据是否能被分割。
• 举例一个未压缩的文件有1GB大小，hdfs默认的block大小是128MB。
• 那么这个文件就会被分为8个block作为mapreduce的输入，每一个单独使用一个map任务。
• 若该文件是已经使用gzip压缩的呢，若分成8个块，每个块做成一个输入，显然是不合适的, 因为gzip压缩流的随机读是不可能的。
• 实际上，当mapreduce处理压缩格式的文件的时候它会认识到这是一个gzip的压缩文件，而gzip又不支持随机读，它就会把8个块分给一个map去处理。
• 这里就会有很多非本地处理的map任务，整个过程耗费的时间就会相当长。
• lzo压缩格式也会是同样的问题，但是通过使用hadoop lzo库的索引工具以后，lzo就可以支持splittable。bzip2也是支持splitable的。

总结

• 每一种压缩方式都有他的优缺点，讲求压缩效率，压缩比就会低，占用的网络io和磁盘io就多
• 讲求压缩比，对cpu的损耗就比较大，同时压缩和解压的耗时就比较多
• 对于支持split的（lzo和bzip）可以实现并行处理