Redis分布式緩存技術(shù)在Hadoop平臺(tái)上的應(yīng)用

姚經(jīng)緯,楊福軍

(1.江南大學(xué) 物聯(lián)網(wǎng)工程學(xué)院,江蘇 無錫 214122; 2.中國(guó)空氣動(dòng)力研究與發(fā)展中心 計(jì)算空氣動(dòng)力研究所,四川 綿陽(yáng) 621000)

Redis分布式緩存技術(shù)在Hadoop平臺(tái)上的應(yīng)用

姚經(jīng)緯1,楊福軍2

(1.江南大學(xué) 物聯(lián)網(wǎng)工程學(xué)院,江蘇 無錫 214122; 2.中國(guó)空氣動(dòng)力研究與發(fā)展中心 計(jì)算空氣動(dòng)力研究所,四川 綿陽(yáng) 621000)

在使用Hadoop進(jìn)行大規(guī)模數(shù)據(jù)分析時(shí)，經(jīng)常會(huì)遇到的一個(gè)較為典型的問題就是共享數(shù)據(jù)的快速訪問問題。該類問題存在的場(chǎng)景很多，如網(wǎng)頁(yè)排名算法、最小錯(cuò)誤率訓(xùn)練算法、最大期望算法等。雖然已有關(guān)于此類問題的解決方案，但實(shí)際取得的效果卻不盡如人意。為此，提出了使用Redis內(nèi)存數(shù)據(jù)庫(kù)作為分布式緩存，以解決Hadoop中共享數(shù)據(jù)訪問的問題。驗(yàn)證實(shí)驗(yàn)結(jié)果表明，Redis分布式緩存的吞吐率與集群規(guī)模有較好的線性關(guān)系，所提出的方法能夠較好地解決Hadoop任務(wù)對(duì)共享數(shù)據(jù)的訪問問題，同時(shí)也為其他大規(guī)模共享數(shù)據(jù)訪問的問題提供了簡(jiǎn)便的解決思路。Redis作為開源的商業(yè)化工具，使得所提出的方法具有較好的適用性，可為科研以及生產(chǎn)實(shí)踐中遇到的同類問題提供一種較為通用的解決方案。

Redis;分布式緩存;Hadoop;MapReduce

0 引 言

隨著信息技術(shù)的飛速發(fā)展，互聯(lián)網(wǎng)數(shù)據(jù)量也呈現(xiàn)出爆炸式增長(zhǎng)，進(jìn)入了大數(shù)據(jù)時(shí)代[1]。對(duì)于日益增長(zhǎng)的海量數(shù)據(jù)處理，傳統(tǒng)的數(shù)據(jù)處理方式已無法支持如此龐大的數(shù)據(jù)量，因而云計(jì)算技術(shù)應(yīng)運(yùn)而生。在諸多云計(jì)算平臺(tái)中，Hadoop憑借其開源、廉價(jià)等優(yōu)勢(shì)，在大數(shù)據(jù)的存儲(chǔ)和處理等方面應(yīng)用廣泛[2]，很多互聯(lián)網(wǎng)企業(yè)，如亞馬遜、阿里巴巴、中國(guó)移動(dòng)等都紛紛使用Hadoop作為自己的數(shù)據(jù)處理平臺(tái)。Hadoop的核心主要是HDFS(分布式文件系統(tǒng))和MapReduce分布式數(shù)據(jù)處理框架；除此之外，還有很多基于Hadoop的工具，如：HBase分布式數(shù)據(jù)庫(kù)、Hive數(shù)據(jù)倉(cāng)庫(kù)分析工具、Spark流式數(shù)據(jù)處理框架等[3]。

Hadoop的出現(xiàn)大大簡(jiǎn)化了分布式程序設(shè)計(jì)，使用者只需要簡(jiǎn)單地將數(shù)據(jù)處理應(yīng)用分解為Mapper和Reducer，就可以使之運(yùn)行在Hadoop集群上，而不用關(guān)心各節(jié)點(diǎn)之間如何通信、如何傳遞數(shù)據(jù)等底層實(shí)現(xiàn)[4]。然而，Hadoop在實(shí)際使用中仍然存在一系列問題亟待解決，任務(wù)節(jié)點(diǎn)如何快速訪問海量共享數(shù)據(jù)則是其中一個(gè)較為典型的問題。

