《電子技術應用》
您所在的位置:首頁 > 嵌入式技術 > 設計應用 > 大數據處理平臺比較與分析
大數據處理平臺比較與分析
2015年微型機與應用第11期
何海林1,2,皮建勇1,2
1.貴州大學 計算機科學與信息學院,貴州 貴陽 550025; 2.貴州大學 云計算與物聯網研究中心,貴州 貴陽 550025
摘要: 雖然以MapReduce和Hadoop分布式系統(HDFS)為核心的Hadoop已在大規模數據密集的商業領域成功應用,但是對于多個并行操作之間重用工作數據集卻表現不佳。作為對其的一種補充,本文介紹了Spark。首先介紹Hadoop的MapReduce與HDFS基本概念與設計思想,然后介紹了Spark的基本概念與思想,并且著重介紹了彈性分布式數據集RDD,并通過實驗證明和分析對比了Hadoop與Spark。
Abstract:
Key words :

何海林1,2,皮建勇1,2

1.貴州大學 計算機科學與信息學院,貴州 貴陽 550025; 2.貴州大學 云計算與物聯網研究中心,貴州 貴陽 550025

  摘  要: 雖然以MapReduceHadoop分布式系統(HDFS)為核心的Hadoop已在大規模數據密集的商業領域成功應用,但是對于多個并行操作之間重用工作數據集卻表現不佳。作為對其的一種補充,本文介紹了Spark。首先介紹Hadoop的MapReduce與HDFS基本概念與設計思想,然后介紹了Spark的基本概念與思想,并且著重介紹了彈性分布式數據集RDD,并通過實驗證明和分析對比了Hadoop與Spark。

  關鍵詞: Hadoop;MapReduce;HDFS;Spark;彈性分布式數據集

0 引言

  在這個知識爆炸性增長的社會,隨著各種技術的進步,人們越來越依賴身邊的各種終端設備進行各種各樣的生產生活,而這些設備會產生大量的數據。如何從這些數據中高效地獲得有用信息成為一個有經濟價值的問題。Hadoop[1]憑借其良好的出身與優越的性能,如高可靠性、高可擴展性、高效性,并且它是開源的,已經成為大數據分析的標準框架。但是Hadoop并不適用于所有場合,它有其本身不可克服的缺點,如訪問時間延遲過長不適用于時間要求較高的應用,代碼越來越長限制了它更大規模的應用。這時候Spark[2]異軍突起,克服了Hadoop的眾多缺點。

1 Hadoop

  Hadoop是Apach的一個開源項目,Hadoop提供了一個分布式文件系統(HDFS)[3]和一個用于分析和轉化大規模數據集的MapReduce[4]框架,Hadoop的一個重要特點就是通過對數據進行分割在多臺主機上進行運行,并且并行地執行應用計算。其中HDFS用于存儲數據,MapReduce是Google公司的一項重要技術,后被模仿,它主要采用并行計算的方法用于對大數據的計算。它們之間的關系如圖1。以Hadoop分布式文件系統和MapReduce分布式計算框架為核心,為用戶提供了底層細節透明的分布式基礎設施。HDFS的高容錯性和高彈性的優點,允許用戶將其部署到廉價的機器上,構建分布式系統。MapReduce分布式計算框架允許用戶在不了解分布式系統底層細節的情況下開發并行分布的應用程序,充分利用大規模的計算資源,解決傳統單機無法解決的大數據處理問題。

001.jpg

  1.1 MapReduce編程模型

  正與其名字一樣,MapReduce包含兩項關鍵操作:Map與Reduce,兩者來源于函數式編程語言,并且作為MapReduce的兩項核心操作由用戶編程完成。如圖2,MapReduce模型包含Map、Shuffle和Reduce三個階段。

  Map階段:輸入數據被系統分為相互獨立的片塊,這些小塊同時被Map處理,在用戶指定的Map程序中執行,最大限度地利用并行處理產生結果,最后Map階段的輸出作為Reduce階段的輸入。

002.jpg

  Shuffle階段:將具有相同鍵的記錄送到同一個Reduce。

  Reduce階段:將Shuffle的輸出作為輸入進行處理產生最終結果。

  在MapReduce中的處理主要靠鍵值對實現。例如輸入的記錄用<Key1,Value1>表示,在Map階段讀入記錄處理產生結果,Map階段的輸出用模式<Key2,Value2>表示,如果幾個記錄需要在Reduce階段一起處理,那么這些記錄就會被同一個Reduce處理,在Shuffle階段,將具有相同鍵的送到同一個Reduce,這樣,在Reduce階段Map階段的輸出被最終輸出為<Key3,Value3>。可以用下面的式子表示:

  Map:(K1,V1)->list(K2,V2)

  Reduce:(K2,list(V2))->list(K3,V3)

  1.2 HDFS

  HDFS當初被發展主要是為了實現與GFS[5]相似的功能,HDFS是Hadoop的文件系統的組件,它的接口與UNIX文件系統相似,犧牲了標準,是為了提高應用的性能。

  HDFS正如GFS一樣將系統數據與應用數據分開進行存放。存放元數據在專門的服務器上,叫做NameNode,應用數據存放在其他服務器上叫做DataNode,所有的服務器通過TCP協議來進行連接。不同于Lustre[6]與PVFS[7],數據節點在HDFS不采用數據保護機制,例如磁盤陣列RAID來確保數據的持久性,而是采用與GFS類似的方式將數據目錄復制到多個數據節點來保證其可靠性,并能保證數據的持久性,這種策略恰好又讓數據傳輸的帶寬提高了多倍,可以讓數據存放在離局部計算更近的地方,幾個分布式文件系統或多或少地實現了命名空間。

