本發(fā)明涉及復(fù)合存儲(chǔ)方法技術(shù)，尤其涉及一種云計(jì)算架構(gòu)下的混合云存儲(chǔ)方法。

背景技術(shù)：

隨著互聯(lián)網(wǎng)技術(shù)的不斷發(fā)展,數(shù)字信息時(shí)代的數(shù)據(jù)正在呈爆炸式增長(zhǎng),如何高效地存儲(chǔ)和處理海量數(shù)據(jù)成為一個(gè)亟待解決的問(wèn)題。憑借其開(kāi)源、易用的特點(diǎn),Ha-doop分布式平臺(tái)已成為管理和處理海量數(shù)據(jù)的首選方案。以Hadoop分布式文件系統(tǒng)(Hadoop dis-tributed file system,HDFS)為基本存儲(chǔ), 并通過(guò)Map-Reduce 計(jì)算框架提供各種服務(wù)，使得用戶可以在低廉硬件環(huán)境下搭建Hadoop集群，利用HBase等組件完成海量數(shù)據(jù)的處理和分析任務(wù) ，從而為超大數(shù)據(jù)集的處理及應(yīng)用提供了一種低成本的分布式存儲(chǔ)解決方案，因此，近年以來(lái)得到了特別廣泛的應(yīng)用。

HDFS 的主要工作對(duì)象是大文件，對(duì)于存儲(chǔ)海量小文件并不合適。 小文件指的是那些size 比HDFS 的 blocksize小得多的文件。HDFS 在存儲(chǔ)小文件時(shí)存在以下具體問(wèn)題。

（1） 海量的小文件勢(shì)必造成元數(shù)據(jù)的龐大，耗費(fèi)元數(shù)據(jù)服務(wù)器的內(nèi)存。這是因?yàn)镹amenode把文件系統(tǒng)的元數(shù)據(jù)放置在內(nèi)存中，所以文件系統(tǒng)所能容納的文件數(shù)目是由Namenode的內(nèi)存大小來(lái)決定。一般來(lái)說(shuō)，每一個(gè)文件、文件夾和Block需要占據(jù)150字節(jié)左右的空間，當(dāng)文件擴(kuò)展至數(shù)億級(jí)時(shí)，對(duì)于當(dāng)前硬件水平來(lái)說(shuō)就無(wú)法實(shí)現(xiàn)了。

（2） 小文件存儲(chǔ)和讀取效率不佳。 因?yàn)?HDFS設(shè)計(jì)初衷是便于存儲(chǔ)超大文件，具有較大的數(shù)據(jù)吞吐量，以一定延時(shí)為代價(jià)。 實(shí)驗(yàn)表明，HDFS 集群存儲(chǔ) 10 GByte 大文件的速度比存儲(chǔ) 10 GByte小文件的速度要快得多。 同時(shí)，無(wú)法對(duì)海量小文件實(shí)現(xiàn)有效管理，加上內(nèi)存容量的限制，海量小文件的訪問(wèn)效率嚴(yán)重下降。

技術(shù)實(shí)現(xiàn)要素：

為了解決以上問(wèn)題，本發(fā)明提出了一種云計(jì)算架構(gòu)下的混合云存儲(chǔ)方法。利用分布式列式數(shù)據(jù)庫(kù)HBase 直接存儲(chǔ)小文件，減少 HDFS 負(fù)擔(dān)。 將大、小文件分別處理，如果系統(tǒng)判別為小文件，則直接存儲(chǔ)于 HBase 數(shù)據(jù)庫(kù)中，HDFS 只處理其擅長(zhǎng)的大文件。

從上至下主要包括3層：用戶層、接入層、存儲(chǔ)層；下層為上一層提供相應(yīng)服務(wù)，用戶層采用 HTTP 協(xié)議與接入層進(jìn)行交互，而接入層通過(guò)文件接口來(lái)調(diào)用對(duì)外封裝好的類 UDDomian，并與 HBase 存儲(chǔ)層進(jìn)行交互；在存儲(chǔ)層中提供的文件接口為上一層提供服務(wù)，而 HBase 存儲(chǔ)則實(shí)現(xiàn)對(duì)文件信息和文件內(nèi)容的存儲(chǔ)。

