相信看這篇文章的你們，都和我一樣對Hadoop和Apache Spark的選擇有一定的疑惑，今天查了不少資料，我們就來談?wù)勥@兩種 平臺的比較與選擇吧，看看對于工作和發(fā)展，到底哪個更好。

一、Hadoop與Spark

1.Spark

Spark是一個用來實現(xiàn)快速而通用的集群計算的平臺。速度方面，Spark擴(kuò)展了廣泛使用的MapReduce計算模型，而且高效地支持更多計算模式，包括交互式查詢和流處理。

Spark項目包含多個緊密集成的組件。Spark的核心是一個對由很多計算任務(wù)組成的、運行在多個工作機(jī)器或者是一個計算集群上的應(yīng)用進(jìn)行調(diào)度、分發(fā)以及監(jiān)控的計算引擎。

2.Hadoop

Hadoop是一個由Apache基金會所開發(fā)的分布式系統(tǒng)基礎(chǔ)架構(gòu)。用戶可以在不了解分布式底層細(xì)節(jié)的情況下，開發(fā)分布式程序。充分利用集群的威力進(jìn)行高速運算和存儲。Hadoop的框架最核心的設(shè)計就是：HDFS和MapReduce。HDFS為海量的數(shù)據(jù)提供了存儲，則MapReduce為海量的數(shù)據(jù)提供了計算。

二、異與同

解決問題的層面不一樣

首先，Hadoop和Apache Spark兩者都是大數(shù)據(jù)框架，但是各自存在的目的不盡相同。Hadoop實質(zhì)上更多是一個分布式數(shù)據(jù)基礎(chǔ)設(shè)施: 它將巨大的數(shù)據(jù)集分派到一個由普通計算機(jī)組成的集群中的多個節(jié)點進(jìn)行存儲，意味著您不需要購買和維護(hù)昂貴的服務(wù)器硬件。同時，Hadoop還會索引和跟蹤這些數(shù)據(jù)，讓大數(shù)據(jù)處理和分析效率達(dá)到前所未有的高度。Spark，則是那么一個專門用來對那些分布式存儲的大數(shù)據(jù)進(jìn)行處理的工具，它并不會進(jìn)行分布式數(shù)據(jù)的存儲。

兩者可合可分

Hadoop除了提供為大家所共識的HDFS分布式數(shù)據(jù)存儲功能之外，還提供了叫做MapReduce的數(shù)據(jù)處理功能。所以這里我們完全可以拋開Spark，使用Hadoop自身的MapReduce來完成數(shù)據(jù)的處理。

相反，Spark也不是非要依附在Hadoop身上才能生存。但如上所述，畢竟它沒有提供文件管理系統(tǒng)，所以，它必須和其他的分布式文件系統(tǒng)進(jìn)行集成才能運作。這里我們可以選擇Hadoop的HDFS,也可以選擇其他的基于云的數(shù)據(jù)系統(tǒng)平臺。但Spark默認(rèn)來說還是被用在Hadoop上面的，畢竟，大家都認(rèn)為它們的結(jié)合是最好的。

順帶說一下什么是mapreduce：我們要數(shù)圖書館中的所有書。你數(shù)1號書架，我數(shù)2號書架。這就是“Map”。我們?nèi)嗽蕉?，?shù)書就更快。現(xiàn)在我們到一起，把所有人的統(tǒng)計數(shù)加在一起。這就是“Reduce”。

Spark數(shù)據(jù)處理速度秒殺MapReduce

Spark因為其處理數(shù)據(jù)的方式不一樣，會比MapReduce快上很多。MapReduce是分步對數(shù)據(jù)進(jìn)行處理的: ”從集群中讀取數(shù)據(jù)，進(jìn)行一次處理，將結(jié)果寫到集群，從集群中讀取更新后的數(shù)據(jù)，進(jìn)行下一次的處理，將結(jié)果寫到集群，等等…“ Booz Allen Hamilton的數(shù)據(jù)科學(xué)家Kirk Borne如此解析。

反觀Spark，它會在內(nèi)存中以接近“實時”的時間完成所有的數(shù)據(jù)分析：“從集群中讀取數(shù)據(jù)，完成所有必須的分析處理，將結(jié)果寫回集群，完成，” Born說道。Spark的批處理速度比MapReduce快近10倍，內(nèi)存中的數(shù)據(jù)分析速度則快近100倍。如果需要處理的數(shù)據(jù)和結(jié)果需求大部分情況下是靜態(tài)的，且你也有耐心等待批處理的完成的話，MapReduce的處理方式也是完全可以接受的。

