1.压缩格式
格式 工具 算法 扩展名 多文件 可分割性 压缩比 压缩速度 解压速度
DEFLATE 无 DEFLATE .deflate3 不 不
gzip gzip DEFLATE .gz 不 不 78% 17.5MB/2 58MB/s
zip zip DEFLATE .zip 是 是，在文件范围内
bzip2 bzip2 bzip2 .bz2 不 是 86% 2.4MB/s 9.5MB/s
lzo lzop LZO .lzo 不 是 65% 49.3MB/s 74.6MB/s
2.Hadoop输出压缩
2.1 why?
[1]输出数据较大时，使用hadoop提供的压缩机制对数据进行压缩，可以指定压缩的方式。减少网络传输带宽和存储的消耗；
[2]可以对map的输出进行压缩（map输出到reduce输入的过程，可以减少shuffle过程中网络传输的数据量）
[3]可以对reduce的输出结果进行压缩（最终保存到hdfs上的数据，主要是减少占用HDFS存储）
map 输出压缩：
hadoop:
mapred.compress.map.output=true
mapred.map.output.compression.codec= 压缩格式
hive:
hive.exec.compress.intermediate = true
mapred.map.output.compression.codec= 压缩格式{例如:org.apache.hadoop.io.compress.SnappyCodec}
reduce输出压缩：
Hadoop:
mapred.output.compress = true
mapred.ouput.compression.codec = 压缩格式
Hive:
set hive.exec.compress.output=true
set mapred.output.compression.codec = 压缩格式
压缩格式 HadoopCompressionCodec
DEFLATE org.apache.hadoop.io.compress.DefaultCodec
gzip org.apache.hadoop.io.compress.GzipCodec
bzip2 org.apache.hadoop.io.compress.BZip2Codec
LZO com.hadoop.compression.lzo.LzopCodec
LZ4 org.apache.hadoop.io.compress.Lz4Codec
Snappy org.apache.hadoop.io.compress.SnappyCodec
2.2 压缩的应用场景
输入：
在input split前进行的压缩，压缩格式要支持分割（lzo 或者bzip2{bzip2解压过程耗时，瓶颈在CPU，因此lzo更好一些}）
如果不支持文件分割，则2G大小的解压缩文件会交由一个map任务处理，影响任务执行效率
如果支持分割，则改文件会被分割成16个128MB的分片，每个分片有一个map任务处理
中间：
map输出进行压缩，压缩和解压缩要尽可能地快(snappy/lz4/lzo)
输出：
reduce输出进行压缩
如果reduce输出为最终输出，选用高压缩比的压缩格式（bzip2/gzip）
如果reduce输出为非最终输出，选用支持分割的压缩格式(bzip2/lzo)
2.3 对比
不仅如此，由于 mapreduce作业通常瓶颈都在IO上，存储压缩数据就意味这更少的IO操作，job运行更加的高效。但是，在hadoop上使用压缩也有两个比较麻 烦的地方：第一，有些压缩格式不能被分块，并行的处理，比如gzip。第二，另外的一些压缩格式虽然支持分块处理，但是解压的过程非常的缓慢，使job的 瓶颈转移到了cpu上，例如bzip2。比如我们有一个1.1GB的gzip文件，该文 件 被分成128MB/chunk存储在hdfs上，那么它就会被分成9块。为了能够在mapreduce中并行的处理 各个chunk，那么各个mapper之间就有了依赖。而第二个mapper就会在文件的某个随机的byte出进行处理。那么gzip解压时要用到的上下 文字典就会为空，这就意味这gzip的压缩文件无法在hadoop上进行正确的并行处理。也就因此在hadoop上大的gzip压缩文件只能被一个 mapper来单个的处理，这样就很不高效，跟不用mapreduce没有什么区别了。而另一种bzip2压缩格式，虽然bzip2的压缩非常的快，并且 甚至可以被分块，但是其解压过程非常非常的缓慢，并且不能被用streaming来读取，这样也无法在hadoop中高效的使用这种压缩。即使使用，由于 其解压的低效，也会使得job的瓶颈转移到cpu上去。
lzo文件可以根据block boundaries来进行分块，比如一个1.1G的lzo压缩文件，那么处理第二个128MB block的mapper就必须能够确认下一个block的boundary，以便进行解压操作。lzo并没有写什么数据头来做到这一点，而是实现了一个 lzo index文件，将这个文件（foo.lzo.index）写在每个foo.lzo文件中。这个index文件只是简单的包含了每个block在数据中的 offset，这样由于offset已知的缘故，对数据的读写就变得非常的快。
3. hive压缩
3.1 输出进行压缩
sethive.exec.compress.output=true;
setmapred.output.compression.codec=压缩格式
#压缩格式设置
setmapred.output.compression.type=BLOCK;
#一共三种压缩方式（NONE, RECORD,BLOCK），BLOCK压缩率最高，一般用BLOCK。
Map操作之前合并小文件：
setmapred.max.split.size=2048000000
#每个Map最大输入大小设置为2GB（单位：字节）
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat
#执行Map前进行小文件合并
输出时进行合并：
set hive.merge.mapfiles = true
#在Map-only的任务结束时合并小文件
set hive.merge.mapredfiles= true
#在Map-Reduce的任务结束时合并小文件
set hive.merge.size.per.task = 1024000000
#合并后文件的大小为1GB左右
set hive.merge.smallfiles.avgsize=1024000000
#当输出文件的平均大小小于1GB时，启动一个独立的map-reduce任务进行文件merge
