梁曉杰　王紹宇

摘 要 在大規(guī)模離線數(shù)據(jù)的分析場景中，由于元數(shù)據(jù)庫被頻繁訪問造成的性能瓶頸導(dǎo)致集群計算速度急劇下降。典型的Hadoop平臺多基于磁盤進行數(shù)據(jù)讀寫，磁盤的讀寫速度又明顯不如內(nèi)存。針對這種情況，本文基于Hadoop平臺，結(jié)合對其他分布式緩存的研究，提出了一種新的分布式緩存技術(shù)來加快數(shù)據(jù)的計算速度，從而提高數(shù)據(jù)的計算時效性。實驗結(jié)果表明應(yīng)用于Hadoop的MMap內(nèi)存模型能極大提升了集群的計算速度。該模型能有效將文件映射到內(nèi)存區(qū)域，減少內(nèi)核與用戶空間來回拷貝數(shù)據(jù)，同時數(shù)據(jù)異步式追加方式不會阻塞計算進程，能有效提升集群整體的計算能力。

關(guān)鍵詞 Hadoop；分布式；緩存

中圖分類號： TP392 文獻標(biāo)識碼 A

Abstract In the scene of large-scale offline data analysis， some performance bottlenecks caused by frequent access to the metadata database make a sharp decline in the calculation of the cluster. Typical Hadoop platform is based on disk read and write， while the disk read and write speed is obviously slower than memory. In view of this， based on the Hadoop platform and the research of other distributed caches， this paper presents a new set of distributed cache technology to speed up the data computations， then also to improve the date timeliness. Experimental results show that the MMap memory model applied to Hadoop could greatly improve the computation of the cluster. This model could map the file to the memory area effectively， reduce the kernel and user space to copy data， and the asynchronous type of data append will not block the process， which can effectively improve the computing power of the whole cluster.

Keywords Hadoop ； Distributed ； Cache

0 引 言

國內(nèi)互聯(lián)網(wǎng)化的重心從個人擴展到企業(yè)與組織，進而推動了企業(yè)級“大數(shù)據(jù)”時代的到來。大規(guī)模數(shù)據(jù)分析無疑成為大數(shù)據(jù)時代的主要技術(shù)挑戰(zhàn)之一，不僅表現(xiàn)在傳統(tǒng)的企業(yè)結(jié)構(gòu)化數(shù)據(jù)會伴隨著時間的變遷而日趨膨脹，而且現(xiàn)代新型電子設(shè)備產(chǎn)生的非結(jié)構(gòu)化也將對企業(yè)的數(shù)據(jù)中心基礎(chǔ)建設(shè)造成巨大的壓力。因此大規(guī)模數(shù)據(jù)的計算一方面即對單機服務(wù)器的CPU主頻、內(nèi)存容量和I/O吞吐量提出嚴(yán)苛要求，另一方面則對服務(wù)器集群在能夠存儲海量數(shù)據(jù)的基礎(chǔ)上仍要兼具高速計算的能力也表現(xiàn)出了迫切需要。從目前發(fā)展趨勢看，不出五年內(nèi)，年產(chǎn)值在上億元的企業(yè)，其數(shù)據(jù)量的規(guī)模必將達到千億行級?，F(xiàn)舉一生產(chǎn)中的實例，某快遞集團日均訂單量是百萬級，在站點之間物件的運轉(zhuǎn)即會產(chǎn)生千萬級運單，同時也將帶來上億次計費。Hadoop最初是由Doug Cutting受Google公司發(fā)表三篇分布式論文的啟示而開發(fā)面世的分布式系統(tǒng)基礎(chǔ)架構(gòu)。Hadoop框架最核心的設(shè)計就是：HDFS和MapReduce[1]。其中，HDFS能部署在廉價的機器集群上，為海量數(shù)據(jù)提供存儲的同時還有效地降低了成本。而MapReduce則借用函數(shù)式編程語言的思想，并適用于大規(guī)模數(shù)據(jù)集的并行計算。但是Hadoop早期的設(shè)計就是基于多磁盤讀寫，甚至連一些中間計算結(jié)果也要存放在磁盤中。實際上Hadoop平臺已經(jīng)整合有一個分布式緩存工具，名為Hadoop DistributedCache。在節(jié)點上執(zhí)行任一任務(wù)之前，DistributedCache都將拷貝緩存的文件到Slave節(jié)點。不過這個工具的功能略顯低弱，不能用于大規(guī)模數(shù)據(jù)緩存。本文將介紹Hadoop DistributedCache的主要工作原理以及其自身設(shè)計上的缺點，然后結(jié)合對其他分布式緩存的研究，最后提出一套適用于大規(guī)模離線數(shù)據(jù)分析的分布式緩存技術(shù)。

