相信大家都聽說過火的不能再火、炒得不能再炒的新一代大數(shù)據(jù)處理框架 Spark. 那么 Spark 是何方神圣？為何大有取代 Hadoop 的勢頭？Spark 內(nèi)部又是如何工作的呢？我們會用幾篇文章為大家一一介紹。

還是從 Hadoop 處理海量數(shù)據(jù)的架構(gòu)說起，一個 Hadoop job 通常都是這樣的：

• 從 HDFS 讀取輸入數(shù)據(jù)；

• 在 Map 階段使用用戶定義的 mapper function, 然后把結(jié)果寫入磁盤；

• 在 Reduce 階段，從各個處于 Map 階段的機器中讀取 Map 計算的中間結(jié)果，使用用戶定義的 reduce function, 通常最后把結(jié)果寫回 HDFS;

不知道大家是否注意到，一個 Hadoop job 進行了多次磁盤讀寫，比如寫入機器本地磁盤，或是寫入分布式文件系統(tǒng)中（這個過程包含磁盤的讀寫以及網(wǎng)絡傳輸）。考慮到磁盤讀取比內(nèi)存讀取慢了幾個數(shù)量級，所以像 Hadoop 這樣高度依賴磁盤讀寫的架構(gòu)就一定會有性能瓶頸。

在實際應用中，我們通常需要設計復雜算法處理海量數(shù)據(jù)，比如之前提過的 Google crawling indexing ranking, 顯然不是一個 Hadoop job 可以完成的。再比如現(xiàn)在風生水起的機器學習領域，大量使用迭代的方法訓練機器學習模型。而像 Hadoop 的基本模型就只包括了一個 Map 和 一個 Reduce 階段，想要完成復雜運算就需要切分出無數(shù)單獨的 Hadoop jobs, 而且每個 Hadoop job 都是磁盤讀寫大戶，這就讓 Hadoop 顯得力不從心。

隨著業(yè)界對大數(shù)據(jù)使用越來越深入，大家都呼喚一個更強大的處理框架，能夠真正解決更多復雜的大數(shù)據(jù)問題。

Spark 橫空出世

2009年，美國加州大學伯克利分校的 AMPLab 設計并開發(fā)了名叫 Spark 的大數(shù)據(jù)處理框架。真如其名，Spark 像燎原之火，迅猛占領大數(shù)據(jù)處理框架市場。

性能優(yōu)秀

Spark 沒有像 Hadoop 一樣使用磁盤讀寫，而轉(zhuǎn)用性能高得多的內(nèi)存存儲輸入數(shù)據(jù)、處理中間結(jié)果、和存儲最終結(jié)果。在大數(shù)據(jù)的場景中，很多計算都有循環(huán)往復的特點，像 Spark 這樣允許在內(nèi)存中緩存輸入輸出，上一個 job 的結(jié)果馬上可以被下一個使用，性能自然要比 Hadoop MapReduce 好得多。

同樣重要的是，Spark 提供了更多靈活可用的數(shù)據(jù)操作，比如 filter, union, join, 以及各種對 key value pair 的方便操作，甚至提供了一個通用接口，讓用戶根據(jù)需要開發(fā)定制的數(shù)據(jù)操作。

此外，Spark 本身作為平臺也開發(fā)了 streaming 處理框架 spark streaming, SQL 處理框架 Dataframe, 機器學習庫 MLlib, 和圖處理庫 GraphX. 如此強大，如此開放，基于 Spark 的操作，應有盡有。

Hadoop 的 MapReduce 為什么不使用內(nèi)存存儲？選擇依賴 HDFS，豈不給了后來者據(jù)上的機會？

歷史原因。當初 MapReduce 選擇磁盤，除了要保證數(shù)據(jù)存儲安全以外，更重要的是當時企業(yè)級數(shù)據(jù)中心購買大容量內(nèi)存的成本非常高，選擇基于內(nèi)存的架構(gòu)并不現(xiàn)實；現(xiàn)在 Spark 真的趕上了好時候，企業(yè)可以輕松部署多臺大內(nèi)存機器，內(nèi)存大到可以裝載所有要處理的數(shù)據(jù)。

更加上這兩年機器學習算法越來越豐富，越來越成熟，真正能夠為企業(yè)解決問題。那當一個企業(yè)想要使用大數(shù)據(jù)處理框架時，是使用拿來就可以用、強大支持的 Spark ？還是去改進 Hadoop 的性能和通用性？顯然是前者。

基于以上種種原因，我們看 Spark 被炒得這么火，也就不足為奇了。

只要把 Hadoop 的 MapReduce 轉(zhuǎn)為基于內(nèi)存的架構(gòu)不就解決了？聽起來沒有本質(zhì)變化嘛。

非也。MapReduce 定死了 Map 和 Reduce 兩種運算以及之間 shuffle 的數(shù)據(jù)搬運工作。就是 Hadoop 運算無論多么靈活，你都要走 map -> shuffle -> reduce 這條路。要支持各類不同的運算，以及優(yōu)化性能，還真不是改個存儲介質(zhì)這么簡單。AMPLab 為此做了精心設計，讓各種數(shù)據(jù)處理都能得心應手。

展望

今天這篇文章我們對比了 Hadoop 和 Spark 的不同之處，以及 Spark 的誕生和生態(tài)環(huán)境。其實 Spark 有很多設計精妙之處，接下來我們的系列文章會繼續(xù)介紹 Spark 的內(nèi)部細節(jié)，歡迎大家持續(xù)關注。

作者：Joseph Holy
鏈接：https://zhuanlan.zhihu.com/p/20305882
來源：知乎

有對大數(shù)據(jù)感興趣的小伙伴嗎？可以加入我們免費獲取大數(shù)據(jù)資料視頻等，想要學習大數(shù)據(jù)的小伙伴，我們這里有經(jīng)驗豐富，博學多識，幽默風趣的老師們，現(xiàn)在報班還有精美禮物和各種優(yōu)惠等著你哦~