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

1.ORCFile

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

• 列數(shù)據(jù)的類型感知：與RCFile之前對(duì)于列數(shù)據(jù)都統(tǒng)一為Blob數(shù)據(jù)不同稀轨，ORCFile可以感知列的數(shù)據(jù)類型，做出更為合理的數(shù)據(jù)壓縮選擇岸军。顯然奋刽，這樣可以節(jié)省不少存儲(chǔ)資源。（Facebook論文之中已經(jīng)提到這個(gè)思路了艰赞，但是發(fā)布論文的時(shí)候還沒(méi)有實(shí)現(xiàn)佣谐，屬于一個(gè)next to do的工作）

• 嵌套數(shù)據(jù)類型支持：ORCFile可以在列數(shù)據(jù)之中插入Struct，Union方妖，List狭魂，Map等數(shù)據(jù)，讓數(shù)據(jù)的操作更加靈活党觅，也更加適合非結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)與處理雌澄。

• 謂詞下推：這個(gè)算是RCFile原先功能的補(bǔ)強(qiáng)，在元數(shù)據(jù)層面增加了很多內(nèi)容杯瞻，來(lái)利用謂詞下推加速處理的過(guò)程镐牺。ORCFile自己稱之為輕量級(jí)索引，其實(shí)就是一些相較于RCFile更為詳細(xì)的統(tǒng)計(jì)數(shù)據(jù)魁莉。

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

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

ORCFile的存儲(chǔ)結(jié)構(gòu)

• (1) stripe：stripe是ORC文件的主體逆皮，還記的上文提到RCfile之中的Row Group的大小為4MB宅粥，而stripe的大小膨脹到了250MB。（果真還是越大越好么~~）至于為什么選擇250MB這個(gè)大小的用意也很明顯电谣，是為了與底層HDFS的塊大小契合秽梅，來(lái)減少M(fèi)apReduce處理時(shí)可能會(huì)帶來(lái)的通信損耗抹蚀。 stripe也分為具體三個(gè)部分：

  • Index Data：存儲(chǔ)每行的統(tǒng)計(jì)數(shù)據(jù)，默認(rèn)是10000行的大小企垦。Index Data在Strip的最前面环壤，因它們只在使用謂詞向下推或讀者尋找特定行時(shí)加載。（這里主要利用的是統(tǒng)計(jì)信息與布隆過(guò)濾器實(shí)現(xiàn)的）
  • Row Data：實(shí)際存儲(chǔ)數(shù)據(jù)的單元钞诡，利用列存原理郑现，對(duì)不同列可以實(shí)現(xiàn)不同壓縮方案，所有的列數(shù)據(jù)可以組成行數(shù)據(jù)荧降。
  • Stripe Footer：存儲(chǔ)了每個(gè)列的編碼與位置接箫。

• (2) File Footer：部分包含Row data的布局、類型信息朵诫、行數(shù)和每個(gè)列的統(tǒng)計(jì)信息辛友。通過(guò)這塊可以篩選出需要讀取列的數(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ù)了废累，包括了使用的壓縮類型，各個(gè)數(shù)據(jù)的長(zhǎng)度等脱盲。由于HDFS只支持Append的操作九默，所以，元數(shù)據(jù)放在文件的末尾是便于修改的宾毒。

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

2.Parquet

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

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

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

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

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

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

將嵌套字段切分之后變?yōu)榱写娴哪Ｊ?/div>

首先洲劣，將上述結(jié)構(gòu)之中每一個(gè)字段拆分出來(lái)备蚓，就可以變?yōu)榱写鎯?chǔ)的模式了。但是接下來(lái)的問(wèn)題在于如何處理非結(jié)構(gòu)化數(shù)據(jù)之中repeated與optional字段囱稽。這里是通過(guò)Repetition Level與Definition Level才能來(lái)完整的還原數(shù)據(jù)的結(jié)構(gòu)郊尝。

• Repetition Level：顧名思義，記錄了該列的值是在哪一個(gè)級(jí)別的字段上重復(fù)的战惊。
• Definition Level：對(duì)于非NULL值并沒(méi)有什么意義流昏，因?yàn)榉荖ULL值Definition Level一定是相同的。（顯然是可以壓縮存儲(chǔ)）記錄了該列的值是在哪一個(gè)級(jí)別上開(kāi)始作為NULL值存儲(chǔ)的吞获。

通過(guò)上述的兩個(gè)值况凉，便可以通過(guò)有限狀態(tài)機(jī)來(lái)還原Protocol Buffer格式所定義的數(shù)據(jù)結(jié)構(gòu)，落地到實(shí)際的存儲(chǔ)之中各拷。（這里涉及到列存儲(chǔ)的跳轉(zhuǎn)刁绒，詳細(xì)的內(nèi)容可以參考Dremel論文的原文）

上述Parquet的核心就在于：通過(guò)嵌套的數(shù)據(jù)模型設(shè)計(jì)來(lái)規(guī)避Join操作和掃描最少的列存儲(chǔ)。下圖是Parquet的數(shù)據(jù)模型烤黍，可以看出除了列存的模式之外知市，其余與ORCFile大同小異，筆者在這里就不進(jìn)贅述了：

Parquet的數(shù)據(jù)結(jié)構(gòu)

3.ORCfile與Parquet的比較

目前兩者都作為Apache的頂級(jí)項(xiàng)目來(lái)進(jìn)行維護(hù)速蕊，但是無(wú)論是設(shè)計(jì)的思路還是合理性都是ORCFile更為優(yōu)秀嫂丙。簡(jiǎn)單來(lái)說(shuō)，對(duì)于OLAP的應(yīng)用规哲，本身就是需要通過(guò)ETL的流程進(jìn)行數(shù)據(jù)的格式復(fù)寫(xiě)奢入，對(duì)于Protocol Buffer的兼容的必要性這塊，筆者是存疑的。

但是或許是因?yàn)楸澈笏鲗?dǎo)的力量不同腥光，畢竟是出身名門关顷，在各個(gè)存儲(chǔ)系統(tǒng)的支持上，和實(shí)際的運(yùn)用之中武福，Parquet還是占了很大的優(yōu)勢(shì)议双。縱觀It產(chǎn)業(yè)的歷史發(fā)展，從來(lái)都不是因?yàn)榧夹g(shù)優(yōu)勢(shì)而能夠贏得賽跑的捉片。從ORCFile與Parquet目前在開(kāi)源上的不同境遇來(lái)看平痰，也符合兩家公司的在資本市場(chǎng)上的表現(xiàn)吧。

Hortonworks市值為13.63億美元

Cloudera市值為20.49億美元

但是無(wú)論商業(yè)競(jìng)逐上的勝利與失敗伍纫，能夠開(kāi)源好的技術(shù)來(lái)便利開(kāi)發(fā)者與使用者宗雇，應(yīng)該都是一件功德無(wú)量的事情。