許吳環(huán)+顧瀟華

摘要：大數(shù)據(jù)環(huán)境下，傳統(tǒng)的數(shù)據(jù)處理方式不再適用，以云計(jì)算技術(shù)為支撐的大數(shù)據(jù)處理平臺(tái)應(yīng)運(yùn)而生。比較了開源Hadoop和Spark平臺(tái)各自的優(yōu)缺點(diǎn)，發(fā)現(xiàn)各自的適用范圍：Hadoop適用于數(shù)據(jù)密集型任務(wù)，并廣泛應(yīng)用于離線分析；Spark因其基于內(nèi)存計(jì)算，在迭代計(jì)算和實(shí)時(shí)分析領(lǐng)域占據(jù)優(yōu)勢。二者在功能上有較強(qiáng)的互補(bǔ)性，協(xié)同使用可以發(fā)揮更大效益。

關(guān)鍵詞：大數(shù)據(jù)平臺(tái)；Hadoop； Spark；比較研究

中圖分類號(hào)：TP301

文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：16727800（2017）004021202

1大數(shù)據(jù)處理平臺(tái)

1.1大數(shù)據(jù)特點(diǎn)

目前，大數(shù)據(jù)還沒有一個(gè)標(biāo)準(zhǔn)定義，但是把握大數(shù)據(jù)的特征，有助于加深對大數(shù)據(jù)內(nèi)涵的理解。數(shù)據(jù)具有的3V特征，即規(guī)模大（Volume）、種類多（Variety）、速度快（Velocity）。規(guī)模大，意味著數(shù)據(jù)量不斷擴(kuò)張，數(shù)據(jù)量級(jí)從現(xiàn)在的GB、TB增長到PB、EB甚至ZB級(jí)；種類多，指數(shù)據(jù)類型有結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化，其中文字、圖片、音頻、視頻等非結(jié)構(gòu)化數(shù)據(jù)占很大比例；速度快，表示大數(shù)據(jù)有強(qiáng)時(shí)效性，數(shù)據(jù)快速產(chǎn)生，需要及時(shí)處理及分析才能實(shí)現(xiàn)大數(shù)據(jù)的經(jīng)濟(jì)價(jià)值。 大數(shù)據(jù)的處理過程為數(shù)據(jù)抽取與集成、數(shù)據(jù)分析以及數(shù)據(jù)解釋 [1]。巨量的數(shù)據(jù)往往也意味著噪聲較多，這給數(shù)據(jù)清洗工作造成困難。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫處理對象單位通常為MB，適合處理存儲(chǔ)結(jié)構(gòu)化數(shù)據(jù)，而面向大數(shù)據(jù)的數(shù)據(jù)庫技術(shù)能夠解決海量的非結(jié)構(gòu)數(shù)據(jù)存儲(chǔ)問題。傳統(tǒng)的數(shù)據(jù)分析方法以算法的準(zhǔn)確率作為重要的衡量指標(biāo)，而大數(shù)據(jù)的高速性要求算法必須犧牲一部分準(zhǔn)確性以更高效地處理數(shù)據(jù)。

1.2大數(shù)據(jù)處理平臺(tái)

