基于Redis的海量小文件分布式存儲方法研究＊

劉高軍，王帝澳

（北方工業(yè)大學(xué)信息工程學(xué)院，北京100144）

1 引言

小文件是現(xiàn)代社會傳輸和存儲信息的重要方式之一，使用規(guī)模不斷擴大，如通過電子郵件、即時通訊軟件快速地共享、分發(fā)信息。在主要的辦公系統(tǒng)中，小文件也是公司職員日常辦公和匯報工作的主要方式之一。用戶在使用中，不僅要求高速的處理速度，還要求存儲的可靠性。因此，海量小文件云存儲的研究具有重要的現(xiàn)實意義。

2 研究現(xiàn)狀

海量小文件存儲一般以HDFS（Hadoop Distributed File System）作為基礎(chǔ)平臺。HDFS是分布式的文件系統(tǒng)，通過廉價的多臺機器支持大規(guī)模數(shù)據(jù)集的大文件存儲，伸縮性強，解決了存儲空間的限制問題。同時，HDFS能提供高吞吐量的數(shù)據(jù)訪問，非常適合大規(guī)模數(shù)據(jù)集上的應(yīng)用，而且即使在出錯的情況下也能保證數(shù)據(jù)存儲的可靠性［1］。它假設(shè)計算元素和存儲會失敗，維護多個工作數(shù)據(jù)副本確保能夠針對失敗的節(jié)點重新分布處理；它以并行的方式工作，保證了處理的高效性［2，3］。但是，HDFS中小文件的存儲效率不高。采用NameNode維護文件路徑到數(shù)據(jù)塊的映射、數(shù)據(jù)塊到DataNode的映射，監(jiān)控DataNode的心跳和維護數(shù)據(jù)塊副本的個數(shù)［4］。當大量的小文件存儲到HDFS中時，NameNode會耗盡大部分內(nèi)存，造成存儲效率低下，限制了文件的訪問速度。

針對HDFS中小文件存取效率低下這一問題，目前國內(nèi)外一般采用合并的方法。趙曉永等［5］充分利用MP3文件自身豐富的元信息，提出了一種基于Hadoop的海量MP3文件存儲模型；Dong Bo等［6］針對BlueSky中課件的存儲和形式，通過文件合并和預(yù)讀機制，減輕了NameNode的負荷，同時改善了HDFS中存儲和訪問大量小文件的效率。以上的這些合并方法解決了小文件存儲的一部分問題，但其仍有待改善。（1）這種傳統(tǒng)的整合小文件的方法，需要占用主服務(wù)器內(nèi)存進行整理合并，主服務(wù)器的性能成了小文件整合優(yōu)化的瓶頸。（2）在小文件上傳到HDFS之后進行合并整理，這種二次整理的方式對每個小文件進行了兩次存盤操作，增加了磁盤I／O的負擔。

基于以上問題，首先，本文使用單獨的高內(nèi)存服務(wù)器緩存待合并的數(shù)據(jù)，提高管理節(jié)點的性能，避免了主服務(wù)器的瓶頸。在緩存服務(wù)器上采用Redis（Remote Dictionary Server）進行存儲，它是一個基于內(nèi)存的高性能Key／Value數(shù)據(jù)庫，周期性地把更新的數(shù)據(jù)寫入磁盤或把修改操作寫入追加的記錄文件，保證數(shù)據(jù)的持久化，其 Master-Slave（主從）同步的方式為用戶提供了高可用性和可靠的平臺［7］。其次，將第一次上傳的文件緩存在Redis上，僅需要在合并文件后進行一次存盤操作，減少了磁盤I／O。再次，用戶的文件上傳在內(nèi)存中進行，大幅度縮短了文件上傳的響應(yīng)時間。

3 優(yōu)化方案設(shè)計

