從Hadoop到Spark技術(shù)的革新

權(quán)趙恒 李嘉迪

摘要：隨著互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展，人類社會逐漸進入了大數(shù)據(jù)的時代。海量數(shù)據(jù)的產(chǎn)生給現(xiàn)代人類帶來了新的挑戰(zhàn)，促使人們研究發(fā)現(xiàn)新的技術(shù)和手段去解決大數(shù)據(jù)帶來的各種難題。Hadoop和Spark技術(shù)就是在這樣的背景下產(chǎn)生的，目前在人們生活的各個領(lǐng)域，都離不開這兩種技術(shù)的支持。本文主要以這兩種技術(shù)為主，按照技術(shù)產(chǎn)生的時間順序，分析了這兩種技術(shù)的發(fā)展以及存在的問題。

關(guān)鍵詞：大數(shù)據(jù)；大數(shù)據(jù)技術(shù)；Hadoop；Spark

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

文章編號：1009-3044（2019）08-0265-04

From Hadoop to Spark Technology Innovation

QUAN Zhao-heng，LI Jia-di

（School of Computer Science， Southwest Petroleum University， Chengdu 610500， China）

Abstract： With the rapid development of Internet technology， human society has gradually entered the era of big data. The generation of massive data has brought new challenges to modern humans. Encourage people to research and discover new technologies and means to solve the problems brought by big data. Hadoop and Spark technology are produced in this context， and currently in the various fields of people's lives， they are inseparable from the support of these two technologies. This paper mainly focuses on these two technologies， and analyzes the development and problems of these two technologies according to the time sequence of technology generation.

Key words： big data； big data technology； hadoop； spark

1 引言

我們生活在數(shù)據(jù)的時代，我們每天在手機或者電腦上瀏覽的網(wǎng)頁、收到的各種消息以及看的視頻、聽的音樂都會產(chǎn)生數(shù)據(jù)，都會存儲在我們的電腦或者手機上。數(shù)據(jù)的產(chǎn)生是相當容易的，但對于大量數(shù)據(jù)的存儲與處理，發(fā)現(xiàn)其中的價值，為社會創(chuàng)造更多的價值卻是我們正在面臨的問題。

隨著互聯(lián)網(wǎng)等信息技術(shù)的發(fā)展，越來越多的TB、PB甚至FB級別的數(shù)據(jù)產(chǎn)生，Hadoop與Spark作為當今大數(shù)據(jù)處理的主流平臺，已經(jīng)在各個領(lǐng)域廣泛使用[1， 2]。Hadoop作為最早的大數(shù)據(jù)處理框架，像MapReduce、HDFS等Hadoop生態(tài)圈的開源項目至今仍然是處理大數(shù)據(jù)的必不可少的工具，但是隨著越來越多機器學習、圖計算等應(yīng)用的出現(xiàn)，大數(shù)據(jù)平臺不僅要求能夠處理大規(guī)模的數(shù)據(jù)，還對效率有了一定的要求，因此Spark就由此而生[3， 4]。

2 Hadoop

Hadoop作為最早的大數(shù)據(jù)處理框架，在大數(shù)據(jù)領(lǐng)域一直沿用至今，說明它有自身天然的優(yōu)點。Hadoop主要由MapReduce計算模型與HDFS存儲模型兩部分組成，優(yōu)點主要有低成本、高可靠、可擴展等，低成本主要是因為Hadoop集群主要是部署在那些價格低廉的普通PC機上；Hadoop可以通過配置文件決定數(shù)據(jù)的存儲副本，當由于某些原因?qū)е聰?shù)據(jù)丟失時，Hadoop集群可以自動恢復(fù)，這個保證了它的高可靠性；可擴展就是集群的節(jié)點可以根據(jù)實際需求不斷地擴展。相比優(yōu)點，Hadoop的缺點也是非常明顯的，MapReduce計算模型是一種基于數(shù)據(jù)集的計算模型，它的數(shù)據(jù)輸入輸出方式是從物理存儲上加載數(shù)據(jù)，然后操作數(shù)據(jù)，最后再寫入物理存儲設(shè)備，如果有一個復(fù)雜的作業(yè)，這樣頻繁的磁盤寫入寫出會使得效率特別的低，甚至導致作業(yè)執(zhí)行失敗。因此，Hadoop主要應(yīng)用在那些對效率要求不高的批處理作業(yè)。

