大數(shù)據(jù)處理平臺比較研究

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

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

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

中圖分類號：TP301

文獻標識碼：A

文章編號：16727800（2017）004021202

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

1.1大數(shù)據(jù)特點

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

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

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

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

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

2.1Hadoop與Spark比較

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

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

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

2.2Hadoop與Spark應用場景比較

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

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

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

3結(jié)語

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

參考文獻：

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

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

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

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

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

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

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

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

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

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

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