為從規(guī)模巨大、種類繁多、生成快速的數(shù)據(jù)集中挖掘價(jià)值[2]，針對大數(shù)據(jù)的技術(shù)和方法應(yīng)運(yùn)而生。GFS、NoSQL、ITHbase、MapReduce等云計(jì)算技術(shù)發(fā)展，使大數(shù)據(jù)有效存儲(chǔ)、管理和分析成為可能。但從眾多復(fù)雜的大數(shù)據(jù)技術(shù)中進(jìn)行選擇，并搭建完備的大數(shù)據(jù)處理框架難度很高，不利于挖掘大數(shù)據(jù)中的經(jīng)濟(jì)價(jià)值。大數(shù)據(jù)平臺(tái)能在用戶不了解架構(gòu)底層細(xì)節(jié)的情況下，開發(fā)大數(shù)據(jù)應(yīng)用程序。全球領(lǐng)先的科技巨頭紛紛提出了建設(shè)與應(yīng)用大數(shù)據(jù)處理平臺(tái)：IBM公司推出了云端版InfoSphere BigInsights[3]；HP推出了HP Vertica6.1分析平臺(tái)[4]；Google提出的GFS、MapReduce等云計(jì)算技術(shù)催生了大數(shù)據(jù)處理平臺(tái)的事實(shí)標(biāo)準(zhǔn)Hadoop。目前，Google使用的是自己開發(fā)的Caffeine[2]；Facebook結(jié)合自身需求實(shí)現(xiàn)了Corona、Prism。完備、高效的大數(shù)據(jù)處理平臺(tái)為大數(shù)據(jù)應(yīng)用提供一站式基礎(chǔ)服務(wù)，支持應(yīng)用系統(tǒng)從清洗、集成、分析到結(jié)果可視化展現(xiàn)全過程建設(shè)，降低了用戶技術(shù)門檻[5]。

2大數(shù)據(jù)處理平臺(tái)比較

Hadoop的支撐技術(shù)（MapReduce等）成熟，實(shí)現(xiàn)了海量數(shù)據(jù)分布式存儲(chǔ)和批量處理，應(yīng)用廣泛，成為大數(shù)據(jù)處理平臺(tái)的事實(shí)標(biāo)準(zhǔn)。Spark以其近乎實(shí)時(shí)的性能和相對靈活易用而受到歡迎，它同Hadoop一樣都是Apache旗下的開源集群系統(tǒng)，是目前發(fā)展最快的大數(shù)據(jù)處理平臺(tái)之一。

2.1Hadoop與Spark比較

