999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

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

2019-05-23 10:44:48權(quán)趙恒李嘉迪
電腦知識與技術(shù) 2019年8期
關(guān)鍵詞:大數(shù)據(jù)技術(shù)大數(shù)據(jù)

權(quán)趙恒 李嘉迪

摘要:隨著互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展,人類社會逐漸進(jìn)入了大數(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 文獻(xiàn)標(biāo)識碼: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ù)的時代,我們每天在手機(jī)或者電腦上瀏覽的網(wǎng)頁、收到的各種消息以及看的視頻、聽的音樂都會產(chǎn)生數(shù)據(jù),都會存儲在我們的電腦或者手機(jī)上。數(shù)據(jù)的產(chǎn)生是相當(dāng)容易的,但對于大量數(shù)據(jù)的存儲與處理,發(fā)現(xiàn)其中的價值,為社會創(chuàng)造更多的價值卻是我們正在面臨的問題。

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

2 Hadoop

Hadoop作為最早的大數(shù)據(jù)處理框架,在大數(shù)據(jù)領(lǐng)域一直沿用至今,說明它有自身天然的優(yōu)點(diǎn)。Hadoop主要由MapReduce計(jì)算模型與HDFS存儲模型兩部分組成,優(yōu)點(diǎn)主要有低成本、高可靠、可擴(kuò)展等,低成本主要是因?yàn)镠adoop集群主要是部署在那些價格低廉的普通PC機(jī)上;Hadoop可以通過配置文件決定數(shù)據(jù)的存儲副本,當(dāng)由于某些原因?qū)е聰?shù)據(jù)丟失時,Hadoop集群可以自動恢復(fù),這個保證了它的高可靠性;可擴(kuò)展就是集群的節(jié)點(diǎn)可以根據(jù)實(shí)際需求不斷地?cái)U(kuò)展。相比優(yōu)點(diǎn),Hadoop的缺點(diǎn)也是非常明顯的,MapReduce計(jì)算模型是一種基于數(shù)據(jù)集的計(jì)算模型,它的數(shù)據(jù)輸入輸出方式是從物理存儲上加載數(shù)據(jù),然后操作數(shù)據(jù),最后再寫入物理存儲設(shè)備,如果有一個復(fù)雜的作業(yè),這樣頻繁的磁盤寫入寫出會使得效率特別的低,甚至導(dǎo)致作業(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和分布式計(jì)算模型MapReduce組成,其中HDFS由一個管理節(jié)點(diǎn)NameNode和多個物理存儲節(jié)點(diǎn)DataNode組成,MapReduce由一個JobTracker和多個TaskTracker組成[5]。

2.1.1 MapReduce計(jì)算模型

在Hadoop1.0中,MapReduce由兩個階段組成:Map階段和Reduce階段,對于一個作業(yè),不管其簡單或復(fù)雜,都可以將其轉(zhuǎn)換為一個或多個MapReduce來完成。一次MapReduce需要從物理存儲設(shè)備進(jìn)行一次讀出寫入,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計(jì)算模型的整體框架圖:

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

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

2.2 Hadoop2.0

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

2.2.1 Hadoop1.0存在的問題

在Hadoop1.0中,HDFS只有一個NameNode節(jié)點(diǎn),對于Hadoop集群來說,NameNode管理著整個文件系統(tǒng),如果由于一些原因使得NameNode掛掉的話,整個HDFS分布式文件系統(tǒng)就會徹底癱瘓了,這就是Hadoop1.0中存在的NameNode單點(diǎn)故障問題;NameNode是整個HDFS分布式文件系統(tǒng)的管理節(jié)點(diǎn),負(fù)責(zé)與用戶的交互,它里面存儲著整個文件系統(tǒng)的元數(shù)據(jù)信息,隨著互聯(lián)網(wǎng)時代的快速發(fā)展,數(shù)據(jù)的產(chǎn)生量也日益增長,這也使得集群的規(guī)模不斷擴(kuò)大,當(dāng)我們的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又是閑置的,這樣就使得資源利用率低,造成資源浪費(fèi);對于Hadoop1.0,MapReduce中JobTracker職責(zé)過多,既需要分配資源,又需要跟蹤監(jiān)控每一個Job下的tasks的運(yùn)行情況,這往往造成了內(nèi)存以及資源的極大浪費(fèi),對于實(shí)時性的作業(yè)和批處理作業(yè),在Hadoop1.0中需要搭建不同的集群環(huán)境,每個集群環(huán)境運(yùn)行不同的作業(yè)類型,這往往導(dǎo)致了集群的資源利用率并不高,在實(shí)際的業(yè)務(wù)中,MapReduce處理的主要業(yè)務(wù)為有些延遲的批處理的作業(yè),也就是說由于1.0中MapReduce的設(shè)計(jì)導(dǎo)致集群資源利用率并不高。

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ù)的安全性進(jìn)一步得到保證[11]。

2.2.3 單點(diǎn)故障問題的解決

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

2.3 新一代資源管理框架Yarn

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

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

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

2.3.2 YARN的基本組成

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

(1)ResourceManager充當(dāng)master的角色,負(fù)責(zé)整個集群的資源管理和調(diào)度以及ApplicationMaster的啟動;

(2)NodeManager充當(dāng)slave的角色,負(fù)責(zé)單個從節(jié)點(diǎn)的資源管理和任務(wù)執(zhí)行;

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

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

