相比Hadoop,如何看待Spark技術?
之前看Spark的評價，幾乎一致表示，Spark是小數據集上處理復雜迭代的交互系統，并不擅長大數據集，也沒有穩定性。但是最近的風評已經變 化，尤其是14年10月他們完成了Peta sort的實驗，這標志著Spark越來越接近替代Hadoop MapReduce了。
Sort和Shuffle是MapReduce上最核心的操作之一，比如上千個Mapper之后，按照Key將數據集分發到對應的Reducer上，要走一個復雜的過程，要平衡各種因素。Spark能處理Peta sort的話，本質上已經沒有什么能阻止它處理Peta級別的數據了。這差不多遠超大多數公司單次Job所需要處理的數據上限了。
回到本題，來說說Hadoop和Spark。Hadoop包括Yarn和HDFS以及MapReduce，說Spark代替Hadoop應該說是代替MpReduce。
上面這些問題，算是每個號稱下一代平臺都嘗試解決的。
現在號稱次世代平臺現在做的相對有前景的是Hortonworks的Tez和Databricks的Spark。他們都嘗試解決了上面說的那些問 題。Tez和Spark都可以很自由地描述一個Job里執行流（所謂DAG，有向無環圖）。他們相對現在的MapReduce模型來說，極大的提升了對各 種復雜處理的直接支持，不需要再絞盡腦汁“挖掘”MR模型的潛力。=
相比Tez，Spark加入了更多內存Cache操作，但據了解它也是可以不Cache直接處理的，只是效率就會下降。
再說Programming Interface，Tez的Interface更像MapReduce，但是允許你定義各種Edge來連接不同邏輯節點。Spark則利用了 Functional Programming的理念，API十分簡潔，相比MR和Tez簡單到令人發指。我不清楚Spark如果要表現復雜的DAG會不會也變得很麻煩。
處理大規模數據而言，他們都需要更多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個看起來有戲的“次世代”平臺，那慢慢試用，不斷觀望，逐步替換，會是大多數公司的策略。
