Spark 1.2：向MapReduce在Hadoop中的統治地位發起挑戰
作為面向Hadoop的內存內兼實時數據處理框架，Apache Spark已經在1.0版本正式推出之后逐步邁上發展正軌。在1.2版本中的特性變更證明了Spark并不滿足于對現有成績的持續改進，同時也致力于發展成一款足以應對Hadoop環境下大規模數據處理場景的未來框架。
在Spark 1.2版本的眾多變更當中，最主要的趨勢在于進一步擴大Spark在各類使用方式當中的實用能力。新的彈性擴展系統允許Spark在長期運行任務當中更為出色地發揮集群節點性能，而這一點對于多用戶環境而言顯然已經成為最常見也最迫切的需求。Spark的流功能如今迎來了一款Python API、同時具備了用于支持高可用性場景的預寫入日志方案，這一切都讓Spark在用戶心目中的地位不斷上升。
新版本當中自然不能少了Spark SQL，其允許Spark任務能夠對相關數據執行與Apache Hive類似的查詢操作，而且它現在能夠通過新的API與外部數據源順利協作。作為Hadoop領域的另一大重點，機器學習方案也在Spark新版本的支持下得到了強化，這要歸功于一系列新型API與算法的鼎力協助，此外還有對于Python更出色的支持效果錦上添花。***，Spark的圖形-計算API GraphX目前已經告別alpha測試、開始邁入穩定版本階段。
Spark項目一直在Hadoop世界當中努力推動并拓展兩項發展目標。首先是打破Hadoop長久以來對于MapReudce框架的高度依賴，逐步將處理任務交給YARN、Tez以及Spark等新生代方案承載。數據-應用程序基礎設施方案供應商Concurrent公司CEO Gary Nakamura認為，在未來一年中“經過時間考驗且切實可靠”的MapReduce將繼續在生產環境中擁有壓倒Spark（以及Tez）的市場占有率。然而，MapReduce自身的局限性實在難于忽略，而且這一切已經開始影響到通過它所實現的業務任務。
另一大值得注意的發展趨勢在于，對于Python的支持能力在Spark當中一直處于拓展當中——包括在Hadoop中也一樣。Python在數據處理領域的人氣一直居高不下，同時也非常適合在Hadoop及Spark當中加以使用，但大部分Python支持能力仍然局限于MapReduce任務范疇。通過對Python支持能力的持續推進，可以看到Spark項目已經將著眼點放在傳統企業Java領域之外、開始向真正的通用Hadoop方向進軍。
Spark項目的大部分持續性發展成果一直在由Hadoop廠商Hortonworks公司所貢獻。這家企業已經將Spark與YARN進行了深度整合，并通過Apache Argus項目向其中添加更多安全性與治理手段、且不斷加以改進與調試。
目前擺在面前的***一個、也是過去被無數次批評的問題在于，正如程序員Alex Rubinsteyn所言，Spark項目在調試難度方面實在太過夸張：“Spark項目本身疏于評估，”他寫道，“這使我們很難弄清楚自己程序中的真正瓶頸所在。而且即使大家能夠確定速度較慢的特定表達式，往往也沒辦法弄明白它為什么這么慢或者如何才能使其擁有理想的速度表現。”
英文：http://www.infoworld.com/article/2862225/hadoop/spark-12-challenges-mapreduces-hadoop-dominance.html
對于與 Hadoop 對比，如何看待 Spark 技術？在知乎上Xiaoyu Ma曾這么認為：
我本人是類似Hive平臺的系統工程師，我對MapReduce的熟悉程度是一般，它是我的底層框架。我隔壁組在實驗Spark，想將一部分計算遷移到Spark上。
年初的時候，看Spark的評價，幾乎一致表示，Spark是小數據集上處理復雜迭代的交互系統，并不擅長大數據集，也沒有穩定性。但是最近的風評已經變化，尤其是14年10月他們完成了Peta sort的實驗，這標志著Spark越來越接近替代Hadoop MapReduce了。
Spark the fastest open source engine for sorting a petabyte
Sort和Shuffle是MapReduce上最核心的操作之一，比如上千個Mapper之后，按照Key將數據集分發到對應的Reducer上，要走一個復雜的過程，要平衡各種因素。Spark能處理Peta sort的話，本質上已經沒有什么能阻止它處理Peta級別的數據了。這差不多遠超大多數公司單次Job所需要處理的數據上限了。
回到本題，來說說Hadoop和Spark。Hadoop包括Yarn和HDFS以及MapReduce，說Spark代替Hadoop應該說是代替MapReduce。
MapReduce的缺陷很多，***的缺陷之一是Map ＋ Reduce的模型。這個模型并不適合描述復雜的數據處理過程。很多公司（包括我們）把各種奇怪的Machine Learning計算用MR模型描述，不斷挖（lan）掘（yong）MR潛力，對系統工程師和Ops也是極大挑戰了。很多計算，本質上并不是一個Map，Shuffle再Reduce的結構，比如我編譯一個SubQuery的SQL，每個Query都做一次Group By，我可能需要Map，Reduce＋Reduce，中間不希望有無用的Map；又或者我需要Join，這對MapReduce來說簡直是噩夢，什么給左右表加標簽，小表用Distributed Cache分發，各種不同Join的Hack，都是因為MapReduce本身是不直接支持Join的，其實我需要的是，兩組不同的計算節點掃描了數據之后按照Key分發數據到下一個階段再計算，就這么簡單的規則而已；再或者我要表示一組復雜的數據Pipeline，數據在一個無數節點組成的圖上流動，而因為MapReduce的呆板模型，我必須一次一次在一個Map/Reduce步驟完成之后不必要地把數據寫到磁盤上再讀出，才能繼續下一個節點，因為Map Reduce2個階段完成之后，就算是一個獨立計算步驟完成，必定會寫到磁盤上等待下一個Map Reduce計算。
上面這些問題，算是每個號稱下一代平臺都嘗試解決的。
現在號稱次世代平臺現在做的相對有前景的是Hortonworks的Tez和Databricks的Spark。他們都嘗試解決了上面說的那些問題。Tez和Spark都可以很自由地描述一個Job里執行流（所謂DAG，有向無環圖）。他們相對現在的MapReduce模型來說，極大的提升了對各種復雜處理的直接支持，不需要再絞盡腦汁“挖掘”MR模型的潛力。
有興趣的童鞋可以看看這個PPT
http://www.slideshare.net/Hadoop_Summit/w-235phall1pandey
這是Hadoop峰會上Tez的材料，第九頁開始有描述Hive on Tez和傳統MR Hive的區別，這些區別應該也適用于MR Hive和Spark SQL，也很清楚的體現了為何MR模型很笨重。
相比Tez，Spark加入了更多內存Cache操作，但據了解它也是可以不Cache直接處理的，只是效率就會下降。
再說Programming Interface，Tez的Interface更像MapReduce，但是允許你定義各種Edge來連接不同邏輯節點。Spark則利用了Functional Programming的理念，API十分簡潔，相比MR和Tez簡單到令人發指。我不清楚Spark如果要表現復雜的DAG會不會也變得很麻煩，但是至少wordcount的例子看起來是這樣的，大家可以比較感受下：
incubator-tez/WordCount.java at master · apache/incubator-tez · GitHub
處理大規模數據而言，他們都需要更多proven cases。至少Hadoop MapReduce是被證明可行的。
作為Data Pipeline引擎來說，MapReduce每個步驟都會存盤，而Spark和Tez可以直接網絡發送到下一個步驟，速度上是相差很多的，但是存盤的好處是允許繼續在失敗的數據上繼續跑，所以直觀上說MapReduce作為pipeline引擎更穩健。但理論上來說，如果選擇在每個完成的小步驟上加CheckPoint，那Tez和Spark完全能和現在的MapReduce達到一樣的穩健。
總結來說，即便現在不成熟，但是并沒有什么阻礙他們代替現有的MapReduce Batch Process。
對Tez而言，似乎商業上宣傳不如Spark成功。Databricks頭頂Berkley的光環，商業宣傳又十分老道，陣營增長極快。光就系統設計理念，沒有太大的優劣，但是商業上可能會拉開差距。Cloudera也加入了Spark陣營，以及很多其他大小公司，可以預見的是，Spark會成熟的很快，相比Tez。
但Tez對于Hortonworks來說是贏取白富美的關鍵，相信為了幸福他們也必須努力打磨推廣tez。
所以就算現在各家試用會有種種問題，但是畢竟現在也就出現了2個看起來有戲的“次世代”平臺，那慢慢試用，不斷觀望，逐步替換，會是大多數公司的策略。
