Apache 基金會(huì)下的 Spak 再次引爆了大數(shù)據(jù)的話題。帶著比 Hadoop MapReduce 速度要快 100 倍的承諾以及更加靈活方便的 API，一些人認(rèn)為這或許預(yù)示著 Hadoop MapReduce 的終結(jié)。

作為一個(gè)開源的數(shù)據(jù)處理框架，Spark 是如何做到如此迅速地處理數(shù)據(jù)的呢?秘密就在于它是運(yùn)行在集群的內(nèi)存上的，而且不受限于 MapReduce 的二階段范式。這大大加快了重復(fù)訪問同一數(shù)據(jù)的速度。

Spark 既可以單獨(dú)運(yùn)行，也可以運(yùn)行在 Hadoop YARN 上(注：Hadoop第二代框架中的改進(jìn)框架，用于將資源管理和處理組件分開，基于YARN的結(jié)構(gòu)不受 MapReduce 約束)，此時(shí) Spark 可以直接從 HDFS (Hadoop Distributed File System 分布式文件系統(tǒng))中讀取數(shù)據(jù)。 諸如 Yahoo(雅虎)、Intel(因特爾)、Baidu(百度)、Trend Micro(趨勢科技)和 Groupon(高朋)等公司已經(jīng)在使用 Spark 了。

聽上去好像 Spark 已經(jīng)注定要取代 Hadoop MapReduce 了。但真的是這樣嗎?本文我們將對比這兩個(gè)平臺(tái)來看看是否 Spark 真的技高一籌。

[[162944]]

性能

Spark 在內(nèi)存中處理數(shù)據(jù)，而 Hadoop MapReduce 是通過 map 和 reduce 操作在磁盤中處理數(shù)據(jù)。因此從這個(gè)角度上講 Spark 的性能應(yīng)該是超過 Hadoop MapReduce 的。

然而，既然在內(nèi)存中處理，Spark 就需要很大的內(nèi)存容量。就像一個(gè)標(biāo)準(zhǔn)的數(shù)據(jù)庫系統(tǒng)操作一樣， Spark 每次將處理過程加載到內(nèi)存之中，然后該操作作為緩存一直保持在內(nèi)存中直到下一步操作。如果 Spark 與其它資源需求型服務(wù)一同運(yùn)行在 Hadoop YARN 上，又或者數(shù)據(jù)塊太大以至于不能完全讀入內(nèi)存，此時(shí) Spark 的性能就會(huì)有很大的降低。

與此相反， MapReduce 會(huì)在一個(gè)工作完成的時(shí)候立即結(jié)束該進(jìn)程，因此它可以很容易的和其它服務(wù)共同運(yùn)行而不會(huì)產(chǎn)生明顯的性能降低。

當(dāng)涉及需要重復(fù)讀取同樣的數(shù)據(jù)進(jìn)行迭代式計(jì)算的時(shí)候，Spark 有著自身優(yōu)勢。 但是當(dāng)涉及單次讀取、類似 ETL (抽取、轉(zhuǎn)換、加載)操作的任務(wù)，比如數(shù)據(jù)轉(zhuǎn)化、數(shù)據(jù)整合等時(shí)，MapReduce 絕對是不二之選，因?yàn)樗褪菫榇硕摹?/p>

小結(jié)：當(dāng)數(shù)據(jù)大小適于讀入內(nèi)存，尤其是在專用集群上時(shí)，Spark 表現(xiàn)更好;Hadoop MapReduce 適用于那些數(shù)據(jù)不能全部讀入內(nèi)存的情況，同時(shí)它還可以與其它服務(wù)同時(shí)運(yùn)行。

使用難度

Spark 有著靈活方便的Java，Scala和 Python 的API，同時(shí)對已經(jīng)熟悉 SQL 的技術(shù)員工來說， Spark 還適用 Spark SQL(也就是之前被人熟知的 Shark)。多虧了 Spark 提供的簡單易用的構(gòu)造模塊，我們可以很容易的編寫自定義函數(shù)。它甚至還囊括了可以即時(shí)反饋的交互式命令模式。

Hadoop MapReduce 是用 Java 編寫的，但由于其難于編程而備受詬病。盡管需要一定時(shí)間去學(xué)習(xí)語法，Pig 還是在一定程度上簡化了這個(gè)過程， Hive也為平臺(tái)提供了 SQL 的兼容。一些 Hadoop 工具也可以無需編程直接運(yùn)行 MapReduce 任務(wù)。Xplenty 就是一個(gè)基于 Hadoop 的數(shù)據(jù)整合服務(wù)，而且也不需要進(jìn)行任何編程和部署。

