一種海量大數據云存儲系統框架設計

費賢舉，王樹鋒，王文

(常州工學院計算機信息工程學院，江蘇 常州 213002)

一種海量大數據云存儲系統框架設計

費賢舉，王樹鋒，王文

(常州工學院計算機信息工程學院，江蘇 常州 213002)

隨著數據爆炸性增長，傳統的存儲方式已經不再滿足海量數據的存儲需求，云存儲技術的飛速發展，使得云存儲成為了一種新型的數據存儲解決方案。文章在分析Hadoop分布式文件系統HDFS的基礎上，提出了一種新的基于云計算環境的海量大數據存儲設計方法，主要給出了文件存儲方案設計以及副本方案設計等，為云計算海量數據存儲與管理提供了一種可行的關鍵技術方案。

海量大數據;云存儲系統;HDFS

0 引言

近年來，隨著社交網絡、網絡新聞媒體和娛樂視頻等各種信息化服務的開展產生了大量的數據，使得數據存儲規模也呈現爆炸性增長。個人用戶的數據存儲規模達到TB(1012B)級別，大中型企業的數據存儲甚至達到EB(1018B)級別。[1]云計算和物聯網的迅速發展，越來越多的個人和企業選擇將自己的業務遷移到大規模的數據中心，以此來降低本地的硬件成本和系統維護費用。由于數據中心存儲的數據量十分龐大，管理系統的復雜性較高;從存儲設備級別上看，由于數據中心為了控制成本，大量采用廉價存儲設備，致使數據極易因硬件設備故障而丟失。這些都對海量數據存儲性能、可靠性等方面帶來了挑戰。

云存儲是解決海量數據存儲的最有效手段。谷歌公司提出的 MapReduce[2]，作為一種新的編程模型，能有效地并行處理海量的數據，其采用的文件系統和數據管理模式分別是 GFS[3]和Big Table[4]。近些年，作為 MapReduce的開源實現，Hadoop[5]得到了企業和研究機構的廣泛關注。本文基于Hadoop平臺，提出了一種海量大數據云存儲系統設計，并分析了實現應用系統需要實現的關鍵技術。

1 Hadoop平臺

云計算是一種商業計算模式，其來源于分布式計算，并行計算和網格計算。Hadoop作為云計算的核心技術，目前在工業界得到了廣泛的應用。

Hadoop是Apache開源組織按照MapReduce的工作原理設計的一種開源的分布式處理框架，也是云計算環境下最著名的開源軟件。在Hadoop系統中，應用程序可以并行運行在由大規模廉價硬件構成的分布式系統中。Hadoop在內部實現了容錯和擴展機制，可以構建成高可靠性和高擴展性的分布式系統。

Hadoop主要有三部分組成:HDFS(Hadoop Distributed File System)、MapReduce分布式計算模型和Hbase(Hadoop Database)，其結構如圖1所示。

圖1 Hadoop結構圖

HDFS[6]與谷歌的 GFS 相對應，布署在廉價的硬件設備上，是Hadoop的最底層。HDFS可以存儲TB級(甚至PB級)的海量數據，并為應用程序提供高吞吐率的數據訪問。HDFS的數據訪問是順序的，適用于數據密集型的應用。

MapReduce[2]是一種海量數據處理的分布式計算模型。在集群中運行分布式應用程序時，MapReduce編程模型簡單易用。Hadoop提供的MapReduce編程模型是谷歌MapReduce的開源實現。在MapReduce編程模型中，開發者只需要編寫Map和Reduce函數，而任務調度、容錯等機制由底層實現。因此，即使開發者沒有分布式系統的經驗也能編寫高效的分布式應用程序。

Hbase[7]是 Big Table 的開源實現。Hbase 構建在HDFS之上，提供分布式數據庫服務。Hbase提供一種按列存儲的模型，用戶可以實時讀寫，也可以在大規模數據集上進行隨機訪問。

圖2 海量數據存儲和管理框架圖

2 海量數據存儲系統設計

2.1 文件系統的設計

節點主要分為兩部分:一種是數據節點，另外一種是非數據結點，其中系統中的主要成分都是數據節點(如圖3所示的DataNode節點)，非數據節點主要指管理節點和監控節點統一由Master節點表示，如圖3所示。

①Client節點。這個節點主要是指需要獲取海量分布式文件系統數據文件的應用程序(訪問客戶)，可以是Web應用業務服務器(如社交網絡、娛樂視頻、網絡虛擬銀行等)，也可以是其他通過當前海量數據存儲系統的訪問接口進行訪問的其他主機和服務器。

圖3 云存儲系統的結構示意圖

②DataNode節點。作為系統的主要構成部分，DataNode節點負責了系統正常運行的大部分任務，其中包括:數據存儲、提供查詢和事務處理，并且在必要時根據系統的需求提供計算能力。其中所有Node節點之間的關系也不完全是相同的，可以根據地域劃分鄰居節點和非鄰居節點，一般使得同一地域內的節點都是鄰居節點，基于這種設計主要考慮到系統規模可能會隨著分布式數據應用不斷增大，如果只有一層關系管理節點，將會變得很困難，并且在實際使用中，同一地域的節點之間的通信單價和質量都是比較好的，所以讓系統的管理分為3層，一個Master以每個組的關系看待節點，而節點自己能夠區分是鄰居節點(同一組)還是遠程節點(不同組的)。

