常見大數(shù)據(jù)處理框架比較研究

孫麗

摘要：本文主要對Hadoop、Spark兩種大數(shù)據(jù)處理框架進行介紹，闡述各自的原理、生態(tài)組成及應用特點，并對兩者進行了簡單的比較。

關(guān)鍵詞：Hadoop;Spark;大數(shù)據(jù)框架

中圖分類號：TP311 文獻標識碼：A

文章編號：1009-3044（2020）12-0003-03

隨著互聯(lián)網(wǎng)技術(shù)的迅猛發(fā)展，以及人們獲取信息的方式和方法的改變，各行業(yè)應用系統(tǒng)的規(guī)模迅速擴大，所產(chǎn)生的數(shù)據(jù)呈井噴式增長，遠遠超出傳統(tǒng)單臺計算機的信息處理能力。因此若干大數(shù)據(jù)處理平臺應運而生，如Hadoop、Spark、Flink、Storm、Samza等，各種平臺都具有自己的特點與應用領(lǐng)域，現(xiàn)對其中最常見、應用最廣泛的Hadoop及Spark進行介紹。

1Hadoop

1.1關(guān)于Hadoop

Hadoop是Apache下的一個開源的分布式計算平臺。Hadoop作為一種底層細節(jié)透明的架構(gòu)，其核心包括兩部分：HDFS分布式文件系統(tǒng)（Hadoop Distributed File System）和MapReduce。HDFS實現(xiàn)分布式文件系統(tǒng)，提供了文件操作和數(shù)據(jù)存儲;MapReduce實現(xiàn)了分布式計算和分布式任務處理，實現(xiàn)了任務的分發(fā)、執(zhí)行、跟蹤等工作。

1.2Hadoop原理與運行機制

Hadoop是典型的主從結(jié)構(gòu)，包括Master和Slave，即其構(gòu)成包括數(shù)據(jù)節(jié)點多個以及名字節(jié)點一個。主服務器（master）由名字節(jié)點構(gòu)成，其主要作用是對HDFS（分布式文件系統(tǒng)）的name space進行管理，并執(zhí)行client提出的文件訪問命令;對系統(tǒng)數(shù)據(jù)進行存儲是數(shù)據(jù)節(jié)點具有的功能。一定數(shù)量的TaskTracker和一個Job共同構(gòu)成了MapReduce框架，主節(jié)點和數(shù)據(jù)節(jié)點分別為運行JobTracker和TaskTracker提供了相應的場所。各項任務和作用的調(diào)度工作均由主節(jié)點負責，將任務分派到從節(jié)點的同時，還會對其執(zhí)行狀況進行監(jiān)督，如果任務在分配或監(jiān)控上未獲得成功，將自動重復上一步驟;對來自主節(jié)點的任務予以執(zhí)行是從節(jié)點唯一的工作。在對Job進行提交時，Job等相關(guān)信息的接收工作由JobTracker負責，并向從節(jié)點分發(fā)相應的信息，此外，還會對其具體的執(zhí)行狀況實施監(jiān)督管理。

在應用中，從基礎(chǔ)層面為框架提供支持是Hadoop Common的主要作用，處理大數(shù)據(jù)的工作是由MapReduce組件和HDFS合作完成的。圖1展示的內(nèi)容就是運行過程中Hadoop所依據(jù)的機制，其對于相關(guān)部署環(huán)境等方面進行了詳細展示。

1.3Hadoop生態(tài)

Hadoop生態(tài)圈主要包括HBase、Hive、Pig、Sqoop、Avro和ZooKeeper等。Hive是基于Hadoop的分布式數(shù)據(jù)倉庫技術(shù)，用于查詢和管理存儲在分布式環(huán)境下的大數(shù)據(jù)集，適合處理相對靜態(tài)的海量數(shù)據(jù)集，即在處理過程中數(shù)據(jù)不會發(fā)生快速變化且對處理結(jié)果的實時響應要求不高，其HQL語句結(jié)合了SQL技術(shù)和MapReduce分布式計算框架，降低了傳統(tǒng)數(shù)據(jù)分析人員使用Hadoop進入大數(shù)據(jù)時代的障礙。HBase是運行于Hadoop之上的分布式海量數(shù)據(jù)庫，用來存儲分結(jié)構(gòu)化和半結(jié)構(gòu)化的松散數(shù)據(jù)，它起源于Google的BigTable，起初解決大規(guī)模網(wǎng)頁搜索，現(xiàn)在應用于多種應用如地圖、社交網(wǎng)站YouTube、博客網(wǎng)站等，是一種典型的NoSQL技術(shù)，能夠?qū)崿F(xiàn)海量數(shù)據(jù)的準實時查詢。Sqoop是一個用來將Hadoop和關(guān)系型數(shù)據(jù)庫中的數(shù)據(jù)相互轉(zhuǎn)移的工具，可以將一個關(guān)系型數(shù)據(jù)庫（如：MySQL，Oracle，Postgres等）中的數(shù)據(jù)導入到HDFS中，也可以將HDFS的數(shù)據(jù)導出到關(guān)系型數(shù)據(jù)庫中。