1 相關(guān)工作

全峰快遞集團有這樣一個生產(chǎn)系統(tǒng)，每個月數(shù)據(jù)庫系統(tǒng)會對數(shù)據(jù)表進行分區(qū)，分區(qū)名是按照“年份-月份”來相應(yīng)命名，每個分區(qū)表的記錄總行數(shù)即超過億級，而由于數(shù)據(jù)量規(guī)模跡近龐大，僅是一次簡單的匯總查詢（比如查詢集團運單月額度），程序就可能需要運行十幾分鐘才能得到結(jié)果。由此可知，簡單查詢都要經(jīng)歷長時間的等待，那么稍微復(fù)雜查詢就可能得不到想要的結(jié)果。例如，如果想看到季度的數(shù)據(jù)統(tǒng)計情況，那就需要重新完成表間合并，也就是將三個數(shù)據(jù)量非常龐大的月份表順次查詢后得到的數(shù)據(jù)匯聚到一起。

這個過程需要人工執(zhí)行命令來開展與完成，可見其中的出錯率將會極高。面對大數(shù)據(jù)的挑戰(zhàn)，傳統(tǒng)的RDBMS無法勝任大數(shù)據(jù)分析任務(wù)[2]。綜上所述，筆者針對這一數(shù)據(jù)分析系統(tǒng)的現(xiàn)狀而提出了在原來數(shù)據(jù)庫應(yīng)用系統(tǒng)的基礎(chǔ)上設(shè)計一套數(shù)據(jù)倉庫的解決方案。具體方法是將數(shù)據(jù)庫生產(chǎn)系統(tǒng)的數(shù)據(jù)進行數(shù)據(jù)預(yù)處理從而分離出來，即ETL[3]。在ETL過程進行的時候，不能過度消耗在線生產(chǎn)數(shù)據(jù)庫的資源。在ETL過程結(jié)束之后，必須對數(shù)據(jù)倉庫的數(shù)據(jù)進行沉淀提煉，建立多維度雪花模型以支持上層應(yīng)用的快速查詢。比如說，生產(chǎn)數(shù)據(jù)庫中存儲的是每個快遞運單的詳細(xì)記錄，但是數(shù)據(jù)倉庫并不關(guān)心詳細(xì)記錄，而是希望能快速查詢到所有記錄的統(tǒng)計量，例如每天省份之間的運單總量以及運單總金額。在以前的生產(chǎn)數(shù)據(jù)庫中多是用簡單的求和函數(shù)sum來實現(xiàn)這個需求，但是由于數(shù)據(jù)量規(guī)模太大，一個簡單的求和函數(shù)運算可能需要十幾分鐘才能得出結(jié)果，并且結(jié)果也不能獲得有效緩存。所以建立數(shù)據(jù)倉庫是進行大規(guī)模數(shù)據(jù)集計算的基礎(chǔ)前提條件。

數(shù)據(jù)倉庫中重要一步，就是在OLAP服務(wù)器上建立元數(shù)據(jù)數(shù)據(jù)庫。元數(shù)據(jù)庫和以前所說的數(shù)據(jù)庫不同，主要用于存放元數(shù)據(jù)，元數(shù)據(jù)庫有很多呈現(xiàn)方式，可以把維度表當(dāng)成一種元數(shù)據(jù)。而在典型的hadoop平臺上，Master節(jié)點的NameNode就是存儲元數(shù)據(jù)的中心地帶，JobTracker在進行節(jié)點分配計算時，會先從NameNode讀取元數(shù)據(jù)，這些元數(shù)據(jù)就記錄了各個DataNode的實際情況，然后通知TaskTracker去主動聯(lián)系各個DataNode以讀取具體的數(shù)據(jù)。操作性環(huán)境與分析性環(huán)境元數(shù)據(jù)的區(qū)別如圖1所示[4]。

