實(shí)驗(yàn)室環(huán)境下Hadoop和HAMR的性能比較

趙迪生

【摘要】 隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，數(shù)據(jù)爆炸即將發(fā)生。為了處理海量數(shù)據(jù)，包括存儲(chǔ)，組織和分析，單個(gè)機(jī)器的能力是遠(yuǎn)遠(yuǎn)不夠的。因此，構(gòu)建一個(gè)分布式計(jì)算平臺(tái)不僅對(duì)學(xué)術(shù)目的，而且對(duì)工業(yè)使用是有重要意義的?，F(xiàn)如今，Hadoop是大數(shù)據(jù)最受歡以及開(kāi)發(fā)最為完善的解決方案之一。 它為基于HDFS和MapReduce的大規(guī)模數(shù)據(jù)處理提供可靠，可擴(kuò)展，容錯(cuò)和高效的服務(wù)。HAMR是另一種新出現(xiàn)的大數(shù)據(jù)處理技術(shù)，據(jù)說(shuō)運(yùn)行速度比Hadoop更快，內(nèi)存和CPU消耗更少。 本文通過(guò)測(cè)量運(yùn)行時(shí)間，最大和平均內(nèi)存和CPU使用率，基于運(yùn)行PageRank來(lái)進(jìn)行Hadoop和HAMR之間的性能比較。 結(jié)果有助于構(gòu)建分布式計(jì)算機(jī)平臺(tái)。

【關(guān)鍵詞】 分布式計(jì)算平臺(tái) Hadoop HAMR PageRank

一、引言

如今，數(shù)據(jù)已經(jīng)成為最寶貴的社會(huì)財(cái)富之一，并且與其他社會(huì)和自然資源不同的是，它可以從幾乎任何地方產(chǎn)生：從智能手機(jī)，從社會(huì)媒體，從電子商務(wù)和信用卡，從交通系統(tǒng)，從無(wú)線(xiàn)傳感器監(jiān)控系統(tǒng)，從工業(yè)生產(chǎn)領(lǐng)域以及從科學(xué)和工程計(jì)算領(lǐng)域。在每一分鐘：Facebook用戶(hù)點(diǎn)贊4，166，667個(gè)； Instagram的用戶(hù)贊了1，736，111張照片； Twitter用戶(hù)發(fā)送了347222條tweets； Skype用戶(hù)撥打110，040個(gè)電話(huà)；蘋(píng)果用戶(hù)下載了51，000個(gè)應(yīng)用程序。所有這些大數(shù)字都將人們引向了今天的熱門(mén)話(huà)題 - 大數(shù)據(jù)。

為了以可擴(kuò)展，可靠和容錯(cuò)的方式處理如此大規(guī)模的數(shù)據(jù)，Google推出了著名的數(shù)據(jù)處理框架MapReduce，基于它， Apache Hadoop得以發(fā)布。以四個(gè)最初的組件（GFS，MapReduce，Bigtable和Chubby）為基礎(chǔ)，Hadoop現(xiàn)在已發(fā)展成一個(gè)完整的生態(tài)系統(tǒng)，包括HDFS，Hive和Hbase等。雖然Hadoop易于實(shí)現(xiàn)，但由于任務(wù)調(diào)度算法的限制，使得其并不適合處理具有高并發(fā)和大量交互操作的作業(yè)。此外，在執(zhí)行迭代時(shí)，Hadoop需要更多的I / O操作。

HAMR作為以款新式分布式計(jì)算框架，用于處理和分析大規(guī)模的數(shù)據(jù)，它可以提供比Hadoop快30倍的處理速度。它是由ET International公司開(kāi)發(fā)和首次發(fā)布。與Hadoop不同，HAMR是一個(gè)流式引擎，通過(guò)Flowlet技術(shù)驅(qū)動(dòng)數(shù)據(jù)的流式傳輸和實(shí)時(shí)分析。這不僅減少了每個(gè)任務(wù)的內(nèi)存使用，而且降低了CPU利用率。

在本文中，我們進(jìn)行實(shí)驗(yàn)來(lái)評(píng)估和比較Hadoop和HAMR在實(shí)驗(yàn)室條件下的系統(tǒng)性能。我們選擇一個(gè)典型的基準(zhǔn)PageRank來(lái)運(yùn)行數(shù)據(jù)集。實(shí)驗(yàn)結(jié)果表明，HAMR運(yùn)行速度遠(yuǎn)遠(yuǎn)超過(guò)Hadoop，并且內(nèi)存使用量更少。