2Spark

2.1關(guān)于Spark

Apache Spark是專為大規(guī)模數(shù)據(jù)處理而設(shè)計的快速通用的計算引擎。Spark應用程序在集群運行機制如圖2所示，Spark應用程序作為獨立的進程集合運行在集群上，由主程序中的SparkContext對這些進程進行協(xié)調(diào)。SparkContext可以連接多種類型的集群管理器，包括Mesos，YARN，Spark自己的Standalone，集群管理器可以在應用程序間分配計算資源。當SparkContext連接上集群管理器后，會在集群節(jié)點上申請創(chuàng)建executor， executor就是進行運算的執(zhí)行以及存儲應用數(shù)據(jù)的進程，之后SparkContext將用戶的應用程序以JAR文件或者Python文件的形式發(fā)送給executor，最后SparkContext發(fā)送task到executor進行執(zhí)行。

線程池是所有Spark應用程序均具備的，為執(zhí)行多線程任務提供保障。采取此種方式的優(yōu)點在于，可以有效隔離不同應用程序的調(diào)動，換而言之，drive的任務尤其自行調(diào)度，不同程序在執(zhí)行任務時使用的JVM也不同。但此種方式也存在一定的弊端，即每個SparkContext所形成的數(shù)據(jù)不具備共享性。

2.2Spark的RDD

對于Spark的抽象性主要表現(xiàn)為兩種形式：其一，通過RDD（即彈性分布式數(shù)據(jù)）來抽象表示數(shù)據(jù)，只有進行RDD轉(zhuǎn)換后的數(shù)集，才可以通過Spark完成相應操作;其二，通過動作等算子抽象化RDD，所有位于集群節(jié)點的元素均被納入RDD中。形成RDD具體方式是：通過Hadoop以及對此類文件予以支持的系統(tǒng)形成，此外，通過轉(zhuǎn)換其他RDD也可以獲得。

集群節(jié)點是RDD的具體分布位置，其構(gòu)成元素均具有只讀性，如果部分數(shù)據(jù)由于某節(jié)點的功能失效而遺失，在重新對數(shù)據(jù)進行構(gòu)建時可以將lineage作為Spark的依據(jù)，對算子在RDD構(gòu)建過程中所經(jīng)歷的轉(zhuǎn)換過程進行記錄是血統(tǒng)的工作原理，從而為遺失分區(qū)的恢復提供便利。在對算子進行轉(zhuǎn)換時Spark會在內(nèi)存中緩存相應的結(jié)果，新的RDD由此形成，隨后便可以直接讀取緩存在內(nèi)存中的相關(guān)操作，在磁盤中緩存兩個Job的步驟可以省略，使運行速度顯著提升。通過抽象化處理數(shù)據(jù)集獲得了RDD，基于此，在轉(zhuǎn)換時僅能實現(xiàn)粗粒度。但在分析數(shù)據(jù)時，并行數(shù)據(jù)方式仍然可以被RDD很好適應，將相同操作執(zhí)行在不同記錄上是此類應用顯著特征，具體包括機器學習等。

由于Spark框架對RDD的操作算子都是基于數(shù)據(jù)分區(qū)進行粗粒度的操作處理，每個轉(zhuǎn)換算子操作過后都會產(chǎn)生一個新的RDD，因此RDD之間會形成一個前后依賴關(guān)系。