2.1.1Hadoop及特點(diǎn) Hadoop是由Apache開發(fā)的開源云計(jì)算平臺(tái)，實(shí)現(xiàn)在大量計(jì)算機(jī)組成的集群中進(jìn)行分布式存儲(chǔ)和計(jì)算。Hadoop框架最核心的技術(shù)是HDFS和MapReduce。HDFS是可部署在廉價(jià)機(jī)器上的分布式文件系統(tǒng)，采用主/從結(jié)構(gòu)，將大文件分割后形成大小相等的block復(fù)制3份，分別存儲(chǔ)在不同節(jié)點(diǎn)上，實(shí)現(xiàn)了海量數(shù)據(jù)存儲(chǔ)。MapReduce編程模型實(shí)現(xiàn)大數(shù)據(jù)處理，它的核心是“分而治之”[1]。Map任務(wù)區(qū)將輸入數(shù)據(jù)源分塊后，分散給不同的節(jié)點(diǎn)，通過用戶自定義的Map函數(shù)，得到中間key/Value集合，存儲(chǔ)到HDFS上。Reduce任務(wù)區(qū)從硬盤上讀取中間結(jié)果，把相同K值數(shù)據(jù)組織在一起，再經(jīng)過用戶自定義的Reduce函數(shù)處理，得到并輸出結(jié)果；將巨量資料的處理并行運(yùn)行在集群上，實(shí)現(xiàn)對大數(shù)據(jù)的有效處理。 Hadoop具有如下優(yōu)點(diǎn)[69]： （1）高擴(kuò)展性。Hadoop的橫向擴(kuò)展性能很好，海量數(shù)據(jù)能橫跨幾百甚至上千臺(tái)服務(wù)器，而用戶使用時(shí)感覺只是面對一個(gè)。大量計(jì)算機(jī)并行工作，對大數(shù)據(jù)的處理能在合理時(shí)間內(nèi)完成并得以應(yīng)用，這是傳統(tǒng)單機(jī)模式無法實(shí)現(xiàn)的。 （2）高容錯(cuò)性。從HDFS的設(shè)計(jì)可以看出它通過提供數(shù)據(jù)冗余的方式提供高可靠性。當(dāng)某個(gè)數(shù)據(jù)塊損壞或丟失，NameNode就會(huì)將其它DataNode上的副本進(jìn)行復(fù)制，保證每塊都有3份。所以，在數(shù)據(jù)處理過程中，當(dāng)集群中機(jī)器出現(xiàn)故障時(shí)計(jì)算不會(huì)停止。 （3）節(jié)約成本。首先，Hadoop本身是開源軟件，完全免費(fèi)；其次，它可以部署在廉價(jià)的PC機(jī)上；“把計(jì)算推送給數(shù)據(jù)”的設(shè)計(jì)理念，節(jié)省了數(shù)據(jù)傳輸中的通信開銷。而傳統(tǒng)的關(guān)系型數(shù)據(jù)庫將所有數(shù)據(jù)存儲(chǔ)起來，成本高昂，這不利于大數(shù)據(jù)產(chǎn)業(yè)發(fā)展。 （4）高效性。Hadoop以簡單直觀的方式解決了大數(shù)據(jù)處理中的儲(chǔ)存和分析問題。數(shù)據(jù)規(guī)模越大，相較于單機(jī)處理Hadoop的集群并行處理優(yōu)勢越明顯。 （5）基礎(chǔ)性。對于技術(shù)優(yōu)勢企業(yè)，可以根據(jù)基礎(chǔ)的Hadoop結(jié)合應(yīng)用場景進(jìn)行二次開發(fā)，使其更適合工作環(huán)境。比如，F(xiàn)acebook從自身應(yīng)用需求出發(fā)，構(gòu)建了實(shí)時(shí)Hadoop系統(tǒng)。 Hadoop系統(tǒng)局限性 [1011]：①不適合迭代運(yùn)算。MapReduce要求每個(gè)運(yùn)算結(jié)果都輸出到HDFS，每次初始化都要從HDFS讀入數(shù)據(jù)。在迭代運(yùn)算中，每次運(yùn)算的中間結(jié)果都要寫入磁盤，Hadoop在執(zhí)行每一次功能相同的迭代任務(wù)時(shí)都要反復(fù)操作I/O，計(jì)算代價(jià)很大。而對于常見的圖計(jì)算和數(shù)據(jù)挖掘等，迭代計(jì)算又是必要的；②實(shí)時(shí)性差。Hadoop平臺(tái)由于頻繁的磁盤I/O操作，大大增加了時(shí)間延遲，不能勝任快速處理任務(wù)；③易用性差。Hadoop只是一個(gè)基礎(chǔ)框架，精細(xì)程度有所欠缺，如果要實(shí)現(xiàn)具體業(yè)務(wù)還需進(jìn)一步開發(fā)。MapReduce特定的編程模型增加了Hadoop的技術(shù)復(fù)雜性。

2.1.2Spark及特點(diǎn) Spark的整個(gè)生態(tài)系統(tǒng)稱為BDAS（伯克利數(shù)據(jù)分析棧），包括Tachyon、Spark Streaming、Spark Core、MLlib等。其核心框架Spark是為了實(shí)現(xiàn)大數(shù)據(jù)的快速處理而設(shè)計(jì)的，可以用來構(gòu)建低延遲應(yīng)用。Spark以RDD（彈性分布數(shù)據(jù)集）為基礎(chǔ)，實(shí)現(xiàn)了基于內(nèi)存的大數(shù)據(jù)計(jì)算。RDD是對數(shù)據(jù)的基本抽象，實(shí)現(xiàn)了對分布式內(nèi)存的抽象使用。由于RDD能緩存到內(nèi)存中，因此避免了過多的磁盤I/O操作，大大降低了時(shí)延。Tachyon是分布式內(nèi)存文件系統(tǒng)，類似于內(nèi)存中的HDFS，基于它可以實(shí)現(xiàn)RDD或文件在計(jì)算機(jī)集群中共享。Spark沒有自己的文件系統(tǒng)，通過支持Hadoop HDFS、HBase等進(jìn)行數(shù)據(jù)存儲(chǔ)。Spark更專注于計(jì)算性能，其特點(diǎn)如下[1113]： （1）高速性。Spark通過內(nèi)存計(jì)算減少磁盤I/O開銷，極大縮小了時(shí)間延遲，能處理Hadoop無法應(yīng)對的迭代運(yùn)算，在進(jìn)行圖計(jì)算等工作時(shí)表現(xiàn)更好。高速數(shù)據(jù)處理能力使得Spark更能滿足大數(shù)據(jù)分析中實(shí)時(shí)分析的要求。 （2）靈活性。較之僅支持map函數(shù)和reduce函數(shù)的Hadoop，Spark支持map、reduce、filter、join、count等近80多種操作類型。Spark的交互模式使用戶在進(jìn)行操作時(shí)能及時(shí)獲得反饋，這是Hadoop不具備的。Spark SQL能直接用標(biāo)準(zhǔn)SQL語句在Spark上進(jìn)行大數(shù)據(jù)查詢，簡單易學(xué)。盡管在Hadoop中有Hive，可以不用Java來編寫復(fù)雜的MapReduce程序，但是Hive在MapReduce上的運(yùn)行速度卻達(dá)不到期望程度。