本文設(shè)計的文件存儲方案是建立一個用戶與HDFS的中間平臺，處理接收文件的上傳、獲取和刪除操作。由于大文件可以直接高效地存儲在HDFS中，本平臺僅對小文件進行處理，對超過64 MB的大文件返回不接收標記。合并存儲方案如圖1所示，用戶通過Socket與應(yīng)用交互進行操作，用Redis緩存用戶文件，通過HDFS接口把緩存文件合并存儲在HDFS中的Sequence File中，并把元數(shù)據(jù)記錄在Redis中。

Figure 1 File consolidated storage solutions圖1 文件合并存儲方案

3.1 存儲結(jié)構(gòu)

Redis作為文件的緩存服務(wù)器，保存緩存文件內(nèi)容和元數(shù)據(jù)記錄，其緩存和元數(shù)據(jù)記錄結(jié)構(gòu)分別如表1和表2所示。

Table 1 Redis cache data storage structure表1 Redis中緩存數(shù)據(jù)的存儲結(jié)構(gòu)

Table 2 Redis file metadata structure表2 Redis中文件的元數(shù)據(jù)結(jié)構(gòu)

HDFS平臺上的存儲結(jié)構(gòu)為：基本目錄下存儲合并后的Sequence File，以時間戳命名。Sequence File采用順序存儲結(jié)構(gòu)，這樣就可以通過元數(shù)據(jù)中文件名對應(yīng)記錄的文件位置storepos快速定位小文件內(nèi)容。其中，Sequence File采用Block壓縮，以降低磁盤占用和提高傳輸速度。Block壓縮是將一連串的記錄，也就是這里的小文件組織到一起，統(tǒng)一壓縮成一個Block。Block信息主要存儲：塊所包含的記錄數(shù)、每條記錄Key長度的集合、每條記錄Key值的集合、每條記錄Value長度的集合和每條記錄Value值的集合。

3.2 文件操作

平臺在存儲結(jié)構(gòu)的基礎(chǔ)上，對文件的上傳、獲取和刪除操作的處理如下所示：

（1）文件上傳時，首先將上傳的小文件存入Redis的文件緩存中，方便用戶高速地讀取。當上傳的文件總量達到指定閾值時，在合適的時間把緩存文件合并為Sequence File存儲到HDFS中，以釋放內(nèi)存和保證文件存取的高容錯性和高效性，同時更新元數(shù)據(jù)記錄。

（2）文件獲取時，首先在上傳緩存中檢查讀取文件，其他的可根據(jù)元數(shù)據(jù)記錄讀取。在文件讀取過程中，由于采用Sequence File的Block壓縮，同步點在Block的兩端，需要從Block開頭遍歷到待獲取文件。其中，讀取遍歷過程中的文件的代價很小，獲取文件的代價跟遍歷的文件的數(shù)量正相關(guān)（在本文實驗中驗證）。另外，在高并發(fā)訪問時，依據(jù)Sequence File順序讀取的特點，每次從Block開始訪問時可能命中多個待獲取的文件，直接讀取會造成同一Block的多次讀取。因此，可采用緩存機制保存Block來提高讀取效率。

（3）文件刪除時，通過更改元數(shù)據(jù)記錄標識當前文件的刪除狀態(tài)。刪除后，在指定時間間隔對文件進行刪除檢查，對文件再次歸檔，避免大量未刪除的無效數(shù)據(jù)降低文件緩存的命中率，保證文件在讀取時的快速定位和文件空間的高使用率。

4 存儲平臺實現(xiàn)

根據(jù)以上提出的設(shè)計方案，平臺采用的實現(xiàn)結(jié)構(gòu)如圖2所示。在負載代價模型的基礎(chǔ)上，將小文件平臺分為基本處理和后臺處理兩部分。用戶通過平臺與Redis和Sequence File交互進行文件的基本處理，如上傳、修改和刪除；定時器結(jié)合基本操作觸發(fā)事件調(diào)用后臺處理保證系統(tǒng)的可靠和速度。其負載代價模型和基本處理、后臺處理的具體方式如下。

