梁曉杰　王紹宇

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

關鍵詞 Hadoop；分布式；緩存

中圖分類號： TP392 文獻標識碼 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 引 言

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

1 相關工作

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

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

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

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

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

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

2 Hadoop分布式緩存的弊端

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

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

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

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

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

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

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

4 實驗

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

4.1 實驗1

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

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

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

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

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

4.2 實驗2

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

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

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

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

5 結束語

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

參 考 文 獻

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

[2] 覃雄派，王會舉，杜小勇，等.大數據分析——RDMBS與MapReduce的競爭與共生[J].軟件學報，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] 孟小峰，慈祥.大數據管理：概念、 技術與挑戰(zhàn)[J].計算機學報，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].國防科技大學學報，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)中的應用[J].微型機與應用，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/