接入層主要負(fù)責(zé)接收用戶的文件操作請(qǐng)求，并將請(qǐng)求轉(zhuǎn)發(fā)給相應(yīng)服務(wù)器，與存儲(chǔ)層交互進(jìn)行文件讀寫；接入層主要涉及 Up/Down Server 和 Proxy Server 兩類服務(wù)和 HBase 文件接口；Up/Down Server主要負(fù)責(zé)處理用戶端對(duì)文件的第一類操作，即上傳、下載操作，并與 HBase 文件接口、存儲(chǔ)層進(jìn)行文件交互，此外，也會(huì)和底層的 HDFS 存儲(chǔ)層進(jìn)行數(shù)據(jù)讀、寫交互。

該方法可以實(shí)現(xiàn)海量小文件的高效存儲(chǔ),提高HDFS環(huán)境下小文件的讀寫效率。從而達(dá)到了整個(gè)大數(shù)據(jù)處理集群對(duì)大文件和小文件處理效率性能相當(dāng)?shù)睦硐胄Ч?/p>

附圖說(shuō)明

圖1是本發(fā)明的整體架構(gòu)示意圖；

圖2是本發(fā)明的文件存儲(chǔ)流程圖；

圖3是本發(fā)明的文件讀取流程圖。

具體實(shí)施方式

下面對(duì)本發(fā)明的內(nèi)容進(jìn)行更加詳細(xì)的闡述：

本發(fā)明整體架構(gòu)如圖一所示，詳細(xì)流程如圖二、圖三所示，其具體實(shí)現(xiàn)方案如下：

（一）整體架構(gòu)

該架構(gòu)從上至下主要包括3層：用戶層、接入層、存儲(chǔ)層。 下層為上一層提供相應(yīng)服務(wù)，用戶層采用 HTTP 協(xié)議與接入層進(jìn)行交互，而接入層通過(guò)文件接口來(lái)調(diào)用對(duì)外封裝好的類 UDDomian，并與 HBase 存儲(chǔ)層進(jìn)行交互。 在存儲(chǔ)層中提供的文件接口為上一層提供服務(wù)，而 HBase 存儲(chǔ)則實(shí)現(xiàn)對(duì)文件信息和文件內(nèi)容的存儲(chǔ)。

基于圖一的邏輯架構(gòu)，本文基于 HBase 的小文件存儲(chǔ)核心在于將大、小文件分別進(jìn)行處理，服務(wù)器接收到文件上傳請(qǐng)求后，如果是大文件，則按照傳統(tǒng)HDFS 方法進(jìn)行操作；而對(duì)于小文件，接入層的 Up/Down Server接口將通過(guò)存儲(chǔ)層的統(tǒng)一文件操作接口，將用戶“標(biāo)識(shí)符＿文件”上傳路徑作為row_key，其他文件信息作為內(nèi)容存儲(chǔ)到 HBase 數(shù)據(jù)庫(kù)表中。當(dāng)有用戶下載文件時(shí)，通過(guò) Up/Down Server端接收文件讀取請(qǐng)求，從而獲取用戶“標(biāo)識(shí)符＿文件”路徑信息，接入層的 Up/Down Server接口通過(guò)該信息與HBase交互并讀取文件內(nèi)容并返回給用戶。

（二）接入層設(shè)計(jì)

接入層主要負(fù)責(zé)接收用戶的文件操作請(qǐng)求，并將請(qǐng)求轉(zhuǎn)發(fā)給相應(yīng)服務(wù)器，與存儲(chǔ)層交互進(jìn)行文件讀寫。 接入層主要涉及 Up/Down Server 和 Proxy Server 兩類服務(wù)和 HBase 文件接口。 Up/Down Server主要負(fù)責(zé)處理用戶端對(duì)文件的第一類操作，即上傳、下載操作，并與 HBase 文件接口、存儲(chǔ)層進(jìn)行文件交互，此外，也會(huì)和底層的 HDFS 存儲(chǔ)層進(jìn)行數(shù)據(jù)讀、寫交互。 Proxy Server主要負(fù)責(zé)處理用戶端對(duì)文件的第二類操作，包括遍歷文件目錄、創(chuàng)建目錄、刪除目錄、拷貝文件、刪除文件、重命名文件等操作；并與 HBase 文件接口進(jìn)行交互。