在操作性環(huán)境的任何時刻，對數(shù)據(jù)結(jié)構(gòu)都有且僅有一個正確的定義。但是在數(shù)據(jù)倉庫中，存于此環(huán)境中的數(shù)據(jù)會存在很長一段時間，所以數(shù)據(jù)結(jié)構(gòu)將發(fā)生經(jīng)常性改變。因此即須管理多種數(shù)據(jù)結(jié)構(gòu)的定義，而這些變化的數(shù)據(jù)結(jié)構(gòu)定義將主要由元數(shù)據(jù)庫來維護。如圖2所示[4]。近年來關(guān)于Hadoop的研究成果大多集中在對Hadoop平臺的性能改進上[5]，其中頻繁提到的就是通過優(yōu)化HDFS來提高存儲性能以及改進算法來提升MR計算性能，這其中都涉及到了元數(shù)據(jù)的處理，但是卻極少突顯元數(shù)據(jù)的重要性。

由上述兩點可見，關(guān)于元數(shù)據(jù)的操作橫跨整個數(shù)據(jù)倉庫建倉過程，既然元數(shù)據(jù)在數(shù)據(jù)倉庫中連續(xù)訪問具有普遍高發(fā)性質(zhì)，所以對連續(xù)數(shù)據(jù)進行有效的存儲就成為一個至關(guān)重要的因素。而Hadoop平臺雖然支持大規(guī)模并行計算，但其設(shè)計的理念卻是基于磁盤IO讀寫數(shù)據(jù)。一旦把元數(shù)據(jù)的塊結(jié)構(gòu)放到內(nèi)存中，那么存儲塊的所有行則只需要電子時間就能被訪問到。

HDCache[6]在HDFS之上設(shè)計并實現(xiàn)了一套分布式緩存系統(tǒng)。FlatLFS[7]也研究并開發(fā)了一個采用扁平式數(shù)據(jù)存儲方法的輕量級文件系統(tǒng)。不過本文面向的卻并非HDFS，而是基于元數(shù)據(jù)以及中間計算結(jié)果的分布式緩存。在計算過程中，計算源數(shù)據(jù)還是取自HDFS。

2 Hadoop分布式緩存的弊端

Hadoop分布式緩存（DistributedCache）是Hadoop平臺內(nèi)置的一個工具，支持若干文件類型。該工具假設(shè)所指定的文件已經(jīng)存儲在HDFS上，并且可被集群中任何機器正常訪問得到。Hadoop框架會在TaskTracker節(jié)點開始執(zhí)行任務(wù)之前，JobTracker就把所指定的緩存文件復(fù)制到該任務(wù)節(jié)點。在分發(fā)了緩存文件之后，TaskTracker會為緩存中的每個文件維護一個計數(shù)器。計數(shù)器記錄著文件被同時使用的任務(wù)個數(shù)，如果計數(shù)器值為0，表明該文件可以從緩存中刪除。

顯而易見，內(nèi)置的分布式緩存工具只適用于數(shù)據(jù)量較小的情況，最常用的場景就是JobTracker到TaskTracker的代碼分發(fā)共享。迄至目前，內(nèi)置的分布式緩存卻仍無法解決由于大規(guī)模數(shù)據(jù)量帶來的以下問題：

（1）網(wǎng)絡(luò)資源問題。JobTracker在啟動TaskTracker之前，會先從JobTracker分發(fā)緩存塊到TackTracker。一旦緩存塊過大，那么不僅對JobTracker節(jié)點造成極大的分發(fā)壓力，還將嚴(yán)重消耗整個計算集群的網(wǎng)絡(luò)資源。

（2）緩存共享問題。只要機器的CPU核心數(shù)量充足，單機可以運行多個TaskTracker進程。但是基于分布式緩存的進程獨占性，所以同一臺機器上的TaskTracker不能共享同一份緩存。并且，一般情況下OLAP型分析數(shù)據(jù)多是只讀而不改的，所以一臺機器將用多個內(nèi)存塊來分別存儲同一份數(shù)據(jù)，從而形成對集群內(nèi)存資源的浪費。

