ORC(The Optimized Row Columnar),被设计用来给hive提供更高效的数据存储格式。和其它数据格式相比(parquest、text、rc),orc在读、写、处理数据上有着更优的表现。
ORC是一种文件结构,排列组织存储数据的一种结构,而非一种数据压缩格式,就像hbase索引数据用B+树形式来存储数据。
orc是列式存储结构,(关系型数据库大多用的是行式存储),由于列式数据数据库在扫描数据时候是按照一列一列来进行扫描的,所以在有大量数据而且有很多行的情况下,列式数据有着更好的扫描效率。列式存储也可以根据各行的数据类型进行特定的数据压缩格式。
1.文件结构
如上图所示,是一个orc文件的基本结构。
- stripe:一个stripe由index data、row data、stripe data三个组成。
orc文件里面的一个stripe包含了数行的数据。
stripe大小默认是250M。stripe越大,读写的效率越高。 - file footer:包含了orc文件的一些辅助信息。如每一个stripe有多少行,每一列数据的类型。而且还存了列级别的聚合运算结果(count、min、max、sum),所以orc文件在一定情况下做这些运算的时候并没有计算,而是从file footer里面直接读。
- postscript:包含了orc文件压缩的一些参数。
- stripe footer:stripe的一些元信息。
- row data:存数据的部分。
- index data:包含了每一列的最大值、最小值以及位置信息。index data是用来在查询数据时检测要查询的对象在不在当前stripe以便跳过。
值得注意的是:一个orc文件是一个独立完整不能被分割的文件,举个例子和textfile相比,假如有一个1280M的textfile被分为10个block,任何一个被分割的block都是一个纯文本都可以被直接读写。而一个1280M的orc文件,只能被一个map读写。
2.创建orc结构表
CREATE TABLE ... STORED AS ORC
ALTER TABLE ... [PARTITION partition_spec] SET FILEFORMAT ORC
key | Default | notes |
orc.compress | ZLIB | orc压缩格式(zlib、snappy) |
orc.compress.size | 262,144 | number of bytes in each compression chunk |
orc.stripe.size | 67,108,864 | 每个stripe的大小 |
orc.row.index.stride | 10,000 | 每个index包含的行数量 |
orc.create.index | true | 是否开启索引 |
orc.bloom.filter.columns | “” | comma separated list of column names for which bloom filter should be created |
orc.bloom.filter.fpp 0.05 | false positive probability for bloom filter (must >0.0 and <1.0) |
在index data中,针对上表中后面两个参数中的bloom filter
在计算机科学中,我们常常会碰到时间换空间或者空间换时间的情况,即为了达到某一个方面的最优而牺牲另一个方面。Bloom Filter在时间空间这两个因素之外又引入了另一个因素:错误率。在使用Bloom Filter判断一个元素是否属于某个集合时,会有一定的错误率。也就是说,有可能把不属于这个集合的元素误认为属于这个集合(False Positive),但不会把属于这个集合的元素误认为不属于这个集合(False Negative)。在增加了错误率这个因素之后,Bloom Filter通过允许少量的错误来节省大量的存储空间。
例:
create table Addresses (
name string,
street string,
city string,
state string,
zip int
) stored as orc tblproperties ("orc.compress"="NONE");
3.应用场景
1.orc数据结构适合使用在给数据做聚合运算、表关联的一些场景。
2.在hive中对orc中的某个字段使用”=”过滤条件时,hive不会走mapreduce,而是用orc api根据上面的stripe使用api来查找。