針對(duì)Hadoop任務(wù)節(jié)點(diǎn)如何快速訪問海量共享數(shù)據(jù)的問題，基于對(duì)典型實(shí)例的闡述和分析，提出了使用Redis作為分布式緩存解決共享數(shù)據(jù)的訪問問題。并以PageRank算法為例，研究分析了如何使用Redis解決PageRank算法中網(wǎng)頁(yè)得分?jǐn)?shù)據(jù)的存儲(chǔ)和訪問問題，通過實(shí)驗(yàn)對(duì)該方法的可行性和效率進(jìn)行了驗(yàn)證，并為其他相似問題的解決提供了思路。

1 MapReduce和Redis簡(jiǎn)介

1.1 MapReduce框架

MapReduce[5]最先是由Google公司的Jeffrey Dean和Sanjay Ghemawat提出的一種用于解決大數(shù)據(jù)并行計(jì)算問題的編程模型。后來Apache基金會(huì)的Doug Cutting在Hadoop項(xiàng)目中實(shí)現(xiàn)了該模型并將其開源，大大推動(dòng)了MapReduce框架的研究和發(fā)展。MapReduce程序以鍵值對(duì)的形式進(jìn)行輸入輸出，其具體執(zhí)行步驟如下：

(1)任務(wù)分配：JobTracker將整個(gè)作業(yè)分解為多個(gè)任務(wù)，并分配到任務(wù)數(shù)據(jù)所在的節(jié)點(diǎn)上，由各節(jié)點(diǎn)的TaskTracker負(fù)責(zé)任務(wù)執(zhí)行。

(2)Map階段：任務(wù)節(jié)點(diǎn)將當(dāng)前節(jié)點(diǎn)上的數(shù)據(jù)塊解析為鍵值對(duì)輸入到Map函數(shù)中，Map函數(shù)對(duì)輸入進(jìn)行過濾和轉(zhuǎn)換，再以集合list()的形式輸出并保存為中間結(jié)果。

(3)洗牌：將鍵k2相同的記錄發(fā)送到同一個(gè)Reduce任務(wù)節(jié)點(diǎn)上。

(4)Reduce階段：任務(wù)節(jié)點(diǎn)將所有鍵k2相同的記錄以鍵值對(duì))>的形式輸入到Reduce函數(shù)中，Reduce函數(shù)對(duì)輸入進(jìn)行計(jì)算處理后，再以結(jié)果集list()的形式輸出。

(5)作業(yè)結(jié)束：當(dāng)所有Map任務(wù)和Reduce任務(wù)結(jié)束后，整個(gè)作業(yè)結(jié)束。

在MapReduce編程中，編程人員只需根據(jù)業(yè)務(wù)編寫Map函數(shù)和Reduce函數(shù)就可以實(shí)現(xiàn)比較復(fù)雜的并行計(jì)算作業(yè)，而不用關(guān)心各節(jié)點(diǎn)之間如何通信、如何傳遞數(shù)據(jù)等底層實(shí)現(xiàn)，大大簡(jiǎn)化了并行編程的復(fù)雜度。MapReduce程序還具有很好的可擴(kuò)展性，在大多數(shù)情形下，它不僅可以隨著數(shù)據(jù)規(guī)模的擴(kuò)大表現(xiàn)出持續(xù)的有效性，而且在性能上能隨著節(jié)點(diǎn)數(shù)的增加保持接近線性的增長(zhǎng)。同時(shí)，MapReduce還具有低成本和高可靠性等眾多特征，使其從一開始就受到了學(xué)術(shù)界和商業(yè)界的極大關(guān)注[4]。

1.2 Redis內(nèi)存數(shù)據(jù)庫(kù)

Redis[6]是一種基于內(nèi)存的Key-Value數(shù)據(jù)庫(kù)產(chǎn)品，是由遠(yuǎn)程字典服務(wù)(Remote dictionary server)取名而來。它支持多種數(shù)據(jù)類型的存儲(chǔ)：字符串(string)、鏈表(list)、集合(set)、有序集合(zset)和哈希類型(hash)，并且各種類型都支持豐富的操作，其中大多都支持原子操作。為了保證數(shù)據(jù)存取的效率，數(shù)據(jù)都保存在內(nèi)存中；Redis還提供了對(duì)持久化的支持，它可以定期將更新的數(shù)據(jù)異步寫入磁盤，同時(shí)不影響繼續(xù)提供服務(wù)；在此基礎(chǔ)上，還實(shí)現(xiàn)了主從復(fù)制，這對(duì)預(yù)防單點(diǎn)故障和提高負(fù)載能力有很大幫助。Redis的出現(xiàn)，在很大程度上彌補(bǔ)了Memcached的不足，它不僅支持更加豐富的數(shù)據(jù)類型和操作，而且在讀寫效率上也比Memcached更勝一籌。根據(jù)Redis官方測(cè)試數(shù)據(jù)，Redis寫入速率為198 412.69條/s，讀速率為198 019.80條/s[7]，相比Memcached要高出數(shù)倍。Redis具有如此多的優(yōu)秀特性，使其從一開始就受到了廣泛關(guān)注，Redis可以適用于多種不同的應(yīng)用場(chǎng)景，很多大型互聯(lián)網(wǎng)企業(yè)的后臺(tái)服務(wù)中都有使用，并且存在不少成功應(yīng)用的范例。

