大數(shù)據(jù)小視角2：ORCFile與Parquet，開源圈背后的生意 RCfile的主力團隊都是來自中科院的童鞋在Facebook完成

看見就非常 2020-05-25

展開全文

上一篇文章聊了聊基于PAX的混合存儲結(jié)構(gòu)的RCFile，其實這里筆者還了解一些八卦，RCfile的主力團隊都是來自中科院的童鞋在Facebook完成的，算是一個由華人主導(dǎo)的編碼項目。但是RCfile仍然存在一些缺陷，后續(xù)被HortonWorks盯上之后上馬了ORCFile格式，而老對頭Cloudera則緊抱Google大腿推出了Parquet格式。其實二者需要解決的問題是殊途同歸的，但是不同的爹似乎導(dǎo)致了不太相同的命運。這篇文章，我們主要還是聊聊兩者的技術(shù)細節(jié)，再穿插一些開源圈的商業(yè)八卦~~~

1.ORCFile

Facebook在 2011年的 ICDE 會議之上發(fā)布了RCFile。之后RCFile在Hive之中作為很好的列存儲模型被廣泛使用，雖然RCFile能夠很好的提升Hive的工作性能，但是在Facebook論文之中也提出了一些RCFile值得改進的地方。所以在2013年，HortonWorks就在RCFile的基礎(chǔ)之上開發(fā)出了ORCFile，并且ORCFlie很順利地在2015年成為Apache的頂級項目。接下來我們來看一看ORCFile相對于原本的RCFile解決了什么樣的問題：

列數(shù)據(jù)的類型感知：與RCFile之前對于列數(shù)據(jù)都統(tǒng)一為Blob數(shù)據(jù)不同，ORCFile可以感知列的數(shù)據(jù)類型，做出更為合理的數(shù)據(jù)壓縮選擇。顯然，這樣可以節(jié)省不少存儲資源。（Facebook論文之中已經(jīng)提到這個思路了，但是發(fā)布論文的時候還沒有實現(xiàn)，屬于一個next to do的工作）
嵌套數(shù)據(jù)類型支持：ORCFile可以在列數(shù)據(jù)之中插入Struct，Union，List，Map等數(shù)據(jù)，讓數(shù)據(jù)的操作更加靈活，也更加適合非結(jié)構(gòu)化數(shù)據(jù)的存儲與處理。
謂詞下推：這個算是RCFile原先功能的補強，在元數(shù)據(jù)層面增加了很多內(nèi)容，來利用謂詞下推加速處理的過程。ORCFile自己稱之為輕量級索引，其實就是一些相較于RCFile更為詳細的統(tǒng)計數(shù)據(jù)。

存儲結(jié)構(gòu)

首先，我們先來看看ORCFile的存儲結(jié)構(gòu)。如下圖所示，ORCFile完全拋棄了原有RCFile之中所謂Row Group的概念。引入了三個新的組件，我們分別來看看對應(yīng)組件的內(nèi)容：

(1) stripe：stripe是ORC文件的主體，還記的上文提到RCfile之中的Row Group的大小為4MB，而stripe的大小膨脹到了250MB。（果真還是越大越好么~~）至于為什么選擇250MB這個大小的用意也很明顯，是為了與底層HDFS的塊大小契合，來減少MapReduce處理時可能會帶來的通信損耗。 stripe也分為具體三個部分：
- Index Data：存儲每行的統(tǒng)計數(shù)據(jù)，默認(rèn)是10000行的大小。Index Data在Strip的最前面，因它們只在使用謂詞向下推或讀者尋找特定行時加載。（這里主要利用的是統(tǒng)計信息與布隆過濾器實現(xiàn)的）
- Row Data：實際存儲數(shù)據(jù)的單元，利用列存原理，對不同列可以實現(xiàn)不同壓縮方案，所有的列數(shù)據(jù)可以組成行數(shù)據(jù)。
- Stripe Footer：存儲了每個列的編碼與位置。
(2) File Footer：部分包含Row data的布局、類型信息、行數(shù)和每個列的統(tǒng)計信息。通過這塊可以篩選出需要讀取列的數(shù)據(jù)。至于類型消息，假如有如下的表定義：

  create table Foobar (
    myInt int,
     myMap map<string,
     struct<myString : string,
     myDouble: double>>,
     myTime timestamp
);

則定義的類型是如同下圖的嵌套模式：
ORCFile的類型

(3) PostScript：這塊保存的內(nèi)容就是ORCFile的元數(shù)據(jù)了，包括了使用的壓縮類型，各個數(shù)據(jù)的長度等。由于HDFS只支持Append的操作，所以，元數(shù)據(jù)放在文件的末尾是便于修改的。

上述就是ORCFile核心的存儲結(jié)構(gòu)了。對比原先的RCFile，ORCFile沒有標(biāo)新立異的之處，只是補足了數(shù)據(jù)壓縮與數(shù)據(jù)處理的短板。

2.Parquet

Google同樣在 2010年發(fā)布了最新交互處理的數(shù)據(jù)系統(tǒng)Dremel，并且在Dremel之上構(gòu)建了一個與Protocol Buffer兼容的數(shù)據(jù)模型。基本上Google推出啥，開源圈一定會照貓畫虎的弄一個出來。于是同樣在2013年，Cloudera與Twitter針對Dremel的數(shù)據(jù)模型為模板，推出了Parquet，Parquet同樣在2015年順利“畢業(yè)”，成為Apache的頂級項目。

其實Parquet與ORCFile像是孿生兄弟，許多設(shè)計的思路與細節(jié)是相同的，都是列存儲，數(shù)據(jù)壓縮那一套。所以這里筆者不展開來講Parquet的技術(shù)細節(jié)了，而是結(jié)合Google的論文，來看一看Parquet與ORCFile最大的區(qū)別：數(shù)據(jù)模型。

數(shù)據(jù)模型

為了兼容Protocol Buffer的嵌套結(jié)構(gòu)，Google的工程師設(shè)計了很精巧的模型來將Protocol Buffer的結(jié)構(gòu)落地到實際的存儲結(jié)構(gòu)之中。坦白說，這或許是Google內(nèi)部為了兼容Protocol Buffer而實現(xiàn)的一個很trade off的設(shè)計，所以看起來有點奇怪：

Protocol Buffer的數(shù)據(jù)格式

如上圖所示，通過Protocol Buffer定義了一個組合類型Document，其中required字段是必須填寫的，optional字段是可以省略的，而repeated字段是可以重復(fù)的字段。其中I1與I2為示例數(shù)據(jù)。如何將上述的數(shù)據(jù)模型轉(zhuǎn)換為列存呢？我們接著往下看：

3.ORCfile與Parquet的比較

目前兩者都作為Apache的頂級項目來進行維護，但是無論是設(shè)計的思路還是合理性都是ORCFile更為優(yōu)秀。簡單來說，對于OLAP的應(yīng)用，本身就是需要通過ETL的流程進行數(shù)據(jù)的格式復(fù)寫，對于Protocol Buffer的兼容的必要性這塊，筆者是存疑的。

但是或許是因為背后所主導(dǎo)的力量不同，畢竟是出身名門，在各個存儲系統(tǒng)的支持上，和實際的運用之中，Parquet還是占了很大的優(yōu)勢。縱觀It產(chǎn)業(yè)的歷史發(fā)展，從來都不是因為技術(shù)優(yōu)勢而能夠贏得賽跑的。從ORCFile與Parquet目前在開源上的不同境遇來看，也符合兩家公司的在資本市場上的表現(xiàn)吧。

Hortonworks市值為13.63億美元