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