2.1.3Hadoop與Spark特點(diǎn)比較分析 Hadoop具有高擴(kuò)展性、高容錯(cuò)性、成本低、高效性、不適合迭代運(yùn)算、實(shí)時(shí)性差、易用性差等特點(diǎn)，與之相比，Spark最突出的特點(diǎn)是高速性和靈活性，基于這些特點(diǎn)分析總結(jié)如下：Hadoop更注重存儲(chǔ)性能，而Spark更專注于計(jì)算，可以形象地將二者的處理方式比作“大砍刀”和“剔骨刀”，前者可以勝任更加繁重的任務(wù)，但難免粗糙，后者則勝在快速、靈巧上。

2.2Hadoop與Spark應(yīng)用場景比較

2.2.1Hadoop應(yīng)用場景 Hadoop的高擴(kuò)展性、高容錯(cuò)性、基礎(chǔ)性等優(yōu)點(diǎn)，決定了其適用于龐大數(shù)據(jù)集控制、數(shù)據(jù)密集型計(jì)算和離線分析等場景。針對Hadoop的局限性，為提高Hadoop性能，各種工具應(yīng)運(yùn)而生，已經(jīng)發(fā)展成為包括Hive、Pig、HBase、Cassandra、YARN等在內(nèi)的完整生態(tài)系統(tǒng)。HBase新型NoSQL數(shù)據(jù)庫便于數(shù)據(jù)管理，Hive提供類似SQL的操作方式進(jìn)行數(shù)據(jù)分析，Pig是用來處理大規(guī)模數(shù)據(jù)的高級(jí)腳本語言……這些功能模塊在一定程度上彌補(bǔ)了Hadoop的不足，降低了用戶使用難度，擴(kuò)展了應(yīng)用場景。

2.2.2Spark應(yīng)用場景 與Hadoop不同，Spark高速、靈活的特點(diǎn)，決定了它適用于迭代計(jì)算、交互式查詢、實(shí)時(shí)分析等場景，比如，淘寶使用Spark來實(shí)現(xiàn)基于用戶的圖計(jì)算應(yīng)用[11]。但是，其RDD特點(diǎn)使其不適合異步細(xì)粒度更新狀態(tài)的應(yīng)用[1]，比如，增量的Web抓取和索引。RDD的特點(diǎn)之一是“不可變”，即只讀不可寫，如果要對RDD中的數(shù)據(jù)進(jìn)行更新，就要遍歷整個(gè)RDD并生成一個(gè)新RDD，頻繁更新代價(jià)很大。

