談到大數(shù)據(jù)，相信大家對(duì)Hadoop和Apache Spark這兩個(gè)名字并不陌生。然而，最近業(yè)界有一些人正在大張旗鼓的宣揚(yáng)Hadoop將死，Spark將立。他們究竟是危言聳聽、嘩眾取寵，還是眼光獨(dú)到堪破未來呢？與Hadoop相比，Spark技術(shù)如何？現(xiàn)工業(yè)界大數(shù)據(jù)技術(shù)都在使用何種技術(shù)？如果現(xiàn)在想要開始學(xué)習(xí)大數(shù)據(jù)的話，應(yīng)該從哪一種開始呢？

首先我們就從二者的區(qū)別講起好了：

首先，Hadoop與Spark解決問題的層面不同。

Hadoop和Apache Spark兩者都是大數(shù)據(jù)框架，但是各自存在的目的不盡相同。Hadoop實(shí)質(zhì)上更多是一個(gè)分布式數(shù)據(jù)基礎(chǔ)設(shè)施: 它將巨大的數(shù)據(jù)集分派到一個(gè)由普通計(jì)算機(jī)組成的集群中的多個(gè)節(jié)點(diǎn)進(jìn)行存儲(chǔ)，意味著您不需要購買和維護(hù)昂貴的服務(wù)器硬件。

同時(shí)，Hadoop還會(huì)索引和跟蹤這些數(shù)據(jù)，讓大數(shù)據(jù)處理和分析效率達(dá)到前所未有的高度。Spark，則是那么一個(gè)專門用來對(duì)那些分布式存儲(chǔ)的大數(shù)據(jù)進(jìn)行處理的工具，它并不會(huì)進(jìn)行分布式數(shù)據(jù)的存儲(chǔ)。

其次，還有一點(diǎn)也值得注意——這兩者的災(zāi)難恢復(fù)方式迥異。因?yàn)镠adoop將每次處理后的數(shù)據(jù)都寫入到磁盤上，所以其天生就能很有彈性的對(duì)系統(tǒng)錯(cuò)誤進(jìn)行處理。
 Spark的數(shù)據(jù)對(duì)象存儲(chǔ)在分布于數(shù)據(jù)集群中的叫做彈性分布式數(shù)據(jù)集(RDD: Resilient Distributed Dataset)中。這些數(shù)據(jù)對(duì)象既可以放在內(nèi)存，也可以放在磁盤，所以RDD同樣也可以提供完成的災(zāi)難恢復(fù)功能。

由于兩者的側(cè)重點(diǎn)不同，使用場景不同，筆者認(rèn)為其實(shí)并沒有替代之說。Spark更適合于迭代運(yùn)算比較多的ML和DM運(yùn)算。因?yàn)樵赟park里面，有RDD的概念。RDD可以cache到內(nèi)存中，那么每次對(duì)RDD數(shù)據(jù)集的操作之后的結(jié)果，都可以存放到內(nèi)存中，下一個(gè)操作可以直接從內(nèi)存中輸入，省去了MapReduce大量的磁盤IO操作。但是，我們也要看到spark的限制：內(nèi)存。我認(rèn)為Hadoop雖然費(fèi)時(shí)，但是在OLAP等大規(guī)模數(shù)據(jù)的應(yīng)用場景，還是受歡迎的。目前Hadoop涵蓋了從數(shù)據(jù)收集、到分布式存儲(chǔ)，再到分布式計(jì)算的各個(gè)領(lǐng)域，在各領(lǐng)域都有自己獨(dú)特優(yōu)勢(shì)。

那么為什么還有這么多人唱衰Hadoop，力捧Spark呢？

很多人在談到Spark代替Hadoop的時(shí)候，其實(shí)很大程度上指的是代替MapReduce。

