MapReduce和Spark的區別

性能：

Spark是在內存中處理數據的，而MapReduce是經過map和reduce操做在磁盤中處理數據，因此正常狀況下Spark的處理速度會比mapreduce快。可是當數據量大，不能一次性加載到內存的時候，Spark性能就會下降。

讀取一樣的數據進行迭代計算的話使用Spark，一次性讀取或者ETL用mapreduce更好。

小結：當數據大小適於讀入內存，尤爲是在專用集羣上時，Spark 表現更好；Hadoop MapReduce 適用於那些數據不能所有讀入內存的狀況，同時它還能夠與其它服務同時運行。

 

使用難度

Spark 有着靈活方便的Java，Scala和 Python 的API，同時對已經熟悉 SQL 的技術員工來講， Spark 還適用 Spark SQL（也就是以前被人熟知的 Shark）。多虧了 Spark 提供的簡單易用的構造模塊，咱們能夠很容易的編寫自定義函數。它甚至還囊括了能夠即時反饋的交互式命令模式。

Hadoop MapReduce 是用 Java 編寫的，但因爲其難於編程而備受詬病。儘管須要必定時間去學習語法，Pig 仍是在必定程度上簡化了這個過程， Hive也爲平臺提供了 SQL 的兼容。一些 Hadoop 工具也能夠無需編程直接運行 MapReduce 任務。Xplenty 就是一個基於 Hadoop 的數據整合服務，並且也不須要進行任何編程和部署。

儘管 Hive 提供了命令行接口，但 MapReduce 並無交互式模式。諸如 Impala，Presto 和 Tez 等項目都在嘗試但願爲 Hadoop 提供全交互式查詢模式。

安裝與維護方面， Spark 並不綁定在 Hadoop 上，雖然 在 Hortonworks（HDP 2.2 版） 和 Cloudera（CDH 5 版） 的產品中 Spark 和 Hadoop MapReduce 都包含在其分佈式系統中。（注： Cloudera， Hortonworks 及 MapR 是 Hadoop 領域三大知名的初創公司，致力於打造更好的 Hadoop 企業版應用）。

小結：Spark 更易於編程，同時也包含交互式模式；Hadoop MapReduce 不易編程可是現有的不少工具使其更易於使用。

成本

Spark 和 Hadoop MapReduce 都是開源的，可是機器和人工的花費還是不可避免的。

這兩個框架既能夠在商用服務器上也能夠運行在雲端，下表能夠看到它們有着類似的硬件需求：

框架                 Apache Spark                        Apache Hadoop balanced workload slaves

內核                      8–16                                                           4

內存             8 GB 到數百GB                                                24 GB

硬盤                      4–8                                                        4–6 1TB

網絡                10 GB 或更多                                           1 GB 以太網

Spark 集羣的內存至少要和須要處理的數據塊同樣大，由於只有數據塊和內存大小合適才能發揮出其最優的性能。因此若是真的須要處理很是大的數據，Hadoop 絕對是合適之選，畢竟硬盤的費用要遠遠低於內存的費用。

考慮到 Spark 的性能標準，在執行相同的任務的時候，須要的硬件更少而運行速度卻更快，所以應該是更合算的，尤爲是在雲端的時候，此時只須要即用即付。

在技術人員方面，即便 Hadoop 從 2005 年就開始普及，可是 MapReduce 方面的專家仍然存在着短缺。而對於從 2010 年纔開始普及的 Spark ，這又意味着什麼呢？ 或許投身 Spark 學習的人正在快速增長，可是相比於 Hadoop MapReduce 仍然存在着更大的技術人才的缺口。

進一步講，現存了大量的 Hadoop 即服務的資料和基於 Hadoop 的服務（好比咱們 Xplenty 的數據整合服務），這些都下降對技術人員能力和底層硬件知識的要求。相比之下，幾乎沒有現有可選的 Spark 服務，僅有的那些也是新產品。