如圖5所示,是Yarn的整體框架圖:

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

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

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

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

3.2 Spark快的原因

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

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

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

3.2.2 DAG計(jì)算模型更加高效

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

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

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

3.2.4 JVM優(yōu)化

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

4 結(jié)論

目前大數(shù)據(jù)技術(shù)在各個領(lǐng)域已經(jīng)有了具體的應(yīng)用,經(jīng)過這么多年技術(shù)的不斷發(fā)展與進(jìn)步,大數(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)造出更多的財(cái)富。

參考文獻(xiàn):

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

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

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

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

[5] 堯煒, 馬又良. 淺析Hadoop 1.0與2.0設(shè)計(jì)原理[J]. 郵電設(shè)計(jì)技術(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è)計(jì)與實(shí)現(xiàn)原理[M]. 機(jī)械工業(yè)出版社, 2013.

[8] 金偉健, 王春枝. 適于進(jìn)化算法的迭代式MapReduce框架[J]. 計(jì)算機(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è)計(jì)與實(shí)現(xiàn)原理[M]. 機(jī)械工業(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ù)實(shí)踐[M]. 清華大學(xué)出版社, 2015.

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

[16] 董西成. Hadoop技術(shù)內(nèi)幕:深入解析YARN架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)原理[M]. 機(jī)械工業(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]. 計(jì)算機(jī)科學(xué), 2017,44(6):31-35.

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

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

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

猜你喜歡
大數(shù)據(jù)技術(shù)大數(shù)據(jù)
大數(shù)據(jù)技術(shù)在電子商務(wù)中的應(yīng)用
大數(shù)據(jù)技術(shù)對新聞業(yè)務(wù)的影響研究
論大數(shù)據(jù)技術(shù)在智能電網(wǎng)中的應(yīng)用
高校檔案管理信息服務(wù)中大數(shù)據(jù)技術(shù)的應(yīng)用
大數(shù)據(jù)技術(shù)在電氣工程中的應(yīng)用探討
大數(shù)據(jù)技術(shù)在商業(yè)銀行中的應(yīng)用分析
大數(shù)據(jù)環(huán)境下基于移動客戶端的傳統(tǒng)媒體轉(zhuǎn)型思路
新聞世界(2016年10期)2016-10-11 20:13:53
基于大數(shù)據(jù)背景下的智慧城市建設(shè)研究
科技視界(2016年20期)2016-09-29 10:53:22
數(shù)據(jù)+輿情:南方報業(yè)創(chuàng)新轉(zhuǎn)型提高服務(wù)能力的探索
中國記者(2016年6期)2016-08-26 12:36:20
主站蜘蛛池模板: 亚洲一区二区三区中文字幕5566| 中国精品久久| 欧美日韩精品一区二区视频| 91视频精品| 午夜精品久久久久久久2023| 欧美一区二区自偷自拍视频| 毛片久久网站小视频| 狠狠色婷婷丁香综合久久韩国| 欧美性精品| 亚洲国产中文精品va在线播放 | 午夜精品区| 99精品国产高清一区二区| 五月天在线网站| 丰满人妻中出白浆| 黑人巨大精品欧美一区二区区| 国产不卡一级毛片视频| 欧美福利在线| 免费高清毛片| 欧美精品亚洲精品日韩专区va| 日本久久久久久免费网络| 99re在线视频观看| 好吊妞欧美视频免费| 国产精品国产三级国产专业不 | 国产手机在线ΑⅤ片无码观看| 久久成人国产精品免费软件| 亚洲天堂啪啪| 高清国产在线| 国产主播在线观看| 国产激爽大片在线播放| 天堂av高清一区二区三区| 欧美日韩在线国产| 欧美第二区| 热99re99首页精品亚洲五月天| 毛片国产精品完整版| 在线观看网站国产| 91毛片网| 免费无码AV片在线观看中文| 亚洲天堂自拍| 免费观看成人久久网免费观看| 伊人婷婷色香五月综合缴缴情| 波多野结衣久久精品| 一区二区三区四区在线| 国产亚洲高清视频| 99er精品视频| 久久国产精品电影| 色婷婷国产精品视频| 亚洲日本在线免费观看| 黄片一区二区三区| 99久久99这里只有免费的精品| 99热这里只有精品5| 久久久久夜色精品波多野结衣| 色九九视频| 国产在线精品美女观看| 中文国产成人精品久久| 秋霞国产在线| 91精品国产自产91精品资源| 动漫精品中文字幕无码| 午夜啪啪福利| 国产精品视频导航| 欧美亚洲中文精品三区| 一级香蕉人体视频| 午夜综合网| 四虎永久免费网站| 久久精品电影| 夜精品a一区二区三区| 国产成人夜色91| 国产在线观看99| 亚洲精品国产精品乱码不卞| 香蕉视频在线精品| 青青青草国产| 免费Aⅴ片在线观看蜜芽Tⅴ | 国产在线欧美| 97免费在线观看视频| 亚洲欧洲免费视频| 日韩精品资源| 2020久久国产综合精品swag| 亚洲欧洲免费视频| 免费av一区二区三区在线| 国产99久久亚洲综合精品西瓜tv| 伊人久久福利中文字幕| 亚洲av日韩av制服丝袜| 婷婷综合缴情亚洲五月伊|