③Master節點。Master主要負責系統的整體狀態的監控其中包括:整個系統的節點狀態、提供局部數據節點的查詢、保持文件塊的地址信息等。這里需要注意的是，根據系統負載能力的需求Master節點本身不一定是單個PC機器，也可能有幾臺機器組成一個集群共同提供服務，這樣才能保證系統不會因為管理節點的瓶頸而受到限制。

2.2 文件塊存儲策略及副本策略設計

在文件塊存儲設計時，規定每個文件塊都用一個主副本，即每次每個事務處理本文件塊的所有副本的更新都由主副本控制。每個文件塊除了本身包含的信息之外必須有以下控制信息塊。

①主副本所在節點編號。每個節點在加入系統時都從Master那里得到自己的唯一編號并且和自己的地址組成一個節點編號。

②副本個數。副本個數包括主副本和其他副本，如果為1說明沒有其他副本，如果為0說明此文件塊不存在。

③副本所在節點編號列表。保存所有節點編號，在必要的時候可以根據這里的節點編號找到保存了副本的節點的地址和系統編號以進行訪問。

在Master里面有一個根據系統的客戶信息生成的一個客戶編號的快照，并且有此快照構成系統文件塊保存的地址信息的索引，在進行全局查詢的時候，Master就是根據這個快照表的信息進行客戶信息定位的。然后根據算法把相應的文件塊的地址返回到應用服務器，讓它自行直接去訪問相應的節點。Master快照表結構如表1。

表1 Master客戶編號快照表

Master快照表中多個客戶的信息有可能保存在同一文件塊中，文件塊出現重復是完全正常的。除了客戶快照表之外，Master還保存了另外一重要的表——文件塊副本表，這個表借用了Google的Big table的思想，主要包括文件塊編號表項和節點信息表項，如表2所示。

表2 文件塊副本信息表

2.3 文件塊更新算法設計

采用Google的Chubby提供進行文件塊更新的鎖控制服務，在進行事務處理的時候經常會遇到如下問題:同一個事務中需要更新的信息不在一個文件塊中也不在一個節點中，在這個時候為了保證事務順利地完成需要在多個涉及到信息更新的節點中選擇一個作為協調節點，由它負責整個事務的更新流程和決定事務最后的成敗，即決定事務最后是成功提交還是失敗回滾。

與傳統分布式的處理方式Paxos算法相比，Chubby服務機制主要解決以下幾個問題。

1)開發人員在開發Service初期很少考慮到系統一致性的問題，也不會使用Consensus Protocol，但隨著開發進行，問題會變得越來越嚴重。Chubby服務中采用Lock Service可以解決一致性問題，同時保持系統原有的程序架構和通信機制不變。

2)系統中很多事件發生(比如Master地址信息)是需要告知其他用戶和服務器，Chubby使用一個基于文件系統的鎖服務可以將這些變動寫入文件中。因此，很多的開發人員通過使用Chubby來保存Metadata和Configuration。

3)雖然基于鎖的開發接口更容易被開發人員所熟悉。但在Chubby系統中采用了建議性的鎖而沒有采用強制性的鎖，采用這種方式是為了方便系統組件之間的信息交互而不會被阻止訪問。同時，Chubby還采用了粗粒度(Coarse-Grained)鎖服務而沒有采用細粒度(Fine-Grained)鎖服務，以提高系統性能。

4)Chubby選擇一個副本為協調者(Coordinator)，協調者從客戶提交的值中選擇一個，接受消息然后廣播給所有的副本，各副本選擇接受或拒接。協調者接收大多數副本的反饋后，認為達到一致性，向個副本發Commit消息。

Chubby的結構圖如圖4所示。

Chubby一般由5臺機器組成就足以提供上萬臺機器的鎖服務，5個服務器機器都是采用完全冗余策略來保證的，在Chubby內部采用Consensus Protocol協議保證系統的一致性，在每次5臺機器內部通過此協議選出Master并且在一定時間后更新Master，在每次數據更新的時候5臺機器在Master的控制下同步更新。

Client和Chubby之間采用event進行通信，并且為了降低通信頻率，Client在本地會保存1個和自己相關的Chubby文件的cache，cache有2個狀態(1個有效，1個無效)。當文件在Chubby端發生更新的時候，Chubby通知Client文件無效，然后Client自己去更新文件。

圖4 Chubby系統結構圖

Client更新DataNode節點數據文件的算法設計如圖5所示。

圖5 Client更新DataNode節點數據時序圖

其中，在DataNode節點數據更新的第四步中，如果Pipeline數據流管道中的某一個DataN-ode節點寫操作失敗，那么算法將進行如下操作。

1)關閉Pipeline數據流，然后將ack queue中的packets添加到 data queue的前面以免發生packets數據包的丟失現象;