3 最優(yōu)分布式緩存解決方案

常見的開源分布式緩存方案有：Memcache、Redis、Tokyo Cabinet等。其中，Memcache是一套分布式的高速緩存系統(tǒng)，由LiveJournal的Brad Fitzpatrick具體實施開發(fā)[8]。Redis是一個key-value存儲系統(tǒng)[9]，和Memcache類似，它支持更多的value類型。

雖然Memcache 與 Redis 在OLTP領(lǐng)域已經(jīng)有過多個成功的使用案例，但是Memcache與Redis的設(shè)計理念卻大都面向在線多用戶高并發(fā)。在OLAP領(lǐng)域，涉及的場景一般是高密度計算類型，所以不要試圖將OTAP的一些開源方案應(yīng)用到OLAP領(lǐng)域。假設(shè)每行數(shù)據(jù)分析都要調(diào)用一次http請求去獲取數(shù)據(jù)，那么究其實質(zhì)，Memcache或者Redis都沒有解決上文提到的網(wǎng)絡(luò)資源問題，卻在另一方面增加了網(wǎng)絡(luò)負(fù)擔(dān)。此時，最優(yōu)的解決方案就是使用嵌入式讀、異步式日志追加的分布式緩存?；诖?，Tokyo Cabinet將是一個不錯的實現(xiàn)[10]，并且還能支持多進程讀。另外，其中的網(wǎng)絡(luò)組件Tokyo Tyrant[11]恰能解決異步增量日志問題，異步增量日志不會給網(wǎng)絡(luò)帶來太大的消耗，因為每臺獨立機器上都會保留一份數(shù)據(jù)的拷貝副本。

更進一步地，Hadoop只是需要與Tokyo Cabinet類似的嵌入式多進程讀功能，卻無需為了加快集群計算速度而引進可能帶著不確定因素的組件。其實在Linux環(huán)境下，基于MMap機制的共享緩存就是一個有效的解決方案。Linux下常規(guī)的文件讀寫是通過read（）跟write（）函數(shù)實現(xiàn)的、read（）接收三個參數(shù)：文件fd，讀取內(nèi)容長度count以及內(nèi)存地址buf，write（）函數(shù)也與其形式相似。而MMap直接映射文件到進程，用戶空間運行的程序就可以通過這段虛擬地址來讀寫文件，而不再調(diào)用read/write函數(shù)。

研究知道在Linux內(nèi)核中，MMap方式與read/write方式訪問文件，都必須經(jīng)過兩個緩存：一個是page cache緩存，另一個是buffer cache。MMap更為快速的原因在于其避開了內(nèi)核與用戶空間的數(shù)據(jù)拷貝。因為read/write方式的基本數(shù)據(jù)流向是：用戶空間先向內(nèi)核請求內(nèi)容大小，內(nèi)核從文件加載內(nèi)容到緩沖塊，再從緩沖塊輸出至用戶空間；寫過程也是同一模式。而MMap的數(shù)據(jù)流向是：用戶空間直接讀取文件內(nèi)容，數(shù)據(jù)不經(jīng)過內(nèi)核緩存塊。經(jīng)此理論分析即可得出，MMap讀寫文件具有明顯優(yōu)勢。

4 實驗

本文實驗使用Dell PowerEdge R910服務(wù)器，操作系統(tǒng)是64位的SUSE Linux Enterprise Server 11，Java1.7，Hadoop版本1.2.1，Hive[12]版本0.13.1。數(shù)據(jù)樣本采用的是IBM股票從1991-11-16起到2014-12-31的數(shù)據(jù)，樣本可以用雅虎官網(wǎng)下載得到。

4.1 實驗1

以鍵值對的形式單線程加載數(shù)據(jù)，Key的數(shù)據(jù)長度是1KB，Value的數(shù)據(jù)長度是4～100KB不等，再用單線程讀取緩存中數(shù)據(jù)。緩存測試指標(biāo)如表1所示，實驗結(jié)果如圖3所示。

通過圖3，可得出以下三個重要結(jié)論：

（1）MMap讀和寫方面都要優(yōu)于Tokyo Cabinet。

