[[125258]] 

作為面向Hadoop的內(nèi)存內(nèi)兼實(shí)時(shí)數(shù)據(jù)處理框架，Apache Spark已經(jīng)在1.0版本正式推出之后逐步邁上發(fā)展正軌。在1.2版本中的特性變更證明了Spark并不滿足于對(duì)現(xiàn)有成績(jī)的持續(xù)改進(jìn)，同時(shí)也致力于發(fā)展成一款足以應(yīng)對(duì)Hadoop環(huán)境下大規(guī)模數(shù)據(jù)處理場(chǎng)景的未來(lái)框架。

在Spark 1.2版本的眾多變更當(dāng)中，最主要的趨勢(shì)在于進(jìn)一步擴(kuò)大Spark在各類使用方式當(dāng)中的實(shí)用能力。新的彈性擴(kuò)展系統(tǒng)允許Spark在長(zhǎng)期運(yùn)行任務(wù)當(dāng)中更為出色地發(fā)揮集群節(jié)點(diǎn)性能，而這一點(diǎn)對(duì)于多用戶環(huán)境而言顯然已經(jīng)成為最常見也最迫切的需求。Spark的流功能如今迎來(lái)了一款Python API、同時(shí)具備了用于支持高可用性場(chǎng)景的預(yù)寫入日志方案，這一切都讓Spark在用戶心目中的地位不斷上升。

新版本當(dāng)中自然不能少了Spark SQL，其允許Spark任務(wù)能夠?qū)ο嚓P(guān)數(shù)據(jù)執(zhí)行與Apache Hive類似的查詢操作，而且它現(xiàn)在能夠通過新的API與外部數(shù)據(jù)源順利協(xié)作。作為Hadoop領(lǐng)域的另一大重點(diǎn)，機(jī)器學(xué)習(xí)方案也在Spark新版本的支持下得到了強(qiáng)化，這要?dú)w功于一系列新型API與算法的鼎力協(xié)助，此外還有對(duì)于Python更出色的支持效果錦上添花。***，Spark的圖形-計(jì)算API GraphX目前已經(jīng)告別alpha測(cè)試、開始邁入穩(wěn)定版本階段。

Spark項(xiàng)目一直在Hadoop世界當(dāng)中努力推動(dòng)并拓展兩項(xiàng)發(fā)展目標(biāo)。首先是打破Hadoop長(zhǎng)久以來(lái)對(duì)于MapReudce框架的高度依賴，逐步將處理任務(wù)交給YARN、Tez以及Spark等新生代方案承載。數(shù)據(jù)-應(yīng)用程序基礎(chǔ)設(shè)施方案供應(yīng)商Concurrent公司CEO Gary Nakamura認(rèn)為，在未來(lái)一年中“經(jīng)過時(shí)間考驗(yàn)且切實(shí)可靠”的MapReduce將繼續(xù)在生產(chǎn)環(huán)境中擁有壓倒Spark（以及Tez）的市場(chǎng)占有率。然而，MapReduce自身的局限性實(shí)在難于忽略，而且這一切已經(jīng)開始影響到通過它所實(shí)現(xiàn)的業(yè)務(wù)任務(wù)。

另一大值得注意的發(fā)展趨勢(shì)在于，對(duì)于Python的支持能力在Spark當(dāng)中一直處于拓展當(dāng)中——包括在Hadoop中也一樣。Python在數(shù)據(jù)處理領(lǐng)域的人氣一直居高不下，同時(shí)也非常適合在Hadoop及Spark當(dāng)中加以使用，但大部分Python支持能力仍然局限于MapReduce任務(wù)范疇。通過對(duì)Python支持能力的持續(xù)推進(jìn)，可以看到Spark項(xiàng)目已經(jīng)將著眼點(diǎn)放在傳統(tǒng)企業(yè)Java領(lǐng)域之外、開始向真正的通用Hadoop方向進(jìn)軍。

Spark項(xiàng)目的大部分持續(xù)性發(fā)展成果一直在由Hadoop廠商Hortonworks公司所貢獻(xiàn)。這家企業(yè)已經(jīng)將Spark與YARN進(jìn)行了深度整合，并通過Apache Argus項(xiàng)目向其中添加更多安全性與治理手段、且不斷加以改進(jìn)與調(diào)試。

目前擺在面前的***一個(gè)、也是過去被無(wú)數(shù)次批評(píng)的問題在于，正如程序員Alex Rubinsteyn所言，Spark項(xiàng)目在調(diào)試難度方面實(shí)在太過夸張：“Spark項(xiàng)目本身疏于評(píng)估，”他寫道，“這使我們很難弄清楚自己程序中的真正瓶頸所在。而且即使大家能夠確定速度較慢的特定表達(dá)式，往往也沒辦法弄明白它為什么這么慢或者如何才能使其擁有理想的速度表現(xiàn)。”

英文：http://www.infoworld.com/article/2862225/hadoop/spark-12-challenges-mapreduces-hadoop-dominance.html

對(duì)于與 Hadoop 對(duì)比，如何看待 Spark 技術(shù)？在知乎上Xiaoyu Ma曾這么認(rèn)為：

我本人是類似Hive平臺(tái)的系統(tǒng)工程師，我對(duì)MapReduce的熟悉程度是一般，它是我的底層框架。我隔壁組在實(shí)驗(yàn)Spark，想將一部分計(jì)算遷移到Spark上。

