上一篇文章聊了聊基于PAX的混合存儲結(jié)構(gòu)的RCFile，其實這里筆者還了解一些八卦，RCfile的主力團隊都是來自中科院的童鞋在Facebook完成的，算是一個由華人主導的編碼項目。但是RCfile仍然存在一些缺陷，后續(xù)被HortonWorks盯上之后上馬了ORCFile格式，而老對頭Cloudera則緊抱Google大腿推出了Parquet格式。 其實二者需要解決的問題是殊途同歸的，但是不同的爹似乎導致了不太相同的命運。這篇文章，我們主要還是聊聊兩者的技術細節(jié)，再穿插一些開源圈的商業(yè)八卦~~~
Facebook在 2011年的 ICDE 會議之上發(fā)布了RCFile。之后RCFile在Hive之中作為很好的列存儲模型被廣泛使用，雖然RCFile能夠很好的提升Hive的工作性能，但是在Facebook論文之中也提出了一些RCFile值得改進的地方。所以在2013年，HortonWorks就在RCFile的基礎之上開發(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ù)。
首先，我們先來看看ORCFile的存儲結(jié)構(gòu)。如下圖所示，ORCFile完全拋棄了原有RCFile之中所謂Row Group的概念。引入了三個新的組件，我們分別來看看對應組件的內(nèi)容：
(1) stripe：stripe是ORC文件的主體，還記的上文提到RCfile之中的Row Group的大小為4MB，而stripe的大小膨脹到了250MB。（果真還是越大越好么~~）至于為什么選擇250MB這個大小的用意也很明顯，是為了與底層HDFS的塊大小契合，來減少MapReduce處理時可能會帶來的通信損耗。 stripe也分為具體三個部分：
(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核心的存儲結(jié)構(gòu)了。對比原先的RCFile，ORCFile沒有標新立異的之處，只是補足了數(shù)據(jù)壓縮與數(shù)據(jù)處理的短板。
Google同樣在 2010年發(fā)布了最新交互處理的數(shù)據(jù)系統(tǒng)Dremel，并且在Dremel之上構(gòu)建了一個與Protocol Buffer兼容的數(shù)據(jù)模型?；旧螱oogle推出啥，開源圈一定會照貓畫虎的弄一個出來。于是同樣在2013年，Cloudera與Twitter針對Dremel的數(shù)據(jù)模型為模板，推出了Parquet，Parquet同樣在2015年順利“畢業(yè)”，成為Apache的頂級項目。
其實Parquet與ORCFile像是孿生兄弟，許多設計的思路與細節(jié)是相同的，都是列存儲，數(shù)據(jù)壓縮那一套。所以這里筆者不展開來講Parquet的技術細節(jié)了，而是結(jié)合Google的論文，來看一看Parquet與ORCFile最大的區(qū)別：數(shù)據(jù)模型。
為了兼容Protocol Buffer的嵌套結(jié)構(gòu)，Google的工程師設計了很精巧的模型來將Protocol Buffer的結(jié)構(gòu)落地到實際的存儲結(jié)構(gòu)之中。坦白說，這或許是Google內(nèi)部為了兼容Protocol Buffer而實現(xiàn)的一個很trade off的設計，所以看起來有點奇怪：
如上圖所示，通過Protocol Buffer定義了一個組合類型Document，其中required字段是必須填寫的，optional字段是可以省略的，而repeated字段是可以重復的字段。其中I1與I2為示例數(shù)據(jù)。如何將上述的數(shù)據(jù)模型轉(zhuǎn)換為列存呢？我們接著往下看：
首先，將上述結(jié)構(gòu)之中每一個字段拆分出來，就可以變?yōu)榱写鎯Φ哪Ｊ搅恕５墙酉聛淼膯栴}在于如何處理非結(jié)構(gòu)化數(shù)據(jù)之中repeated與optional字段。這里是通過Repetition Level與Definition Level才能來完整的還原數(shù)據(jù)的結(jié)構(gòu)。
通過上述的兩個值，便可以通過有限狀態(tài)機來還原Protocol Buffer格式所定義的數(shù)據(jù)結(jié)構(gòu)，落地到實際的存儲之中。（這里涉及到列存儲的跳轉(zhuǎn)，詳細的內(nèi)容可以參考Dremel論文的原文）
上述Parquet的核心就在于：通過嵌套的數(shù)據(jù)模型設計來規(guī)避Join操作和掃描最少的列存儲。下圖是Parquet的數(shù)據(jù)模型，可以看出除了列存的模式之外，其余與ORCFile大同小異，筆者在這里就不進贅述了：
目前兩者都作為Apache的頂級項目來進行維護，但是無論是設計的思路還是合理性都是ORCFile更為優(yōu)秀。簡單來說，對于OLAP的應用，本身就是需要通過ETL的流程進行數(shù)據(jù)的格式復寫，對于Protocol Buffer的兼容的必要性這塊，筆者是存疑的。
但是或許是因為背后所主導的力量不同，畢竟是出身名門，在各個存儲系統(tǒng)的支持上，和實際的運用之中，Parquet還是占了很大的優(yōu)勢。縱觀It產(chǎn)業(yè)的歷史發(fā)展，從來都不是因為技術優(yōu)勢而能夠贏得賽跑的。從ORCFile與Parquet目前在開源上的不同境遇來看，也符合兩家公司的在資本市場上的表現(xiàn)吧。
但是無論商業(yè)競逐上的勝利與失敗，能夠開源好的技術來便利開發(fā)者與使用者，應該都是一件功德無量的事情。
