常见压缩格式

压缩优缺点

优点:
- 减少存储磁盘空间
- 降低 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

<property>
   <name>io.compression.codecs</name>
   <value>
org.apache.hadoop.io.compress.GzipCodec,
org.apache.hadoop.io.compress.DefaultCodec,
org.apache.hadoop.io.compress.BZip2Codec,
  </value>
</property>

mapred-site.xml

<property>
    <name>mapreduce.output.fileoutputformat.compress</name>
  <value>true</value>
</property>

<property> 
  <name>mapreduce.output.fileoutputformat.compress.codec</name>
  <value>org.apache.hadoop.io.compress.BZip2Codec</value>
</property>   
<property> 
     <name>mapreduce.map.output.compress</name>
     <value>true</value>
</property>
<property>
   <name>mapreduce.map.output.compress.codec</name> 
   <value>org.apache.hadoop.io.compress.SnappyCodec</value>                      </property>

场景

为什么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）可以实现并行处理

常见压缩格式

压缩优缺点

常见压缩格式

压缩比

Hadoop配置压缩

场景

Splitable

总结

猜你喜欢