費(fèi)賢舉，王樹(shù)鋒，王文

(常州工學(xué)院計(jì)算機(jī)信息工程學(xué)院，江蘇 常州 213002)

一種海量大數(shù)據(jù)云存儲(chǔ)系統(tǒng)框架設(shè)計(jì)

費(fèi)賢舉，王樹(shù)鋒，王文

(常州工學(xué)院計(jì)算機(jī)信息工程學(xué)院，江蘇 常州 213002)

隨著數(shù)據(jù)爆炸性增長(zhǎng)，傳統(tǒng)的存儲(chǔ)方式已經(jīng)不再滿(mǎn)足海量數(shù)據(jù)的存儲(chǔ)需求，云存儲(chǔ)技術(shù)的飛速發(fā)展，使得云存儲(chǔ)成為了一種新型的數(shù)據(jù)存儲(chǔ)解決方案。文章在分析Hadoop分布式文件系統(tǒng)HDFS的基礎(chǔ)上，提出了一種新的基于云計(jì)算環(huán)境的海量大數(shù)據(jù)存儲(chǔ)設(shè)計(jì)方法，主要給出了文件存儲(chǔ)方案設(shè)計(jì)以及副本方案設(shè)計(jì)等，為云計(jì)算海量數(shù)據(jù)存儲(chǔ)與管理提供了一種可行的關(guān)鍵技術(shù)方案。

海量大數(shù)據(jù);云存儲(chǔ)系統(tǒng);HDFS

0 引言

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

云存儲(chǔ)是解決海量數(shù)據(jù)存儲(chǔ)的最有效手段。谷歌公司提出的 MapReduce[2]，作為一種新的編程模型，能有效地并行處理海量的數(shù)據(jù)，其采用的文件系統(tǒng)和數(shù)據(jù)管理模式分別是 GFS[3]和Big Table[4]。近些年，作為 MapReduce的開(kāi)源實(shí)現(xiàn)，Hadoop[5]得到了企業(yè)和研究機(jī)構(gòu)的廣泛關(guān)注。本文基于Hadoop平臺(tái)，提出了一種海量大數(shù)據(jù)云存儲(chǔ)系統(tǒng)設(shè)計(jì)，并分析了實(shí)現(xiàn)應(yīng)用系統(tǒng)需要實(shí)現(xiàn)的關(guān)鍵技術(shù)。

1 Hadoop平臺(tái)

云計(jì)算是一種商業(yè)計(jì)算模式，其來(lái)源于分布式計(jì)算，并行計(jì)算和網(wǎng)格計(jì)算。Hadoop作為云計(jì)算的核心技術(shù)，目前在工業(yè)界得到了廣泛的應(yīng)用。

Hadoop是Apache開(kāi)源組織按照MapReduce的工作原理設(shè)計(jì)的一種開(kāi)源的分布式處理框架，也是云計(jì)算環(huán)境下最著名的開(kāi)源軟件。在Hadoop系統(tǒng)中，應(yīng)用程序可以并行運(yùn)行在由大規(guī)模廉價(jià)硬件構(gòu)成的分布式系統(tǒng)中。Hadoop在內(nèi)部實(shí)現(xiàn)了容錯(cuò)和擴(kuò)展機(jī)制，可以構(gòu)建成高可靠性和高擴(kuò)展性的分布式系統(tǒng)。

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

圖1 Hadoop結(jié)構(gòu)圖

HDFS[6]與谷歌的 GFS 相對(duì)應(yīng)，布署在廉價(jià)的硬件設(shè)備上，是Hadoop的最底層。HDFS可以存儲(chǔ)TB級(jí)(甚至PB級(jí))的海量數(shù)據(jù)，并為應(yīng)用程序提供高吞吐率的數(shù)據(jù)訪(fǎng)問(wèn)。HDFS的數(shù)據(jù)訪(fǎng)問(wèn)是順序的，適用于數(shù)據(jù)密集型的應(yīng)用。

MapReduce[2]是一種海量數(shù)據(jù)處理的分布式計(jì)算模型。在集群中運(yùn)行分布式應(yīng)用程序時(shí)，MapReduce編程模型簡(jiǎn)單易用。Hadoop提供的MapReduce編程模型是谷歌MapReduce的開(kāi)源實(shí)現(xiàn)。在MapReduce編程模型中，開(kāi)發(fā)者只需要編寫(xiě)Map和Reduce函數(shù)，而任務(wù)調(diào)度、容錯(cuò)等機(jī)制由底層實(shí)現(xiàn)。因此，即使開(kāi)發(fā)者沒(méi)有分布式系統(tǒng)的經(jīng)驗(yàn)也能編寫(xiě)高效的分布式應(yīng)用程序。

