馮漢超,周凱東
(河北工程大學信息與電氣工程學院,河北邯鄲056038)
當前社會已經進入數據爆炸的時代,海量數據的處理與分析被稱為“大數據”[1]。全世界億萬用戶通過互聯網相互聯系,隨之產生的數據也在高速增長。在互聯網領域,與大數據有關的應用已變的非常重要。由于傳統關系型數據庫在管理大數據時遇到種種困難和阻礙,基于分布式的海量數據管理系統成了當前的研究熱點。
Hadoop[2]是 MapReduce[3]分布式計算框架的實現,為大數據處理提供可擴展、高容錯性的大型分布式集群。基于MapReduce的數據倉庫[4]并不能直接管理集群中的數據存儲,而是由Hadoop分布式存儲系統HDFS(Hadoop Distributed File System)[5-7]來管理海量數據。如何在 HDFS中設計一個高效的數據存儲結構來組織大數據遇到了一系列的困難,而影響數據倉庫性能的關鍵因素是能夠滿足充分利用MapReduce計算特性來處理大數據的數據存儲結構。本文在分析分布式存儲系統HDFS局限性基礎上,通過改變數據存儲結構對大數據存儲和處理作出了一定改進。
高速的數據加載。數據的高速加載是大數據處理中的一個關鍵問題,例如Facebook每天要有20TB的數據存放到數據倉庫中。在正常的查詢時,由于網絡帶寬、磁盤I/O在數據傳輸時的資源瓶頸,縮短數據加載時間變得非常關鍵。
高速的查詢處理。為滿足大量用戶同時向系統提交實時請求和高負載查詢,要求底層數據存儲結構在滿足數據不斷增長的同時,能夠高效處理查詢請求。
存儲空間的高利用率。不斷增長的互聯網用戶,導致全球數據急劇增長。這就要求系統在存儲上有很好的擴展能力。如何存放數據使磁盤利用率達到最高是關鍵問題。
適應動態高負載模式。對于不同的應用程序,用戶分析大數據集的方式不盡相同。雖然一些數據分析以靜態模式周期執行,但大部分數據分析不遵循任何的常規模式。因此,需要系統在有限的存儲空間下使用不可預測的數據分析請求,而不是在特定的模式下運行。
行式存儲結構[8]是傳統關系型數據庫存儲結構,記錄以行的形式存儲在數據庫關系表中。在添加行時,記錄中所有的列都需要存儲,且記錄被連續的存儲到磁盤的頁塊中。在分布式系統存儲下,表按行水平分割,每行中所有數據存放在同一個HDFS塊中。圖1表示以行式存儲的數據結構在HDFS塊中的分布。
行式存儲在 Hadoop集群 DataNode[5]節點間的數據分布分析。以行式結構存儲時,每行中所有的列存放在同一個HDFS塊中。在分布式系統HDFS中,大表中的數據按行水平分割,分割后每組數據可能分布在不同的DataNode節點上。行式存儲在Hadoop集群DataNode節點間的數據分布結構圖如圖2所示。


行式存儲時數據讀取操作分析。若讀取行中A和C兩列,首先讀取本地DataNode節點上所有符合條件的行,然后從每行中選擇A和C兩列數據,過濾掉不需要的B和D列。行式數據讀取操作示意圖如圖3所示。
采用督脈上行腦部后正中線以枕骨粗隆上為定點,每次進針破骨約1 mm,每次選穴1個(四肢關節以骨面進針,每次兩個穴位,每十天為一個療程,間隔七天第二個療程)病程需要3~5個療程,重者可以行81天,有的可以行兩個81天治療。急性患者選擇刺骨結合石學敏教授的醒腦開竅療效更好。

行式存儲結構優點和缺點分析。數據加載速度快,所有數據都從本地讀取,無需額外的網絡帶寬消耗。但是,每行中所有列都存放在相同的HDFS塊中,在數據讀取一行數據時,行中所有列都需從磁盤上讀取,不需要的列也會被讀取,這樣會額外增加磁盤I/O開銷。
每列存儲的數據類型不能一樣,在數據壓縮時不同數據類型壓縮效果很差,這樣導致磁盤空間利用率低,同時也加大了磁盤I/O開銷。
列式存儲結構[9-10]是將關系表按列垂直分割成多個子關系表,分割后的每組子關系表中的所有數據存放在同一個HDFS塊中,每一列都獨立存儲。列式存儲的數據結構在HDFS塊中的分布如圖4所示。

列式存儲在Hadoop集群DataNode節點間的數據分布分析。以列式結構存儲時,每列中所有數據存放在同一個HDFS塊中。在分布式系統HDFS中,大表中的數據按列垂直分割,分割后每組數據可能分布在不同的DataNode節點上。列式存儲在Hadoop集群DataNode節點間的數據分布結構圖如圖5所示。

列式存儲時數據讀取操作分析。若讀取行中A和C兩列,A和C列分別存放在兩個不同的節點上,首先從DataNode1上讀取A列所有數據,再從DataNode3上讀取C列數據,最后通過網絡將數據傳輸到同一個機器上。列式數據讀取操作示意圖如圖6所示。