雖然Redis讀寫性能非常優(yōu)秀，但是因?yàn)閮?nèi)存容量的限制，僅使用單臺(tái)服務(wù)器一般是不夠的，這就需要使用集群的形式進(jìn)行水平擴(kuò)容。在舊版Redis中通常使用客戶端分片來構(gòu)建集群，但這種方式有很多缺點(diǎn)，比如維護(hù)成本高，增加、移除節(jié)點(diǎn)較繁瑣等；但Redis 3.0版的發(fā)布解決了這一問題，因?yàn)樗黾恿藢?duì)集群的原生支持。Redis集群采用無中心架構(gòu)，各節(jié)點(diǎn)間使用Gossip協(xié)議進(jìn)行通信；在對(duì)數(shù)據(jù)的分配上使用預(yù)分桶的策略，將每個(gè)鍵的鍵名有效部分使用CRC16算法計(jì)算出散列值，然后對(duì)16 384取余，使得每個(gè)鍵都可以被分配到預(yù)先分配好的16 384個(gè)插槽，進(jìn)而在對(duì)應(yīng)的節(jié)點(diǎn)中進(jìn)行處理；集群具有較高的可用性，它采用主-從形式，確保當(dāng)主節(jié)點(diǎn)失效后可以將一個(gè)從節(jié)點(diǎn)轉(zhuǎn)變?yōu)橹鞴?jié)點(diǎn)，以此確保集群的完整性和可用性[8]。Redis集群的這些特性使得能夠很方便地將其作為分布式緩存使用。

2 問題探討

Hadoop在生產(chǎn)實(shí)踐中被廣泛應(yīng)用于大數(shù)據(jù)的存儲(chǔ)和處理，并且存在很多成功應(yīng)用的典范。但是在實(shí)際應(yīng)用中也暴露出一些問題，其中一個(gè)較為典型的就是任務(wù)節(jié)點(diǎn)如何快速訪問海量共享數(shù)據(jù)的問題。存在該類問題的算法和情景不在少數(shù)，這里僅列舉三個(gè)典型對(duì)該類問題進(jìn)行簡(jiǎn)單闡述。

2.1 網(wǎng)頁(yè)排名算法

網(wǎng)頁(yè)排名算法(PageRank)[9-10]是由Google創(chuàng)始人Sergey Brin和Lawrence Page提出的用于在搜索引擎上對(duì)網(wǎng)頁(yè)進(jìn)行排名，以此體現(xiàn)網(wǎng)頁(yè)重要性的一種算法。該算法初始時(shí)為每個(gè)網(wǎng)頁(yè)設(shè)置一個(gè)得分，經(jīng)過多次迭代不斷更新各網(wǎng)頁(yè)的得分，最終各網(wǎng)頁(yè)得分收斂時(shí)算法結(jié)束。在每次迭代中，都需要根據(jù)每個(gè)網(wǎng)頁(yè)的得分給所有鏈出網(wǎng)頁(yè)打分，每個(gè)網(wǎng)頁(yè)根據(jù)所有鏈入網(wǎng)頁(yè)給出的打分，計(jì)算并更新自己的得分。在Hadoop上運(yùn)行該算法時(shí)，網(wǎng)頁(yè)得分?jǐn)?shù)據(jù)是所有任務(wù)的共享數(shù)據(jù)，在每個(gè)任務(wù)中都需要獲取和更新網(wǎng)頁(yè)得分?jǐn)?shù)據(jù)，因此網(wǎng)頁(yè)得分?jǐn)?shù)據(jù)的訪問效率會(huì)直接影響算法的執(zhí)行效率。而且在實(shí)際應(yīng)用中，網(wǎng)頁(yè)得分?jǐn)?shù)據(jù)往往會(huì)達(dá)到數(shù)百億條，因此，如何存儲(chǔ)和訪問網(wǎng)頁(yè)得分?jǐn)?shù)據(jù)則是接下來所主要討論的問題。

2.2 最小錯(cuò)誤率訓(xùn)練算法

