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

[[132867]]

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

回到本題，來說說Hadoop和Spark。Hadoop包括Yarn和HDFS以及MapReduce，說Spark代替Hadoop應該說是代替MpReduce。

上面這些問題，算是每個號稱下一代平臺都嘗試解決的。

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

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

再說Programming Interface，Tez的Interface更像MapReduce，但是允許你定義各種Edge來連接不同邏輯節(jié)點。Spark則利用了 Functional Programming的理念，API十分簡潔，相比MR和Tez簡單到令人發(fā)指。我不清楚Spark如果要表現(xiàn)復雜的DAG會不會也變得很麻煩。

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

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

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

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

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

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