但如果你需要對流數(shù)據(jù)進(jìn)行分析，比如那些來自于工廠的傳感器收集回來的數(shù)據(jù)，又或者說你的應(yīng)用是需要多重數(shù)據(jù)處理的，那么你也許更應(yīng)該使用Spark進(jìn)行處理。大部分機(jī)器學(xué)習(xí)算法都是需要多重數(shù)據(jù)處理的。此外，通常會用到Spark的應(yīng)用場景有以下方面：實時的市場活動，在線產(chǎn)品推薦，網(wǎng)絡(luò)安全分析，機(jī)器日記監(jiān)控等。

Recovery 恢復(fù)

兩者的災(zāi)難恢復(fù)方式迥異，但是都很不錯。因為Hadoop將每次處理后的數(shù)據(jù)都寫入到磁盤上，所以其天生就能很有彈性的對系統(tǒng)錯誤進(jìn)行處理。Spark的數(shù)據(jù)對象存儲在分布于數(shù)據(jù)集群中的叫做彈性分布式數(shù)據(jù)集(RDD: Resilient Distributed Dataset)中?！斑@些數(shù)據(jù)對象既可以放在內(nèi)存，也可以放在磁盤，所以RDD同樣也可以提供完成的災(zāi)難恢復(fù)功能”

三、學(xué)哪個?

其實，正如所了解的那樣，Spark的確是大數(shù)據(jù)行業(yè)中的后起之秀，與Hadoop相比，Spark有很多的優(yōu)勢。Hadoop之所以在大數(shù)據(jù)行業(yè)能夠得到充分的認(rèn)同主要是因為：

• Hadoop解決了大數(shù)據(jù)的可靠存儲和處理問題;
• Hadoop的開源性，這能讓很多大數(shù)據(jù)從業(yè)人員在里面找到靈感，方便實用;
• Hadoop經(jīng)過了多年的開發(fā)，擁有完整的生態(tài)系統(tǒng)。
• HDFS在由普通PC組成的集群上提供高可靠的文件存儲，通過將塊保存多個副本的辦法解決服務(wù)器或硬板壞掉的問題。
• MapReduce通過簡單的Mapper和Reducer的抽象提供一個變成模型，可以在一個由幾十臺至上百臺的PC組成的不可靠集群上并發(fā)地，分布式地處理大量的數(shù)據(jù)集，而把并發(fā)、分布式和故障恢復(fù)等計算細(xì)節(jié)隱藏起來。

Hadoop也有許多局限和不足，籠統(tǒng)的講，在數(shù)據(jù)量不斷擴(kuò)大的情況下，Hadoop的運算速度會越發(fā)顯得吃力。雖然現(xiàn)階段，Hadoop在大數(shù)據(jù)行業(yè)內(nèi)仍然有很高頻率的應(yīng)用，但不難想象在若干年后，數(shù)據(jù)量又上升幾個數(shù)量級時，Hadoop所面臨的窘境。而Spark的運算速度是Hadoop的百分之一甚至更快，因此，在未來，Spark必然會取代Hadoop，主宰大數(shù)據(jù)行業(yè)。

那是不是就可以跳過Hadoop，只學(xué)Spark呢?當(dāng)然不是，有以下原因：

• 現(xiàn)階段，Hadoop仍然主導(dǎo)著大數(shù)據(jù)領(lǐng)域，我們可以學(xué)習(xí)先進(jìn)的技術(shù)，但更是為了現(xiàn)階段的就業(yè)，就目前階段而言，學(xué)大數(shù)據(jù)必學(xué)Hadoop。
• MapReduce中有許多經(jīng)典的思想，值得我們學(xué)習(xí)，這對我們理解大數(shù)據(jù)十分有幫助。
• 確切的講，Spark要替換的是Hadoop中的MapReduce，而不是Hadoop，Hadoop是一個工具包，而Spark和MapReduce一樣，只是一種工具而已。

結(jié)論：

如果你是往業(yè)界的算法工程方面發(fā)展，那么兩個都要學(xué)，Hadoop要了解，Spark要熟悉。如果你是大數(shù)據(jù)研究人員，那么要精通這兩種。所以，這里的建議是，對于有志于在ML和大數(shù)據(jù)等領(lǐng)域發(fā)展的各位，可以按照J(rèn)ava - Hadoop - Spark這樣的路徑，如果你有C++和SQL的基礎(chǔ)，那么學(xué)習(xí)曲線將不會特別陡峭，對于spark來說，學(xué)一點Scala則會更有幫助

分享文章：大數(shù)據(jù)：學(xué)Hadoop好還是Spark好？
網(wǎng)站地址：http://www.rwnh.cn/news/97632.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營銷推廣、關(guān)鍵詞優(yōu)化、Google、移動網(wǎng)站建設(shè)、動態(tài)網(wǎng)站、營銷型網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)