大數據小視角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與Parquest的是如何更進步來解決大規模OLAP應用的數據存儲格式的。
大數據小視角1：從行存儲到RCFile