2)升級在正常的DataNode節點上的保存的block的ID版本，使得發生故障的DataNode節點上的block數據會在節點恢復正常后被刪除，同時也會從Pipeline中刪除失效節點;

3)剩下的數據會被寫入到Pipeline數據流管道中的其他正常的數據節點中。

2.4 事務故障恢復系統設計

云存儲系統事務的恢復:對于云存儲系統事務來說，因為處于網絡環境中，其恢復過程遠遠要比集中式數據庫復雜的多，在云存儲系統事務恢復中，本地事務的恢復類同集中式事務的恢復。而整個云存儲系統事務的恢復由云存儲系統管理器與本地事務管理器協同完成。圖6是本系統的全局事務恢復模型。

圖6 云存儲系統事務恢復模型

3 目錄存儲與負載均衡設計

系統目錄存儲和管理是將系統的目錄分為若干個組，即前面所提到的按地域分組的方式。在每個組內，由Master指定一個節點專門提供目錄服務，它本身也是一個普通節點，只是根據系統的設置成為一個為系統提供目錄服務的組服務器，Master同時會將所有存儲目錄的節點的地址和編號信息通知所有節點。每個節點根據自己的信息和Master提供的信息對有目錄的節點進行排序。然后在目錄查詢的時候各個節點就能夠根據已知目錄節點信息進行查詢，雖然這個節點的其他查詢任務也能執行，但在設計系統負載平衡算法的時候，盡量減輕提供目錄查詢的節點的其他查詢任務。

按地區對來自客戶的訪問進行分類，并且根據客戶的IP信息通過DNS進行分流。而在同一地區的負載進行輪轉法分流本地區的各個訪問到本地區的不同數據節點上，同時保持Master和DNS之間的通信，Master根據節點自身反應的信息對DNS中的各個節點的權值進行調整，及時調整系統的負載平衡。

4 結語

本文首先分析了Hadoop云計算平臺，在文件系統架構層次中本系統盡量保持云計算平臺的各種優勢，提出了一種基于Hadoop的海量大數據云存儲系統設計方案。對文件塊的可讀性特性方面進行了改進，并分析了實現應用系統所需要的關鍵技術，為云計算海量數據存儲與管理提供了一種可行的關鍵技術方案。

[1]沈志榮，易樂天，舒繼武.大規模數據中心的數據存儲可靠性[J].中國計算機學會通訊，2012，8(10):8 -16.

[2]Dean J，Ghemawat S.MapReduce:Simplified Data Processing on Large Clusters[J].Communications of the ACM，2008，51(1):107-113.

[3]Ghemawat S，Gobioff H，Leung Shun-Tak.The Google File System[J].ACM SIGOPS Operating Systems Review，2003，37(5):29-43.

[4]Chang F，Dean J，Ghemawat S，et al.Bigtable:A Distributed Storage System for Structured Data[J].ACM Transactions on Computer Systems(TOCS)，2008，26(2):4.

[5]武海平，余宏亮，鄭緯民，等.聯網審計系統中海量數據的存儲與管理策略[J].計算機學報，2006，29(4):618 -624.

[6]崔杰，李陶深，蘭紅星.基于 Hadoop的海量數據存儲平臺設計與開發[J].計算機研究與發展，2012，49(z1):12 -18.

[7]劉樹仁，宋亞奇，朱永利，等.基于 Hadoop的智能電網狀態監測數據存儲研究[J].計算機科學，2013，40(1):81 -84.

[8]Zeng Wenying，Zhao Yuelong，Ou Kairi，et al.Research on Cloud Storage Architecture and Key Technologies[C]//Proceedings of the 2nd International Conference on Interaction Sciences:Information Technology，Culture and Human.ACM，2009.

[9]Robert G L，Gu Yuhong，Sabala N，et al.Compute and Storage Clouds Using Wide Area High performance Networks[J].Future Generation Computer Systems，2009，25(2):179 -183.

[10]Storer M W，Greenan K，Long D D E，et al.Secure Data Deduplication[C]//4thInternation Workshop on StorageSS'08，Virginia:Fairfax，2008:1 -10.

Designing a Cloud Storage System of Massive Data

FEI Xianju，WANG Shufeng，WANG Wen

(School of Computer Information Engineering，Changzhou Institute of Technology，Changzhou 213002)

With the explosion of data，traditional storage methods no longer meet the massive data storage requirements.The rapid development of cloud storage technology makes cloud storage become a new type of data storage solution.Based on the Hadoop Distributed File System(HDFS)，this paper puts forward a new type of distributed cloud storage solution for massive data，providing the persistence of high availability of data storage.This paper proposes a framework of storage and management of massive data，and analyzes key techniques that we need to implement the proposed framework.

massive data;cloud storage system;HDFS

TP312

A

1671-0436(2014)03-0038-05

2014-05-06

常州市2012年科技局應用基礎研究計劃項目(CJ20120009);常州工學院2013年度校級科研基金項目(YN1316)

費賢舉(1975— )，男，碩士，講師。

責任編輯:陳 亮