数仓文件格式和压缩算法选择

百度关于ORC和Parquet文件的测试报告，可惜拿不出来，结论可以参考下，之前百度采用了Array{Map{Map}}这样的嵌套数据做的测试，400G的ORC数据文件，吃了1000G的内存，而Parquet相对好点，结论大概是ORC压缩比高，但是吃CPU和内存，适合存储空间吃紧，计算资源强大的集群，既时间换空间；Parquet适合存储空间巨大，计算资源相对紧缺的资源，适合空间换时间，但是也提醒到，不能一概而论，如果可以，最好结合自己的数据结构做一下测试，另外如果集群有打算架Impala的想法，那么就要注意了，还是Parquet文件好，因为ORC目前不支持。

Parquet和ORC对比总结

 

表1 Parquet和ORC对比总结

 

性状	Parquet	ORC
现状	Apache顶级项目	Apache顶级项目
列式存储	支持	支持
开发语言	Java	Java
嵌套结构	完美支持	支持起来比较复杂，比较耗CPU，内存等资源
ACID(事务)	不支持	支持
Update，Delete操作	不支持	支持
元数据	支持粗粒度的索引	支持粗粒度的索引
查询性能	具体要看数据文件结构分布，一般ORC略优	具体要看数据文件结构分布，一般ORC略优
压缩能力	ORC略优	ORC略优
支持的查询引擎	常见的大数据查询引擎都支持	不支持Impala

总结：注意不要被关系型数据库所迷惑ACID(事务)和Update,Delete操作在大数据里面是很鸡肋的，不要因为这个条件来决定使用ORC合适Parquet，因为1T的数据里面有几条数据去做Update和Delete吗？没必要的，事务就跟没必要了，因为事务防止的危险如脏读等场景，一般在大数据场景下不太要求，或者采用其他的架构来避免。

个人建议的文件选取

具体还是要看自己数据文件的结构，结合测试会好一点，但是如果非要我说一种搭配，可以选取Parquet文件+Snappy压缩作为热数据的存储，相对于ORC牺牲点存储空间，而且存储空间快速填充也可以成为你集群扩容的资本，毕竟如果自己搭建集群的话，内存一般比较局限，你可以评估存储不够为理由要求运维机器，从而达到扩容集群内存的目的，谈判的艺术性，一般人我不告诉他。
而冷数据，如三年前的数据，可以采取牺牲时间换取空间的方式，采用ORC文件+Gzip压缩格式,进一步archive(归档)掉，别人申请三年前的数据，需要行政上约定提前一周时间提出申请。

常见压缩格式对比及搭配建议

Hadoop支持压缩格式,可以用指令hadoop checknative来获取自己Hadoop集群默认支持的压缩格式，注意这个hadoop是自己安装的hadoop目录下/tools/hadoop/hadoop-2.8.5/bin/hadoop指令hadoop，我做了环境变量

1 2 3 4 5 6 7 8 9 10

[liuxiaowei@shucang-01 ~]$ hadoop checknative 20/05/11 18:47:44 INFO bzip2.Bzip2Factory: Successfully loaded & initialized native-bzip2 library system-native 20/05/11 18:47:44 INFO zlib.ZlibFactory: Successfully loaded & initialized native-zlib library Native library checking: hadoop:  true /tools/hadoop/hadoop-2.8.5/lib/native/libhadoop.so.1.0.0 zlib:    true /lib64/libz.so.1 snappy:  true /lib64/libsnappy.so.1 lz4:     true revision:10301 bzip2:   true /lib64/libbz2.so.1 openssl: false Cannot load libcrypto.so (libcrypto.so: cannot open shared object file: No such file or directory)!

具体对比如表2：

 

表2 Hadoop支持压缩格式

 

压缩格式	可分割	算法	扩展名	Linux工具
gzip	否	DEFLATE	.gz	gzip
lzo	是(加索引)	LZO	.lzo	lzop
snappy	否	Snappy	.snappy	无
Bzip2	是	Bzip2	.bz2	bzip2
deflate	否	DEFLATE	.deflate	无
zip	是	ZIP	.zip	zip

基于128MB文本文件的压缩性能测试横向比较，具体如表3：

 

表3 基于128MB`文本文件`的压缩性能测试横向比

 

编码器	压缩时间（秒）	解压缩时间（秒）	压缩文件大小	压缩比率
Deflate	6.88	6.80	24,866,259	18.53%
gzip	6.68	6.88	24,866,271	18.53%
bzip2	3,012.34	24.31	19,270,217	14.36%
lzo	1.69	7.00	40,946,704	30.51%
lzop	1.70	5.62	40,946,746	30.51%
Snappy	1.31	6.66	46,108,189	34.45%

• Gzip压缩:
  优点：压缩率比较高，压缩/解压速度也比较快，hadoop本身支持。
  缺点：不支持分片。
  应用场景：当每个文件压缩之后在1个block块大小内，可以考虑用gzip压缩格式,冷数据archive(归档)。

• lzo压缩
  优点：压缩/解压速度也比较快，合理的压缩率，支持分片，是Hadoop中最流行的压缩格式，支持Hadoop native库。
  缺点：压缩率比gzip要低一些，Hadoop本身不支持，需要安装，如果支持分片需要建立索引，还需要指定inputformat改为lzo格式。
  应用场景：一个很大的文本文件，压缩之后还大于200M以上的可以考虑，而且单个文件越大，lzo优点越明显。

• snappy压缩
  优点：支持Hadoop native库，高速压缩速度和合理的压缩率，hadoop-2.8.5自带；
  缺点：不支持分片，压缩率比gzip要低；
  应用场景：当MapReduce作业的map输出的数据比较大的时候，作为map到reduce的中间数据的压缩格式；Parquet文件的默认压缩方式。

• bzip2压缩
  优点：支持分片，具有很高的压缩率，比gzip压缩率都高，Hadoop本身支持，但不支持native。
  缺点：压缩/解压速度慢，不支持Hadoop native库。
  应用场景：适合对速度要求不高，但需要较高的压缩率的时候，可以作为mapreduce作业的输出格式，输出之后的数据比较大，处理之后的数据需要压缩存档减少磁盘空间并且以后数据用得比较少的情况。

总结：压缩比：bzip2 > gzip > lzo > snappy；压缩速度：snappy > lzo> gzip > bzip2。

 

 

所有压缩算法都必须在压缩程度和压缩/解压缩速度之间进行权衡。我们必须根据我们的场景选择这些编解码器，假设我们必须对很少查询的数据进行存档，然后我们必须使用像Bzip2这样的编解码器，如果我们经常需要访问我们的数据，我们可以使用像Snappy这样的算法给我们最快的数据压缩和解压缩。
个人推荐：可以选取Parquet文件+Snappy压缩作为热数据的存储，相对于ORC牺牲点存储空间，采用ORC文件+Gzip压缩格式或者ORC文件+bzip2 压缩格式,进一步archive(归档)掉，别人申请三年前的数据，需要行政上约定提前一周时间提出申请。

 

原文链接：https://www.codenong.com/cs106016092/