2.1 Hadoop1.0

Hadoop 1.0指的是版本為Apache Hadoop 0.20.x、1.x或者CDH3系列的Hadoop，由分布式存儲系統(tǒng)HDFS和分布式計算模型MapReduce組成，其中HDFS由一個管理節(jié)點NameNode和多個物理存儲節(jié)點DataNode組成，MapReduce由一個JobTracker和多個TaskTracker組成[5]。

2.1.1 MapReduce計算模型

在Hadoop1.0中，MapReduce由兩個階段組成：Map階段和Reduce階段，對于一個作業(yè)，不管其簡單或復(fù)雜，都可以將其轉(zhuǎn)換為一個或多個MapReduce來完成。一次MapReduce需要從物理存儲設(shè)備進行一次讀出寫入，MapReduce由map（）和reduce（）兩個函數(shù)組成，map（）函數(shù)以key-value的格式從物理存儲設(shè)備上讀入源文件，并以key-value的格式輸出，reduce（）函數(shù)以同樣的形式從map（）函數(shù)中讀取數(shù)據(jù)，并最終將處理后的數(shù)據(jù)以key-value的格式將數(shù)據(jù)寫入到物理存儲設(shè)備，這里所說的物理存儲設(shè)備就是隨后要說的分布式文件系統(tǒng)HDFS[6-8]。

如圖1是Hadoop1.0中MapReduce計算模型的整體框架圖：

2.1.2 HDFS分布式存儲系統(tǒng)

分布式文件系統(tǒng)HDFS是Hadoop大數(shù)據(jù)計算框架的一個重要組成部分，在目前的大多數(shù)新出現(xiàn)的大數(shù)據(jù)框架中也沿用了HDFS這種價格低、可擴展、高可靠的持久層工具。Hadoop1.0中，HDFS由一個NameNode管理節(jié)點和一個或多個DataNode存儲節(jié)點組成，NameNode節(jié)點是整個HDFS分布式文件系統(tǒng)的管理節(jié)點，上面存儲著DataNode節(jié)點存儲數(shù)據(jù)的元數(shù)據(jù)信息，它接收用戶的請求，并向DataNode發(fā)出請求，完成相關(guān)操作；除此之外，它還保證了整個HDFS系統(tǒng)的高可靠性。HDFS中還有一個SecondaryNameNode節(jié)點，它的主要作用是協(xié)助NameNode節(jié)點，來完成將用戶修改內(nèi)容保存到磁盤中[9]。

2.2 Hadoop2.0

Hadoop 2.0指的是版本為Apache Hadoop 0.23.x、2.x或者CDH4系列的Hadoop，主要由分布式文件系統(tǒng)HDFS、計算模型MapReduce和資源管理器YARN三個部分組成，Hadoop2.0的出現(xiàn)改善了Hadoop1.0中存在的一些問題，使得Hadoop大數(shù)據(jù)框架更加完善，這也是Hadoop框架沿用至今的原因[10]。

2.2.1 Hadoop1.0存在的問題