本文組織如下。第二部分提供了相關(guān)工作的系統(tǒng)概述。第三部分描述我們的實(shí)驗(yàn)設(shè)置。第四節(jié)介紹了我們的實(shí)驗(yàn)結(jié)果。我們?cè)诘谖骞?jié)中給出我們的結(jié)論和未來(lái)的工作。

二、相關(guān)研究介紹

2.1 hadoop

Apache Hadoop作為一個(gè)開(kāi)源軟件項(xiàng)目，是以提供一個(gè)綜合大數(shù)據(jù)解決方案為目的而設(shè)計(jì)的。它包含兩種主要技術(shù)：HDFS，用于數(shù)據(jù)存儲(chǔ)； MapReduce，它用于數(shù)據(jù)處理。Hadoop分布式文件系統(tǒng)（HDFS）是一種用于大型分布式文件系統(tǒng)的可擴(kuò)展文件系統(tǒng)。與其他分布式文件系統(tǒng)不同，HDFS被設(shè)計(jì)為可運(yùn)行在低成本的商業(yè)硬件之上的一套系統(tǒng)，這要求它擁有較完善的容錯(cuò)機(jī)制和較高高的容錯(cuò)率。HDFS集群由稱(chēng)為NameNode的主服務(wù)器和稱(chēng)為DataNode的幾個(gè)子服務(wù)器組成。

MapReduce1.0最初是由Google開(kāi)發(fā)的。 它是一種大規(guī)?？蓴U(kuò)展的并行處理編程模型和軟件框架，用于處理大型數(shù)據(jù)集。顧名思義它包含兩個(gè)部分：Map和Reduce。其主要想法是將輸入數(shù)據(jù)映射到鍵值，并將相同鍵的值分組在一起，然后reduce函數(shù)將這些值與相同的鍵合并。

2.2 HAMR

HAMR作為另外一種用于處理大規(guī)模數(shù)據(jù)的分布式軟件系統(tǒng)，與其他系統(tǒng)最大的區(qū)別在于它以流式數(shù)據(jù)引擎作為核心。最終目標(biāo)是最小化數(shù)據(jù)的內(nèi)存占用。這使得在運(yùn)行過(guò)程中，中間運(yùn)算結(jié)果會(huì)占用更少的內(nèi)存空間，使得更多的系統(tǒng)資源得以釋放從而分配給更多的計(jì)算任務(wù)。為了實(shí)現(xiàn)這一點(diǎn)，HAMR盡可能早地減少數(shù)據(jù)，并盡快將數(shù)據(jù)推出系統(tǒng)。HAMR的工作流程包括許多稱(chēng)為Flowlet的邏輯數(shù)據(jù)處理單元。如圖2.1所示。

這些Flowlet形成有向無(wú)環(huán)圖。圖中的邊是連接Flowlet并傳遞它們之間的鍵/值對(duì)的數(shù)據(jù)鏈接。Flowlet表示單個(gè)并行處理但與，對(duì)鍵/值對(duì)進(jìn)行操作。

像Hadoop一樣，HAMR的集群也包含主節(jié)點(diǎn)和從節(jié)點(diǎn)。每個(gè)計(jì)算節(jié)點(diǎn)包含幾個(gè)處理器核心。在HAMR中，每個(gè)計(jì)算節(jié)點(diǎn)被看作是計(jì)算資源的集合，在節(jié)點(diǎn)內(nèi)部，計(jì)算資源可以被分為多個(gè)Partition，如圖2.2所示。這些分區(qū)是Flowlet的物理基礎(chǔ)。圖中顯示了Flowlet和分區(qū)之間的關(guān)系。一個(gè)Flowlet包含多Partition，每個(gè)Partition表示一個(gè)或多個(gè)串行處理器，其執(zhí)行相應(yīng)的Flowlet行為，包括鍵值對(duì)的計(jì)算以及傳遞。

2.3 PageRank

1996年，PageRank算法由來(lái)自斯坦福大學(xué)的Larry Page和Sergey Brin首先提出，到目前為止已經(jīng)成為最成功的算法之一，幾乎被用于所有的搜索引擎。其基本思想是，能鏈接到許多其他具有高質(zhì)量的網(wǎng)頁(yè)的網(wǎng)頁(yè)往往也具有很高的質(zhì)量。我們使用PageRank（PR）值來(lái)描述這種質(zhì)量并進(jìn)行計(jì)算。這是一種迭代過(guò)程。