Figure 2 Storage platform architecture圖2 存儲平臺架構(gòu)實現(xiàn)

4.1 負載代價模型

作為一個完整的系統(tǒng)，在提高小文件存儲效率的同時，也應(yīng)該考慮到系統(tǒng)的負載狀況［8］。而在對現(xiàn)有的服務(wù)器資源的統(tǒng)計中，一般采用獨立的CPU或內(nèi)存的使用評估代價，并不全面。比如，高的CPU使用率是不會影響僅對內(nèi)存和磁盤I／O占用高的操作；而且，在實際使用中，線程操作對各類資源的使用要求也不能準確地評測。

為彌補傳統(tǒng)資源統(tǒng)計的不足，本文提出負載代價模型，以用戶的響應(yīng)時間估算標準，在實驗的基礎(chǔ)上根據(jù)統(tǒng)計數(shù)據(jù)進行分析，確定代價計算公式，更合理地評價多種因素的影響。其具體過程為：在實際系統(tǒng)正常運行時，對多類資源如CPU、內(nèi)存、磁盤I／O等進行實時統(tǒng)計，記錄執(zhí)行處理任務(wù)的線程后，為客戶服務(wù)的主線程的響應(yīng)時間，并在此基礎(chǔ)上進行分析，確定各因素的影響系數(shù)。這樣，避免了傳統(tǒng)的統(tǒng)計估算所缺乏的有效性，采用實際的系統(tǒng)測試保證了即使在不確定的各類環(huán)境資源要求下，也能可靠評測。

4.2 基本處理

基本處理實現(xiàn)平臺的基本操作，接收文件的上傳、獲取和刪除操作。文件上傳時，先將接收到的文件存入Redis中的文件緩存（CFH）中，更新CFH所存文件的長度CFHL。之后，判斷CFHL，若達到文件的合并大小，發(fā)送“可合并文件”的消息（CM）到后臺處理模塊，至此，文件上傳完成。文件讀取時，若在Redis的上傳緩存中則直接返回，否則通過緩存處理模塊讀取文件內(nèi)容并返回給客戶端。文件刪除時，首先判斷是否在CFH中，若存在則直接刪除，否則將元數(shù)據(jù)的status置為0，標記文件已被刪除。

文件獲取的緩存處理模塊實現(xiàn)為：當接到小文件讀取請求時，存入文件獲取隊列，讀取Sequence File，當讀取隊列中同一Block內(nèi)的所有文件獲取完成后結(jié)束，并將遍歷的所有小文件和訪問該文件所需遍歷的文件數(shù)N存入緩存。若緩存器滿，采用小文件緩存替換策略置換文件。

本方案結(jié)合Sequence File訪問的特點，在GD-SIZE算法基礎(chǔ)上，用公式（1）計算代價H，實現(xiàn)小文件緩存替換策略。一般的GD-SIZE算法［9］為：緩存器中的每個文檔都有相應(yīng)的代價H，當文檔被帶進緩存器時，該文檔的H值為文檔大小的倒數(shù)；發(fā)生置換時，H 值最小的文檔（Hmin）被換出，剩下的文檔的H 值變?yōu)橹脫Q前的H 值減去Hmin。依據(jù)Sequence File讀取的特點，單一Block內(nèi)讀取文件可能需要遍歷多次，GD-SIZE算法中采用的價值H并不能實際反映文檔的代價，文檔的代價與訪問該文件所遍歷的文件數(shù)N正相關(guān)。故可以把文件大小S的倒數(shù)乘以N（即公式（1））作為GD-SIZE算法的初始價值H，實現(xiàn)緩存替換。

4.3 后臺處理