最小錯(cuò)誤率訓(xùn)練算法(MERT)[11]是由Franz Josef Och提出的一種在機(jī)器翻譯中以翻譯質(zhì)量為優(yōu)化目標(biāo)，以此調(diào)節(jié)對(duì)數(shù)線性模型參數(shù)的算法。該算法初始時(shí)生成翻譯候選和對(duì)應(yīng)特征權(quán)重，經(jīng)過多次迭代不斷對(duì)其進(jìn)行更新，直到不再產(chǎn)生新的翻譯候選時(shí)算法結(jié)束。每次迭代中使用解碼器對(duì)翻譯候選進(jìn)行解碼，生成新的翻譯候選與之前的合并，并在擴(kuò)展的候選集上重新調(diào)整特征權(quán)重。在Hadoop上運(yùn)行MERT算法時(shí)，特征權(quán)重?cái)?shù)據(jù)是所有任務(wù)的共享數(shù)據(jù)，其訪問效率會(huì)直接影響到算法的執(zhí)行效率。實(shí)際應(yīng)用中，特征權(quán)重?cái)?shù)據(jù)也可能會(huì)達(dá)到數(shù)十億條，那么又該如何解決數(shù)據(jù)的存儲(chǔ)和訪問問題。

2.3 最大期望算法

最大期望算法(EM)[12]是由Arthur Dempster等提出的在已知部分相關(guān)變量的情況下，尋找未知變量的最大似然估計(jì)或最大后驗(yàn)估計(jì)的算法，在數(shù)據(jù)挖掘領(lǐng)域的聚類算法中應(yīng)用廣泛。以基于高斯混合模型的EM算法為例，它分為兩個(gè)階段交替執(zhí)行直到模型參數(shù)趨于收斂：

(1)步驟：根據(jù)數(shù)據(jù)集和模型參數(shù)計(jì)算對(duì)數(shù)似然函數(shù)的條件期望；

(2)更新模型參數(shù)，使對(duì)數(shù)似然函數(shù)期望最大化。

在Hadoop上運(yùn)行EM算法時(shí)，模型參數(shù)為所有任務(wù)所共享，其訪問效率同樣會(huì)直接影響算法的執(zhí)行效率。同樣，當(dāng)模型參數(shù)數(shù)據(jù)量過大時(shí)，又該如何解決數(shù)據(jù)的存儲(chǔ)和訪問問題。

上述三類問題都涉及到任務(wù)節(jié)點(diǎn)如何訪問共享數(shù)據(jù)這一共性問題。雖然Hadoop提供了分布式文件緩存機(jī)制，可以將共享文件拷貝到每個(gè)任務(wù)節(jié)點(diǎn)并裝載到內(nèi)存中以實(shí)現(xiàn)數(shù)據(jù)的共享，該方法確實(shí)可以在一定程度上解決上述問題；但是當(dāng)共享文件過大無法正常裝載到任務(wù)節(jié)點(diǎn)的內(nèi)存中時(shí)，該方法就不再適用，這在實(shí)際應(yīng)用中并不罕見；況且，對(duì)每一個(gè)任務(wù)節(jié)點(diǎn)來說，它所需要的數(shù)據(jù)可能僅僅是全部共享數(shù)據(jù)的一小部分，這種情況下將全部共享數(shù)據(jù)拷貝到任務(wù)節(jié)點(diǎn)上不僅浪費(fèi)網(wǎng)絡(luò)和內(nèi)存資源，而且還可能拖慢任務(wù)的執(zhí)行。因此，提出了使用Redis內(nèi)存數(shù)據(jù)庫(kù)作為分布式緩存，實(shí)現(xiàn)在Hadoop任務(wù)節(jié)點(diǎn)間快速獲取共享數(shù)據(jù)的方法，從而更好地解決上述問題。

3 解決方案

根據(jù)討論中提及的三個(gè)問題，需要一種能夠在Hadoop任務(wù)節(jié)點(diǎn)間快速獲取共享數(shù)據(jù)的機(jī)制，并且必須滿足以下條件：

(1)鍵必須保證全局唯一性；

(2)必須能夠支持大規(guī)模的數(shù)據(jù)存儲(chǔ)；

(3)必須確保在高并發(fā)量前提下數(shù)據(jù)訪問的高效性。

Redis內(nèi)存數(shù)據(jù)庫(kù)的特性剛好滿足上述需求[13]，因此，提出子在Hadoop中引入Redis分布式緩存來解決共享數(shù)據(jù)的存儲(chǔ)和訪問問題。

使用Redis作為分布式緩存，需要確保Hadoop集群中各節(jié)點(diǎn)都能同等地訪問Redis中存儲(chǔ)的數(shù)據(jù)，因此，采用圖1的架構(gòu)方式。這種將Hadoop集群與Redis分布式緩存直接相連的方式，不僅在實(shí)現(xiàn)上比較簡(jiǎn)單，而且也最大程度地保證了數(shù)據(jù)存取的效率。對(duì)于分布式緩存的使用，一般分兩步進(jìn)行：

