大資料小視角1：從行儲存到RCFile

前段時間一直在忙碌寫畢設與專案的事情，很久沒有寫一些學習心得與工作記錄了，開了一個新的坑，希望能繼續堅持寫作與記錄分散式儲存相關的知識。為什麼叫小視角呢？因為屬於隨想型的內容，可能一個由小的視角來審視海量資料的儲存與計算技術，把知識點分為兩到三章來梳理。管中窺豹，可見一斑，希望能利用這個過程提高自己，也歡迎閱讀的朋友多指正。 第一章先從Facebook的一篇論文《RCFile: A Fast and Space-efficient Data Placement Structure in MapReduce-based Warehouse Systems》展開，來聊一聊儲存格式的變遷，來看看如何因地制宜的讓海量資料適應計算需求。上車，上車~~

1.資料儲存格式

資料的佈局結構深刻的影響著資料處理的效率與效能，在底層的儲存系統之中如何組織資料。如何對資料進行佈局會直接影響資料查詢引擎的設計與實現，並且也影響著儲存空間的利用效率。好的資料儲存與佈局能夠更好的利用好儲存空間，並且契合業務應用場景的查詢實踐。接下來，我們來看看儲存資料的格式是如何隨著資料需求的不同進行變遷的。

在傳統的資料庫系統之中，衍生出了一下幾種資料的佈局結構：

• （1）水平行儲存結構

• （2）垂直列儲存結構

• （3）混合PAX儲存結構

這幾種資料佈局方式各有優點與缺陷，我們來一步一步梳理看看：

2.水平的行儲存結構

行儲存在傳統的的資料庫之中佔據主導地位，例如MySQL的MyISAM的MYD檔案，innodb的idb檔案，Hive之中的Sequence檔案，都是透過行儲存來實現的。如下圖所示，各個資料記錄被組織在一個n元儲存模型之中，資料記錄是一個接一個地按順序排列的：

當然，這樣的儲存佈局方式的優點是：因為每行的資料都共同存放，所以單行的資料載入快速，很適合OLTP資料庫的增刪改查。
而在另一方便，缺點也十分明顯，就是不適用於海量資料的儲存的OLAP的應用場景：

• （1）當僅僅對單個列，或少量列進行資料處理時，需要讀取額外許多不必要的資料，會產生極大的效能損耗。因為每次都載入了不必要的列，導致快取被塞滿無用的資料，並且隨著資料量的增加，這種損耗是成倍增加的。

• （2）行儲存的資料相似性很低，很難實現較高的資料壓縮比例，所以相對來說也比較佔用儲存空間。

所以行儲存並不適用於海量資料的分析查詢，由行儲存便衍生出新的儲存模式。

3.垂直的列儲存結構

列儲存結構可以避免行儲存結構的缺點：在實際的資料讀取過程中可以避免讀取不必要的列。而且由於同一列的資料時共同儲存的，可以輕鬆地實現高的壓縮比例來達到節省空間的目的。

天下沒有免費的午餐，既然列儲存提供了許多優秀的特性，它自然也帶來了它自身的缺點，如上圖所示：當需要對單行進行查詢處理時，列儲存不能保證所有欄位都存在同一個datanode之上，通常對於一個大表來說也是不可能的事情。在上圖之中，同一條記錄的四個欄位，分別位於不同的三個HDFS塊之中，這些塊很可能就分佈在不同的datanode之上，因此，對於行的讀取將會佔用叢集大量的頻寬資源。

更加麻煩的地方在於：當資料刪除時，由於不同的資料列分佈在不同的資料節點，所以需要同步多個資料節點之上的資料，由此引發的一致性問題是十分棘手的.

所以儘管列儲存適用於單機的資料分析查詢，但是當海量資料存放在分散式儲存系統之上時，列儲存似乎也要付出更多的代價。

4.混合PAX儲存結構

• 行儲存面對資料記錄的訪問具有靈活性，但是快取利用能力差，資料壓縮能力差。

• 列儲存顯然I/O效能更好，資料壓縮能力強，但是對於單行資料的處理在分散式環境之下表現也不近人意。

好吧，你倆都不錯，那就結合一下試一試，所以就引申出下文要聊的：混合PAX儲存結構

PAX最早是一種改進CPU快取的混合佈局結構，透過對於具有多個不同欄位的記錄進行最佳化來提高快取的效能。PAX利用一個快取頁面來儲存屬於每個欄位的所有欄位，並且佈局它們的分佈。（相當於後設資料）

同樣的，我們也可以利用這種混合佈局的思路，來結合行儲存與列儲存的優點，由Facebook設計的Record Columnar File(RCFile)就借鑑了PAX儲存模型，透過先進行水平分割槽，再垂直分割槽的方式保證了同一行的資料一定在同一個datanode，同時在單個datanode之上又利用行儲存來最佳化資料的查詢與儲存效能。

如上圖所示，在RCFile之中，在每個HDFS的資料塊之上，資料Row Group進行排列。每個Row Group包含了三部分：

• 資料分隔標誌

• 後設資料（後設資料儲存了該Row Group有許多記錄，有多少位元組。在每個列之中有多少位元組）

• 列式儲存資料 （實際儲存資料的內容，不同的列可以使用不同的壓縮演算法來最大程度的壓縮資料的儲存空間）

寫到這裡想必大家都對RCFile有充分的瞭解了，我們接下來藉著RCFile論文的部分再談兩個細節的問題：

• 懶解壓：
  舉個例子：假如說有如下查詢 :

  select a from table where a > 1 ;

懶解壓意味著列不一定在記憶體中解壓縮，直到執行單元確定列中的資料需要處理才會對資料進行解壓。懶解壓十分適合條件查詢的應用場景，如果有條件不能滿足行組中的所有記錄，則不需要進行資料解壓，這樣可以大大減少記憶體和CPU的佔用。

例如，在上述查詢中，如果該Row Group之中所有的a都小於或等於1，則沒必要對Row Group的內容進行解壓，可以直接跳過。當然，這裡就需要依賴後設資料的內容了。

• Row Group的size：
  顯然，越大的Row Group更有利於資料的壓縮處理，但是顯然過大的資料儲存容量會影響上文提到的懶壓縮的效能。妹子的胸也不是越大越好的，所以最終Facebook選擇了4MB的Row Group大小。（記住這個問題，後續我們還會回來再談這個問題的）

5.小結：

本文主要是從資料的佈局角度梳理了由行儲存到RCFile的演變，分析了各種儲存佈局模式所合適的場景。下一篇我們將繼續探討這個問題，來看看ORCFile與Parquet的是如何更進步來解決大規模OLAP應用的資料儲存格式的。