大數(shù)據未來是什么？Spark會宣布Hadoop“死刑”？

說到大數(shù)據，很多人都會提及Hadoop 與 Apache Spark。Hadoop解決了大數(shù)據的可靠存儲和處理問題。但因為其本身的工作流程一板一眼，只擅長靜態(tài)存儲對象的批式處理，有自身的局限和不足。Spark應運而生，受到追捧，甚至被認為是大數(shù)據的未來，將會替代Hadoop。

所以在這里簡要總結下各自的優(yōu)劣勢，并從五個方面比較二者的區(qū)別?？纯碨park是否能宣布Hadoop的“死刑”？

Hadoop和ApacheSpark雖然都是大數(shù)據框架，但他們并不真正服務于同樣的目的。 Hadoop是一個分布式數(shù)據基礎設施：可以支持一個或多個服務器，在集群內跨多個節(jié)點，分配大量數(shù)據集合。這意味著如果你要處理大數(shù)據，有了它就足以解決大數(shù)據的存儲和處理問題，不需要購買昂貴的定制化硬件及維護服務了。 它還也可以索引和跟蹤數(shù)據，使大數(shù)據處理和分析更有效。 另一方面，Spark是一個數(shù)據處理工具，可以做分布式數(shù)據收集，但不能做分布式存儲。

Hadoop不僅是個存儲組件，還包括Hadoop分布式文件系統(tǒng)和被稱作MapReduce的處理組件。所以，人家自身功能很多，你不一定非要用Spark配合。 相反地，不搭建在Hadoop上，也可以單獨使用Spark。但是，由于Spark不自帶文件管理系統(tǒng)，還得結合HDFS或者基于云的數(shù)據平臺。 其實，Spark是專為完善Hadoop而生，因此有人認為在未來會替代Hadoop。但是，大部分人目前通常是采用二者配合來做的方式搭建，更希望二者可以協(xié)作起來，更好地發(fā)揮各自的效用。

Spark通常比MapReduce快得多，因為處理數(shù)據的方式不一樣。 在MapReduce按部就班的處理時，Spark可以對整個數(shù)據集中處理。 有數(shù)據科學家這樣形容MapReduce的工作流程：從集群讀取數(shù)據——執(zhí)行一個操作——將結果寫入集群——從集群中讀取更新的數(shù)據——執(zhí)行下一步操作——寫未來結果到集群……” 另一方面，Spark是基于內存計算，在完成完整的數(shù)據分析操作上，也是接近實時處理的。它的工作流程可以這樣形容：從集群中讀取數(shù)據——執(zhí)行所有必要的分析操作——將結果寫入集群，完成。Spark比MapReduce在批處理上速度快得高達10倍，基于內存計算分析上快100倍。

如果數(shù)據操作和報告需求大多是靜態(tài)的， MapReduce的處理風格完全可以勝任了，你只需耐心等待它的批處理模式來做就行。但是，如果你需要對流數(shù)據做分析，比如工廠里的傳感器數(shù)據，或要處理多個操作的應用程序，這種情況選擇Spark更合適。 例如，大多數(shù)機器學習算法需要多個操作。 Spark常見的應用場景還有：實時營銷活動、在線產品推薦、網絡安全分析和機器的日志監(jiān)控等。

Hadoop對系統(tǒng)故障具備天然抵抗力，因為上文所說的，它的工作流程非常穩(wěn)扎穩(wěn)打：在執(zhí)行每個操作后都會把數(shù)據寫入磁盤，自然便于恢復。而Spark，采用類似的方式，具有內置彈性。 具體來說，其數(shù)據對象存儲在集群數(shù)據里的，彈性分布式數(shù)據集上（即RDD，Spark的核心。它具備像MapReduce等數(shù)據流模型的容錯特性，并且允許開發(fā)人員在大型集群上執(zhí)行基于內存的計算）。這些數(shù)據對象可以存儲在內存或磁盤上，當系統(tǒng)報錯時候，RDD可以幫助全面恢復。

綜上所說，可以看出，二者各有千秋，場景不同所選方案就會不同。不過，大多數(shù)人更愿意看到1+1>2的效果。

注：文章翻譯自cio網站，作者Katherine Noyes。

生成海報

免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現(xiàn)的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。