首先將HDFS上的共享數(shù)據(jù)加載到分布式緩存中。這一步并不需要用到Reduce，因此發(fā)起一個(gè)只有Map階段的作業(yè)即可完成，各Map任務(wù)可以并行地讀取數(shù)據(jù)，并保存到分布式緩存中。

當(dāng)分布式緩存數(shù)據(jù)準(zhǔn)備完成后，啟動(dòng)需要執(zhí)行的MapReduce作業(yè)。各任務(wù)節(jié)點(diǎn)在初始化時(shí)使用Jedis客戶端建立起到Redis集群的連接，這樣，在任務(wù)執(zhí)行中需要訪問緩存時(shí)就可以隨時(shí)通過連接讀寫共享數(shù)據(jù)。

圖1 Hadoop與Redis分布式緩存架構(gòu)圖

為了進(jìn)一步闡述問題，并驗(yàn)證Redis作為分布式緩存的性能，以網(wǎng)頁(yè)排名算法為例，闡述Redis分布式緩存在Hadoop任務(wù)中的應(yīng)用。在實(shí)例中使用原始的網(wǎng)頁(yè)排名算法進(jìn)行闡述，一方面，研究的主要目的在于使用Redis分布式緩存解決大規(guī)模共享數(shù)據(jù)問題，而非僅僅論述網(wǎng)頁(yè)排名算法的優(yōu)化問題，對(duì)網(wǎng)頁(yè)排名算法的優(yōu)化不作為研究重點(diǎn)；另一方面，對(duì)網(wǎng)頁(yè)排名算法的優(yōu)化大都集中于如何減少迭代次數(shù)或如何在每次迭代中減少需要處理的數(shù)據(jù)等方面，優(yōu)化后的算法仍可能出現(xiàn)上述問題，而原始的網(wǎng)頁(yè)排名算法具有很好的代表性，能夠較簡(jiǎn)明地說明問題。

網(wǎng)頁(yè)排名算法計(jì)算網(wǎng)頁(yè)排名基于以下兩個(gè)基本假設(shè)：

(1)數(shù)量假設(shè)：一個(gè)具有較多鏈入的網(wǎng)頁(yè)會(huì)有較高得分。

(2)質(zhì)量假設(shè)：一個(gè)得分較高的網(wǎng)頁(yè)能夠給其鏈出的網(wǎng)頁(yè)打出較高的分?jǐn)?shù)。

根據(jù)這兩個(gè)假設(shè)，可得[9]：

(1)

其中，pi和pj表示兩個(gè)不同的網(wǎng)頁(yè)；PR(pi)和PR(pj)分別表示pi和pj的得分；M(pi)表示所有鏈入pi的網(wǎng)頁(yè)集合;L(pj)表示pj鏈出的網(wǎng)頁(yè)數(shù)目;N表示全部網(wǎng)頁(yè)數(shù)目;d表示阻尼系數(shù)(表示用戶到達(dá)某網(wǎng)頁(yè)后繼續(xù)向后瀏覽的概率，一般取0.85)。

網(wǎng)頁(yè)排名算法計(jì)算網(wǎng)頁(yè)得分是一個(gè)迭代計(jì)算的過程。初始時(shí)賦予每個(gè)網(wǎng)頁(yè)相同的得分，在之后的每次迭代中，使用式(1)更新得分，直到所有網(wǎng)頁(yè)得分穩(wěn)定時(shí)算法終止。

使用Redis作為分布式緩存，在Hadoop上實(shí)現(xiàn)網(wǎng)頁(yè)排名迭代算法的步驟如下：

(1)原始數(shù)據(jù)的預(yù)處理。對(duì)原始數(shù)據(jù)進(jìn)行處理，生成符合格式要求的網(wǎng)頁(yè)鏈接數(shù)據(jù)文件，并保存到HDFS中。網(wǎng)頁(yè)鏈接數(shù)據(jù)文件的每行第一列表示當(dāng)前網(wǎng)頁(yè)鏈接地址，后面的各列表示當(dāng)前網(wǎng)頁(yè)所有鏈出的網(wǎng)頁(yè)地址，各列以Tab鍵分隔，后文出現(xiàn)的網(wǎng)頁(yè)鏈接數(shù)據(jù)，如無特別說明，都使用該格式。

