中國IDC圈5月20日報道，Apache 基金會下的 Spak 再次引爆了大數據的話題。帶著比 Hadoop MapReduce 速度要快 100 倍的理睬以及越發機動利便的 API，一些人認為這或者預示著 Hadoop MapReduce 的終結。

作為一個開源的數據處，Spark 是如何做到如此迅速地處理懲罰數據的呢?奧秘就在于它是運行在集群的內存上的，并且不受限于 MapReduce 的二階段范式。這大大加速了反復會見同一數據的速度。

Spark 既可以單獨運行，也可以運行在 Hadoop YARN 上(注：Hadoop第二代框架中的改造框架，用于將資源打點和處理懲罰組件分隔，基于YARN的布局不受 MapReduce 約束)，此時 Spark 可以直接從 HDFS (Hadoop Distributed File System 漫衍式文件系統)中讀取數據。 諸如 Yahoo(雅虎)、Intel(因特爾)、Baidu(百度)、Trend Micro(趨勢科技)和 Groupon(貴賓)等公司已經在利用 Spark 了。

聽上去仿佛 Spark 已經注定要代替 Hadoop MapReduce 了。但真的是這樣嗎?本文我們將比擬這兩個平臺來看看是否 Spark 真的技高一籌。

機能

Spark 在內存中處理懲罰數據，而 Hadoop MapReduce 是通過 map 和 reduce 操縱在磁盤中處理懲罰數據。因此從這個角度上講 Spark 的機能應該是高出 Hadoop MapReduce 的。

然而，既然在內存中處理懲罰，Spark 就需要很大的內存容量。就像一個尺度的數據庫系統操縱一樣， Spark 每次將處理懲罰進程加載到內存之中，然后該操縱作為緩存一直保持在內存中直到下一步操縱。假如 Spark 與其它資源需求型處事一同運行在 Hadoop YARN 上，又可能數據塊太大以至于不能完全讀入內存，此時 Spark 的機能就會有很大的低落。

與此相反， MapReduce 會在一個事情完成的時候當即竣事該歷程，因此它可以很容易的和其它處事配合運行而不會發生明明的機能低落。

當涉及需要反復讀取同樣的數據舉辦迭代式計較的時候，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 仍然存在著更大的技能人才的缺口。