（2）py_dict可視為Hadoop分布式緩存的內(nèi)置實現(xiàn)，和py_mmap在讀方面的性能未見明顯差異。另外，py_mmap還可支持多進程讀。

（3）在寫方面，py_dict優(yōu)于py_mmap，但是由于py_dict是全緩存替換，而py_mmap只是增量緩存替換，所以實際生產(chǎn)中效率差距并不明顯。

4.2 實驗2

數(shù)據(jù)異步式追加主要是通過網(wǎng)絡(luò)流實現(xiàn)，每條記錄key長度是16字節(jié)，value長度是100字節(jié)[13]。網(wǎng)絡(luò)吞吐量測試指標(biāo)如表2所示，實驗結(jié)果如圖4所示。

LMDB是基于MMap實現(xiàn)的一個數(shù)據(jù)存儲引擎，其他四種數(shù)據(jù)存儲引擎都是基于文件存儲。通過圖4，可得出以下兩個結(jié)論：

（1）數(shù)據(jù)存儲引擎在寫方面性能相近，只顯輕微變化。

（2）基于MMap實現(xiàn)的LMDB在讀方面性能要遠(yuǎn)遠(yuǎn)優(yōu)于其他存儲引擎。

5 結(jié)束語

本文針對分布式緩存技術(shù)在Hadoop平臺上的實現(xiàn)進行分析與研究。通過研究發(fā)現(xiàn)，基于MMap的嵌入式讀取、異步式追加的分布式內(nèi)存模型相比多數(shù)分布式緩存模型都具有顯著優(yōu)勢，尤其是在處理大規(guī)模數(shù)據(jù)的時候。為此，在深入理解MMap的原理與實現(xiàn)的基礎(chǔ)上，本文闡述了MMap分布式緩存模型的簡單實現(xiàn)，還對其進行了性能方面的測試。實驗結(jié)果表明應(yīng)用于Hadoop的MMap內(nèi)存模型能極大提升集群的計算速度，這也為今后在Hadoop分布式平臺上解決內(nèi)存問題提供了一個全新的思路。

參 考 文 獻

[1] 吳曉婷，劉學(xué)超.淺談Hadoop云計算的認(rèn)識[J].無線互聯(lián)科技，2012，（8）：45.

[2] 覃雄派，王會舉，杜小勇，等.大數(shù)據(jù)分析——RDMBS與MapReduce的競爭與共生[J].軟件學(xué)報，2012，23（1）：32-45.

[3] Ferguson M. Offloading and Accelerating Data Warehouse ETL Processing using Hadoop[R]. Wilmslow， UK： Report of Intelligent Business Strategies， 2013.

[4] William H. Inmon. Building the Data Warehouse[M]. Fourth Edition. New York： Wiley Computer Publishing， 2005

[5] 孟小峰，慈祥.大數(shù)據(jù)管理：概念、 技術(shù)與挑戰(zhàn)[J].計算機學(xué)報，2013，50（1）：146-149.

[6] ZHANG Jing， WU Gongqing， HU Xuegang， et al. A distributed cache for Hadoop distributed file system in real-time cloud services， Grid Computing（GRID）[J].ACM/IEEE 13th International Conference， 2012，45（1）：12-21

[7] 付松齡，廖湘科，黃辰林，等.FlatLFS：一種面向海量小文件處理優(yōu)化的輕量級文件系統(tǒng)[J].國防科技大學(xué)學(xué)報，2013，35（2）：120-126.

[8] NISHTALA R， FUGAL H， GRIMM S， et al. Scaling memcache at facebook[C]//Proc of the 10th USENIX Conference on Networked Systems Design and Implementation， Berkeley：USENIX Association， 2013：385-398.

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

[10] Tokyo Cabinet： a modern implementation of DBM[EB/OL]. [2015-09-08] http：//fallabs.com/tokyocabinet/

[11] Tokyo Tyrant： network interface of Tokyo Cabinet[EB/OL]. [2015-09-08] http：//fallabs.com/tokyotyrant/

[12] The Apache Hive[EB/OL]. [2015-09-08] http：//hive.apache.org/

[13] In-Memory Microbenchmark[EB/OL].[2015-09-08] http：//symas.com/mdb/inmem/