趙迪生

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

【關鍵詞】 分布式計算平臺 Hadoop HAMR PageRank

一、引言

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

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

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

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

本文組織如下。第二部分提供了相關工作的系統(tǒng)概述。第三部分描述我們的實驗設置。第四節(jié)介紹了我們的實驗結(jié)果。我們在第五節(jié)中給出我們的結(jié)論和未來的工作。

二、相關研究介紹

2.1 hadoop

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

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

2.2 HAMR

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

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

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

2.3 PageRank

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

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

三、實驗場景搭建

3.1 集群設置

本次實驗集群由四臺計算機組成。 其中一個計算機充當主節(jié)點。其他三個被設計為從節(jié)點。每臺計算機的IP地址和主機名顯示在表3.1中。

每臺計算機有4GB RAM和64GB硬盤驅(qū)動器，并使用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在安裝前需要軟件依賴關系。我們使用ZooKeeper 3.4.6和RabbitMQ 3.5.4，然后我們安裝了Hadoop 0.4.1。 所有這三個都是是最新的版本。

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

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

3.3 Hadoop上的PageRank

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

3.4 HAMR上的PageRank

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

四、實驗結(jié)果分析

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

4.1 運行時間

顯然，在運行PageRank算法時HAMR比Hadoop更高效。它比Hadoop快10倍，當輸入大小更大時，這種優(yōu)勢將達到20倍。 參見圖4.1。

4.2 內(nèi)存使用率

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

4.3 CPU使用率

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

4.4 包通過量

HAMR在每個節(jié)點中具有比Hadoop高得多的吞吐量。當輸入集變大時，HAMR展示出比Hadoop更好的自適應特性。見圖4.4。

五、總結(jié)與展望

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

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

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

參 考 文 獻

[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，”Proceedings of the VLDB Endowment， vol. 3， no. 1-2， pp. 472-483， 2010.