小結：根據基準要求， Spark 更加合算， 儘管人工成本會很高。依靠着更多熟練的技術人員和 Hadoop 即服務的供給， Hadoop MapReduce 可能更便宜。

兼容性

Spark 既能夠單獨運行，也能夠在 Hadoop YARN 上，或者在預置 Mesos 上以及雲端。它支持實現 Hadoop 輸入範式的數據源，因此能夠整合全部 Hadoop 支持的數據源和文件格式。 根據 Spark 官方教程， 它還能夠經過 JDBC 和 ODBC 同 BI（商業智能） 工具一塊兒運行。 Hive 和 Pig 也在逐步實現這樣的功能。

小結： Spark 和 Hadoop MapReduce 具備相同的數據類型和數據源的兼容性。

數據處理

除了日常的數據處理，Spark 能夠作的遠不止這點：它還能夠處理圖和利用現有的機器學習庫。高性能也使得 Spark 在實時處理上的表現和批處理上的表現同樣好。這也催生了一個更好的機遇，那就是用一個平臺解決全部問題而不是隻能根據任務選取不一樣的平臺，畢竟全部的平臺都須要學習和維護。

Hadoop MapReduce 在批處理上表現卓越。若是須要進行實時處理，能夠利用另外的平臺好比  Storm 或者 Impala，而圖處理則能夠用 Giraph。MapReduce 過去是用 Mahout 作機器學習的，但其負責人已經將其拋棄轉而支持 Spark 和 h2o（機器學習引擎）。

小結：Spark 是數據處理的瑞士軍刀；Hadoop MapReduce 是批處理的突擊刀。

容錯

和 MapReduce 同樣， Spark 會重試每一個任務並進行預測執行。然而，MapReduce 是依賴於硬盤驅動器的，因此若是一項處理中途失敗，它能夠從失敗處繼續執行，而 Spark 則必須從頭開始執行，因此 MapReduce 這樣節省了時間。

小結：Spark 和 Hadoop MapReduce 都有着較好的容錯能力，可是 Hadoop MapReduce 要稍微更好一點。

安全性

在安全性上， 此時的 Spark 還略顯不足。 受權驗證由共享祕鑰機制支持，網絡用戶接口則經過 servlet 過濾器和事件日誌保護。Spark 能夠運行在 YARN 上並配合使用 HDFS， 這也就意味着它同時還擁有 Kerberos 認證受權驗證，HDFS 文件許可機制和節點間的加密機制。

Hadoop MapReduce 擁有全部 Hadoop 支持的安全機制，同時也整合了其它基於 Hadoop 的安全項目， 好比  Knox 網關和  Sentry。志在解決 Hadoop 安全的  Rhino 項目也只是在添加 Sentry 支持時添加了 Spark 支持。不然 Spark 開發者們只能本身去提高其安全性了。

小結： Spark 的安全機制仍處在發展期。 Hadoop MapReduce 擁有更多安全控制機制和項目。

總結

Spark 是大數據領域冉冉升起的新星，可是 Hadoop MapReduce 仍有着較廣的應用領域。

在內存中進行數據處理使得 Spark 具備較好的性能表現，也比較高效合算。它兼容全部 Hadoop 的數據源和文件格式， 支持多種語言的簡單易用的 API 也令人們更快速的能夠上手。 Spark 甚至實現了圖處理和機器學習工具。

Hadoop MapReduce 是一個更加成熟的平臺，爲進行批處理而生。當遇到確實很是大的數據以致於沒法徹底讀入內存，又或是依靠着大量對該平臺有經驗的技術人員，它可能會比 Spark 更加合算。 並且圍繞 Hadoop MapReduce 的衍生系統正在依靠着更多的支撐項目、工具和雲服務而更加壯大。

可是即便看上去 Spark 像是最終的贏家，問題在於咱們永遠不會單獨使用它—咱們須要 HDFS 存儲數據，或許還會須要用到 HBase，Hive，Pig，Impala 或其餘 Hadoop 項目。這意味着在處理很是大的數據的時候，Spark 仍然須要同 Hadoop 和 MapReduce 共同運行。