盡管 Hive 提供了命令行接口，但 MapReduce 并沒有交互式模式。諸如 Impala，Presto 和 Tez 等項(xiàng)目都在嘗試希望為 Hadoop 提供全交互式查詢模式。

安裝與維護(hù)方面， Spark 并不綁定在 Hadoop 上，雖然 在 Hortonworks(HDP 2.2 版) 和 Cloudera(CDH 5 版) 的產(chǎn)品中 Spark 和 Hadoop MapReduce 都包含在其分布式系統(tǒng)中。(注： Cloudera， Hortonworks 及 MapR 是 Hadoop 領(lǐng)域三大知名的初創(chuàng)公司，致力于打造更好的 Hadoop 企業(yè)版應(yīng)用)。

小結(jié)：Spark 更易于編程，同時(shí)也包含交互式模式;Hadoop MapReduce 不易編程但是現(xiàn)有的很多工具使其更易于使用。

成本

Spark 和 Hadoop MapReduce 都是開源的，但是機(jī)器和人工的花費(fèi)仍是不可避免的。

這兩個(gè)框架既可以在商用服務(wù)器上也可以運(yùn)行在云端，下表可以看到它們有著相似的硬件需求：

• 框架 Apache Spark Apache Hadoop balanced workload slaves
• 內(nèi)核 8–16 4
• 內(nèi)存 8 GB 到數(shù)百GB 24 GB
• 硬盤 4–8 4–6 1TB
• 網(wǎng)絡(luò) 10 GB 或更多 1 GB 以太網(wǎng)

Spark 集群的內(nèi)存至少要和需要處理的數(shù)據(jù)塊一樣大，因?yàn)橹挥袛?shù)據(jù)塊和內(nèi)存大小合適才能發(fā)揮出其最優(yōu)的性能。所以如果真的需要處理非常大的數(shù)據(jù)，Hadoop 絕對是合適之選，畢竟硬盤的費(fèi)用要遠(yuǎn)遠(yuǎn)低于內(nèi)存的費(fèi)用。

考慮到 Spark 的性能標(biāo)準(zhǔn)，在執(zhí)行相同的任務(wù)的時(shí)候，需要的硬件更少而運(yùn)行速度卻更快，因此應(yīng)該是更合算的，尤其是在云端的時(shí)候，此時(shí)只需要即用即付。

在技術(shù)人員方面，即使 Hadoop 從 2005 年就開始普及，但是 MapReduce 方面的專家仍然存在著短缺。而對于從 2010 年才開始普及的 Spark ，這又意味著什么呢? 或許投身 Spark 學(xué)習(xí)的人正在快速增加，但是相比于 Hadoop MapReduce 仍然存在著更大的技術(shù)人才的缺口。

進(jìn)一步講，現(xiàn)存了大量的 Hadoop 即服務(wù)的資料和基于 Hadoop 的服務(wù)(比如我們 Xplenty 的數(shù)據(jù)整合服務(wù))，這些都降低對技術(shù)人員能力和底層硬件知識(shí)的要求。相比之下，幾乎沒有現(xiàn)有可選的 Spark 服務(wù)，僅有的那些也是新產(chǎn)品。

小結(jié)：根據(jù)基準(zhǔn)要求， Spark 更加合算， 盡管人工成本會(huì)很高。依靠著更多熟練的技術(shù)人員和 Hadoop 即服務(wù)的供給， Hadoop MapReduce 可能更便宜。

兼容性

Spark 既可以單獨(dú)運(yùn)行，也可以在 Hadoop YARN 上，或者在預(yù)置 Mesos 上以及云端。它支持實(shí)現(xiàn) Hadoop 輸入范式的數(shù)據(jù)源，所以可以整合所有 Hadoop 支持的數(shù)據(jù)源和文件格式。 根據(jù) Spark 官方教程， 它還可以通過 JDBC 和 ODBC 同 BI(商業(yè)智能) 工具一起運(yùn)行。 Hive 和 Pig 也在逐步實(shí)現(xiàn)這樣的功能。

小結(jié)： Spark 和 Hadoop MapReduce 具有相同的數(shù)據(jù)類型和數(shù)據(jù)源的兼容性。

數(shù)據(jù)處理