Hbase[7]是 Big Table 的開(kāi)源實(shí)現(xiàn)。Hbase 構(gòu)建在HDFS之上，提供分布式數(shù)據(jù)庫(kù)服務(wù)。Hbase提供一種按列存儲(chǔ)的模型，用戶(hù)可以實(shí)時(shí)讀寫(xiě)，也可以在大規(guī)模數(shù)據(jù)集上進(jìn)行隨機(jī)訪(fǎng)問(wèn)。

圖2 海量數(shù)據(jù)存儲(chǔ)和管理框架圖

2 海量數(shù)據(jù)存儲(chǔ)系統(tǒng)設(shè)計(jì)

2.1 文件系統(tǒng)的設(shè)計(jì)

節(jié)點(diǎn)主要分為兩部分:一種是數(shù)據(jù)節(jié)點(diǎn)，另外一種是非數(shù)據(jù)結(jié)點(diǎn)，其中系統(tǒng)中的主要成分都是數(shù)據(jù)節(jié)點(diǎn)(如圖3所示的DataNode節(jié)點(diǎn))，非數(shù)據(jù)節(jié)點(diǎn)主要指管理節(jié)點(diǎn)和監(jiān)控節(jié)點(diǎn)統(tǒng)一由Master節(jié)點(diǎn)表示，如圖3所示。

①Client節(jié)點(diǎn)。這個(gè)節(jié)點(diǎn)主要是指需要獲取海量分布式文件系統(tǒng)數(shù)據(jù)文件的應(yīng)用程序(訪(fǎng)問(wèn)客戶(hù))，可以是Web應(yīng)用業(yè)務(wù)服務(wù)器(如社交網(wǎng)絡(luò)、娛樂(lè)視頻、網(wǎng)絡(luò)虛擬銀行等)，也可以是其他通過(guò)當(dāng)前海量數(shù)據(jù)存儲(chǔ)系統(tǒng)的訪(fǎng)問(wèn)接口進(jìn)行訪(fǎng)問(wèn)的其他主機(jī)和服務(wù)器。

圖3 云存儲(chǔ)系統(tǒng)的結(jié)構(gòu)示意圖

②DataNode節(jié)點(diǎn)。作為系統(tǒng)的主要構(gòu)成部分，DataNode節(jié)點(diǎn)負(fù)責(zé)了系統(tǒng)正常運(yùn)行的大部分任務(wù)，其中包括:數(shù)據(jù)存儲(chǔ)、提供查詢(xún)和事務(wù)處理，并且在必要時(shí)根據(jù)系統(tǒng)的需求提供計(jì)算能力。其中所有Node節(jié)點(diǎn)之間的關(guān)系也不完全是相同的，可以根據(jù)地域劃分鄰居節(jié)點(diǎn)和非鄰居節(jié)點(diǎn)，一般使得同一地域內(nèi)的節(jié)點(diǎn)都是鄰居節(jié)點(diǎn)，基于這種設(shè)計(jì)主要考慮到系統(tǒng)規(guī)?？赡軙?huì)隨著分布式數(shù)據(jù)應(yīng)用不斷增大，如果只有一層關(guān)系管理節(jié)點(diǎn)，將會(huì)變得很困難，并且在實(shí)際使用中，同一地域的節(jié)點(diǎn)之間的通信單價(jià)和質(zhì)量都是比較好的，所以讓系統(tǒng)的管理分為3層，一個(gè)Master以每個(gè)組的關(guān)系看待節(jié)點(diǎn)，而節(jié)點(diǎn)自己能夠區(qū)分是鄰居節(jié)點(diǎn)(同一組)還是遠(yuǎn)程節(jié)點(diǎn)(不同組的)。

③Master節(jié)點(diǎn)。Master主要負(fù)責(zé)系統(tǒng)的整體狀態(tài)的監(jiān)控其中包括:整個(gè)系統(tǒng)的節(jié)點(diǎn)狀態(tài)、提供局部數(shù)據(jù)節(jié)點(diǎn)的查詢(xún)、保持文件塊的地址信息等。這里需要注意的是，根據(jù)系統(tǒng)負(fù)載能力的需求Master節(jié)點(diǎn)本身不一定是單個(gè)PC機(jī)器，也可能有幾臺(tái)機(jī)器組成一個(gè)集群共同提供服務(wù)，這樣才能保證系統(tǒng)不會(huì)因?yàn)楣芾砉?jié)點(diǎn)的瓶頸而受到限制。

