hive压缩算法对⽐
背景：
1）已经创建好了4张不同类型的表
2）清理hxh2，hxh3，hxh4表的数据，保留hxh1⾥⾯的数据，hxh1的表数据⼤⼩为：74.1GB
3）同时创建hxh5表和hxh1⼀样都是TEXTFILE存储类型
4）原始数据⼤⼩：74.1 G
开始测试：
1、TextFile测试
1. Hive数据表的默认格式，存储⽅式：⾏存储。
2. 可以使⽤Gzip压缩算法，但压缩后的⽂件不⽀持split
3. 在反序列化过程中，必须逐个字符判断是不是分隔符和⾏结束符，因此反序列化开销会⽐SequenceFile⾼⼏⼗倍。
开启压缩：
1. press.output=true; --启⽤压缩格式
2. set dec=org.apache.hadoop.iopress.GzipCodec; --指定输出的压缩格式为Gzip
3. set mapred.outputpress=true; --开启mapred输出结果进⾏压缩
4. decs=org.apache.hadoop.iopress.GzipCodec; --选⽤GZIP进⾏压缩
向hxh5表插⼊数据：
insert into table hxh5 partition(createdate="2019-07-21") select pvid,sgid,fr,ffr,mod,version,vendor from hxh1;
进⾏压缩后的hxh5表数据⼤⼩：23.8 G，消耗：81.329 seconds
2、Sequence File测试
1. 压缩数据⽂件可以节省磁盘空间，但Hadoop中有些原⽣压缩⽂件的缺点之⼀就是不⽀持分割。⽀持
gzip是什么文件夹分割的⽂件可以并⾏的有多个
mapper程序处理⼤数据⽂件，⼤多数⽂件不⽀持可分割是因为这些⽂件只能从头开始读。Sequence File是可分割的⽂件格式，⽀持Hadoop的block级压缩。
2. Hadoop API提供的⼀种⼆进制⽂件，以key-value的形式序列化到⽂件中。存储⽅式：⾏存储。
3. sequencefile⽀持三种压缩选择：NONE，RECORD，BLOCK。Record压缩率低，RECORD是默认选项，通常BLOCK会带来较
RECORD更好的压缩性能。
4. 优势是⽂件和hadoop api中的MapFile是相互兼容的
开启压缩：
1. press.output=true; --启⽤压缩格式
2. set dec=org.apache.hadoop.iopress.GzipCodec; --指定输出的压缩格式为Gzip
3. set pe=BLOCK; --压缩选项设置为BLOCK
4. set mapred.outputpress=true;
5. decs=org.apache.hadoop.iopress.GzipCodec;
向hxh2表中插⼊数据：
insert into table hxh2 partition(createdate="2019-07-21") select pvid,sgid,fr,ffr,mod,version,vendor from hxh1;
进⾏压缩后的hxh2表数据⼤⼩：80.8 G，消耗：186.495 seconds //未进⾏type类型设置，默认是Record
进⾏压缩后的hxh2表数据⼤⼩：25.2 G，消耗：81.67 seconds //设置type类型为BLOCK
3、RCFile测试
存储⽅式：数据按⾏分块，每块按列存储。结合了⾏存储和列存储的优点：
1. ⾸先，RCFile 保证同⼀⾏的数据位于同⼀节点，因此元组重构的开销很低
2. 其次，像列存储⼀样，RCFile 能够利⽤列维度的数据压缩，并且能跳过不必要的列读取
3. 数据追加：RCFile不⽀持任意⽅式的数据写操作，仅提供⼀种追加接⼝，这是因为底层的 HDFS当前仅仅⽀持数据追加写⽂件尾部。
4. ⾏组⼤⼩：⾏组变⼤有助于提⾼数据压缩的效率，但是可能会损害数据的读取性能，因为这样增加了Lazy 解压性能的消耗。⽽且⾏组
变⼤会占⽤更多的内存，这会影响并发执⾏的其他MR作业。考虑到存储空间和查询效率两个⽅⾯，Facebook 选择 4MB 作为默认的⾏组⼤⼩，当然也允许⽤户⾃⾏选择参数进⾏配置。
开启压缩：
1. press.output=true;
2. set dec=org.apache.hadoop.iopress.GzipCodec;
3. set mapred.outputpress=true;
4. decs=org.apache.hadoop.iopress.GzipCodec;
向hxh3表中插⼊数据：
insert into table hxh3 partition(createdate="2019-07-01") select pvid,sgid,fr,ffr,mod,version,vendor from hxh1;
进⾏压缩后的表⼤⼩：22.5 G，消耗时间：136.659 seconds
4、ORC测试
存储⽅式：数据按⾏分块，每块按照列存储。
压缩快，快速列存取。效率⽐rcfile⾼，是rcfile的改良版本。
开启压缩：
1. press.output=true;
2. set dec=org.apache.hadoop.iopress.GzipCodec;
3. set mapred.outputpress=true;
4. decs=org.apache.hadoop.iopress.GzipCodec;
向hxh4表中插⼊数据：
insert into table hxh4 partition(createdate="2019-07-01") select pvid,sgid,fr,ffr,mod,version,vendor from hxh1;
进⾏压缩后的表⼤⼩：21.9 G，消耗时间：76.602 seconds
5、什么是可分割
  在考虑如何压缩那些将由MapReduce处理的数据时，考虑压缩格式是否⽀持分割是很重要的。考虑存储在HDFS中的未压缩的⽂件，其⼤⼩为1GB，HDFS的块⼤⼩为64MB，所以该⽂件将被存储为16块，将此⽂件⽤作输⼊的MapReduce作业会创建1个输⼈分⽚（split，也称为“分块”。对于block，我们统⼀称为“块”。）每个分⽚都被作为⼀个独⽴map任务的输⼊单独进⾏处理。
  现在假设，该⽂件是⼀个gzip格式的压缩⽂件，压缩后的⼤⼩为1GB。和前⾯⼀样，HDFS将此⽂件存储为16块。然⽽，针对每⼀块创建⼀个分块是没有⽤的，因为不可能从gzip数据流中的任意点开始读取，map任务也不可能独⽴于其他分块只读取⼀个分块中的数据。gzip 格式使⽤DEFLATE来存储压缩过的数据，DEFLATE将数据作为⼀系列压缩过的块进⾏存储。问题是，每块的开始没有指定⽤户在数据流中任意点定位到下⼀个块的起始位置，⽽是其⾃⾝与数据流同步。因此，gzip不⽀持分割(块)机制。
  在这种情况下，MapReduce不分割gzip格式的⽂件，因为它知道输⼊是gzip压缩格式的(通过⽂件扩展名得知)，⽽gzip压缩机制不⽀持分割机制。因此⼀个map任务将处理16个HDFS块，且⼤都不是map的本地数据。与此同时，因为map任务少，所以作业分割的粒度不够细，从⽽导致运⾏时间变长。