在Hadoop1.0中，HDFS只有一個NameNode節(jié)點，對于Hadoop集群來說，NameNode管理著整個文件系統(tǒng)，如果由于一些原因使得NameNode掛掉的話，整個HDFS分布式文件系統(tǒng)就會徹底癱瘓了，這就是Hadoop1.0中存在的NameNode單點故障問題；NameNode是整個HDFS分布式文件系統(tǒng)的管理節(jié)點，負責與用戶的交互，它里面存儲著整個文件系統(tǒng)的元數(shù)據(jù)信息，隨著互聯(lián)網(wǎng)時代的快速發(fā)展，數(shù)據(jù)的產(chǎn)生量也日益增長，這也使得集群的規(guī)模不斷擴大，當我們的NameNode無法在內(nèi)存中加載全部元數(shù)據(jù)信息的時候，集群也就會出現(xiàn)各種各樣的問題，我們將這條概括為NameNode的內(nèi)存容量不足的問題；MapReduce1.0中采用基于slot的粗粒度的資源分配模型，分為Map slot和Reduce slot，而且這兩者是不可以相互共享的，我們都知道MapReduce作業(yè)是有先后順序的，因此在執(zhí)行Map步驟時，Reduce slot資源是閑置的，相反，在執(zhí)行Reduce步驟時，Map slot又是閑置的，這樣就使得資源利用率低，造成資源浪費；對于Hadoop1.0，MapReduce中JobTracker職責過多，既需要分配資源，又需要跟蹤監(jiān)控每一個Job下的tasks的運行情況，這往往造成了內(nèi)存以及資源的極大浪費，對于實時性的作業(yè)和批處理作業(yè)，在Hadoop1.0中需要搭建不同的集群環(huán)境，每個集群環(huán)境運行不同的作業(yè)類型，這往往導致了集群的資源利用率并不高，在實際的業(yè)務(wù)中，MapReduce處理的主要業(yè)務(wù)為有些延遲的批處理的作業(yè)，也就是說由于1.0中MapReduce的設(shè)計導致集群資源利用率并不高。

2.2.2 內(nèi)存限制問題的解決

針對Hadoop1.0中單個NameNode存在內(nèi)存壽險的問題，在Hadoop2.0中提出NameNode聯(lián)邦的概念，也就是NameNode Federation，這樣原來由一個NameNode管理的系統(tǒng)，現(xiàn)在由多個NameNode來管理，不僅解決了內(nèi)存限制問題，也使得數(shù)據(jù)的安全性進一步得到保證[11]。

2.2.3 單點故障問題的解決

針對1.0中NameNode的單點故障問題，在2.0中引入了新的HA機制：即如果Active的NameNode節(jié)點掛掉，處于Standy的NameNode節(jié)點將替換掉它繼續(xù)工作[12]。

2.3 新一代資源管理框架Yarn

Yarn是Hadoop2.0中的資源管理系統(tǒng)，它是一個通用的資源管理模塊，可為各類應(yīng)用程序進行資源管理和調(diào)度。Yarn不僅限于MapReduce一種框架的使用，也可以供其他框架使用，比如Tez、Spark、Storm等，它的引入大大提高了集群的利用率[13， 14]。

2.3.1 Yarn產(chǎn)生的背景

針對MapReduce1.0中出現(xiàn)的資源利用率低和集群擴展性差的問題，在Hadoop2.0中引入了Yarn來替代JobTracker，將它原有的資源管理和任務(wù)調(diào)度分別由ResourceManager、ApplicationMaster這兩個工具來分擔[15， 16]。

2.3.2 YARN的基本組成

Yarn的整體結(jié)構(gòu)延續(xù)了Hadoop生態(tài)圈一貫的風格，仍然采用的是主從結(jié)構(gòu)，下面是它的組件及功能：

（1）ResourceManager充當master的角色，負責整個集群的資源管理和調(diào)度以及ApplicationMaster的啟動；

（2）NodeManager充當slave的角色，負責單個從節(jié)點的資源管理和任務(wù)執(zhí)行；

（3）ApplicationMaster是對于每個App而言的，負責應(yīng)用程序執(zhí)行時的資源獲取以及任務(wù)分配；

（4）Container是Yarn中的資源的抽象，它是對Hadoop1.0中slot的改進，它封裝了集群中的多維度資源，例如內(nèi)存、CPU、磁盤、網(wǎng)絡(luò)等。