后臺處理是在文件預(yù)處理完成的基礎(chǔ)上，為保證文件的可靠性、文件訪問的高效性，節(jié)省存儲空間進行的處理。具體操作為處理緩存與HDFS的同步和HDFS中Sequence File的整理，主要完成緩存文件的合并、保存和元數(shù)據(jù)更新操作。以下對后臺處理的基本流程、上傳合并模塊、刪除合并模塊進行說明。

4.3.1 基本流程

基本流程是觸發(fā)后臺處理的基本環(huán)節(jié)。為保證Redis中的緩存能及時地保存到HDFS中，在服務(wù)端設(shè)置合并定時器CTimer，當達到既定時間時，將合并時間到（CTU）的標記置為有效。同樣，設(shè)定文件刪除定時器DTimer，給處理模塊發(fā)送刪除檢測時間到達的消息（DTU）。當收到CM消息時，首先通過負載代價模型的公式計算負載，低于既定閾值的負載調(diào)用上傳合并模塊進行合并，否則判斷CTU是否有效，有效則進行文件合并，無效則不做處理。當收到DTU消息時，調(diào)用刪除模塊檢查刪除文件并進行文件合并。

4.3.2 上傳合并模塊

上傳合并模塊負責將緩存文件打包同步到HDFS中。首先，在Redis中重命名CFH為CFHB，保證新上傳的文件可繼續(xù)使用CFH緩存。用HDFS對文件進行合并壓縮儲存到HDFS中。然后，把所合并的文件的信息（包含存儲位置）記錄到元數(shù)據(jù)記錄集MH中。

4.3.3 刪除合并模塊

刪除合并模塊是將有標記刪除小文件的Sequence File進行整理合并。首先進行刪除合并檢查。在元數(shù)據(jù)記錄集中找到有效邏輯文件大小總和最小的前兩個存儲文件，若其文件大小總和小于既定閾值，則可進行文件刪除合并。然后，依次讀取兩個Sequence File內(nèi)容，讀取到有效的小文件內(nèi)容保存到新的Sequence File文件中，并刪除原文件，更新元數(shù)據(jù)記錄，完成刪除合并。

5 實驗

本實驗采用64位的CentOS作為操作系統(tǒng)，Hadoop為r1.1.1，單一NameNode節(jié)點，Redis為AOF（Append Only File）模式，即每秒進行一次數(shù)據(jù)保存。測試數(shù)據(jù)上，采用隨機生成的10萬個100KB的小文件進行存儲分析測試。實驗內(nèi)容如下：（1）確定建立負載代價模型及代價系數(shù)。（2）比較本方案與現(xiàn)有方法的文件合并磁盤I／O。（3）分析文件在Block中的遍歷個數(shù)對文件獲取代價的影響。（4）檢驗本方案的性能：分別在傳統(tǒng)的直接上傳到HDFS和本文實現(xiàn)的存儲平臺上，統(tǒng)計小文件上傳速度、10萬個小文件上傳后的文件獲取速度、文件刪除速度、內(nèi)存占用。

5.1 確定負載代價計算公式

為建立負載代價模型，確定負載代價公式，需要把各種因子對主線程的響應(yīng)時間的影響進行量化，可通過實驗數(shù)據(jù)采用多元線性回歸分析的方法［10］得到因子的影響系數(shù)，確定估算代價值的計算公式。在本系統(tǒng)中，CPU使用率（C）、內(nèi)存使用率（M）和磁盤I／O（D）對性能有主要影響，將其作為因變量，把用戶請求文件上傳的響應(yīng)時間（T）作為響應(yīng)變量，則多元回歸方程表達式為：

具體操作如下：首先，在平臺運行的集群的節(jié)點上分別在執(zhí)行多個對C、M、D影響較大的進程，達到不同的資源占用結(jié)果，并統(tǒng)計此時的文件上傳時間，統(tǒng)計結(jié)果如表3所示。

