大資料小視角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應用的資料儲存格式的。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/1747/viewspace-2814518/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 產品視角下的資料倉儲
- 從全域性視角看資料結構資料結構
- 透過spark將資料儲存到elasticsearchSparkElasticsearch
- 大資料小視角3:CarbonData,來自華為的中國力量大資料
- 滴滴從KV儲存到NewSQL實戰SQL
- 大資料小視角2:ORCFile與Parquet,開源圈背後的生意大資料
- 大資料小視角5:探究SSD寫放大的成因與解決思路大資料
- 資料儲存(1):從資料儲存看人類文明-資料儲存器發展歷程
- Kettle 從資料庫讀取資料存到變數中資料庫變數
- 從0到1,成為大資料行業領袖大資料行業
- 上帝視角一覽大資料開發體系大資料
- 從工程視角看邁向資料網格架構的六大問題架構
- Python程式設計從0到1(實戰篇:提取Word表格儲存到Excel)Python程式設計Excel
- 小豬的Python學習之旅 —— 20.抓取Gank.io所有資料儲存到MySQL中PythonMySql
- sql server資料庫如何儲存陣列,int[]float[]double[]陣列儲存到資料庫方法SQLServer資料庫陣列
- 便捷、高效、智慧—從運維視角看星環科技大資料基礎平臺TDH運維大資料
- 短視訊app開發,長按將視訊儲存到相簿APP
- 加密技術的未來:從服務端密碼儲存到使用者資料加密方案加密服務端密碼
- 微信小程式(canvas)畫圖儲存到本地相簿(wepy)微信小程式Canvas
- 爬蟲雙色球所有的歷史資料並儲存到SQLite爬蟲SQLite
- [BUG反饋]後臺選單資料儲存到session問題Session
- golang讀取檔案的json資料流,並解析到struct,儲存到資料庫GolangJSONStruct資料庫
- 上傳視訊介面:使用for迴圈,把視訊從本地上傳到伺服器,生成視訊和圖片地址,並儲存到log檔案A1伺服器
- 白話大資料 | 從買菜這件小事來聊聊資料倉儲大資料
- 從0到1搭建DeltaLake大資料平臺大資料
- gin框架,讀取檔案的json資料流,並解析到struct,儲存到資料庫框架JSONStruct資料庫
- html轉image 儲存到zipHTML
- SACC2022-酷克資料 牛雲飛:從分析視角的變化看銀行業資料平臺架構演進行業架構
- 微信小程式--通過canvas生成圖片並儲存到本地微信小程式Canvas
- Java 從指定URL下載檔案並儲存到指定目錄Java
- 從 RAID 到 Hadoop Hdfs 『大資料儲存的進化史』AIHadoop大資料
- 將MYSQL資料顯示在QT的tablewidget中/將QT中的資料儲存到MYSQL資料庫中MySqlQT資料庫
- 從前端程式設計師的視角看小程式的穩定性保障前端程式設計師
- 教你從0到1搭建小程式音視訊
- 從一個Android碼農視角回顧2018GDD大會Android
- 『中美科技實力對比:全球視角』今日資料行業日報(2019.05.27)行業
- python 爬蟲 5i5j房屋資訊 獲取並儲存到資料庫Python爬蟲資料庫
- 淺談資料倉儲和大資料大資料