(2)初始化網(wǎng)頁(yè)得分?jǐn)?shù)據(jù)并保存到Redis中。啟動(dòng)一個(gè)只有Map階段的作業(yè)用來讀取網(wǎng)頁(yè)鏈接數(shù)據(jù)，Map函數(shù)中，將當(dāng)前的鍵(url)和初始化得分(score)以鍵值對(duì)的形式保存到Redis分布式緩存中。Map函數(shù)的偽代碼如下：

1 //key：當(dāng)前網(wǎng)頁(yè)的鏈接地址；value：以Tab鍵分隔的所有鏈出地址

2 Map(key,value) {

3 init = 0.5; //默認(rèn)初始得分

4 setToRedis(key,init); //將鍵值對(duì)保存到Redis分布式緩存中

5 }

(3)使用一次MapReduce作業(yè)完成網(wǎng)頁(yè)排名算法的一次迭代。在每次迭代的Map函數(shù)中，從分布式緩存中獲取當(dāng)前網(wǎng)頁(yè)得分(score)，將該得分平均分配給各鏈出地址(url，共n個(gè))作為對(duì)該鏈接的打分，并以鍵值對(duì)輸出。Map函數(shù)的偽代碼如下：

1 //key：當(dāng)前網(wǎng)頁(yè)的鏈接地址；value：以Tab鍵分隔的所有鏈出地址

2 Map(key,value) {

3 //根據(jù)鍵從Redis分布式緩存中獲取相應(yīng)的值

4 score=getFromRedis(key);

5 urls=value.split(" ");//將value以Tab鍵分割得到數(shù)組

6 for(url :urls) {

7 context.write(url,score/urls.length);//Map的輸出

8 }

9 }

在每次迭代的Reduce函數(shù)中，將其他網(wǎng)頁(yè)給本網(wǎng)頁(yè)(url)的打分計(jì)算匯總后得出本網(wǎng)頁(yè)的得分(score)，并以鍵值對(duì)的形式保存到Redis分布式緩存中。Reduce函數(shù)的偽代碼如下：

1 //key：本網(wǎng)頁(yè)的鏈接地址；values：其他網(wǎng)頁(yè)給本網(wǎng)頁(yè)的打分集合

2 Reduce(key,values) {

3d=0.85; //阻尼系數(shù)

4 //sum(values)：對(duì)values集合進(jìn)行求和

5 score=(1-d)+d*sum(values);

6 setToRedis(key,score); //將鍵值對(duì)保存到Redis分布式緩存中

7 }

4 實(shí)驗(yàn)結(jié)果及分析

實(shí)驗(yàn)中使用9臺(tái)普通PC，每臺(tái)PC配置如下：3 GB內(nèi)存，酷睿2雙核CPU，500 GB硬盤，Ubuntu 14.04操作系統(tǒng)。實(shí)驗(yàn)使用Apache Hadoop 1.2.1，其中1臺(tái)作為NameNode和JobTracker，其他8臺(tái)作為DataNode；Redis版本3.0.7，分別搭建在8臺(tái)DataNode上，構(gòu)成一個(gè)8節(jié)點(diǎn)的Redis集群作為分布式緩存。

實(shí)驗(yàn)數(shù)據(jù)使用網(wǎng)絡(luò)爬蟲從互聯(lián)網(wǎng)上爬取，經(jīng)過過濾和預(yù)處理后得到符合格式要求的網(wǎng)頁(yè)鏈接數(shù)據(jù)。鏈接數(shù)據(jù)共包含36 323 864個(gè)網(wǎng)頁(yè)節(jié)點(diǎn)，大小約37 GB。實(shí)驗(yàn)按照第三節(jié)中的步驟進(jìn)行，作業(yè)執(zhí)行時(shí)間使用4次迭代的平均時(shí)間計(jì)算。在每次迭代中，需要讀取緩存36 323 864次，寫入緩存36 323 864次，共計(jì)訪問緩存72 647 728次。

實(shí)驗(yàn)結(jié)果如表1和圖2所示。

表1 Redis分布式緩存實(shí)驗(yàn)結(jié)果

圖2 節(jié)點(diǎn)數(shù)與執(zhí)行時(shí)間和吞吐率關(guān)系圖

從圖2中可以看出，隨著Hadoop集群節(jié)點(diǎn)數(shù)的增加，作業(yè)執(zhí)行所需的時(shí)間在減少。這是因?yàn)殡S著任務(wù)并發(fā)量的增大，相同時(shí)間內(nèi)能夠處理更多的數(shù)據(jù)，因此作業(yè)執(zhí)行所需的時(shí)間也會(huì)相應(yīng)減少。與此同時(shí)，隨著Hadoop集群節(jié)點(diǎn)數(shù)的增加，Redis分布式緩存的吞吐率接近直線增加(R=0.996)，也就是說，Redis分布式緩存的吞吐率與并發(fā)訪問量有較好的線性關(guān)系。