MapReduce的缺陷很多，最大的缺陷之一是Map ＋ Reduce的模型。這個(gè)模型并不適合描述復(fù)雜的數(shù)據(jù)處理過程。很多公司把各種奇怪的Machine Learning計(jì)算用MR模型描述，不斷挖掘MR潛力，對(duì)系統(tǒng)工程師和Ops也是極大挑戰(zhàn)了。很多計(jì)算，本質(zhì)上并不是一個(gè)Map，Shuffle再Reduce的結(jié)構(gòu)，比如我編譯一個(gè)SubQuery的SQL，每個(gè)Query都做一次Group By，我可能需要Map，Reduce＋Reduce，中間不希望有無用的Map；又或者我需要Join，這對(duì)MapReduce來說簡直是噩夢(mèng)，什么給左右表加標(biāo)簽，小表用Distributed Cache分發(fā)，各種不同Join的Hack，都是因?yàn)镸apReduce本身是不直接支持Join的，其實(shí)我需要的是，兩組不同的計(jì)算節(jié)點(diǎn)掃描了數(shù)據(jù)之后按照Key分發(fā)數(shù)據(jù)到下一個(gè)階段再計(jì)算，就這么簡單的規(guī)則而已；再或者我要表示一組復(fù)雜的數(shù)據(jù)Pipeline，數(shù)據(jù)在一個(gè)無數(shù)節(jié)點(diǎn)組成的圖上流動(dòng)，而因?yàn)镸apReduce的呆板模型，我必須一次一次在一個(gè)Map/Reduce步驟完成之后不必要地把數(shù)據(jù)寫到磁盤上再讀出，才能繼續(xù)下一個(gè)節(jié)點(diǎn)，因?yàn)镸ap Reduce2個(gè)階段完成之后，就算是一個(gè)獨(dú)立計(jì)算步驟完成，必定會(huì)寫到磁盤上等待下一個(gè)Map Reduce計(jì)算。

上面這些問題，算是每個(gè)號(hào)稱下一代平臺(tái)都嘗試解決的?，F(xiàn)在號(hào)稱次世代平臺(tái)現(xiàn)在做的相對(duì)有前景的是Hortonworks的Tez和Databricks的Spark。他們都嘗試解決了上面說的那些問題。Tez和Spark都可以很自由地描述一個(gè)Job里執(zhí)行流。他們相對(duì)現(xiàn)在的MapReduce模型來說，極大的提升了對(duì)各種復(fù)雜處理的直接支持，不需要再絞盡腦汁“挖掘”MR模型的潛力。綜上，Spark數(shù)據(jù)處理速度秒殺MapReduce因?yàn)槠涮幚頂?shù)據(jù)的方式不一樣，會(huì)比MapReduce快上很多。

那么可以由此判定Hadoop“死刑”嗎？

目前備受追捧的Spark還有很多缺陷，比如：

· 穩(wěn)定性方面，由于代碼質(zhì)量問題，Spark長時(shí)間運(yùn)行會(huì)經(jīng)常出錯(cuò)，在架構(gòu)方面，由于大量數(shù)據(jù)被緩存在RAM中，Java回收垃圾緩慢的情況嚴(yán)重，導(dǎo)致Spark性能不穩(wěn)定，在復(fù)雜場景中SQL的性能甚至不如現(xiàn)有的Map/Reduce。

· 不能處理大數(shù)據(jù)，單獨(dú)機(jī)器處理數(shù)據(jù)過大，或者由于數(shù)據(jù)出現(xiàn)問題導(dǎo)致中間結(jié)果超過RAM的大小時(shí)，常常出現(xiàn)RAM空間不足或無法得出結(jié)果。然而，Map/Reduce運(yùn)算框架可以處理大數(shù)據(jù)，在這方面，Spark不如Map/Reduce運(yùn)算框架有效。

· 不能支持復(fù)雜的SQL統(tǒng)計(jì)；目前Spark支持的SQL語法完整程度還不能應(yīng)用在復(fù)雜數(shù)據(jù)分析中。在可管理性方面，SparkYARN的結(jié)合不完善，這就為使用過程中埋下隱憂，容易出現(xiàn)各種難題。

但本文的目的并不在于踩Spark為Hadoop證明，而是想指出——大家在比較Hadoop和Spark方面要記住的最重要一點(diǎn)就是，它們并不是非此即彼的關(guān)系，因?yàn)樗鼈儾皇窍嗷ヅ懦猓膊皇钦f一方是另一方的簡易替代者。兩者彼此兼容，這使得這對(duì)組合成為一種功能極其強(qiáng)大的解決方案，適合諸多大數(shù)據(jù)應(yīng)用場合。

也就是說，大數(shù)據(jù)行業(yè)的老鳥們?nèi)绻粫?huì)Hadoop就要當(dāng)心了，擠出時(shí)間來學(xué)習(xí)Spark和其他新技術(shù)是絕對(duì)必要的；而對(duì)于目前正準(zhǔn)備進(jìn)入大數(shù)據(jù)行業(yè)的朋友們，從Hadoop開始仍然是最好的選擇。長遠(yuǎn)來看新技術(shù)總會(huì)不斷出現(xiàn)，不管是Spark還是Tez似乎都有著更美妙的前景，然而沒有人會(huì)勸你完全拋開Hadoop。

在這里筆者再推薦一堂免費(fèi)的Hadoop公開課>>,有興趣學(xué)習(xí)的朋友可以看一下。