對結(jié)果進行回歸分析，可得k1＝0.257，k2＝0.332，k3＝0.103。為使用戶在100ms以內(nèi)能夠得到響應(yīng)，由C、M、D計算得出的響應(yīng)時間T應(yīng)小于100ms，以此作為負載的既定閾值。該實驗環(huán)境下，將k1、k2、k3的值輸入運行配置中，則當后臺處理收到CM消息時，用式（2）計算負載閾值。以下的實驗均在此條件下完成。

Table 3 Response time of the user request表3 用戶請求響應(yīng)時間

5.2 與現(xiàn)有的文件合并磁盤I／O的比較

搭建采用現(xiàn)有小文件合并的平臺，這里選取比較常用的HAR（Hadoop Archives）合并方式。分別采用HAR合并和本文小文件處理平臺上傳1萬個小文件，并分別統(tǒng)計上傳過程中磁盤512字節(jié)塊讀?。˙lk＿read）和寫入（Blk＿wrtn）的總數(shù)量。實驗得出，采用HAR合并文件的讀取數(shù)為2.19MBlk＿read，寫入數(shù)4.23MBlk＿wrtn，而采用小文件處理平臺的磁盤512字節(jié)塊的讀取和寫入分別為0.06MBlk＿read和2.31MBlk＿wrtn?？梢钥闯?，采用小文件處理模塊能有效地減少磁盤I／O，因為其在Redis中緩存小文件的方式可以避免未合并前的首次磁盤寫入和合并時的讀取，所有文件都減少了一次寫入和讀取。

5.3 文件獲取時Block遍歷數(shù)對獲取代價的影響分析

文件獲取代價在本系統(tǒng)中是緩存服務(wù)器獲取HDFS中小文件的代價。采用緩存機制條件下，同一文件多次獲取的代價不會一成不變，這里采用該文件的平均代價標識文件的代價，其平均代價為直接獲取代價和間接獲取代價的加權(quán)平均，計算公式如式（3）。當Block為1MB時，由于壓縮的影響，實際系統(tǒng)每個Block存儲15個左右的小文件。實驗在上傳完10萬小文件后進行。隨機抽取10個Block中的小文件在緩存服務(wù)器上直接讀取文件和同時讀取遍歷過程中的文件，記錄讀取文件的時間，并一直讀到Block結(jié)束，記錄小文件數(shù)，實驗結(jié)果如表4所示?？梢缘贸?，讀取遍歷過程中文件的代價比較小，僅多占用了1.5%的時間。其中，每次中間遍歷和獲取文件的總時間基本一致，平均值為2.07ms。以此平均值計算平均代價結(jié)果，如表4所示。由計算結(jié)果可以看出，平均代價隨遍歷數(shù)的增加而增加，呈正相關(guān)關(guān)系。

Table 4 Consideration of the file read表4 文件讀取代價

公式（3）中，H 為評價代價，TD為直接獲取時間，TS為同時遍歷文件時的獲取時間，TA為平均每次中間遍歷和獲取文件的總時間，NS為遍歷數(shù)，NA為Block文件數(shù)。

5.4 文件上傳速度

為排除不穩(wěn)定因素（如網(wǎng)速）的影響，隨機抽取10個小文件分別在標準HDFS中和采用優(yōu)化模塊的文件系統(tǒng)中進行上傳，所消耗的時間如圖3所示。

Figure 3 File upload time圖3 文件上傳的時間

可以看出，采用了小文件處理模塊后，文件上傳的時間明顯縮短，由傳統(tǒng)方式的平均478.1ms減少到平均62.3ms，節(jié)省了86.97%的時間。在采用小文件處理模塊的文件上傳中，用戶上傳文件的操作由原來HDFS內(nèi)存接收文件、寫入磁盤的操作精簡為直接Redis內(nèi)存接收文件，不再需要等待比較緩慢的寫入磁盤操作，上傳的速度明顯提高。

5.5 文件獲取速度

在10萬個小文件分別上傳后，分別進行不同Sequence File的讀取、同一Sequence File讀取的測試。

