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

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

上面這些問(wèn)題，算是每個(gè)號(hào)稱下一代平臺(tái)都嘗試解決的。

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

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

再說(shuō)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ì)也變得很麻煩。

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

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

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

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

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

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