1.压缩的好处和坏处：
好处：
1.减少存储磁盘空间
2.降低IO(网络的IO和磁盘的IO)
3.加快数据在磁盘和网络中的传输速度，从而提高系统的处理速度
坏处：
由于使用数据时，需要先将数据解压，加重CPU负荷
当我们要使用压缩的时候，需要根据场景来判断，比如当我们的生产上的cpu利用率非常高的时候，就不合适用压缩
2.压缩格式：
| 压缩格式 | 工具 | 算法 | 扩展名 | 是否支持分割 | 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
各种压缩的压缩比：
1 | Snappy:49.9% |
3.选择压缩格式的前提：
1）压缩比 vs 压缩速度
2）是否分片
text文本：200M （自带分片功能），===》 2InputSplit 128M+72M
BZIP2：支持分片
Snappy：不支持分片 如果1T文件，这个时候不管用 mapreduce/spark 都只能有一个task，因为
Snappy不支持分片。
LZO：默认不支持分片，但是可以通过创建索引，Create Index，来支持分片。
4.压缩格式各自优缺点
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系统下没有对应的命令
应用场景：
当mapreduce作业的map输出的数据比较大的时候，作为map到reduce的中间数据的压缩格式；或者作为一个mapreduce作业的输出和另外一个mapreduce作业的输入。
d. bzip2
优点：
支持split；具有很高的压缩率，比gzip压缩率都高；hadoop本身支持，但不支持native；在linux系统下自带bzip2命令，使用方便
缺点：
压缩/解压速度慢；不支持native
总结：
不同的场景选择不同的压缩方式，肯定没有一个一劳永逸的方法，如果选择高压缩比，那么对于cpu的性能要求要高，同时压缩、解压时间耗费也多；选择压缩比低的，对于磁盘io、网络io的时间要多，空间占据要多；对于支持分割的，可以实现并行处理。
应用场景：
适合对速度要求不高，但需要较高的压缩率的时候，可以作为mapreduce作业的输出格式；或者输出之后的数据比较大，处理之后的数据
需要压缩存档减少磁盘空间并且以后数据用得比较少的情况；或者对单个很大的文本文件想压缩减少存储空间，同时又需要支持split，而且兼容之前的应用程
序（即应用程序不需要修改）的情况。
应用场景：
一般在HDFS 、Hive、HBase中会使用；
当然一般较多的是结合Spark 来一起使用。
5.压缩场景：
input： Flume Sink HDFS <== Spark/MapReduce （从Flume采集到HDFS上的过程中）
temp: Sink DISK （map和reduce的中间环节数据需要先进入到环形缓冲区，然后落盘）
output: Spark/MapReduce ==> Sink Hadoop （mapreduce输出数据）
1）执行mapreduce的过程中要用到压缩的时候
红色星星表示：压缩
蓝色星星表示：解压
分析：
1）Flume采集数据到Hadoop上时，可以采用压缩（注：必须要用用支持分片的压缩）
2）Map输出 Spill落盘的时候，需要压缩（注：必须要压缩和解压速度快的，一般map和reduce
中间选择 Snappy压缩）
3）Reduce 输出文件，需要压缩（注：这里的压缩又两种场景）
①Reduce输出的文件作为下一个Reduce输入的文件：（注：这个时候就不能用高压缩比的压缩方
式，并且压缩必须支持分片）
②Reduce输出的文件用作归档，或者不再用了（注：这个时候可以采用高压缩比的压缩方式）
6.配置压缩文件：
1 | core-site.xml 文件 |
配置完以后，做一个wordcount例子：
1 | [hadoop@hadoop001 mapreduce]$ hadoop jar hadoop-mapreduce-examples-2.6.0-cdh5.7.0.jar wordcount /date/wc/wccount.text /date/wc/output |