2 Spark

  Spark誕生于美國加州理工大學AMPLab集群計算平臺,利用內存計算速度快的特點,并從MapReduce不適用于在多個并行操作之間重用工作數據集(多迭代批量處理與交互式數據分析)的特點出發,在流處理和圖計算等多種計算范式具有更加強的能力。由此提出了一種新的架構叫做Spark,用于處理迭代機器學習算法,以保持像MapReduce一樣的高擴展性與容錯能力。Spark引入了RDD,即彈性分布式數據集(resilient distributed datasets,RDD)[8]。

  Spark是通過Scala[9]實現的一種基于Java虛擬機的高級編程語言,提供類似于DryadLINQ的編程接口,這樣編寫并行任務變得非常方便。同時Spark還可以修改Scala的編譯器,與Ruby和Python一樣,Scala也提供了一個交互式shell。實現時間延遲減少的方法主要是基于內存的數據,通過允許用戶從解釋器交互式地運行Spark,從而可以在大數據集上實現大規模并行數據挖掘。雖然現階段Spark還是一個原型,但是前途還是令人鼓舞的。實驗表明,在處理迭代式應用上Spark比Hadoop的速度提高20多倍,計算數據分析類報表的性能提高了40多倍,在交互式查詢39 GB數據集時可以達到次秒級響應時間。

  Spark應用稱為driver,實現單個節點或多個節點上的操作。與Hadoop一樣,Spark支持單節點和多節點集群,可以在Hadoop文件系統中并行運行。通過名為Mesos[10]的第三方集群框架可以支持此行為。這種配置的優點是:允許Spark與Hadoop共用一個節點共享池,擴大了應用范圍。

003.jpg

  要想使用Spark,開發者需要編寫一個Driver程序,連接到集群以運行worker,如圖3所示。Driver定義了一個或多個RDD,并調用RDD上的動作。worker是長時間運行的進程,將RDD分區以Java對象的形式緩存在內存中。

  RDD是一種分布式的內存抽象。Spark引入的RDD采用了Scala編程風格,因為Scala特性決定了RDD是一個Scala表示的對象,RDD不需要存在于物理存儲中。RDD的一個句柄包含足夠的信息計算RDD,這就意味著RDD可以以四種方式重建[11]:

  (1)改變已有RDD的持久性,RDD是懶散和短暫的,數據集在進行并行操作時已經按照要求進行了實例化(如請求將已有RDD緩存在內存中,之后會被拋出內存)。

  (2)從其他RDD轉換得來,一個數據集元素類型為A可以通過調用flatmap轉換為數據類型B。

  (3)將Driver中Scala的集合劃分為并行切片,分布在各個節點之間。

  (4)一個從文件系統創建的Scala對象。

  RDD的以上操作決定了它有數據流的特點,比如:位置感知調度、強大的自動容錯,以及很好的可伸縮性。這樣在有多個查詢請求時Spark會將工作集緩存在內存中,如果內存不夠用,可以寫到硬盤上,后續查詢時提高了重用度,可以讓查詢速度有質的提升。

3 實驗

  3.1 實現設置

  本次實驗采用4 000家餐廳140萬條點評數據,先預處理,再通過運行K-means算法[12]將數據分為四類,對比在兩種平臺上的迭代時間。K-means算法是聚類算法中最簡單的一種,它需要不斷地迭代直到收斂。

  設備:3臺內存為2 GB、硬盤為500 GB的PC安裝搭建Hadoop后再安裝Spark,其中K-means的Scala的主要代碼為:

  val sparkConf=new SparkConf().setAppName("SparkKMeans")

  val sc=new SparkContext(sparkConf)

  val lines=sc.textFile(args(0))

  迭代時間花費如圖4所示。

