Spark與Hadoop MapReduce相比，有哪些優點你知道嗎？

一提到大資料處理，相信很多人第一時間想到的是 Hadoop MapReduce。沒錯，Hadoop MapReduce 為大資料處理技術奠定了基礎。近年來，隨著 Spark 的發展，越來越多的聲音提到了 Spark。而Spark相比Hadoop MapReduce有哪些優勢?

Spark與Hadoop MapReduce在業界有兩種說法 ：

一是 Spark 將代替 Hadoop MapReduce，成為未來大資料處理發展的方向 ;

二是 Spark 將會和 Hadoop 結合，形成更大的生態圈。其實 Spark 和 Hadoop MapReduce 的重點應用場合有所不同。

相對於 Hadoop MapReduce 來說，Spark 有點“青出於藍”的感覺，Spark 是在Hadoop MapReduce 模型上發展起來的，在它的身上我們能明顯看到 MapReduce的影子，所有的 Spark 並非從頭創新，而是站在了巨人“MapReduce”的肩膀上。千秋功罪，留於日後評說，我們暫且擱下爭議，來看看相比 Hadoop MapReduce，Spark 都有哪些優勢。

Spark和Hadoop MapReduce

1、計算速度快

大資料處理首先追求的是速度。Spark 到底有多快?用官方的話說，“Spark 允許 Hadoop 叢集中的應用程式在記憶體中以 100 倍的速度執行，即使在磁碟上執行也能快 10 倍”。可能有的讀者看到這裡會大為感嘆，的確如此，在有迭代計算的領域，Spark 的計算速度遠遠超過 MapReduce，並且迭代次數越多，Spark 的優勢越明顯。這是因為 Spark 很好地利用了目前伺服器記憶體越來越大這一優點，通過減少磁碟 I/O 來達到效能提升。它們將中間處理資料全部放到了記憶體中，僅在必要時才批量存入硬碟中。或許讀者會問 ：如果應用程式特別大，記憶體能放下多少 GB ?答曰 ：什麼? GB ?目前 IBM 伺服器記憶體已經擴充套件至幾 TB 了。

2、應用靈活，上手容易

知道 AMPLab 的 Lester 為什麼放棄 MapReduce 嗎?因為他需要把很多精力放到Map和Reduce的程式設計模型上，極為不便。 Spark在簡單的Map及Reduce操作之外，還支援 SQL 查詢、流式查詢及複雜查詢，比如開箱即用的機器學習演算法。同時，使用者可以在同一個工作流中無縫地搭配這些能力，應用十分靈活。歡迎加入大資料學習交流分享群： 658558542   一起吹水交流學習（☛點選即可加入群聊）

Spark 核心部分的程式碼為 63 個 Scala 檔案，非常的輕量級。並且允許 Java、Scala、Python 開發者在自己熟悉的語言環境下進行工作，通過建立在Java、Scala、Python、SQL(應對互動式查詢)的標準 API 以方便各行各業使用，同時還包括大量開箱即用的機器學習庫。它自帶 80 多個高等級操作符，允許在 Shell中進行互動式查詢。即使是新手，也能輕鬆上手應用。

3、相容競爭對手

Spark 可以獨立執行，除了可以執行在當下的 YARN 叢集管理外，還可以讀取已有的任何 Hadoop 資料。它可以執行在任何 Hadoop 資料來源上，比如 HBase、HDFS 等。有了這個特性，讓那些想從 Hadoop 應用遷移到 Spark 上的使用者方便了很多。Spark 有相容競爭對手的胸襟，何愁大事不成?

4、實時處理效能非凡

MapReduce 更 加 適 合 處 理 離 線 數 據( 當 然， 在 YARN 之 後，Hadoop也可以藉助其他工具進行流式計算)。Spark 很好地支援實時的流計算，依賴Spark Streaming 對資料進行實時處理。Spark Streaming 具備功能強大的 API，允許使用者快速開發流應用程式。而且不像其他的流解決方案，比如Storm，Spark Streaming 無須額外的程式碼和配置，就可以做大量的恢復和交付工作。

5、社群貢獻力量巨大

從 Spark 的版本演化來看，足以說明這個平臺旺盛的生命力及社群的活躍度。尤其自 2013 年以來，Spark 一度進入高速發展期，程式碼庫提交與社群活躍度都有顯著增長。以活躍度論，Spark 在所有的 Apache 基金會開源專案中位列前三，相較於其他大資料平臺或框架而言，Spark 的程式碼庫最為活躍。