2.2 文件塊存儲(chǔ)策略及副本策略設(shè)計(jì)

在文件塊存儲(chǔ)設(shè)計(jì)時(shí)，規(guī)定每個(gè)文件塊都用一個(gè)主副本，即每次每個(gè)事務(wù)處理本文件塊的所有副本的更新都由主副本控制。每個(gè)文件塊除了本身包含的信息之外必須有以下控制信息塊。

①主副本所在節(jié)點(diǎn)編號(hào)。每個(gè)節(jié)點(diǎn)在加入系統(tǒng)時(shí)都從Master那里得到自己的唯一編號(hào)并且和自己的地址組成一個(gè)節(jié)點(diǎn)編號(hào)。

②副本個(gè)數(shù)。副本個(gè)數(shù)包括主副本和其他副本，如果為1說(shuō)明沒(méi)有其他副本，如果為0說(shuō)明此文件塊不存在。

③副本所在節(jié)點(diǎn)編號(hào)列表。保存所有節(jié)點(diǎn)編號(hào)，在必要的時(shí)候可以根據(jù)這里的節(jié)點(diǎn)編號(hào)找到保存了副本的節(jié)點(diǎn)的地址和系統(tǒng)編號(hào)以進(jìn)行訪(fǎng)問(wèn)。

在Master里面有一個(gè)根據(jù)系統(tǒng)的客戶(hù)信息生成的一個(gè)客戶(hù)編號(hào)的快照，并且有此快照構(gòu)成系統(tǒng)文件塊保存的地址信息的索引，在進(jìn)行全局查詢(xún)的時(shí)候，Master就是根據(jù)這個(gè)快照表的信息進(jìn)行客戶(hù)信息定位的。然后根據(jù)算法把相應(yīng)的文件塊的地址返回到應(yīng)用服務(wù)器，讓它自行直接去訪(fǎng)問(wèn)相應(yīng)的節(jié)點(diǎn)。Master快照表結(jié)構(gòu)如表1。

表1 Master客戶(hù)編號(hào)快照表

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

表2 文件塊副本信息表

2.3 文件塊更新算法設(shè)計(jì)

采用Google的Chubby提供進(jìn)行文件塊更新的鎖控制服務(wù)，在進(jìn)行事務(wù)處理的時(shí)候經(jīng)常會(huì)遇到如下問(wèn)題:同一個(gè)事務(wù)中需要更新的信息不在一個(gè)文件塊中也不在一個(gè)節(jié)點(diǎn)中，在這個(gè)時(shí)候?yàn)榱吮ＷC事務(wù)順利地完成需要在多個(gè)涉及到信息更新的節(jié)點(diǎn)中選擇一個(gè)作為協(xié)調(diào)節(jié)點(diǎn)，由它負(fù)責(zé)整個(gè)事務(wù)的更新流程和決定事務(wù)最后的成敗，即決定事務(wù)最后是成功提交還是失敗回滾。

與傳統(tǒng)分布式的處理方式Paxos算法相比，Chubby服務(wù)機(jī)制主要解決以下幾個(gè)問(wèn)題。

1)開(kāi)發(fā)人員在開(kāi)發(fā)Service初期很少考慮到系統(tǒng)一致性的問(wèn)題，也不會(huì)使用Consensus Protocol，但隨著開(kāi)發(fā)進(jìn)行，問(wèn)題會(huì)變得越來(lái)越嚴(yán)重。Chubby服務(wù)中采用Lock Service可以解決一致性問(wèn)題，同時(shí)保持系統(tǒng)原有的程序架構(gòu)和通信機(jī)制不變。

2)系統(tǒng)中很多事件發(fā)生(比如Master地址信息)是需要告知其他用戶(hù)和服務(wù)器，Chubby使用一個(gè)基于文件系統(tǒng)的鎖服務(wù)可以將這些變動(dòng)寫(xiě)入文件中。因此，很多的開(kāi)發(fā)人員通過(guò)使用Chubby來(lái)保存Metadata和Configuration。