2.2.3Hadoop與Spark的互補(bǔ)競爭關(guān)系 Hadoop與Spark同為大數(shù)據(jù)處理平臺(tái)，必然在市場中存在一定的競爭替代關(guān)系，二者在功能上有較強(qiáng)的互補(bǔ)性。Hadoop解決了如何將大數(shù)據(jù)儲(chǔ)存起來的問題，Spark在此基礎(chǔ)上考慮的是更快速、易用地實(shí)現(xiàn)大數(shù)據(jù)分析，這點(diǎn)從Spark仍采用HDFS作為文件系統(tǒng)就可看出。它們適用于不同的應(yīng)用場景，有時(shí)協(xié)同工作會(huì)達(dá)到更理想的效果，在Spark和Hadoop的許多發(fā)行版（如CDH、MapR、InfoSphere BigInsights）中，它們都已經(jīng)互相支持實(shí)現(xiàn)。

3結(jié)語

本文分析了大數(shù)據(jù)的3V特點(diǎn)，論述了大數(shù)據(jù)處理與傳統(tǒng)數(shù)據(jù)處理的不同，指出了傳統(tǒng)處理方式在大數(shù)據(jù)環(huán)境下的局限性。通過分析常用的大數(shù)據(jù)處理平臺(tái)，并分析Hadoop和Spark的核心技術(shù)，對其優(yōu)缺點(diǎn)進(jìn)行了歸納。Hadoop實(shí)現(xiàn)了海量異構(gòu)數(shù)據(jù)的存儲(chǔ)和處理，雖然在處理速度和易用性方面存在缺陷，但由于它的基礎(chǔ)性還是得到廣泛應(yīng)用，企業(yè)可根據(jù)自身應(yīng)用特點(diǎn)進(jìn)行改進(jìn)。雖然Spark不適合異步細(xì)粒度更新狀態(tài)的應(yīng)用，但在處理性能和易用程度上較Hadoop優(yōu)勢顯著，發(fā)展也十分迅速。通過比較兩者的優(yōu)缺點(diǎn)，可以發(fā)現(xiàn)它們在功能上有較強(qiáng)的互補(bǔ)性，協(xié)同使用可以帶來效益優(yōu)化。目前Spark和很多Hadoop發(fā)行版都已經(jīng)互相支持。期望本文對大數(shù)據(jù)處理平臺(tái)的選擇、利用和研發(fā)有所啟發(fā)。

參考文獻(xiàn)：

[1]孟小峰.大數(shù)據(jù)管理：概念、技術(shù)與挑戰(zhàn)[J].計(jì)算機(jī)研究與發(fā)展，2013，50（1）：146169.

[2]張引.大數(shù)據(jù)應(yīng)用現(xiàn)狀與展望[J].計(jì)算機(jī)研究與發(fā)展，2013，50（S2）：216233.

[3]IBM.積極推進(jìn)“大數(shù)據(jù)”時(shí)代革新[J].硅谷，2011（22）：116117.

[4]于翔.HP Vertica 6.1快速連接Hadoop[N].網(wǎng)絡(luò)世界報(bào)，20130204（034）.

[5]王強(qiáng).大數(shù)據(jù)分析平臺(tái)建設(shè)與應(yīng)用綜述[J].集成技術(shù)，2016，5（2）：218.

[6]黃素萍.Hadoop平臺(tái)在大數(shù)據(jù)處理中的應(yīng)用研究[J].現(xiàn)代計(jì)算機(jī)，2013（29）：1215.

[7]任仁.Hadoop在大數(shù)據(jù)處理中的應(yīng)用優(yōu)勢分析[J].電子技術(shù)與軟件工程，2014（15）：194195.

[8]戴中華.基于Hadoop平臺(tái)的大數(shù)據(jù)分析與處理[J].通訊世界，2015（6）：5960.

[9]張臻.大數(shù)據(jù)處理平臺(tái)分析[J].電信，2014（6）：79.

[10]張巖峰.云環(huán)境下大數(shù)據(jù)迭代計(jì)算研究[D].沈陽：東北大學(xué)，2012.

[11]何海林.大數(shù)據(jù)處理平臺(tái)比較與分析[J].微型機(jī)與應(yīng)用，2015，34（11）：717.（責(zé)任編輯：杜能鋼）