上一篇文章聊了聊基于PAX的混合存储结构的RCFile,其实这里笔者还了解一些八卦,RCfile的主力团队都是来自中科院的童鞋在Facebook完成的,算是一个由华人主导的编码项目。但是RCfile仍然存在一些缺陷,后续被HortonWorks盯上之后上马了ORCFile格式,而老对头Cloudera则紧抱Google大腿推出了Parquet格式。 其实二者需要解决的问题是殊途同归的,但是不同的爹似乎导致了不太相同的命运。这篇文章,我们主要还是聊聊两者的技术细节,再穿插一些开源圈的商业八卦~~~
1.ORCFile
Facebook在 2011年的 ICDE 会议之上发布了RCFile。之后RCFile在Hive之中作为很好的列存储模型被广泛使用,虽然RCFile能够很好的提升Hive的工作性能,但是在Facebook论文之中也提出了一些RCFile值得改进的地方。所以在2013年,HortonWorks就在RCFile的基础之上开发出了ORCFile,并且ORCFlie很顺利地在2015年成为Apache的顶级项目。接下来我们来看一看ORCFile相对于原本的RCFile解决了什么样的问题:
- 列数据的类型感知:与RCFile之前对于列数据都统一为Blob数据不同,ORCFile可以感知列的数据类型,做出更为合理的数据压缩选择。显然,这样可以节省不少存储资源。(Facebook论文之中已经提到这个思路了,但是发布论文的时候还没有实现,属于一个next to do的工作)
- 嵌套数据类型支持:ORCFile可以在列数据之中插入Struct,Union,List,Map等数据,让数据的操作更加灵活,也更加适合非结构化数据的存储与处理。
- 谓词下推:这个算是RCFile原先功能的补强,在元数据层面增加了很多内容,来利用谓词下推加速处理的过程。ORCFile自己称之为轻量级索引,其实就是一些相较于RCFile更为详细的统计数据。
存储结构
首先,我们先来看看ORCFile的存储结构。如下图所示,ORCFile完全抛弃了原有RCFile之中所谓Row Group的概念。引入了三个新的组件,我们分别来看看对应组件的内容:
- (1) stripe:stripe是ORC文件的主体,还记的上文提到RCfile之中的Row Group的大小为4MB,而stripe的大小膨胀到了250MB。(果真还是越大越好么~~)至于为什么选择250MB这个大小的用意也很明显,是为了与底层HDFS的块大小契合,来减少MapReduce处理时可能会带来的通信损耗。 stripe也分为具体三个部分:
- Index Data:存储每行的统计数据,默认是10000行的大小。Index Data在Strip的最前面,因它们只在使用谓词向下推或读者寻找特定行时加载。(这里主要利用的是统计信息与布隆过滤器实现的)
- Row Data:实际存储数据的单元,利用列存原理,对不同列可以实现不同压缩方案,所有的列数据可以组成行数据。
- Stripe Footer:存储了每个列的编码与位置。
- (2) File Footer:部分包含Row data的布局、类型信息、行数和每个列的统计信息。通过这块可以筛选出需要读取列的数据。至于类型消息,假如有如下的表定义:
create table Foobar ( myInt int, myMap map<string, struct<myString : string, myDouble: double>>, myTime timestamp );
则定义的类型是如同下图的嵌套模式:
- (3) PostScript:这块保存的内容就是ORCFile的元数据了,包括了使用的压缩类型,各个数据的长度等。由于HDFS只支持Append的操作,所以,元数据放在文件的末尾是便于修改的。
上述就是ORCFile核心的存储结构了。对比原先的RCFile,ORCFile没有标新立异的之处,只是补足了数据压缩与数据处理的短板。
2.Parquet
Google同样在 2010年发布了最新交互处理的数据系统Dremel,并且在Dremel之上构建了一个与Protocol Buffer兼容的数据模型。基本上Google推出啥,开源圈一定会照猫画虎的弄一个出来。于是同样在2013年,Cloudera与Twitter针对Dremel的数据模型为模板,推出了Parquet,Parquet同样在2015年顺利“毕业”,成为Apache的顶级项目。
其实Parquet与ORCFile像是孪生兄弟,许多设计的思路与细节是相同的,都是列存储,数据压缩那一套。所以这里笔者不展开来讲Parquet的技术细节了,而是结合Google的论文,来看一看Parquet与ORCFile最大的区别:数据模型。
数据模型
为了兼容Protocol Buffer的嵌套结构,Google的工程师设计了很精巧的模型来将Protocol Buffer的结构落地到实际的存储结构之中。坦白说,这或许是Google内部为了兼容Protocol Buffer而实现的一个很trade off的设计,所以看起来有点奇怪:
如上图所示,通过Protocol Buffer定义了一个组合类型Document,其中required字段是必须填写的,optional字段是可以省略的,而repeated字段是可以重复的字段。其中I1与I2为示例数据。如何将上述的数据模型转换为列存呢?我们接着往下看:
首先,将上述结构之中每一个字段拆分出来,就可以变为列存储的模式了。但是接下来的问题在于如何处理非结构化数据之中repeated与optional字段。这里是通过Repetition Level与Definition Level才能来完整的还原数据的结构。
- Repetition Level:顾名思义,记录了该列的值是在哪一个级别的字段上重复的。
- Definition Level:对于非NULL值并没有什么意义,因为非NULL值Definition Level一定是相同的。(显然是可以压缩存储)记录了该列的值是在哪一个级别上开始作为NULL值存储的。
通过上述的两个值,便可以通过有限状态机来还原Protocol Buffer格式所定义的数据结构,落地到实际的存储之中。(这里涉及到列存储的跳转,详细的内容可以参考Dremel论文的原文)
上述Parquet的核心就在于:通过嵌套的数据模型设计来规避Join操作和扫描最少的列存储。下图是Parquet的数据模型,可以看出除了列存的模式之外,其余与ORCFile大同小异,笔者在这里就不进赘述了:
3.ORCfile与Parquet的比较
目前两者都作为Apache的顶级项目来进行维护,但是无论是设计的思路还是合理性都是ORCFile更为优秀。简单来说,对于OLAP的应用,本身就是需要通过ETL的流程进行数据的格式复写,对于Protocol Buffer的兼容的必要性这块,笔者是存疑的。
但是或许是因为背后所主导的力量不同,毕竟是出身名门,在各个存储系统的支持上,和实际的运用之中,Parquet还是占了很大的优势。纵观It产业的历史发展,从来都不是因为技术优势而能够赢得赛跑的。从ORCFile与Parquet目前在开源上的不同境遇来看,也符合两家公司的在资本市场上的表现吧。
但是无论商业竞逐上的胜利与失败,能够开源好的技术来便利开发者与使用者,应该都是一件功德无量的事情。
原文地址:https://www.cnblogs.com/happenlee/p/9087273.html