最近公司邀請來王家林老師來做培訓(xùn)，其浮夸的授課方式略接受不了。其強(qiáng)烈推崇Spark技術(shù)，宣稱Spark是大數(shù)據(jù)的未來，同時宣布了Hadoop的死刑。
那么與Hadoop相比，Spark技術(shù)如何？現(xiàn)工業(yè)界大數(shù)據(jù)技術(shù)都在使用何種技術(shù)？
來自Xiaoyu Ma，號稱是大數(shù)據(jù)工程師 的回答：
我本人是類似Hive平臺的系統(tǒng)工程師，我對MapReduce的熟悉程度是一般，它是我的底層框架。我隔壁組在實驗Spark，想將一部分計算遷移到Spark上。
年初的時候，看Spark的評價，幾乎一致表示，Spark是小數(shù)據(jù)集上處理復(fù)雜迭代的交互系統(tǒng)，并不擅長大數(shù)據(jù)集，也沒有穩(wěn)定性。但是最近的風(fēng)評已經(jīng)變化，尤其是14年10月他們完成了Peta sort的實驗，這標(biāo)志著Spark越來越接近替代Hadoop MapReduce了。
Spark the fastest open source engine for sorting a petabyte
Sort和Shuffle是MapReduce上最核心的操作之一，比如上千個Mapper之后，按照Key將數(shù)據(jù)集分發(fā)到對應(yīng)的Reducer上，要走一個復(fù)雜的過程，要平衡各種因素。Spark能處理Peta sort的話，本質(zhì)上已經(jīng)沒有什么能阻止它處理Peta級別的數(shù)據(jù)了。這差不多遠(yuǎn)超大多數(shù)公司單次Job所需要處理的數(shù)據(jù)上限了。
回到本題，來說說Hadoop和Spark。Hadoop包括Yarn和HDFS以及MapReduce，說Spark代替Hadoop應(yīng)該說是代替MapReduce。
MapReduce的缺陷很多，最大的缺陷之一是Map ＋ Reduce的模型。這個模型并不適合描述復(fù)雜的數(shù)據(jù)處理過程。很多公司（包括我們）把各種奇怪的Machine Learning計算用MR模型描述，不斷挖（lan）掘（yong）MR潛力，對系統(tǒng)工程師和Ops也是極大挑戰(zhàn)了。很多計算，本質(zhì)上并不是一個Map，Shuffle再Reduce的結(jié)構(gòu)，比如我編譯一個SubQuery的SQL，每個Query都做一次Group By，我可能需要Map，Reduce＋Reduce，中間不希望有無用的Map；又或者我需要Join，這對MapReduce來說簡直是噩夢，什么給左右表加標(biāo)簽，小表用Distributed Cache分發(fā)，各種不同Join的Hack，都是因為MapReduce本身是不直接支持Join的，其實我需要的是，兩組不同的計算節(jié)點(diǎn)掃描了數(shù)據(jù)之后按照Key分發(fā)數(shù)據(jù)到下一個階段再計算，就這么簡單的規(guī)則而已；再或者我要表示一組復(fù)雜的數(shù)據(jù)Pipeline，數(shù)據(jù)在一個無數(shù)節(jié)點(diǎn)組成的圖上流動，而因為MapReduce的呆板模型，我必須一次一次在一個Map/Reduce步驟完成之后不必要地把數(shù)據(jù)寫到磁盤上再讀出，才能繼續(xù)下一個節(jié)點(diǎn)，因為Map Reduce2個階段完成之后，就算是一個獨(dú)立計算步驟完成，必定會寫到磁盤上等待下一個Map Reduce計算。
上面這些問題，算是每個號稱下一代平臺都嘗試解決的。
現(xiàn)在號稱次世代平臺現(xiàn)在做的相對有前景的是Hortonworks的Tez和Databricks的Spark。他們都嘗試解決了上面說的那些問題。Tez和Spark都可以很自由地描述一個Job里執(zhí)行流（所謂DAG，有向無環(huán)圖）。他們相對現(xiàn)在的MapReduce模型來說，極大的提升了對各種復(fù)雜處理的直接支持，不需要再絞盡腦汁“挖掘”MR模型的潛力。
有興趣的童鞋可以看看這個PPT
http://www.slideshare.net/Hadoop_Summit/w-235phall1pandey
這是Hadoop峰會上Tez的材料，第九頁開始有描述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直接處理的，只是效率就會下降。
再說Programming Interface，Tez的Interface更像MapReduce，但是允許你定義各種Edge來連接不同邏輯節(jié)點(diǎn)。Spark則利用了Functional Programming的理念，API十分簡潔，相比MR和Tez簡單到令人發(fā)指。我不清楚Spark如果要表現(xiàn)復(fù)雜的DAG會不會也變得很麻煩，但是至少wordcount的例子看起來是這樣的，大家可以比較感受下：
incubator-tez/WordCount.java at master · apache/incubator-tez · GitHub
Examples | Apache Spark
處理大規(guī)模數(shù)據(jù)而言，他們都需要更多proven cases。至少Hadoop MapReduce是被證明可行的。
作為Data Pipeline引擎來說，MapReduce每個步驟都會存盤，而Spark和Tez可以直接網(wǎng)絡(luò)發(fā)送到下一個步驟，速度上是相差很多的，但是存盤的好處是允許繼續(xù)在失敗的數(shù)據(jù)上繼續(xù)跑，所以直觀上說MapReduce作為pipeline引擎更穩(wěn)健。但理論上來說，如果選擇在每個完成的小步驟上加CheckPoint，那Tez和Spark完全能和現(xiàn)在的MapReduce達(dá)到一樣的穩(wěn)健。
總結(jié)來說，即便現(xiàn)在不成熟，但是并沒有什么阻礙他們代替現(xiàn)有的MapReduce Batch Process。
對Tez而言，似乎商業(yè)上宣傳不如Spark成功。Databricks頭頂Berkley的光環(huán)，商業(yè)宣傳又十分老道，陣營增長極快。光就系統(tǒng)設(shè)計理念，沒有太大的優(yōu)劣，但是商業(yè)上可能會拉開差距。Cloudera也加入了Spark陣營，以及很多其他大小公司，可以預(yù)見的是，Spark會成熟的很快，相比Tez。
但Tez對于Hortonworks來說是贏取白富美的關(guān)鍵，相信為了幸福他們也必須努力打磨推廣tez。
所以就算現(xiàn)在各家試用會有種種問題，但是畢竟現(xiàn)在也就出現(xiàn)了2個看起來有戲的“次世代”平臺，那慢慢試用，不斷觀望，逐步替換，會是大多數(shù)公司的策略。
————————————————————————————————
來自 紀(jì)路，大數(shù)據(jù)工程師/自由軟件擁護(hù)者/Pythoner/…的回答：
我根據(jù)我有限的知識對Hadoop和Spark做一下對比，在附加一點(diǎn)自己的評論就好了。
原生語言：hadoop-JAVA，Spark-scala
評注：雖然可以實現(xiàn)接口，但原生的語言就是好用，如果某人痛恨java，Spark給你一條生路。
計算模型：hadoop-MapReduce，Spark-DAG（有向無環(huán)圖）
評注：經(jīng)常有人說Spark就是內(nèi)存版的MapReduce，實際上不是的。Spark使用的DAG計算模型可以有效的減少M(fèi)ap和Reduce人物之間傳遞的數(shù)據(jù)，尤其適合反復(fù)迭代的機(jī)器學(xué)習(xí)場景。而Hadoop則更擅長批處理。不過Tez也是使用的DAG計算模型，他也是Hadoop，明眼人都知道DAG計算模型比MR更好。
存儲：hadoop-HDFS， Spark-RDD，HDFS
評注：spark既可以僅用內(nèi)存存儲，也可以在HDFS上存儲，即使Spark在HDFS上存儲，DAG計算模型在迭代計算上還是比MR的更有效率。
我并不覺得這兩個及系統(tǒng)又大多的矛盾，只不過Spark一直宣稱比hadoop快而已。實際上從應(yīng)用場景上區(qū)分，Hadoop更適合做批處理，而Spark更適合做需要反復(fù)迭代的機(jī)器學(xué)習(xí)。
京公網(wǎng)安備 11010502049343號