除了平常的數(shù)據(jù)處理，Spark 可以做的遠(yuǎn)不止這點(diǎn)：它還可以處理圖和利用現(xiàn)有的機(jī)器學(xué)習(xí)庫。高性能也使得 Spark 在實(shí)時(shí)處理上的表現(xiàn)和批處理上的表現(xiàn)一樣好。這也催生了一個(gè)更好的機(jī)遇，那就是用一個(gè)平臺(tái)解決所有問題而不是只能根據(jù)任務(wù)選取不同的平臺(tái)，畢竟所有的平臺(tái)都需要學(xué)習(xí)和維護(hù)。

Hadoop MapReduce 在批處理上表現(xiàn)卓越。如果需要進(jìn)行實(shí)時(shí)處理，可以利用另外的平臺(tái)比如 Storm 或者 Impala，而圖處理則可以用 Giraph。MapReduce 過去是用 Mahout 做機(jī)器學(xué)習(xí)的，但其負(fù)責(zé)人已經(jīng)將其拋棄轉(zhuǎn)而支持 Spark 和 h2o(機(jī)器學(xué)習(xí)引擎)。

小結(jié)：Spark 是數(shù)據(jù)處理的瑞士軍刀;Hadoop MapReduce 是批處理的突擊刀。

容錯(cuò)

和 MapReduce 一樣， Spark 會(huì)重試每個(gè)任務(wù)并進(jìn)行預(yù)測執(zhí)行。然而，MapReduce 是依賴于硬盤驅(qū)動(dòng)器的，所以如果一項(xiàng)處理中途失敗，它可以從失敗處繼續(xù)執(zhí)行，而 Spark 則必須從頭開始執(zhí)行，所以 MapReduce 這樣節(jié)省了時(shí)間。

小結(jié)：Spark 和 Hadoop MapReduce 都有著較好的容錯(cuò)能力，但是 Hadoop MapReduce 要稍微更好一點(diǎn)。

安全性

在安全性上， 此時(shí)的 Spark 還略顯不足。 授權(quán)驗(yàn)證由共享秘鑰機(jī)制支持，網(wǎng)絡(luò)用戶接口則通過 servlet 過濾器和事件日志保護(hù)。Spark 可以運(yùn)行在 YARN 上并配合使用 HDFS， 這也就意味著它同時(shí)還擁有 Kerberos 認(rèn)證授權(quán)驗(yàn)證，HDFS 文件許可機(jī)制和節(jié)點(diǎn)間的加密機(jī)制。

Hadoop MapReduce 擁有所有 Hadoop 支持的安全機(jī)制，同時(shí)也整合了其它基于 Hadoop 的安全項(xiàng)目， 比如 Knox 網(wǎng)關(guān)和 Sentry。志在解決 Hadoop 安全的 Rhino 項(xiàng)目也只是在添加 Sentry 支持時(shí)添加了 Spark 支持。否則 Spark 開發(fā)者們只能自己去提升其安全性了。

小結(jié)： Spark 的安全機(jī)制仍處在發(fā)展期。 Hadoop MapReduce 擁有更多安全控制機(jī)制和項(xiàng)目。

總結(jié)

Spark 是大數(shù)據(jù)領(lǐng)域冉冉升起的新星，但是 Hadoop MapReduce 仍有著較廣的應(yīng)用領(lǐng)域。

在內(nèi)存中進(jìn)行數(shù)據(jù)處理使得 Spark 具有較好的性能表現(xiàn)，也比較高效合算。它兼容所有 Hadoop 的數(shù)據(jù)源和文件格式， 支持多種語言的簡單易用的 API 也使人們更快速的可以上手。 Spark 甚至實(shí)現(xiàn)了圖處理和機(jī)器學(xué)習(xí)工具。

Hadoop MapReduce 是一個(gè)更加成熟的平臺(tái)，為進(jìn)行批處理而生。當(dāng)遇到確實(shí)非常大的數(shù)據(jù)以至于無法完全讀入內(nèi)存，又或是依靠著大量對該平臺(tái)有經(jīng)驗(yàn)的技術(shù)人員，它可能會(huì)比 Spark 更加合算。 而且圍繞 Hadoop MapReduce 的衍生系統(tǒng)正在依靠著更多的支撐項(xiàng)目、工具和云服務(wù)而更加壯大。

但是即使看上去 Spark 像是最終的贏家，問題在于我們永遠(yuǎn)不會(huì)單獨(dú)使用它—我們需要 HDFS 存儲(chǔ)數(shù)據(jù)，或許還會(huì)需要用到 HBase，Hive，Pig，Impala 或其他 Hadoop 項(xiàng)目。這意味著在處理非常大的數(shù)據(jù)的時(shí)候，Spark 仍然需要同 Hadoop 和 MapReduce 共同運(yùn)行。