大数据小视角2：ORCFile与Parquet，开源圈背后的生意

2018-05-25 本文已影响190人 LeeHappen

上一篇文章聊了聊基于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的概念。引入了三个新的组件，我们分别来看看对应组件的内容：

ORCFile的存储结构

(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
);

则定义的类型是如同下图的嵌套模式：

ORCFile的类型

(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的数据格式

如上图所示，通过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大同小异，笔者在这里就不进赘述了：

Parquet的数据结构

3.ORCfile与Parquet的比较

目前两者都作为Apache的顶级项目来进行维护，但是无论是设计的思路还是合理性都是ORCFile更为优秀。简单来说，对于OLAP的应用，本身就是需要通过ETL的流程进行数据的格式复写，对于Protocol Buffer的兼容的必要性这块，笔者是存疑的。

但是或许是因为背后所主导的力量不同，毕竟是出身名门，在各个存储系统的支持上，和实际的运用之中，Parquet还是占了很大的优势。纵观It产业的历史发展，从来都不是因为技术优势而能够赢得赛跑的。从ORCFile与Parquet目前在开源上的不同境遇来看，也符合两家公司的在资本市场上的表现吧。

Hortonworks市值为13.63亿美元

Cloudera市值为20.49亿美元

但是无论商业竞逐上的胜利与失败，能够开源好的技术来便利开发者与使用者，应该都是一件功德无量的事情。