如圖5所示，是Yarn的整體框架圖：

3 Spark大數(shù)據(jù)計算模型

Apache Spark是在Hadoop MapReduce計算模型基礎(chǔ)上發(fā)展而來的一種基于內(nèi)存的大數(shù)據(jù)計算框架[2， 17]。

3.1 Spark計算模型產(chǎn)生的背景

Spark的出現(xiàn)是為了改善Hadoop MapReduce在實際應(yīng)用中出現(xiàn)的這樣或那樣的問題，MapReduce在執(zhí)行一個App時，既要寫Map，又要寫Reduce和驅(qū)動類，當需求發(fā)生變動時需要大規(guī)模修改代碼；MapReduce基于進程，進程的啟動和銷毀要花費時間；頻繁的寫入寫出磁盤，不適合做迭代處理；每個階段都必須排序；只適合離線計算，不適合做實時處理。

3.2 Spark快的原因

Spark是基于內(nèi)存的計算模型，有一個誤區(qū)，Spark 是基于內(nèi)存的計算，所以快，這不是主要原因，Spark在其他方面的優(yōu)化也起到了很大的作用。

3.2.1 基于內(nèi)存的計算模型

Spark與MapReduce計算模型在執(zhí)行任務(wù)計算時都是在內(nèi)存中進行的，區(qū)別是Spark會將作業(yè)執(zhí)行時的中間數(shù)據(jù)緩存到內(nèi)存中，而MapReduce是將中間數(shù)據(jù)持久化的磁盤中，在一個基于大數(shù)據(jù)平臺計算的作業(yè)，巨大的數(shù)據(jù)量從內(nèi)存中讀取與從磁盤中讀取，對于速度來說完全不是一個等級的[18]。

3.2.2 DAG計算模型更加高效

Spark將每個作業(yè)都抽象為一個DAG圖，通過DAG，Spark可以對整個作業(yè)的計算流程進行優(yōu)化，對于不需要進行shuffle的計算，可以進行操作合并；對于shuffle操作，在DAG內(nèi)部進行了stage的劃分，這樣使得資源的使用更加高效合理，避免了因為資源等待造成的效率上的降低[19， 20]。

3.2.3 基于粗粒度的資源調(diào)度

在資源申請和調(diào)度方面，Spark是基于粗粒度的，而Mapreduce是基于細粒度的。Spark的粗粒度資源申請是在App執(zhí)行完之前就將所有資源申請完畢了，task執(zhí)行時不需要自己去申請資源，這樣task執(zhí)行的相對較快，整體的速度也提高了；MapReduce的細粒度資源申請一開始不會將資源申請完畢，而是由task執(zhí)行時，自己申請資源，task執(zhí)行完畢后資源立即釋放，這樣task執(zhí)行的較慢，整體的速度也就相對較慢。

3.2.4 JVM優(yōu)化

在MapReduce計算模型中，每啟動一個task便會啟動一次JVM，也就是啟動了一個進程；而Spark是將一個TaskSet提交給Executor執(zhí)行的，啟動一個Executor時啟動了一次JVM，在Executor維護這一個線程池，每個task是交給一個線程執(zhí)行的。每次啟動JVM時就需要幾秒到幾十秒的時間，那么在大多數(shù)大數(shù)據(jù)平臺下的作業(yè)中，task的數(shù)量是很多的，這樣在效率上這兩種計算模型就會差很多。

4 結(jié)論

目前大數(shù)據(jù)技術(shù)在各個領(lǐng)域已經(jīng)有了具體的應(yīng)用，經(jīng)過這么多年技術(shù)的不斷發(fā)展與進步，大數(shù)據(jù)技術(shù)已經(jīng)有了很大的改善。本文主要以Hadoop與Spark兩種大數(shù)據(jù)技術(shù)為代表，介紹了它們之間的相互聯(lián)系以及它們的發(fā)展歷程，使我們可以清楚地看到技術(shù)發(fā)展的一個歷程。但是，隨著社會的發(fā)展和新鮮事物的不斷涌出，新的大數(shù)據(jù)技術(shù)難題會不斷出現(xiàn)，新的技術(shù)也會不斷產(chǎn)生。相信在未來的生活中，大數(shù)據(jù)技術(shù)會為人類創(chuàng)造出更多的財富。