為了對(duì)使用了Redis分布式緩存的作業(yè)與普通MapReduce作業(yè)的執(zhí)行效率進(jìn)行比較，實(shí)現(xiàn)了PageRank算法的MapReduce程序[10,14]：首先啟動(dòng)一個(gè)Hadoop作業(yè)，將網(wǎng)頁(yè)鏈接文件和鏈接得分文件同時(shí)輸入，通過Reduce匯總后計(jì)算得到該網(wǎng)頁(yè)對(duì)其他網(wǎng)頁(yè)的打分，作為中間文件輸出到HDFS上；然后啟動(dòng)另一個(gè)Hadoop作業(yè)，將中間文件作為輸入，通過Reduce匯總后計(jì)算得到每個(gè)網(wǎng)頁(yè)的打分并輸出。這樣就完成了PageRank算法的一次迭代。使用與上述實(shí)驗(yàn)同樣的數(shù)據(jù)集和集群進(jìn)行實(shí)驗(yàn)，結(jié)果如表2和圖3所示。

表2 使用Redis分布式緩存與普通MapReduce作業(yè)的實(shí)驗(yàn)結(jié)果

從圖3中可以看出，使用Redis分布式緩存后，PageRank作業(yè)的執(zhí)行效率與普通基于MapReduce的作業(yè)執(zhí)行效率相比有所提高，這主要是因?yàn)閺膬?nèi)存中讀取數(shù)據(jù)與從硬盤讀取數(shù)據(jù)相比更加高效的緣故；其次，直接從Redis中獲取共享數(shù)據(jù)與采用其他替代的方式間接獲取共享數(shù)據(jù)相比，不僅降低了程序的復(fù)雜度，而且更加簡(jiǎn)便高效。

圖3 使用Redis分布式緩存與普通MapReduce的作業(yè)執(zhí)行時(shí)間

以上結(jié)果表明，Redis集群在高并發(fā)的情況下仍然能夠保持優(yōu)良的性能，因此Redis能夠很好地與Hadoop平臺(tái)相結(jié)合，作為在任務(wù)執(zhí)行過程中高效獲取共享數(shù)據(jù)的分布式緩存，解決共享數(shù)據(jù)的存儲(chǔ)問題。而且，Redis集群本身還具有很好的可擴(kuò)展性，可以通過增加節(jié)點(diǎn)數(shù)目擴(kuò)大集群的容量，而且在性能上也能保持接近線性的增長(zhǎng)，這一特性使得日后數(shù)據(jù)規(guī)模擴(kuò)大后可以比較簡(jiǎn)單地通過增加節(jié)點(diǎn)的方式實(shí)現(xiàn)擴(kuò)展，而不用對(duì)源程序作任何修改。同時(shí)，Redis作為成熟的商業(yè)產(chǎn)品，具有使用簡(jiǎn)單、易于推廣的特點(diǎn)，使得該方案能夠比較容易地運(yùn)用于實(shí)踐中，為Hadoop任務(wù)中共享數(shù)據(jù)的訪問提供一種簡(jiǎn)單、高效的解決方案。

關(guān)于所提到的最小錯(cuò)誤率訓(xùn)練算法和最大期望算法的問題，也可以使用與上面所提到的網(wǎng)頁(yè)排名算法類似的解決方案，即將共享數(shù)據(jù)加載到Redis分布式緩存中，這樣在任務(wù)執(zhí)行時(shí)各任務(wù)節(jié)點(diǎn)就可以隨時(shí)訪問分布式緩存中的數(shù)據(jù)，此處就不再一一贅述。

綜上所述，Redis分布式緩存具有性能高、擴(kuò)展性好、使用簡(jiǎn)單等特點(diǎn)，因此可以作為在Hadoop任務(wù)中訪問共享數(shù)據(jù)的有力工具，為相關(guān)問題提供一種簡(jiǎn)單高效的解決方案。雖然Redis作為分布式緩存在性能上已經(jīng)足夠高效，但是仍有可以進(jìn)一步優(yōu)化之處，比如：使用批量提交請(qǐng)求的方式減少交互次數(shù)，使用異步的請(qǐng)求方式提高并行度，使用UDP協(xié)議加快訪問速度，實(shí)現(xiàn)Redis集群負(fù)載均衡以提高效率……這些Redis性能優(yōu)化問題值得進(jìn)一步深入研究。

5 結(jié)束語