004.jpg

  3.2 結果分析與兩者對比

  在搭建實驗環境與編寫實驗程序階段可以看出,Spark提供了與Scala、Java、Python編程一樣的高級API,這樣便于開發并發處理應用程序。Hadoop每一次迭代會在工作集上反復調用一個函數,每一次迭代都可以看做是Mapduce的任務,每一次任務的執行,都需要從硬盤重新下載數據,這會顯著地增加時間延遲,而Spark卻不用從硬盤調用,只需從內存調用。

  兩者對比,Spark相較于Hadoop最顯著的特征就是快,Spark對于小數據集能夠達到亞秒級的延遲,這相對于Hadoop MapReduce由于“心跳機制”要花費數秒的性能而言無疑是飛躍,Hadoop經常被用于在大數據上通過Sql接口(如Pig和Hive)運行Ad-hoc探索性查詢,實際上用戶可以將數據集裝載到內存進行查詢,然而,Hadoop通過MapReduce任務進行,由于反復從硬盤讀取數據,因此它的延遲非常大。其次,首先安裝的是Hadoop,最后安裝的是Spark,后者借助前者的基礎,與其實現了完美融合,憑借Scala(被業界譽為未來Java的取代者)的強大功能,Scala能運行在運行JVM的任何地方,還可以充分利用大量現存的Java庫和現有的Java代碼。因此,Spark只需要稍作修改,就可以交互式編程。通過對比代碼數量可以發現,由于Scala的簡潔性以及Spark非常好地利用了Hadoop和Mesos的基礎設施,Spark代碼量明顯少了許多。

4 結束語

  本文介紹了Hadoop與Spark的基本概念與設計思想。可以看出Spark實際上作為對Hadoop的一種補充,在處理迭代工作與交互式數據分析方面具有優越性。兩者開始顯現出一種融合的趨勢,從Hadoop 0.23把MapReduce做成庫開始,Hadoop的目標就是要支持包括MapReduce在內的更多的并行計算模型,比如MPI、Spark等。未來隨著技術的發展究竟誰會被取代很難預料,應當取長補短,優勢互補。新的需求會產生新的平臺,如為了強調實時性而發展的Storm[13],常用于實時性要求較高的地方。未來如何實現更多融合,是一個值得發展的方向。

參考文獻

  [1] WHITE T. Hadoop: the definitive guide: the definitive guide[Z]. O′Reilly Media, Inc., 2009.

  [2] INCUBATOR A. Spark: Lightning-fast cluster computing[Z]. 2013.

  [3] SHVACHKO K, KUANG H, RADIA S, et al. The hadoop distributed file system[C].Mass Storage Systems and Technologies(MSST), 2010 IEEE 26th Symposium on. IEEE, 2010:1-10.

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

  [5] GHEMAWAT S, GOBIOFF H, LEUNG S T. The Google file system[C]. ACM SIGOPS operating systems review, ACM, 2003,37(5):29-43.

  [6] BRAAM P J. The Lustre storage architecture[Z]. 2004.

  [7] ROSS R B, THAKUR R. PVFS: A parallel file system for Linux clusters[C]. Proceedings of the 4th annual Linux showcase and conference, 2000:391-430.

  [8] ZAHARIA M, CHOWDHURY M, DAS T, et al. Resilient distributed datasets: a fault-tolerant abstraction for in-memory cluster computing[C]. Proceedings of the 9th USENIX Conference on Networked Systems Design and Implementation. USENIX Association, 2012:2-2.

  [9] ODERSKY M, SPOON L, VENNERS B. Programming in scala[M]. Artima Inc, 2008.

  [10] HINDMAN B, KONWINSKI A, ZAHARIA M, et al. Mesos: a platform for Fine-Grained resource sharing in the data center[C]. NSDI, 2011: 22-22.

  [11] ZAHARIA M, CHOWDHURY M, FRANKLIN M J, et al. Spark: cluster computing with working sets[C]. Proceedings of the 2nd USENIX conference on hot topics in cloud computing, 2010:10.

  [12] WAGSTAFF K, CARDIE C, ROGERS S, et al. Constrained k-means clustering with background knowledge[C]. ICML, 2001:577-584.

  [13] MARZ N. Storm: distributed and fault-tolerant realtime computation[Z]. 2013.


此內容為AET網站原創,未經授權禁止轉載。
主站蜘蛛池模板: 亚洲欧美日本国产综合在线 | 久久人体 | 成人丁香| 老头边吃奶边做边爱 | 久久影视一区 | 久久综合久久网 | 亚洲国产成人精品一区二区三区 | 美女黄网站 | 国产免费看网站v片不遮挡 国产免费黄视频 | 成人在免费视频手机观看网站 | 一区二区中文字幕在线观看 | 在线观看成人免费 | 久久99精品国产麻豆不卡 | 成人av手机在线观看 | 九九色视频 | 国产一区二区三区播放 | 久久精品国产精品亚洲婷婷 | 天天干伊人 | 国产在线视频www色 国产在线视频国产永久视频 | 久久中文字幕制服丝袜美腿 | 欧美在线观看网址 | 韩国在线观看日韩 | 香蕉视频禁18| 亚洲福利区 | 国产人成精品午夜在线观看 | 日日摸日日操 | 欧美高清视频性播放 | 国产色婷婷免费视频 | 日韩精品三级 | 韩国18videos极品| 精品在线小视频 | 亚洲一区日韩二区欧美三区 | 黄色影片在线看 | 在线观看黄色影片 | 性刺激欧美三级在线观看 | 中文字幕一区二区在线播放 | 欧美日韩在线观看精品 | 中文字幕亚洲第一 | yy午夜私人影院免费 | 亚洲国产成人久久一区二区三区 | 国产在线永久视频 |