3)雖然基于鎖的開(kāi)發(fā)接口更容易被開(kāi)發(fā)人員所熟悉。但在Chubby系統(tǒng)中采用了建議性的鎖而沒(méi)有采用強(qiáng)制性的鎖，采用這種方式是為了方便系統(tǒng)組件之間的信息交互而不會(huì)被阻止訪(fǎng)問(wèn)。同時(shí)，Chubby還采用了粗粒度(Coarse-Grained)鎖服務(wù)而沒(méi)有采用細(xì)粒度(Fine-Grained)鎖服務(wù)，以提高系統(tǒng)性能。

4)Chubby選擇一個(gè)副本為協(xié)調(diào)者(Coordinator)，協(xié)調(diào)者從客戶(hù)提交的值中選擇一個(gè)，接受消息然后廣播給所有的副本，各副本選擇接受或拒接。協(xié)調(diào)者接收大多數(shù)副本的反饋后，認(rèn)為達(dá)到一致性，向個(gè)副本發(fā)Commit消息。

Chubby的結(jié)構(gòu)圖如圖4所示。

Chubby一般由5臺(tái)機(jī)器組成就足以提供上萬(wàn)臺(tái)機(jī)器的鎖服務(wù)，5個(gè)服務(wù)器機(jī)器都是采用完全冗余策略來(lái)保證的，在Chubby內(nèi)部采用Consensus Protocol協(xié)議保證系統(tǒng)的一致性，在每次5臺(tái)機(jī)器內(nèi)部通過(guò)此協(xié)議選出Master并且在一定時(shí)間后更新Master，在每次數(shù)據(jù)更新的時(shí)候5臺(tái)機(jī)器在Master的控制下同步更新。

Client和Chubby之間采用event進(jìn)行通信，并且為了降低通信頻率，Client在本地會(huì)保存1個(gè)和自己相關(guān)的Chubby文件的cache，cache有2個(gè)狀態(tài)(1個(gè)有效，1個(gè)無(wú)效)。當(dāng)文件在Chubby端發(fā)生更新的時(shí)候，Chubby通知Client文件無(wú)效，然后Client自己去更新文件。

圖4 Chubby系統(tǒng)結(jié)構(gòu)圖

Client更新DataNode節(jié)點(diǎn)數(shù)據(jù)文件的算法設(shè)計(jì)如圖5所示。

圖5 Client更新DataNode節(jié)點(diǎn)數(shù)據(jù)時(shí)序圖

其中，在DataNode節(jié)點(diǎn)數(shù)據(jù)更新的第四步中，如果Pipeline數(shù)據(jù)流管道中的某一個(gè)DataN-ode節(jié)點(diǎn)寫(xiě)操作失敗，那么算法將進(jìn)行如下操作。

1)關(guān)閉Pipeline數(shù)據(jù)流，然后將ack queue中的packets添加到 data queue的前面以免發(fā)生packets數(shù)據(jù)包的丟失現(xiàn)象;

2)升級(jí)在正常的DataNode節(jié)點(diǎn)上的保存的block的ID版本，使得發(fā)生故障的DataNode節(jié)點(diǎn)上的block數(shù)據(jù)會(huì)在節(jié)點(diǎn)恢復(fù)正常后被刪除，同時(shí)也會(huì)從Pipeline中刪除失效節(jié)點(diǎn);

3)剩下的數(shù)據(jù)會(huì)被寫(xiě)入到Pipeline數(shù)據(jù)流管道中的其他正常的數(shù)據(jù)節(jié)點(diǎn)中。

2.4 事務(wù)故障恢復(fù)系統(tǒng)設(shè)計(jì)

云存儲(chǔ)系統(tǒng)事務(wù)的恢復(fù):對(duì)于云存儲(chǔ)系統(tǒng)事務(wù)來(lái)說(shuō)，因?yàn)樘幱诰W(wǎng)絡(luò)環(huán)境中，其恢復(fù)過(guò)程遠(yuǎn)遠(yuǎn)要比集中式數(shù)據(jù)庫(kù)復(fù)雜的多，在云存儲(chǔ)系統(tǒng)事務(wù)恢復(fù)中，本地事務(wù)的恢復(fù)類(lèi)同集中式事務(wù)的恢復(fù)。而整個(gè)云存儲(chǔ)系統(tǒng)事務(wù)的恢復(fù)由云存儲(chǔ)系統(tǒng)管理器與本地事務(wù)管理器協(xié)同完成。圖6是本系統(tǒng)的全局事務(wù)恢復(fù)模型。

圖6 云存儲(chǔ)系統(tǒng)事務(wù)恢復(fù)模型

3 目錄存儲(chǔ)與負(fù)載均衡設(shè)計(jì)