Narrow Dependencies和WideDependencies即窄依賴和寬依賴構(gòu)成了Spark的依賴形式。使用某個父RDD的權(quán)限僅被賦予單獨的子RDD時，被稱之為窄依賴;反之，如果可以由多個子RDD同時使用，則被稱之為寬依賴。由于依賴不具有多重性，因此，處理相應分區(qū)時，窄依賴的各個節(jié)點均可以進行多次，在對不同轉(zhuǎn)換算子進行操作時，數(shù)據(jù)不需要同其他分區(qū)進行交換，進而對傳輸耗時有效降低，并對相關(guān)效率大幅度提升;由于依賴具有多重性，因此在處理下一步驟前，必須要完成全部節(jié)點的算子轉(zhuǎn)換，此外，還要將數(shù)據(jù)傳送到相應分區(qū)中，不但會占有大量節(jié)點，并且延遲了數(shù)據(jù)傳輸。窄依賴是RDD C，D，F(xiàn)間具有的關(guān)系，基于此，在優(yōu)化其DAG的過程中，Spark會重新對pipeline進行組合，map等算子的操作區(qū)間僅位于SparkEx-ecutor上。寬依賴是RDD A，B，G所具有的關(guān)系，因此要執(zhí)行join算子必須在位于Spark Executor分區(qū)中的groupBy算子全部執(zhí)行完畢時才能夠得到允許，此外，還需要通過網(wǎng)絡對傳輸相關(guān)數(shù)據(jù)，導致執(zhí)行時間延遲。

2.3Spark生態(tài)

SparkCore為整個生態(tài)的核心，其他組件有SparkStreaming、SparkSQL、MLlib、GraphX。SparkStreaming在生態(tài)中用于處理流式數(shù)據(jù)，同時又能和其他三大組件無縫集合;SparkSQL擅長處理結(jié)構(gòu)化數(shù)據(jù)的Spark生態(tài)成員，是一個分布式SQL查詢引擎，它提供了一個DataFrame的數(shù)據(jù)模型。對RDD等方面進行整體性處理是SparkSQL最具代表性的特征，如此，查詢HQL或SQL的工作難度被大幅度降低，并且分析復雜數(shù)據(jù)的工作也可以同時完成。Spark平臺提供的圖計算和圖挖掘接口是GraphX的基礎(chǔ)，極大方便了大家對分布式圖處理的需求。MLlib是機器學習的算法包，里面包含了一些常用的機器學習算法和處理工具，如分類、回歸、聚類等。

3Hadoop、Spark比較

Hadoop較早成為大數(shù)據(jù)行業(yè)應用最廣泛的應用框架，但近些年Spark大有超越Hadoop的趨勢。主要原因在于相比于Hadoop，Spark最大的優(yōu)勢在于“快”。因為Spark的計算是基于內(nèi)存的，而Hadoop的MapReduce計算模型涉及大量磁盤讀寫，10開銷巨大，尤其是涉及迭代的情況，高延時的缺點更加突出，這就決定了Hadoop只能適合于對實時性要求不高的批處理應用場景。其次，Spark開發(fā)多使用Scala，代碼量要比Hadoop簡潔很多。最后，在機器學習和數(shù)據(jù)挖掘算法方面，Spark提供的MLlib使得國內(nèi)外的研究重點紛紛轉(zhuǎn)移至了Spark。但Spark也僅僅是在計算模型方面可以代替MapReduce，還不能使用Hadoop進行完全替代。

隨著有關(guān)方面發(fā)展速度的不斷提升，構(gòu)成Hadoop與Speark的軟件生態(tài)系統(tǒng)所涵蓋的子項目數(shù)量均有所增加，同時還在不斷被優(yōu)化、拓展。兩者各有優(yōu)點，因此各個企業(yè)更多的是將兩者結(jié)合起來統(tǒng)一部署，通過Yarn實現(xiàn)整體調(diào)度和管理，從而最大程度發(fā)揮各自的優(yōu)勢。

4展望

在最近幾年的快速發(fā)展下，無論Hadoop還是Spark，均已經(jīng)成為一個包含多個子項目的軟件生態(tài)系統(tǒng)，并且還在不斷被優(yōu)化、拓展。兩者各有優(yōu)點，因此各個企業(yè)更多的是將兩者結(jié)合起來統(tǒng)一部署，通過Yarn實現(xiàn)整體調(diào)度和管理，從而最大程度發(fā)揮各自的優(yōu)勢。