五分鐘零基礎介紹 spark

相信大家都聽說過火的不能再火、炒得不能再炒的新一代大資料處理架構 Spark. 那麼 Spark 是何方神聖？為何大有取代 Hadoop 的勢頭？Spark 内部又是如何工作的呢？我們會用幾篇文章為大家一一介紹。

Hadoop：我不想知道我是怎麼來的，我就想知道我是怎麼沒的？

還是從 Hadoop 處理海量資料的架構說起，一個 Hadoop job 通常都是這樣的：

從 HDFS 讀取輸入資料；

在 Map 階段使用使用者定義的 mapper function, 然後把結果寫入磁盤；

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

不知道大家是否注意到，一個 Hadoop job 進行了多次磁盤讀寫，比如寫入機器本地磁盤，或是寫入分布式檔案系統中（這個過程包含磁盤的讀寫以及網絡傳輸）。考慮到磁盤讀取比記憶體讀取慢了幾個數量級，是以像 Hadoop 這樣高度依賴磁盤讀寫的架構就一定會有性能瓶頸。

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

随着業界對大資料使用越來越深入，大家都呼喚一個更強大的處理架構，能夠真正解決更多複雜的

遊戲賬号交易

大資料問題。

Spark 橫空出世

2009年，美國加州大學伯克利分校的 AMPLab 設計并開發了名叫 Spark 的大資料處理架構。真如其名，Spark 像燎原之火，迅猛占領大資料處理架構市場。

性能優秀

Spark 沒有像 Hadoop 一樣使用磁盤讀寫，而轉用性能高得多的記憶體存儲輸入資料、進行中間結果、和存儲最終結果。在大資料的場景中，很多計算都有循環往複的特點，像 Spark 這樣允許在記憶體中緩存輸入輸出，上一個 job 的結果馬上可以被下一個使用，性能自然要比 Hadoop MapReduce 好得多。

同樣重要的是，Spark 提供了更多靈活可用的資料操作，比如 filter, union, join, 以及各種對 key value pair 的友善操作，甚至提供了一個通用接口，讓使用者根據需要開發定制的資料操作。

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

Hadoop 的 MapReduce 為什麼不使用記憶體存儲？選擇依賴 HDFS，豈不給了後來者據上的機會？

曆史原因。當初 MapReduce 選擇磁盤，除了要保證資料存儲安全以外，更重要的是當時企業級資料中心購買大容量記憶體的成本非常高，選擇基于記憶體的架構并不現實；現在 Spark 真的趕上了好時候，企業可以輕松部署多台大記憶體機器，記憶體大到可以裝載所有要處理的資料。

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

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

隻要把 Hadoop 的 MapReduce 轉為基于記憶體的架構不就解決了？聽起來沒有本質變化嘛。

非也。MapReduce 定死了 Map 和 Reduce 兩種運算以及之間 shuffle 的資料搬運工作。就是 Hadoop 運算無論多麼靈活，你都要走 map -> shuffle -> reduce 這條路。要支援各類不同的運算，以及優化性能，還真不是改個存儲媒體這麼簡單。AMPLab 為此做了精心設計，讓各種資料處理都能得心應手。

展望

今天這篇文章我們對比了 Hadoop 和 Spark 的不同之處，以及 Spark 的誕生和生态環境。其實 Spark 有很多設計精妙之處。