系統(tǒng)目錄存儲(chǔ)和管理是將系統(tǒng)的目錄分為若干個(gè)組，即前面所提到的按地域分組的方式。在每個(gè)組內(nèi)，由Master指定一個(gè)節(jié)點(diǎn)專(zhuān)門(mén)提供目錄服務(wù)，它本身也是一個(gè)普通節(jié)點(diǎn)，只是根據(jù)系統(tǒng)的設(shè)置成為一個(gè)為系統(tǒng)提供目錄服務(wù)的組服務(wù)器，Master同時(shí)會(huì)將所有存儲(chǔ)目錄的節(jié)點(diǎn)的地址和編號(hào)信息通知所有節(jié)點(diǎn)。每個(gè)節(jié)點(diǎn)根據(jù)自己的信息和Master提供的信息對(duì)有目錄的節(jié)點(diǎn)進(jìn)行排序。然后在目錄查詢(xún)的時(shí)候各個(gè)節(jié)點(diǎn)就能夠根據(jù)已知目錄節(jié)點(diǎn)信息進(jìn)行查詢(xún)，雖然這個(gè)節(jié)點(diǎn)的其他查詢(xún)?nèi)蝿?wù)也能執(zhí)行，但在設(shè)計(jì)系統(tǒng)負(fù)載平衡算法的時(shí)候，盡量減輕提供目錄查詢(xún)的節(jié)點(diǎn)的其他查詢(xún)?nèi)蝿?wù)。

按地區(qū)對(duì)來(lái)自客戶(hù)的訪(fǎng)問(wèn)進(jìn)行分類(lèi)，并且根據(jù)客戶(hù)的IP信息通過(guò)DNS進(jìn)行分流。而在同一地區(qū)的負(fù)載進(jìn)行輪轉(zhuǎn)法分流本地區(qū)的各個(gè)訪(fǎng)問(wèn)到本地區(qū)的不同數(shù)據(jù)節(jié)點(diǎn)上，同時(shí)保持Master和DNS之間的通信，Master根據(jù)節(jié)點(diǎn)自身反應(yīng)的信息對(duì)DNS中的各個(gè)節(jié)點(diǎn)的權(quán)值進(jìn)行調(diào)整，及時(shí)調(diào)整系統(tǒng)的負(fù)載平衡。

4 結(jié)語(yǔ)

本文首先分析了Hadoop云計(jì)算平臺(tái)，在文件系統(tǒng)架構(gòu)層次中本系統(tǒng)盡量保持云計(jì)算平臺(tái)的各種優(yōu)勢(shì)，提出了一種基于Hadoop的海量大數(shù)據(jù)云存儲(chǔ)系統(tǒng)設(shè)計(jì)方案。對(duì)文件塊的可讀性特性方面進(jìn)行了改進(jìn)，并分析了實(shí)現(xiàn)應(yīng)用系統(tǒng)所需要的關(guān)鍵技術(shù)，為云計(jì)算海量數(shù)據(jù)存儲(chǔ)與管理提供了一種可行的關(guān)鍵技術(shù)方案。

[1]沈志榮，易樂(lè)天，舒繼武.大規(guī)模數(shù)據(jù)中心的數(shù)據(jù)存儲(chǔ)可靠性[J].中國(guó)計(jì)算機(jī)學(xué)會(huì)通訊，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]武海平，余宏亮，鄭緯民，等.聯(lián)網(wǎng)審計(jì)系統(tǒng)中海量數(shù)據(jù)的存儲(chǔ)與管理策略[J].計(jì)算機(jī)學(xué)報(bào)，2006，29(4):618 -624.

[6]崔杰，李陶深，蘭紅星.基于 Hadoop的海量數(shù)據(jù)存儲(chǔ)平臺(tái)設(shè)計(jì)與開(kāi)發(fā)[J].計(jì)算機(jī)研究與發(fā)展，2012，49(z1):12 -18.

[7]劉樹(shù)仁，宋亞奇，朱永利，等.基于 Hadoop的智能電網(wǎng)狀態(tài)監(jiān)測(cè)數(shù)據(jù)存儲(chǔ)研究[J].計(jì)算機(jī)科學(xué)，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年科技局應(yīng)用基礎(chǔ)研究計(jì)劃項(xiàng)目(CJ20120009);常州工學(xué)院2013年度校級(jí)科研基金項(xiàng)目(YN1316)

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

責(zé)任編輯:陳 亮