2010年，F(xiàn)acebook 的工程師在 ICDC（IEEE International Conference on Data Engineering） 發(fā)表了一篇 《RCFile: A Fast and Space-efficient Data Placement Structure in MapReduce-based Warehouse Systems》 的論文，介紹了其為基于 MapReduce 的數(shù)據(jù)倉庫設(shè)計的高效存儲結(jié)構(gòu)，這就是我們熟知的 RCFile（Record Columnar File）。下面介紹 RCFile 的一些誕生背景和設(shè)計。
背景
早在2010年以前，F(xiàn)acebook 的數(shù)據(jù)倉庫每天有超過 20TB 的數(shù)據(jù)被推入數(shù)據(jù)倉庫（到了 2014 年 Facebook 的倉庫存儲超過 300PB 的 Hive 數(shù)據(jù)，而且每天的新增數(shù)據(jù)在 600TB 左右，那時候已經(jīng)開始用 ORCFile 了）。按照這么大的增長速度，存儲效率是 Facebook 倉庫基礎(chǔ)設(shè)施的重要考慮因素。
為了提高倉庫的存儲效率，F(xiàn)acebook 在很多方面進(jìn)行了創(chuàng)新，比如構(gòu)建冷存儲數(shù)據(jù)中心，在 HDFS 中采用 RAID 等技術(shù)來降低復(fù)制比率（同時保持高可用性），以及在數(shù)據(jù)寫入 HDFS 之前使用壓縮進(jìn)行數(shù)據(jù)壓縮。但這仍然不能滿足他們的需求，所以在這種背景下，RCFile 被開發(fā)出來以便盡可能高效地存儲 Hive 數(shù)倉里面的數(shù)據(jù)。
大數(shù)據(jù)處理系統(tǒng)的要求
基于對 Facebook 系統(tǒng)和龐大的用戶數(shù)據(jù)集的分析，F(xiàn)acebook 的工程師總結(jié)了 MapReduce 環(huán)境下數(shù)據(jù)存儲必須滿足以下四個關(guān)鍵需求。
快速的數(shù)據(jù)加載?？焖偌虞d數(shù)據(jù)對 Facebook 生產(chǎn)數(shù)據(jù)倉庫至關(guān)重要。平均每天有超過 20TB 的數(shù)據(jù)被推入 Facebook 數(shù)據(jù)倉庫。因此，減少數(shù)據(jù)加載時間是迫切需要的，因為數(shù)據(jù)加載期間的網(wǎng)絡(luò)和磁盤流量會干擾正常的查詢執(zhí)行。
快速查詢處理。為了滿足實時網(wǎng)站請求和高并發(fā)用戶提交的支持決策的查詢的高工作負(fù)載的要求，查詢的響應(yīng)時間是非常關(guān)鍵的。這要求底層數(shù)據(jù)存儲結(jié)構(gòu)在查詢量快速增加時也能夠保持高效的查詢處理。
高效利用存儲空間?？焖僭鲩L的用戶活動總是要求可伸縮的存儲能力和計算能力。有限的磁盤空間實際上需要對數(shù)據(jù)存儲進(jìn)行良好的管理，以解決有關(guān)如何在磁盤中放置數(shù)據(jù)的問題，以便最大程度地利用空間。
對經(jīng)常動態(tài)變化的工作負(fù)載模式有較強的適應(yīng)能力。 在實際業(yè)務(wù)場景中，不同的用戶針對不同的目的以多種不同的方式分析數(shù)據(jù)集。一些數(shù)據(jù)分析是在固定模式下定期執(zhí)行的例行任務(wù)，而另一些數(shù)據(jù)分析是從內(nèi)部平臺發(fā)出的即席查詢。大多數(shù)工作負(fù)載不遵循任何常規(guī)模式，這要求底層系統(tǒng)在有限的存儲空間下高度適應(yīng)數(shù)據(jù)處理中的各種查詢需求，而不是特定于某些查詢需求。
為 MapReduce 設(shè)計存儲格式
為基于 MapReduce 的數(shù)據(jù)倉庫系統(tǒng)設(shè)計和實現(xiàn)高效的數(shù)據(jù)存儲格式的一個關(guān)鍵挑戰(zhàn)是在 MapReduce 計算環(huán)境中來滿足上述四個需求。在傳統(tǒng)的數(shù)據(jù)庫系統(tǒng)中，有三種數(shù)據(jù)放置結(jié)構(gòu)得到了廣泛的研究，分別是：
水平行存儲結(jié)構(gòu)（horizontal row-store structure ）
垂直列存儲結(jié)構(gòu)（ vertical column-store structure ）
PAX 混合存儲結(jié)構(gòu)（hybrid PAX store structure）
上面的每種存儲結(jié)構(gòu)都有其優(yōu)點，但是僅將這些面向數(shù)據(jù)庫的存儲結(jié)構(gòu)移植到基于 MapReduce 的數(shù)據(jù)倉庫系統(tǒng)中并不能完全滿足所有四個需求。
簡單來說，行存儲不能支持快速查詢處理，因為當(dāng)查詢僅需要一個具有許多列的寬表中的少數(shù)列時，它不能跳過不必要的列讀取。其次，列存儲經(jīng)常會導(dǎo)致集群中產(chǎn)生比較較大的網(wǎng)絡(luò)傳輸開銷，這是因為對于列存儲，HDFS 無法保證同一記錄中的所有字段都存儲在同一群集節(jié)點中。盡管將多個列預(yù)先分組在一起可以減少開銷，但它對響應(yīng)高度動態(tài)的工作負(fù)載模式?jīng)]有很強的適應(yīng)性。第三，以優(yōu)化 CPU 緩存性能為目標(biāo)，在每個磁盤頁面內(nèi)使用列存儲的混合PAX結(jié)構(gòu)不能幫助提高用于大數(shù)據(jù)分析的I/O性能。下面我們來詳細(xì)介紹這些存儲結(jié)構(gòu)的短板。
行存儲
行存儲結(jié)構(gòu)在傳統(tǒng)的數(shù)據(jù)庫系統(tǒng)中占主導(dǎo)地位。使用這種結(jié)構(gòu)，關(guān)系記錄組織在 N 元存儲模型中。一條記錄的所有字段按照它們出現(xiàn)的順序逐個填充，記錄被連續(xù)地放置在磁盤頁面中。下圖展示了行存儲結(jié)構(gòu)如何在 HDFS 塊中存儲：
如果想及時了解Spark、Hadoop或者HBase相關(guān)的文章，歡迎關(guān)注微信公眾號：iteblog_hadoop
對于只讀數(shù)據(jù)倉庫系統(tǒng)而言，存儲以下幾個問題：
第一，如果查詢中只需要表中的列的一個子集，那么行存儲不能提供快速的查詢處理，因為會導(dǎo)致不必要的列讀??；
第二，行存儲很難實現(xiàn)高數(shù)據(jù)壓縮率。
行存儲對于基于 hadoop 系統(tǒng)的主要優(yōu)點是數(shù)據(jù)加載速度快，對動態(tài)工作負(fù)載的自適應(yīng)能力強。這是因為行存儲保證了同一記錄中的所有字段都位于同一集群節(jié)點中，因為它們位于同一 HDFS 塊中。
列存儲
垂直存儲方案是基于面向列的存儲模型，主要用于讀取優(yōu)化的數(shù)據(jù)倉庫系統(tǒng)中。在垂直存儲中，一個關(guān)系被垂直劃分為若干個子關(guān)系，垂直存儲的方案基本上有兩種：
一種方案將每一列放在一個子關(guān)系中，比如 MonetDB；這種方案稱為 column-store。
另一種方案是將關(guān)系中的所有列組織到不同的列組中，并且通常允許多個列組之間的列重疊，比如 C-store 和 Yahoo Zebra 就是這么使用的，這種方案稱為 the column-group
下圖展示了如何在 HDFS 上如何按列組（column-group）存儲的示例。在本例中，列 A 和列 B 存儲在同一個列組中，而列 C 和列 D 存儲在兩個獨立的列組中。列式存儲可以避免在查詢執(zhí)行期間讀取不必要的列，并且可以通過壓縮同一數(shù)據(jù)域中的每一列輕松實現(xiàn)高壓縮比。但是，由于元組重構(gòu)的高開銷，它不能在基于 hadoop 的系統(tǒng)中提供快速的查詢處理。這種列式存儲不能保證同一記錄中的所有字段都位于同一集群節(jié)點中。例如，本列中一條記錄的四個字段存儲在可以位于不同節(jié)點的三個 HDFS 塊中。因此，一次記錄重構(gòu)會導(dǎo)致多個集群節(jié)點之間通過網(wǎng)絡(luò)進(jìn)行大量的數(shù)據(jù)傳輸。正如在最初的 MapReduce 論文中所介紹的，MapReduce 集群中過度的網(wǎng)絡(luò)傳輸總是會成為瓶頸來源，應(yīng)該盡可能避免。
如果想及時了解Spark、Hadoop或者HBase相關(guān)的文章，歡迎關(guān)注微信公眾號：iteblog_hadoop
Hybrid Store: PAX
PAX 使用了一種混合存儲結(jié)構(gòu)，旨在提高 CPU 緩存性能。對于具有來自不同列的多個字段的記錄，PAX 不是將這些字段放在不同的磁盤頁中，而是將它們放在單個磁盤頁中，以保存用于記錄重構(gòu)的額外操作。在每個磁盤頁中，PAX 使用一個微型頁（mini-page）來存儲屬于每個列的所有字段，并使用一個頁頭來存儲指向微型頁的指針。
類似于行存儲，PAX 對多種動態(tài)查詢有很強的適應(yīng)能力。然而，它并不能滿足大型分布式系統(tǒng)對于高存儲空間利用率和快速查詢處理的需求，原因在于：
首先，PAX 沒有數(shù)據(jù)壓縮的相關(guān)工作，這部分與 Cache 優(yōu)化關(guān)系不大，但對于大規(guī)模數(shù)據(jù)處理系統(tǒng)是非常關(guān)鍵的，它提供了列維度數(shù)據(jù)壓縮的可能性；
其次，PAX 不能提升 I/O 性能，因為它不能改變實際的頁內(nèi)容，該限制使得大規(guī)模數(shù)據(jù)掃描時不易實現(xiàn)快速查詢處理；
最后，PAX 用固定的頁作為數(shù)據(jù)組織的基本單位，按照這個大小，在海量數(shù)據(jù)處理系統(tǒng)中，PAX將不會有效存儲不同大小類型的數(shù)據(jù)域。
RCFile (Record Columnar File）設(shè)計
基于上面的總結(jié)，F(xiàn)acebook 為基于 MapReduce 的數(shù)據(jù)倉庫系統(tǒng)（如Hive）設(shè)計了一種新的數(shù)據(jù)放置結(jié)構(gòu)：RCFile。RCFile 應(yīng)用了來自 PAX 的“首先水平劃分?jǐn)?shù)據(jù)，然后再垂直劃分列”的概念。它結(jié)合了行式存儲和列式存儲的優(yōu)勢。首先，RCFile 保證了同一行中的數(shù)據(jù)位于同一節(jié)點中，因此具有較低的元組重構(gòu)成本。其次，RCFile 可以利用按列的數(shù)據(jù)壓縮并跳過不必要的列讀取。
RCFile 是基于 HDFS 之上設(shè)計的，具體如下圖所示：
如果想及時了解Spark、Hadoop或者HBase相關(guān)的文章，歡迎關(guān)注微信公眾號：iteblog_hadoop RCFile 的存儲設(shè)計如下：
根據(jù) HDFS 的結(jié)構(gòu)，一張表的數(shù)據(jù)存儲在多個 HDFS 塊中；
在每個 HDFS 塊中，RCFile 用行組（row group）為基本單元來組織記錄。也就是說，存儲在 HDFS 塊中的所有記錄都被劃分為一個或多個行組。對于表來說，所有行組具有相同的大小。根據(jù)行組的大小和 HDFS 塊大小，一個 HDFS 塊中有一個或多個行組。
行組包含三個部分。
第一部分是放在行組開頭的同步標(biāo)記（sync marker）。同步標(biāo)記主要用于在 HDFS 塊中分離兩個連續(xù)的行組。
第二部分是行組的元數(shù)據(jù)。元數(shù)據(jù)存儲有關(guān)此行組中有多少條記錄、每列中有多少字節(jié)以及每列中每個字段中有多少字節(jié)的信息項。
第三部分是表數(shù)據(jù)部分，它實際上是一個列存儲。在這里，同一列中的所有字段被連續(xù)存儲在一起。正如上圖所示，該部分首先存儲列 A 中的所有字段，然后存儲列 B 中的所有字段，以此類推。
RCFile 的數(shù)據(jù)壓縮
RCFile 的每個行組中，元數(shù)據(jù)頭部和表格數(shù)據(jù)段分別進(jìn)行壓縮。
對于元數(shù)據(jù)頭部，RCFile 使用 RLE（Run Length Encoding）算法來壓縮數(shù)據(jù)。由于同一列中所有域的長度值都順序存儲在該部分，RLE 算法能夠找到重復(fù)值的長序列，尤其對于固定的域長度。
對于數(shù)據(jù)部分，RCFile 不會對整個數(shù)據(jù)部分作為整個單元來壓縮；相反每個列被獨立壓縮，RCFile 使用重量級的 Gzip 壓縮算法，這是因為可以獲得較好的壓縮比。此外，由于 Lazy 解壓策略，當(dāng)處理一個行組時，RCFile 不需要解壓所有列，可以提高數(shù)據(jù)的處理效率。
RCFile 對數(shù)據(jù)部分的所有列使用同樣的壓縮算法，不過如果使用不同的算法來壓縮不同列效果會更好，這也就是 ORCFile 的一項改進(jìn)。另外，RCFile 還有一些其他缺點，比如區(qū)分不同行組時需要掃描同步標(biāo)記。為了解決這些問題，F(xiàn)acebook 工程師在探索如何更加高效的處理數(shù)據(jù)，就在同一時刻，HortonWorks 的工程師設(shè)計并實現(xiàn)了 ORCFile 文件格式，其就是針對 RCFile 進(jìn)行了優(yōu)化，這個我們準(zhǔn)備在另外一篇文章進(jìn)行介紹，敬請關(guān)注。