不同Sequence File的讀?。簭闹须S機抽取10個分到不同Sequence File的文件進行下載測試，獲取時間如圖4所示。10次獲取中傳統(tǒng)的和優(yōu)化的平均獲取時間分別為605.3ms和602.2ms，分到不同Sequence File文件的讀取速度并沒有明顯降低。

igure 4 Obtained small files from different sequence file圖4 不同Sequence File小文件獲取時間

同一Sequence File讀?。簭囊粋€Sequence File中抽取10個文件進行下載測試，其中，前5個為不同Block的文件，后5個為前5個Block隨機獲取的文件，其獲取時間如圖5所示。其中，分到同一Sequence File文件的讀取速度因第一次預(yù)讀有所提高。因Block緩存機制的影響，可命中緩存的后5個文件的讀取速度明顯提高。

Figure 5 Obtained small files from same sequence file圖5 從同一Sequence File中獲取文件時間

從以上兩種實驗的結(jié)果可以看出，該文件優(yōu)化的方式在隨機少量文件獲取時不會降低速度，但是，當在大量頻繁的文件讀取時，由于多次讀取同一個Sequence File和緩存機制，能大幅度地提高文件的獲取速度。

5.6 文件刪除速度

在10萬個小文件分別上傳后，隨機進行10次文件的刪除操作，統(tǒng)計結(jié)果如圖6所示。采用小文件合并模塊后的文件刪除和傳統(tǒng)的文件刪除平均刪除時間分別為25.3ms和25.2ms。從實驗可以看出，采用小文件合并模塊跟傳統(tǒng)方式的文件刪除速度基本一致。這是由于原HDFS采用內(nèi)存存儲元數(shù)據(jù)，刪除在修改元數(shù)據(jù)記錄后返回，本文中小文件合并模塊的處理方式跟其基本一致。

Figure 6 File deletion time圖6 文件刪除的時間

5.7 內(nèi)存占用

分別進行10萬小文件的上傳后，NameNode節(jié)點內(nèi)存占用的統(tǒng)計結(jié)果為：文件上傳前，內(nèi)存占用在5%。采用傳統(tǒng)方式直接上傳到HDFS后，內(nèi)存使用率上升到44%；采用比較常用的HAR文件合并方式進行文件合并后，內(nèi)存使用率僅提高到24%，而采用小文件合并模塊上傳到HDFS后，NameNode的內(nèi)存使用率僅提高到23%?？梢钥闯觯瑐鹘y(tǒng)的文件合并方式和本文的合并方式都在以大文件方式存儲，上傳完成后的內(nèi)存占用沒有較大的差別。在HDFS內(nèi)存使用率隨文件數(shù)量增加而增大的情況下，合并文件進行存儲能夠有效地降低內(nèi)存占用率。

在文件上傳過程中，對NameNode節(jié)點內(nèi)存占用進行統(tǒng)計：采用比較常用的HAR文件合并方式進行文件合并時，NameNode節(jié)點的最高內(nèi)存使用率為36%；采用本文的小文件合并模塊，Name-Node節(jié)點的內(nèi)存使用率比較平穩(wěn)，最高僅為26%。本文的小文件合并模塊使用獨立的緩存服務(wù)器，文件合并在NameNode節(jié)點外進行，因此其能有效地避免NameNode節(jié)點高內(nèi)存的消耗。

5.8 實驗總結(jié)

從以上實驗的結(jié)果可以看出，采用基于Redis的HDFS小文件合并存儲優(yōu)化方案能夠在保證不影響文件刪除速度和隨機獲取文件速度的基礎(chǔ)上，較大程度地提高了內(nèi)存的利用率，加快了文件的檢索速度，保證了文件的快速、可靠操作和保存。

6 結(jié)束語