參考文獻：

[1] 周敏奇， 王曉玲， 金澈清， 等. Hadoop權(quán)威指南[M]. 清華大學出版社， 2011.

[2] 王磊， 時亞文. 基于Spark的大數(shù)據(jù)計算模型[J]. 電腦知識與技術(shù)， 2016，12（20）：7-8.

[3] 郝樹魁. Hadoop HDFS和MapReduce架構(gòu)淺析[J]. 郵電設(shè)計技術(shù)， 2012（7）：37-42.

[4] White T. Hadoop： The Definitive Guide[M]. 2011.

[5] 堯煒， 馬又良. 淺析Hadoop 1.0與2.0設(shè)計原理[J]. 郵電設(shè)計技術(shù)， 2014（7）：37-42.

[6] DEAN， Jeffrey， GHEMAWAT， et al. MapReduce： A Flexible Data Processing Tool[J]. Communications of the Acm， 2010，53（1）：72-77.

[7] 董西成. 深入解析MapReduce架構(gòu)設(shè)計與實現(xiàn)原理[M]. 機械工業(yè)出版社， 2013.

[8] 金偉健， 王春枝. 適于進化算法的迭代式MapReduce框架[J]. 計算機應(yīng)用， 2013，33（12）：3591-3595.

[9] Liu J， Li B， Song M. THE optimization of HDFS based on small files： IEEE International Conference on Broadband Network & Multimedia Technology， 2011[C].

[10] Thusoo A， Sarma J S， Jain N， et al. Hive - a petabyte scale data warehouse using Hadoop： IEEE International Conference on Data Engineering， 2010[C].

[11] Mackey G， Sehrish S， Wang J. Improving metadata management for small files in HDFS： IEEE International Conference on Cluster Computing & Workshops， 2009[C].

[12] 蔡斌， 陳湘萍. 深入解析Hadoop Common和HDFS架構(gòu)設(shè)計與實現(xiàn)原理[M]. 機械工業(yè)出版社， 2013.

[13] Murthy A. Apache Hadoop YARN： Moving Beyond MapReduce and Batch Processing with Apache Hadoop 2， 2014[C].

[14] 周維. Hadoop 2.0-YARN核心技術(shù)實踐[M]. 清華大學出版社， 2015.

[15] 董春濤， 李文婷， 沈晴霓， 等. Hadoop YARN大數(shù)據(jù)計算框架及其資源調(diào)度機制研究[J]. 信息通信技術(shù)， 2015（1）：77-84.

[16] 董西成. Hadoop技術(shù)內(nèi)幕：深入解析YARN架構(gòu)設(shè)計與實現(xiàn)原理[M]. 機械工業(yè)出版社， 2013.

[17] Zaharia M， Chowdhury M， Franklin M J， et al. Spark： cluster computing with working sets： Usenix Conference on Hot Topics in Cloud Computing[C]， 2010.

[18] 孟紅濤， 余松平， 劉芳， 等. Spark內(nèi)存管理及緩存策略研究[J]. 計算機科學， 2017，44（6）：31-35.

[19] 廖彬， 張?zhí)眨?于炯， 等. Spark DAG優(yōu)化MapReduce協(xié)同過濾算法[J]. 中山大學學報（自然科學版）， 2017，56（3）：46-56.

[20] 殷榮. 基于DAG模型的離線數(shù)據(jù)處理引擎的設(shè)計與實現(xiàn)[D]. 哈爾濱工業(yè)大學， 2016.

【通聯(lián)編輯：梁書】