列式存儲結構優點和缺點分析。列式存儲只讀取有用的列,能夠避免額外的磁盤I/O開銷。同時,同一列中的數據類型相同,在數據壓縮時有很好的壓縮比,提高磁盤的空間利用率。但是,列式存儲是按列垂直分割,不同的列可能分布在不同的數據節點上,讀取不同列的數據會跨節點訪問,增加了網絡傳輸所消耗的時間。
通過以上行式存儲和列式存儲結構的優缺點分析,行式存儲主要是在讀取不必要的列消耗了額外的磁盤I/O,列式存儲主要是在跨節點查詢數據時消耗額外的網絡傳輸時間。最理想的情況是能夠避免額外的磁盤I/O消耗和網絡傳輸消耗。設從n行數據中讀取i列有效數據,其行列存儲結構在數據讀取和網絡消耗上比較如表1所示。

表1行式存儲與列式存儲讀取效率比較Tab.1 The efficiency of row store and colunn store
分別結合行式存儲和列式存儲節點的優點,將關系表中的數據先按水平劃分成多個行組(Row Group),每一個行組存放在同一個 HDFS塊中。在每一個行組內,將表按列垂直劃分多個子關系表,每一列在進行數據壓縮后獨立存儲在同一個HDFS塊中。行組在Hadoop集群DataNode節點間的數據分布如圖7所示。

行組內按列垂直劃分多個列,每個列在數據壓縮后獨立存儲在HDFS塊中,每行中所有列都存放在同一個HDFS塊中,行組內數據按列垂直分割后的列存儲方式在HDFS塊中分布結構如圖8所示。

數據讀取操作分析。關系表被水平分割成多個行組,行組內按列垂直分割,存儲在同一個HDFS塊中。若讀取列A和C,首先讀取本地行組,然后在行組中選擇需要的列A和C。這樣既避免了行式存儲結構中讀取不必要的列而消耗額外的磁盤I/O,也避免了列式存儲結構中因跨節點訪問而消耗額外的網絡傳輸時間。
數據壓縮分析。由于行組內是按列垂直分割,每一列具有相同的數據類型,因此在數據壓縮時有很好的壓縮比,從而提高了磁盤空間的利用率。
Hadoop分布式存儲系統HDFS的塊大小默認為64MB,該值可以在配置文件中修改。若行組的存儲空間比HDFS塊要大,則一個行組被存儲在多個HDFS塊中,帶來的問題主要有:
1)由分布式存儲系統特點,不同的塊有可能分配在不同的數據節點中。因此,在數據訪問時,有可能跨節點訪問,從而消耗了不必要的網絡傳輸時間。
2)HDFS的高容錯性是默認將每份數據在集群中有三處備份。若數據節點發生故障,因行列結合存儲結構的約束,需要更長的恢復時間,同時也需要額外維護。
所以每個行組分割的大小最大不能超過HDFS塊的大小,可以通過改變HDFS塊的大小來改變行組大小。
對行式存儲、列式存儲、行列結合的數據存儲結構在數據加載時間和數據壓縮效率上進行性能比較。比較結果如圖9所示。
通過測試比較,行式存儲在數據加載上,列式存儲消耗時間最長,行式存儲略優于行列存儲。而在數據壓縮效果上,行式存儲壓縮效果最差,行列存儲壓縮效果最好。

行式數據存儲結構雖然在數據加載上有較好的效果,但由于列的數據類型不同,在數據壓縮上效率很低,不能有效地提高磁盤利用率。列式存儲結構雖然在數據壓縮上有很好的壓縮效果,但由于跨數據節點訪問使得數據加載時間較長,從而降低了系統吞吐量。行列相結合的數據存儲結構不僅有行式結構存儲的高效數據加載,同時有很好的數據壓縮效果。在分布式系統中,行列數據存儲結構極大地提高了大數據存儲及處理性能。
[1]MANYIKA J,CHUI M,BROWN B,et al.Big data:The next frontier for innovation,competition,and productivity[J].Comm unications of the ACM,2011,56(2):100-105.
[2]WHITE T.Hadoop:the definitive guide[M].O 'Reilly,2012.
[3]DEAN J,GHEMAWAT S.MapReduce:simplified data processing on large clusters[J].Communications of the ACM,2008,51(1):107-113.
[4]THUSOO A,SARMA J S,JAIN N,et al.Hive:a warehousing solution over a map - reduce framework[J].Proceedings of the VLDB Endowment,2009,2(2):1626-1629.
[5]BORTHAKUR D.The hadoop distributed file system:Architecture and design[J].Hadoop Project Website,2007(11):21.
[6]KAUSHIK R T,BHANDARKAR M,NAHRSTEDT K.Evaluation and analysis of greenhdfs:A self- adaptive,energy-conserving variant of the hadoop distributed file system[C]//Cloud Computing Technology and Science(CloudCom),2010 IEEE Second International Conference on.IEEE,2010:274-287.
[7]SHVACHKO K,KUANG H,RADIA S,et al.The hadoop distributed file system[C]//Mass Storage Systems and Technologies(MSST),2010 IEEE 26th Symposium on.IEEE,2010:1-10.
[8]LI N,RAO J,SHEKITA E,et al.Leveraging a scalable row store to build a distributed text index[C]//Proceedings of the first international workshop on Cloud data management.ACM,2009:29-36.
[9]IVANOVA M G,KERSTEN M L,NES N J,et al.An architecture for recycling intermediates in a column-store[J].ACM Transactions on Database Systems(TODS),2010,35(4):24.
[10]ABADI D J,BONCZ P A,HARIZOPOULOS S.Column- oriented database systems[J].Proceedings of the VLDB Endowment,2009,2(2):1664 -1665.