本文從HDFS中海量小文件的存儲方式考慮，在可靠的HDFS文件系統(tǒng)上，進行小文件的存儲優(yōu)化設(shè)計和實現(xiàn)，結(jié)合Redis緩存機制有效地減少了NameNode節(jié)點的內(nèi)存占用率，相比傳統(tǒng)的HDFS文件合并方法，減少了磁盤I／O，加快了文件的上傳速度和在大量頻繁的文件讀取時的獲取速度。

［1］ Borthakur D.HDFS architecture guide［EB／OL］.［2012-12-15］.http：／／hadoop.apache.org／docs／r1.0.3／cn／hdfs＿design.html.

［2］ Ding Hui，Zhang Da-hua，Luo Zhi-ming.Hadoop-based mass data processing platform research［J］.Telecommunications Science，2011（9A）：205-210.（in Chinese）

［3］ Li Yuan-fang，Deng Shi-kun，Wen Yu-biao，et al.PageRank matrix partitioned algorithm using Hadoop-Map Reduce［J］.Computer Technology and Development，2011，21（8）：6-9.（in Chinese）

［4］ Cao Ning，Wu Zhong-hai，Liu Hong-zhi，et al.Improving downloading performance in Hadoop distributed file system［J］.Journal of Computer Applications，2010，30（8）：2060-2065.（in Chinese）

［5］ Zhao Xiao-yong，Yang Yang，Sun Li-li，et al.Hadoop-based storage architecture for mass MP3files［J］.Journal of Computer Applications，2012，32（6）：1724-1726.（in Chinese）

［6］ Dong Bo，Qiu Jie，Zheng Qing-hua，et al.A novel approach to improving the efficiency of storing and accessing small files on hadoop：A case study by power point files［C］∥Proc of the 2010IEEE International Conference on Services Computing，2010：65-72.

［7］ Wang Xin-yan.Memcached and Redis in the cache［J］.Journal of Wireless Internet Technology，2012（9）：8-9.（in Chinese）

［8］ Yu Si，Gui Xiao-lin，Huang Ru-wei，et al.Improving the storage efficiency of small files in cloud storage［J］.Journal of Xi’an Jiaotong University，2011，45（6）：59-63.（in Chinese）

［9］ Zuo Li-yun.Optimized schedule algorithm for proxy cache based on rule-driven model［J］.Computer Engineering，2009，35（24）：93-95.（in Chinese）

［10］ Ma Li-ping.Learning and use of modern statistical methods——Multiple linear regression analysis［J］.Beijing Statistical，2000（10）：38.（in Chinese）

附中文參考文獻：

［2］ 丁輝，張大華，羅志明.基于Hadoop的海量數(shù)據(jù)處理平臺研究［J］.電信科學(xué)，2011（9A）：205-210.

［3］ 李遠方，鄧世昆，聞玉彪，等.Hadoop-Map Reduce下的 PageRank矩陣分塊算法［J］.計算機技術(shù)與發(fā)展，2011，21（8）：6-9.

［4］ 曹寧，吳中海，劉宏志，等.HDFS下載效率的優(yōu)化［J］.計算機應(yīng)用，2010，30（8）：2060-2065.

［5］ 趙曉永，楊揚，孫莉莉，等.基于Hadoop的海量MP3文件存儲架構(gòu)［J］.計算機應(yīng)用，2012，32（6）：1724-1726.

［7］ 王心妍.Memcached和Redis在高速緩存方面的應(yīng)用［J］.無線互聯(lián)科技，2012（9）：8-9.

［8］ 余思，桂小林，黃汝維，等.一種提高云存儲中小文件存儲效率的方案［J］.西安交通大學(xué)學(xué)報，2011，45（6）：59-63.

［9］ 左利云.基于規(guī)則驅(qū)動模型的代理緩存優(yōu)化調(diào)度算法［J］.計算機工程，2009，35（24）：93-95.

［10］ 馬立平.現(xiàn)代統(tǒng)計分析方法的學(xué)與用——多元線性回歸分析［J］.北京統(tǒng)計，2000（10）：38.