（三）文件讀寫

1)文件存儲(chǔ)

基于圖二的流程圖，首先判斷文件大小，對(duì)大小文件分別處理，當(dāng)通過(guò)接入層后，大文件直接存儲(chǔ)于 HDFS 中，小文件則存儲(chǔ)于 HBase 數(shù)據(jù)表中。 詳細(xì)步驟如下。

步驟 1 用戶上傳待存儲(chǔ)的文件。

步驟 2 接入層 Up/Down Server 判斷文件大小，當(dāng)文件大小大于設(shè)定閾值，轉(zhuǎn)步驟 4；否則，轉(zhuǎn)步驟 3。

步驟 3 Up/Down Server 端進(jìn)一步對(duì)文件請(qǐng)求進(jìn)行解析，從請(qǐng)求中獲取用戶標(biāo)識(shí)符、文件上傳路徑等信息，在存儲(chǔ)層的 HBase 記錄表中進(jìn)行檢索，如有記錄存在，則表明目標(biāo)上傳路徑中已上傳有相同文件名的文件，此時(shí)，向用戶層返回提示信息，提示用戶端已上傳文件。 否則Up/Down Server端向 HBase 存儲(chǔ)層發(fā)起創(chuàng)建相應(yīng)文件記錄和寫入文件的請(qǐng)求。 轉(zhuǎn)步驟 5。

步驟 4 Up/Down Server 端直接調(diào)用 HDFS 文件寫入接口進(jìn)行操作。

步驟 5 將文件信息寫入

2)文件讀取

基于圖三的流程圖，根據(jù)用戶“ 標(biāo)識(shí)符＿文件”路徑與 HBase 文件存儲(chǔ)記錄表row_key的比較來(lái)實(shí)現(xiàn)文件讀取。

步驟 1 Up/Down Server 端接收文件讀取請(qǐng)求，獲取用戶“ 標(biāo)識(shí)符＿文件”的路徑信息，轉(zhuǎn)步驟 2。

步驟 2 Up/Down Server 端利用所獲得的信息在 HBase 數(shù)據(jù)表中進(jìn)行檢索，如果定位到用戶所請(qǐng)求讀取文件的記錄。 轉(zhuǎn)步驟 3，否則轉(zhuǎn)步驟 4。

步驟 3 Up/Down Server端讀取 HBase 文件記錄中的列簇，由索引層直接返回“文件內(nèi)容”列的數(shù)據(jù)給用戶端，讀取文件過(guò)程結(jié)束。

步驟 4 調(diào)用傳統(tǒng) HDFS。

基于 HDFS 的寫入速度為 20-30Mbyte/s，基于 HBase 的高效存儲(chǔ)方法的寫入速度為 50-70 Mbyte/s，這是因?yàn)樵趯懭胄∥募臅r(shí)候，基于 HBase 儲(chǔ)存方法是直接寫入HBase 數(shù)據(jù)表中，而基于 HDFS 還需要管理元數(shù)據(jù)和數(shù)據(jù)塊等信息，所以，本文提出的方法在寫入速度上有較大提升。

在小文件讀取方面，基于 HDFS 讀取速度為 40-50 Mbyte/s，基于 HBase 的高效存儲(chǔ)方法讀取速度為 100-110 Mbyte/s，HDFS 需要先訪問(wèn)元數(shù)據(jù)，再與 datanode 交互進(jìn)行讀取，而 HBase 利用其自身索引機(jī)制，能夠?qū)?shù)據(jù)表中信息進(jìn)行快速讀取。 實(shí)驗(yàn)結(jié)果表明，在小文件讀寫方面，本文提出的基于 HBase 的小文件高效存儲(chǔ)方法比 HDFS 平均讀取速度有顯著提高，寫入速度提升也明顯。