关键词: 文件格式 压缩效率 文件可分片
需要考虑的因素
文件格式对存储空间利用率, 程序性能都有很大的影响. 具体表现在:
- 文件和压缩算法的组合是否支持可分片, MapReduce在读取数据的时候需要并行, 这就要求压缩后的文件可以分片读取.
在考虑如何压缩那些将由MapReduce处理的数据时，考虑压缩格式是否支持分割是很重要的。考虑存储在HDFS中的未压缩的文件，其大小为1GB，HDFS的块大小为64MB，所以该文件将被存储为16块，将此文件用作输入的MapReduce作业会创建1个输人分片（split，也称为“分块”。对于block，我们统一称为“块”。）每个分片都被作为一个独立map任务的输入单独进行处理。
- io读取性能, 读取相同信息量的信息, 压缩后的文件不仅占用的存储空间低, 而且还会提高磁盘io的读取效率. 提高程序的运行速度
- CPU资源也是启用何种压缩算法不得不考虑的因素, 一般来说压缩效率越高的算法对io效率和存储利用率的提升越有促进作用, 但另一方面也会更高的消耗CPU资源. 所以我们需要在这中间寻求一个平衡点.
- 共通性, 文件格式是否支持多种语言, 服务的读取. 比如Hadoop主要的序列化格式为Writables, 但是Writables只支持Java, 所以后面衍生出了Avro, Thrift等格式. 还如OrcFile是对Hive设计的一种列式存储格式, 但是他不支持Impala, 数据的共用性受到了制约.
- 错误处理能力, 有的文件的某一部分坏掉之后会影响整个表, 有的只会影响其后的数据, 有的只会影响坏掉数据块本身(Avro).
- 读取和载入效率, RCFile的载入速度慢, 但是查询相应速度快, 相对更适合数据仓库一次插入多次读取的特性.
文件格式
hadoop存储上没有既定的标准文件格式和压缩算法, 它和标准文件系统相同, 可以存储各种各样类型的文件, 也支持多种压缩算法. 使用什么格式和压缩算法的主动权在使用者手里. 我们可以根据具体需求来权衡使用哪种组合.
标准文件格式
标准文件格式可以分为文本文件(如 CSV, XML, JSON 等)和二进制文件(图像, 视频等).
文本数据格式
txt, csv等纯文本格式是很常见的, 比如日志的存储和分析. 一般来说, 在大多数场景中, 使用容器格式(如SequenceFile, Avro)都会带来很多好处. 后面会介绍容器格式. 文本数据有一些不可避免的缺点:
- 存储空间利用率低
- 会有额外的序列化反序列化开销: 比如1234存储在文件中是字符串的形式, 转入程序中又是数字型的话读取和写入都会有额外的不必要的性能开销, 数量大的话性能影响就会更加显著.
结构化文本格式
我们常见的json, xml格式就属于此类, 他们很难分片, 且没有hadoop内置提供的InputFormat. 使用他们的时候, 一般用第三方的提供的InputFormat, 或者是将数据转化成Avro格式的数据再进行处理.
二进制数据
虽然Hadoop中存储的大多都是文本, 但是我们也可以存储图像等二进制文件. 对于大多数应用场景来说使用SequenceFile等容器格式都是很适用的.
Hadoop文件类型
为了配合MapReduce, 开发一些专门格式. 基于文件的SequenceFile, 序列化的Avro和列式存储的RCFile和Parquet. 上面的这些虽然各有不同, 但是有些重要的特性是共有的, 这对MapReduce任务来说至关重要. 这些文件都支持通用的压缩算法, 也支持分片.
基于文件的SequenceFile
以二进制键值对的形式存储数据, 支持三种记录存储方式.
- 无压缩, io效率较差. 相比压缩, 不压缩的情况下没有什么优势.
- 记录级压缩, 对每条记录都压缩. 这种压缩效率比较一般.
- 块级压缩, 这里的块不同于hdfs中的块的概念. 这种方式会将达到指定块大小的二进制数据压缩为一个块. 相对记录级压缩, 块级压缩拥有更高的压缩效率. 一般来说使用SequenceFile都会使用块级压缩.
但是SequenceFile只支持Java, SequenceFile一般用来作为小文件的容器使用, 防止小文件占用过多的NameNode内存空间来存储其在DataNode位置的元数据.
序列化存储格式
序列化指的是数据格式转化为字节流的过程, 主要用于远程传输或存储. hadoop采用的序列化格式主要是Writables. 但是它只能支持Java语言, 所以后来就出现了Thrift, Avro等格式.
Thrift
Facebook开发的框架, 用于实现跨语言提供服务和接口, 满足跨平台通信. 但是Thrift不支持分片, 且缺少MapReduce的原生支持.
Avro
Avro是一个语言无关的数据序列化的系统, 它的出现主要是为了解决Writables缺少跨语言移植的缺陷. Avro将模式存储在文件头中, 所以每个文件都是自描述的, 而且Avro还支持模式演进(schema evolution), 也就是说, 读取文件的模式不需要与写入文件的模式严格匹配, 当有新需求时, 可以在模式中加入新的字段.
- Avro支持分片, 即使是进行Gzip压缩之后.
- 支持跨语言的支持
列级存储
ORCFile
ORCFile 可以理解为 Optimized RCFile, 就是RCFile的优化版. 尤其是弥补了查询和存储效率方面的缺陷. 它同样不喜欢小文件. 特性如下:
- 支持所有的hive类型, 包括复合类型: structs, lists, maps 和 unions.
- 支持分片
- 可以仅返回查询的列, 减少io消耗, 提升性能.
- 可以与Zlib, LZO和Snappy结合进一步压缩.
- 不支持其他的查询引擎, 比如impala.
- 内件索引: 其存储了
压缩
Snappy
Google开发的一种压缩编解码器, 用于实现高速压缩, 适当兼顾压缩率, 平衡了压缩速率和文件大小. 但是有一点, Snappy是不支持分片的, 所以它需要和容器格式相互联合使用(如SequenceFile和Avro).
LZO
压缩率和速度与Snappy相近, 由于许可协议的原因, LZO不能打包进hadoop中进行分发, 需要单独安装. Snappy可以与Hadoop打包分发. 它可以支持分割, 但是要求建立索引.
Gzip
压缩速率非常好, 平均可以达到Snappy的2.5倍. 但是相应的, 写入相对较Snappy慢了一倍. Gzip同样也是不支持分片的, 所以应该与容器格式联合使用. Gzip更适合将数据进行归档.
bzip2
压缩性能比Gzip还要高9%, 但是要消耗更多的读取, 写入性能. 一般来说bzip2要比Gzip慢十倍. 所以bzip2应该不是hadoop集群上理想的编解码格式, 除非需求以为了减少空间占用为主. 比如将数据进行归档, 但是使用的时候也要考虑资源的消耗. 另外的, bzip2是支持数据分割的.
几种压缩算法的简单对比
| 压缩方式 | 压缩效率 | 压缩速度 | 是否可分割 |
|---|---|---|---|
| Gzip | 中高 | 中 | 否 |
| bzip2 | 高 | 慢 | 是 |
| Snappy | 低 | 快 | 否 |
| LZO | 低 | 快 | 是(但是要求建立索引) |
| Zlib | 低 | 快 | 是 |
Hive数据格式和压缩
textfile, sequencefile, rcfile, orc
Snappy与Zlib的对比
Disk Usage Comparison:
Hive列式存储ORC和行式存储Text
如果经常会对存储的数据进行少量列的聚合查询, 那么使用列式存储会降低在查询时所需的磁盘空间, 减少I/O消耗, 更快的得到查询结果. 这篇文章里面测试的是列式存储格式ORC相对行式存储Text, 在大量列中查询聚合少量列的情况下的性能提升情况.
- 原始测试数据为2200万条页面点击记录.
- 每行有40列
- 数据文件没有压缩
-
使用ORC格式时, 减少了52%的空间.
image.png -
减少了97%的I/O消耗
image.png
image.png -
提升了21%的查询时间
image.png -
聚合结果如下:
image.png - 相对基于Text文件的大量文件的聚合查询, 使用ORC文件格式并不总是总是显著的减少内存和CPU的消耗. 事实上, 使用ORC文件可能会引起更多的内存占用, 你可以通过使用压缩(例如Zlib或Snappy)来优化, 然而, 压缩和解压缩会增加CPU的使用时间.
配置
#影响非托管表的建表语句:
hive.default.fileformat=[textfile, sequencefile, rcfile, orc]
#影响托管表的建表语句, 如果不填则继承hive.default.fileformat的值.
hive.default.fileformat.managed=[textfile, sequencefile, rcfile, orc]
以ORC文件为例
格式可以指定到表级/分区级, 你可以通过形如下面的HiveQL语句指定ORCFile格式:
- CREATE TABLE ... STORED AS ORC
- ALTER TABLE ... [PARTITION partition_spec] SET FILEFORMAT ORC
- SET hive.default.fileformat=Orc
参考:
https://cwiki.apache.org/confluence/display/Hive/LanguageManual+ORC
《hadoop应用架构》
ORC with Zlib vs ORC with No Compression[大的数据更适合使用压缩]
Performance Comparison b/w ORC SNAPPY and ZLib in hive/ORC files
Hive & Parquet
ORC Creation Best Practices
https://orc.apache.org/docs/indexes.html