Spark 非常重視社群活動，組織也極為規範，會定期或不定期地舉行與 Spark相關的會議。會議分為兩種 ：一種是 Spark Summit，影響力極大，可謂全球 Spark頂尖技術人員的峰會，目前已於 2013—2015 年在 San Francisco 連續召開了三屆Summit 大會 ;另一種是 Spark 社群不定期地在全球各地召開的小型 Meetup 活動。Spark Meetup 也會在我國的一些大城市定期召開，比如北京、深圳、西安等地，讀者可以關注當地的微信公眾號進行參與。歡迎加入大資料學習交流分享群： 658558542   一起吹水交流學習（☛點選即可加入群聊）

Spark 的適用場景

從大資料處理需求來看，大資料的業務大概可以分為以下三類 ：

(1)複雜的批量資料處理，通常的時間跨度在數十分鐘到數小時之間。

(2)基於歷史資料的互動式查詢，通常的時間跨度在數十秒到數分鐘之間。

(3)基於實時資料流的資料處理，通常的時間跨度在數百毫秒到數秒之間。

目前已有很多相對成熟的開源和商業軟體來處理以上三種情景 ：第一種業務，可以利用 MapReduce 來進行批量資料處理 ;第二種業務，可以用 Impala 來進行互動式查詢 ;對於第三種流式資料處理，可以想到專業的流資料處理工具Storm。但是這裡有一個很重要的問題 ：對於大多數網際網路公司來說，一般會同時遇到以上三種情景，如果採用不同的處理技術來面對這三種情景，那麼這三種情景的輸入/ 輸出資料無法無縫共享，它們之間可能需要進行格式轉換，並且每個開源軟體都需要一支開發和維護團隊，從而提高了成本。另外一個不便之處就是，在同一個叢集中對各個系統協調資源分配比較困難。歡迎加入大資料學習交流分享群： 658558542   一起吹水交流學習（☛點選即可加入群聊）

那麼，有沒有一種軟體可以同時處理以上三種情景呢? Spark 就可以，或者說有這樣的潛力。Spark 同時支援複雜的批處理、互操作和流計算，而且相容支援HDFS 和 Amazon S3 等分散式檔案系統，可以部署在 YARN 和 Mesos 等流行的叢集資源管理器上。

從 Spark 的設計理念(基於記憶體的迭代計算框架)出發，其最適合有迭代運算的或者需要多次操作特定資料集的應用場合。並且迭代次數越多，讀取的資料量越大，Spark 的應用效果就越明顯。因此，對於機器學習之類的“迭代式”應用，Spark 可謂拿手好戲，要比 Hadoop MapReduce 快數十倍。另外，Spark Streaming因為記憶體儲存中間資料的特性，處理速度非常快，也可以應用於需要實時處理大資料的場合。

當然，Spark 也有不適用的場合。對於那種非同步細粒度更新狀態的應用，例如 Web 服務的儲存或增量的 Web 爬蟲和索引，也就是對於那種增量修改的應用模型不適合。Spark 也不適合做超級大的資料量的處理，這裡所說的“超級大”是相對於這個叢集的記憶體容量而言的，因為 Spark 要將資料儲存在記憶體中。一般來說，10TB 以上(單次分析)的資料就可以算是“超級大”的資料了。

一般來說，對於中小企業的資料中心而言，在單次計算的資料量不大的情況下，Spark 都是很好的選擇。另外，Spark 也不適合應用於混合的雲端計算平臺，因為混合的雲端計算平臺的網路傳輸是很大的問題，即便有專屬的寬頻在雲端 Cluster和本地 Cluster 之間傳輸資料，相比記憶體讀取速度來說，依然不抵。

結語

感謝您的觀看，如有不足之處，歡迎批評指正。

如果有對大資料感興趣的小夥伴或者是從事大資料的老司機可以加群：

658558542    （☛點選即可加入群聊）

裡面整理了一大份學習資料，全都是些乾貨，包括大資料技術入門，海量資料高階分析語言，海量資料儲存分散式儲存，以及海量資料分析分散式計算等部分，送給每一位大資料小夥伴，這裡不止是小白聚集地，還有大牛線上解答！歡迎初學和進階中的小夥伴一起進群學習交流，共同進步！

最後祝福所有遇到瓶頸的大資料程式設計師們突破自己，祝福大家在往後的工作與面試中一切順利。