其中Ti （i=1，2，...，n）表示鏈接到當(dāng)前網(wǎng)頁(yè)的其他網(wǎng)頁(yè)； d是用戶(hù)可以隨機(jī)到達(dá)網(wǎng)頁(yè)的概率； C（Ti）是指向另一個(gè)網(wǎng)頁(yè)的鏈接數(shù)。

三、實(shí)驗(yàn)場(chǎng)景搭建

3.1 集群設(shè)置

本次實(shí)驗(yàn)集群由四臺(tái)計(jì)算機(jī)組成。 其中一個(gè)計(jì)算機(jī)充當(dāng)主節(jié)點(diǎn)。其他三個(gè)被設(shè)計(jì)為從節(jié)點(diǎn)。每臺(tái)計(jì)算機(jī)的IP地址和主機(jī)名顯示在表3.1中。

每臺(tái)計(jì)算機(jī)有4GB RAM和64GB硬盤(pán)驅(qū)動(dòng)器，并使用Ubuntu 12.04.2操作系統(tǒng)（GNU / Linux3.5.0-24-generiv x86 64）和Java 1.7.0。 我們安裝了目前為止最為穩(wěn)定的Hadoop 2.7.1。

與Hadoop不同，HAMR在安裝前需要軟件依賴(lài)關(guān)系。我們使用ZooKeeper 3.4.6和RabbitMQ 3.5.4，然后我們安裝了Hadoop 0.4.1。 所有這三個(gè)都是是最新的版本。

3.2 數(shù)據(jù)描述

我們使用HiBench Benchmark Suite 4.06版本為實(shí)驗(yàn)生成數(shù)據(jù)。運(yùn)行在HAMR上的PageRank算法代碼包括在HAMR 0.4.1版本中中。表3.2顯示了用于Hadoop和HAMR的PageRank的路徑。

3.3 Hadoop上的PageRank

在Hadoop上運(yùn)行PageRank的基本思想是使用一個(gè)MapReduce過(guò)程作為PageRank的一個(gè)迭代。在每次迭代中，Map的輸入鍵為單個(gè)網(wǎng)頁(yè)，輸入值為當(dāng)前PageRank值。我們將每次迭代劃分為兩個(gè)階段。在第一階段，每個(gè)網(wǎng)頁(yè)將其當(dāng)前PR值與連接數(shù)的比值分配給每個(gè)指向其他網(wǎng)頁(yè)的鏈接。這個(gè)分配過(guò)程由映射函數(shù)實(shí)現(xiàn)。然后每個(gè)網(wǎng)頁(yè)統(tǒng)計(jì)souy甌指向自己鏈接的所攜帶的PR值。該聚合過(guò)程由reduce函數(shù)實(shí)現(xiàn)。Hadoop上PageRank的一個(gè)迭代如表3.3所示。

3.4 HAMR上的PageRank

在算法的初始化階段，從HDFS讀取輸入文件。 創(chuàng)建圖表KeyValueStore，并初始化Ranks KeyValueStore。接下來(lái)執(zhí)行算法的迭代部分。每次迭代中，每個(gè)頁(yè)面的PR值由所有指向其鏈接的PR值之和求得。一旦所有頁(yè)面被遍歷，迭代更新保存PR值的KeyValueStore。為了保持與HAMR的穩(wěn)定，迭代次數(shù)被限制為固定次數(shù)。

四、實(shí)驗(yàn)結(jié)果分析

實(shí)驗(yàn)輸入數(shù)據(jù)集的范圍從200萬(wàn)個(gè)網(wǎng)頁(yè)到3000萬(wàn)個(gè)網(wǎng)頁(yè)，輸入數(shù)據(jù)大小從1GB到19.9GB不等。每個(gè)數(shù)據(jù)集運(yùn)行5次迭代。我們通史記錄運(yùn)行時(shí)間，最大和平均內(nèi)存使用率，最大和平均CPU使用率以及吞吐量。

4.1 運(yùn)行時(shí)間

顯然，在運(yùn)行PageRank算法時(shí)HAMR比Hadoop更高效。它比Hadoop快10倍，當(dāng)輸入大小更大時(shí)，這種優(yōu)勢(shì)將達(dá)到20倍。 參見(jiàn)圖4.1。

4.2 內(nèi)存使用率

當(dāng)輸入數(shù)據(jù)較小（如200萬(wàn)和400萬(wàn)）時(shí)，HAMR的內(nèi)存使用率保持穩(wěn)定，但當(dāng)數(shù)據(jù)大于800萬(wàn)時(shí)，HAMR的內(nèi)存使用速度增長(zhǎng)速度幾乎與Hadoop一樣快。 然而總體來(lái)說(shuō)，HAMR的內(nèi)存利用率比Hadoop高。見(jiàn)圖4.2。

