前段時間一直在忙碌寫畢設與專案的事情，很久沒有寫一些學習心得與工作記錄了，開了乙個新的坑，希望能繼續堅持寫作與記錄分布式儲存相關的知識。為什麼叫小視角呢？因為屬於隨想型的內容，可能乙個由小的視角來審視海量資料的儲存與計算技術，把知識點分為兩到三章來梳理。管中窺豹，可見一斑，希望能利用這個過程提高自己，也歡迎閱讀的朋友多指正。第一章先從facebook的一篇**《rcfile: a fast and space-efficient data placement structure in mapreduce-based warehouse systems》展開，來聊一聊儲存格式的變遷，來看看如何因地制宜的讓海量資料適應計算需求。上車，上車~~資料的布局結構深刻的影響著資料處理的效率與效能，在底層的儲存系統之中如何組織資料。如何對資料進行布局會直接影響資料查詢引擎的設計與實現，並且也影響著儲存空間的利用效率。好的資料儲存與布局能夠更好的利用好儲存空間，並且契合業務應用場景的查詢實踐。接下來，我們來看看儲存資料的格式是如何隨著資料需求的不同進行變遷的。
在傳統的資料庫系統之中，衍生出了一下幾種資料的布局結構：
這幾種資料布局方式各有優點與缺陷，我們來一步一步梳理看看：
行儲存在傳統的的資料庫之中佔據主導地位，例如mysql的myisam的myd檔案，innodb的idb檔案，hive之中的sequence檔案，都是通過行儲存來實現的。如下圖所示，各個資料記錄被組織在乙個n元儲存模型之中，資料記錄是乙個接乙個地按順序排列的：
當然，這樣的儲存布局方式的優點是：因為每行的資料都共同存放，所以單行的資料載入快速，很適合oltp資料庫的增刪改查。
而在另一方便，缺點也十分明顯，就是不適用於海量資料的儲存的olap的應用場景：
所以行儲存並不適用於海量資料的分析查詢，由行儲存便衍生出新的儲存模式。
列儲存結構可以避免行儲存結構的缺點：在實際的資料讀取過程中可以避免讀取不必要的列。而且由於同一列的資料時共同儲存的，可以輕鬆地實現高的壓縮比例來達到節省空間的目的。
天下沒有免費的午餐，既然列儲存提供了許多優秀的特性，它自然也帶來了它自身的缺點，如上圖所示：當需要對單行進行查詢處理時，列儲存不能保證所有欄位都存在同乙個datanode之上，通常對於乙個大表來說也是不可能的事情。在上圖之中，同一條記錄的四個字段，分別位於不同的三個hdfs塊之中，這些塊很可能就分布在不同的datanode之上，因此，對於行的讀取將會占用集群大量的頻寬資源。
更加麻煩的地方在於：當資料刪除時，由於不同的資料列分布在不同的資料節點，所以需要同步多個資料節點之上的資料，由此引發的一致性問題是十分棘手的.
所以儘管列儲存適用於單機的資料分析查詢，但是當海量資料存放在分布式儲存系統之上時，列儲存似乎也要付出更多的代價。
好吧，你倆都不錯，那就結合一下試一試，所以就引申出下文要聊的：混合pax儲存結構
pax最早是一種改進cpu快取的混合布局結構，通過對於具有多個不同欄位的記錄進行優化來提高快取的效能。pax利用乙個快取頁面來儲存屬於每個欄位的所有字段，並且布局它們的分布。（相當於元資料）
同樣的，我們也可以利用這種混合布局的思路，來結合行儲存與列儲存的優點，由facebook設計的record columnar file(rcfile)就借鑑了pax儲存模型，通過先進行水平分割槽，再垂直分割槽的方式保證了同一行的資料一定在同乙個datanode，同時在單個datanode之上又利用行儲存來優化資料的查詢與儲存效能。
如上圖所示，在rcfile之中，在每個hdfs的資料塊之上，資料row group進行排列。每個row group包含了三部分：
懶解壓意味著列不一定在記憶體中解壓縮，直到執行單元確定列中的資料需要處理才會對資料進行解壓。懶解壓十分適合條件查詢的應用場景，如果有條件不能滿足行組中的所有記錄，則不需要進行資料解壓，這樣可以大大減少記憶體和cpu的占用。
例如，在上述查詢中，如果該row group之中所有的a都小於或等於1，則沒必要對row group的內容進行解壓，可以直接跳過。當然，這裡就需要依賴元資料的內容了。
大資料儲存 行儲存還是列儲存
目前大資料儲存有兩種方案可供選擇 行儲存和列儲存。業界對兩種儲存方案有很多爭持，集中焦點是 誰能夠更有效地處理海量資料，且兼顧安全 可靠 完整性。從目前發展情況看，關聯式資料庫已經不適應這種巨大的儲存量和計算要求，基本是淘汰出局。在已知的幾種大資料處理軟體中，hadoop的hbase採用列儲存，mo...
大資料訪問的選擇 行儲存還是列儲存？
目前大資料儲存有兩種方案可供選擇 行儲存和列儲存。業界對兩種儲存方案有很多爭持，集中焦點是 誰能夠更有效地處理海量資料，且兼顧安全 可靠 完整性。從目前發展情況看，關聯式資料庫已經不適應這種巨大的儲存量和計算要求，基本是淘汰出局。在已知的幾種大資料處理軟體中，hadoop的hbase採用列儲存，mo...
大資料訪問的選擇 行儲存還是列儲存？
上個月參加了乙個 雲儲存的技術討論會。這乙個月裡，陸續收到幾位同學討論 大資料儲存和處理的郵件。今天是週末，索性把這個月的交流內容整理寫下來，供各位參考。目前大資料儲存有兩種方案可供選擇 行儲存和列儲存。業界對兩種儲存方案有很多爭持，集中焦點是 誰能夠更有效地處理海量資料，且兼顧安全 可靠 完整性。...