為了解決實(shí)際應(yīng)用中Hadoop任務(wù)節(jié)點(diǎn)快速訪問較大規(guī)模的共享數(shù)據(jù)的相關(guān)問題，以在Hadoop集群中引入Redis分布式緩存的方式，為該類問題提供了一種簡(jiǎn)單、高效的解決方案。實(shí)驗(yàn)結(jié)果表明，Redis分布式緩存在高并發(fā)訪問時(shí)仍具有優(yōu)異的性能，同時(shí)還具有擴(kuò)展性好、使用簡(jiǎn)單等特點(diǎn)，這些使得該方案能夠很好地與實(shí)踐相結(jié)合，解決Hadoop任務(wù)中共享數(shù)據(jù)的訪問問題。

[1] Viktor M S,Cukier K.大數(shù)據(jù)時(shí)代[M].杭州:浙江人民出版社,2013.

[2] 嚴(yán)霄鳳,張德馨.大數(shù)據(jù)研究[J].計(jì)算機(jī)技術(shù)與發(fā)展,2013,23(4):168-172.

[3] 王彥明, 奉國(guó)和, 薛 云.近年來Hadoop國(guó)外研究綜述[J].計(jì)算機(jī)系統(tǒng)應(yīng)用,2013,22(6):1-5.

[4] 杜 江,張 錚,張杰鑫,等.MapReduce并行編程模型研究綜述[J].計(jì)算機(jī)科學(xué),2015,42(6A):537-541.

[5] Dean J,Ghemawat S.MapReduce:simplified data processing on large clusters[J].Communications of the ACM,2008,51(1):107-113.

[6] Redis[EB/OL].2016-01-28.http://redis.io.

[7] How fast is Redis[EB/OL].2013-08-20.http://redis.io/topics/benchmarks.

[8] Redis cluster specification[EB/OL].2014-10-09.http://redis.io/topics/cluster-spec.

[9] Rai P,Lal A.Google PageRank algorithm:Markov chain model and hidden Markov model[J].International Journal of Computer Applications,2016,138(9):9-13.

[10] 李遠(yuǎn)方,鄧世昆,聞?dòng)癖?等.Hadoop-MapReduce下的PageRank矩陣分塊算法[J].計(jì)算機(jī)技術(shù)與發(fā)展,2011,21(8):6-9.

[11] Och F J,Jahr M E,Thayer I E.Minimum error rate training with a large number of features for machine learning:US,2013/0144593 A1[P].2013-06-06.

[12] 胡愛娜,蔡曉艷.基于MapReduce的分布式期望最大化算法[J].科學(xué)技術(shù)與工程,2013,13(16):4603-4606.

[13] 曾超宇,李金香.Redis在高速緩存系統(tǒng)中的應(yīng)用[J].微型機(jī)與應(yīng)用,2013,32(12):11-13.

[14] Leskovec J,Rajaraman A.Mining of massive datasets[M].Cambridge:Cambridge University Press,2014.

Application of Redis Distributed Caching Technology in Hadoop Framework

YAO Jing-wei1，YANG Fu-jun2

(1.School of IoT Engineering,Jiangnan University,Wuxi 214122,China; 2.Computational Aerodynamics Institute,China Aerodynamics Research and Development Center,Mianyang 621000,China)

In the scene of large scale data analysis with Hadoop,rapid accessing to shared resources is a typical problem that has not been satisfactorily solved so far.Examples of such problem include page rank algorithm,minimum error-rate training algorithm,expectation maximization algorithm and so on.Although solutions to such problems have existed,the actual effect is not satisfactory.Thus,an open-source distributed in-memory database,Redis,has been explored to provide high-throughput access to shared resources in Hadoop.Experimental results illustrate that Redis has the characteristic of linear increase in throughput with respect to cluster size so that it can provide a general-purpose solution for rapid accessing to shared resources in Hadoop cluster,and that it has provided an easier implementation of algorithms that has not been satisfactorily solved at large scale with Hadoop.Meanwhile,the use of Redis,the commercial-grade open-source tool,implies that the proposed solution has been easily adapted in both research and production environments.

Redis;distributed caching;Hadoop;MapReduce

2016-07-08

2016-10-11 網(wǎng)絡(luò)出版時(shí)間：2017-04-28

工信部高技術(shù)船舶項(xiàng)目(2016[26])

姚經(jīng)緯(1991-)，男，碩士，研究方向?yàn)橛?jì)算機(jī)應(yīng)用技術(shù)、軟件工程。

http://kns.cnki.net/kcms/detail/61.1450.TP.20170428.1703.060.html

TP311.5

A

1673-629X(2017)06-0146-05

10.3969/j.issn.1673-629X.2017.06.030