4.3 CPU使用率

與Hadoop相比，HAMR的CPU資源使用率，而與此同時(shí)Hadoop的CPU使用率幾乎不受輸入數(shù)據(jù)大小的影響，保持在60%左右。 但是當(dāng)輸入大于800萬(wàn)時(shí)，HAMR需要比Hadoop多2倍的CPU資源。見(jiàn)圖4.3。

4.4 包通過(guò)量

HAMR在每個(gè)節(jié)點(diǎn)中具有比Hadoop高得多的吞吐量。當(dāng)輸入集變大時(shí)，HAMR展示出比Hadoop更好的自適應(yīng)特性。見(jiàn)圖4.4。

五、總結(jié)與展望

在本次實(shí)驗(yàn)中，我們建立了一個(gè)在實(shí)驗(yàn)室環(huán)境下運(yùn)行大數(shù)據(jù)應(yīng)用的平臺(tái)，我們選擇PageRank算法來(lái)測(cè)試Hadoop和HAMR的性能。通過(guò)比較運(yùn)行時(shí)間，內(nèi)存使用率，CPU使用率和包通過(guò)量，我們發(fā)現(xiàn)HAMR的與性速度遠(yuǎn)超Hadoop，并消耗更少的內(nèi)存資源。這意味著HAMR有能力處理一些具有高實(shí)時(shí)性要求的任務(wù)。然而，由于HAMR的Flowlet技術(shù)，它需要更多的CPU資源來(lái)協(xié)調(diào)并行進(jìn)程，因此HAMR對(duì)CPU性能的要求比MapReduce高。但隨著處理器技術(shù)的巨大發(fā)展，這種要求可以更容易和更容易地實(shí)現(xiàn)。

隨著我們的未來(lái)工作，我們計(jì)劃通過(guò)在我們的平臺(tái)上實(shí)施Spark來(lái)擴(kuò)展我們的實(shí)驗(yàn)。Spark也是一個(gè)用于解決大數(shù)據(jù)問(wèn)題的開(kāi)源集群計(jì)算框架，它也已成為最廣泛使用的程序之一。它被設(shè)計(jì)為支持應(yīng)用程序，其在多個(gè)并行操作中重用一組工作數(shù)據(jù)，同時(shí)還提供與MapReduce相同的可伸縮性和容錯(cuò)屬性。而不是在I / O操作上浪費(fèi)太多的計(jì)算資源，這使得Spark運(yùn)行速度也快于MapReduce。然而，Spark是否也具有HAMR的優(yōu)勢(shì)是我們下一步驗(yàn)證。

此外，我們計(jì)劃建立一個(gè)更大的集群，以測(cè)試每個(gè)框架的性能，并使用更多的算法，如WordCount，Naiver Bayes和K-Cliques8來(lái)更全面的衡量系統(tǒng)性能性能。此外，我們計(jì)劃設(shè)計(jì)一個(gè)智能系統(tǒng)，可以幫助我們根據(jù)應(yīng)用程序和輸入數(shù)據(jù)大小選擇平臺(tái)和配置參數(shù)，以獲得優(yōu)化的性能。

參 考 文 獻(xiàn)

[1] Josh James. Data never sleeps 3.0. [Online]. Available： https：//www.domo.com/blog/2015/08/datanever-sleeps-3-0/， August 2015.

[2] J. Dean and S. Ghemawat， “MapReduce： Simplified data processing on large clusters，” in OSDI， 2004

[3] Apache Hadoop. [Online]. Available： http：//hadoop.apache.org

[4] Hamr – beyond mapreduce. [Online]. Availabe： http：//www.etinternational.com/index.php/news-andevents/press-releases/hamr-beyond-mapreduce/， August 2014.

[5] HAMR. [Online]. Available http：//hamrtech.com/benchmarks.html

[6] Hibench. [Online]. Available： https：//github.com/intel-hadoop/HiBench.

[7] J. Lin and C. Dyer， “Dara-Intensive Text Processing with MapReduce，” Morgan & Claypool， 2010

[8] D. Jiang， B. C. Ooi， I. Shi， and S. Wu， “The performance of MapReduce： An in-depth study，”P(pán)roceedings of the VLDB Endowment， vol. 3， no. 1-2， pp. 472-483， 2010.