6、压缩模式说明
1. 压缩模式评价
可使⽤以下三种标准对压缩⽅式进⾏评价：
1. 压缩⽐：压缩⽐越⾼，压缩后⽂件越⼩，所以压缩⽐越⾼越好。
2. 压缩时间：越快越好。
3. 已经压缩的格式⽂件是否可以再分割：可以分割的格式允许单⼀⽂件由多个Mapper程序处理，可以更好的并⾏化。
2. 压缩模式对⽐
1. BZip2有最⾼的压缩⽐但也会带来更⾼的CPU开销，Gzip较BZip2次之。如果基于磁盘利⽤率和I/O考虑，这两个压缩算法都是⽐较有
吸引⼒的算法。
2. LZO和Snappy算法有更快的解压缩速度，如果更关注压缩、解压速度，它们都是不错的选择。 LZO和Snappy在压缩数据上的速度⼤
致相当，但Snappy算法在解压速度上要较LZO更快。
3. Hadoop的会将⼤⽂件分割成HDFS block(默认64MB)⼤⼩的splits分⽚，每个分⽚对应⼀个Mapper程序。在这⼏个压缩算法中
BZip2、LZO、Snappy压缩是可分割的，Gzip则不⽀持分割。
7、常见压缩格式
压缩⽅
式
压缩后⼤⼩压缩速度是否可以分隔
GZIP中中否
BZIP2⼩慢是
LZO⼤快是
Snapp⼤快是
注：这⾥的可分隔是指：本地⽂件使⽤某种压缩算法进⾏压缩后传到hdfs上⾯，然后进⾏MapReduce计算，在mapper阶段是否⽀持对压缩后的⽂件进⾏split分隔，且分隔是否有效。
Hadoop编码/解码器⽅式，如下表所⽰
压缩格式对应的编码/解码器
DEFAULTorg.apache.hadoop.iopress.DefaultCodec
Gzip org.apache.hadoop.iopress.GzipCodec
Bzip org.apache.hadoop.iopress.BZip2Codec DEFLATEorg.apache.hadoop.iopress.DeflateCodec
Snappy org.apache.hadoop.iopress.SnappyCodec（中间输出使⽤）Lzo org.apache.hadoop.iopress.Lz4Codec（中间输出使⽤）8、对⽐结果
压缩前是74.1G，压缩后的⽂件⽬录⼤⼩
TextFileSequence FileRCFileORC
GZip23.8 G25.2 G22.5 G21.9 G
Snappy39.5 G41.3 G39.1 G21.9 G
BZIP17.9 G18.9 G18.7 G21.9 G
LZO39.9 G41.8 G40.8 G21.9 G
压缩后的⽂件名称
TextFile Sequence FileRCFile ORC
GZip*.gz000000_0000000_1000000000_0
Snappy*.snappy000000_0000000_1000000_0
BZIP*.bz2000000_0000000_1000000000_0
LZO*.lz4000000_2000000_0000000_0
导⼊数据消耗时间
TextFileSequence FileRCFileORC
GZip81.329s81.67s136.6s76.6s
Snappy226s180s79.8s75s
BZIP138.2s134s145.9s98.3s
LZO231.8234s86.1s248.1s
LZO231.8234s86.1s248.1s
查询速度
select count(1) from table_name
TextFileSequence FileRCFileORC
GZip46.2s50.4s44.3s38.3s
Snappy46.3s54.3s42.2s40.3s
BZIP114.3s110.3s40.3s38.2s
LZO60.3s52.2s42.2s50.3s
总结：
压缩⽐：BZip > Gzip > Snappy > LZO，但是对于ORC存储类型压缩⽐都是⼀样的
压缩时
间：
Gzip < BZip < Snappy < LZO，但是对应RCFile和ORC存储类型，都是Snappy压缩类型压缩的时间最短数据统计
时间：
GZip < Snappy < LZO < Bzip，但是对应RCFile和ORC存储类型，都是BZip压缩类型查询时间最短
压缩类型推荐：1）BZip和Gzip都有很好的压缩⽐但是会带来更⾼的CPU消耗，如果是基于磁盘利⽤率和I/O，可以考虑着两种压缩算法
2）LZO和Snappy算法有更快的解压缩速度，如果关注压缩和解压缩速度，他们都是不错的选择。如果hive表的存储类型RCFile和ORC的时候，Snappy和LZO拥有相当的解压缩效率，但是在压缩⽅⾯Snappy较LZO更胜⼀筹
3）Hadoop会将⼤⽂件分隔成HDFS block⼤⼩的splits分⽚，每个分⽚对应⼀个Mapper程序。在这⼏个压缩算法中Bzip2、LZO、Snappy压缩是可以分隔的，Gzip则不⽀持分隔