年初的時(shí)候，看Spark的評(píng)價(jià)，幾乎一致表示，Spark是小數(shù)據(jù)集上處理復(fù)雜迭代的交互系統(tǒng)，并不擅長(zhǎng)大數(shù)據(jù)集，也沒有穩(wěn)定性。但是最近的風(fēng)評(píng)已經(jīng)變化，尤其是14年10月他們完成了Peta sort的實(shí)驗(yàn)，這標(biāo)志著Spark越來(lái)越接近替代Hadoop MapReduce了。

Spark the fastest open source engine for sorting a petabyte

Sort和Shuffle是MapReduce上最核心的操作之一，比如上千個(gè)Mapper之后，按照Key將數(shù)據(jù)集分發(fā)到對(duì)應(yīng)的Reducer上，要走一個(gè)復(fù)雜的過程，要平衡各種因素。Spark能處理Peta sort的話，本質(zhì)上已經(jīng)沒有什么能阻止它處理Peta級(jí)別的數(shù)據(jù)了。這差不多遠(yuǎn)超大多數(shù)公司單次Job所需要處理的數(shù)據(jù)上限了。

回到本題，來(lái)說說Hadoop和Spark。Hadoop包括Yarn和HDFS以及MapReduce，說Spark代替Hadoop應(yīng)該說是代替MapReduce。

MapReduce的缺陷很多，***的缺陷之一是Map ＋ Reduce的模型。這個(gè)模型并不適合描述復(fù)雜的數(shù)據(jù)處理過程。很多公司（包括我們）把各種奇怪的Machine Learning計(jì)算用MR模型描述，不斷挖（lan）掘（yong）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，中間不希望有無(wú)用的Map；又或者我需要Join，這對(duì)MapReduce來(lái)說簡(jiǎn)直是噩夢(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ì)算，就這么簡(jiǎn)單的規(guī)則而已；再或者我要表示一組復(fù)雜的數(shù)據(jù)Pipeline，數(shù)據(jù)在一個(gè)無(wú)數(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)都嘗試解決的。

現(xiàn)在號(hào)稱次世代平臺(tái)現(xiàn)在做的相對(duì)有前景的是Hortonworks的Tez和Databricks的Spark。他們都嘗試解決了上面說的那些問題。Tez和Spark都可以很自由地描述一個(gè)Job里執(zhí)行流（所謂DAG，有向無(wú)環(huán)圖）。他們相對(duì)現(xiàn)在的MapReduce模型來(lái)說，極大的提升了對(duì)各種復(fù)雜處理的直接支持，不需要再絞盡腦汁“挖掘”MR模型的潛力。

有興趣的童鞋可以看看這個(gè)PPT

http://www.slideshare.net/Hadoop_Summit/w-235phall1pandey

這是Hadoop峰會(huì)上Tez的材料，第九頁(yè)開始有描述Hive on Tez和傳統(tǒng)MR Hive的區(qū)別，這些區(qū)別應(yīng)該也適用于MR Hive和Spark SQL，也很清楚的體現(xiàn)了為何MR模型很笨重。

相比Tez，Spark加入了更多內(nèi)存Cache操作，但據(jù)了解它也是可以不Cache直接處理的，只是效率就會(huì)下降。

再說Programming Interface，Tez的Interface更像MapReduce，但是允許你定義各種Edge來(lái)連接不同邏輯節(jié)點(diǎn)。Spark則利用了Functional Programming的理念，API十分簡(jiǎn)潔，相比MR和Tez簡(jiǎn)單到令人發(fā)指。我不清楚Spark如果要表現(xiàn)復(fù)雜的DAG會(huì)不會(huì)也變得很麻煩，但是至少wordcount的例子看起來(lái)是這樣的，大家可以比較感受下：

incubator-tez/WordCount.java at master · apache/incubator-tez · GitHub

Examples | Apache Spark

處理大規(guī)模數(shù)據(jù)而言，他們都需要更多proven cases。至少Hadoop MapReduce是被證明可行的。

作為Data Pipeline引擎來(lái)說，MapReduce每個(gè)步驟都會(huì)存盤，而Spark和Tez可以直接網(wǎng)絡(luò)發(fā)送到下一個(gè)步驟，速度上是相差很多的，但是存盤的好處是允許繼續(xù)在失敗的數(shù)據(jù)上繼續(xù)跑，所以直觀上說MapReduce作為pipeline引擎更穩(wěn)健。但理論上來(lái)說，如果選擇在每個(gè)完成的小步驟上加CheckPoint，那Tez和Spark完全能和現(xiàn)在的MapReduce達(dá)到一樣的穩(wěn)健。

總結(jié)來(lái)說，即便現(xiàn)在不成熟，但是并沒有什么阻礙他們代替現(xiàn)有的MapReduce Batch Process。

對(duì)Tez而言，似乎商業(yè)上宣傳不如Spark成功。Databricks頭頂Berkley的光環(huán)，商業(yè)宣傳又十分老道，陣營(yíng)增長(zhǎng)極快。光就系統(tǒng)設(shè)計(jì)理念，沒有太大的優(yōu)劣，但是商業(yè)上可能會(huì)拉開差距。Cloudera也加入了Spark陣營(yíng)，以及很多其他大小公司，可以預(yù)見的是，Spark會(huì)成熟的很快，相比Tez。

但Tez對(duì)于Hortonworks來(lái)說是贏取白富美的關(guān)鍵，相信為了幸福他們也必須努力打磨推廣tez。

所以就算現(xiàn)在各家試用會(huì)有種種問題，但是畢竟現(xiàn)在也就出現(xiàn)了2個(gè)看起來(lái)有戲的“次世代”平臺(tái)，那慢慢試用，不斷觀望，逐步替換，會(huì)是大多數(shù)公司的策略。