中國IDC圈5月20日?qǐng)?bào)道，Apache 基金會(huì)下的 Spak 再次引爆了大數(shù)據(jù)的話題。帶著比 Hadoop MapReduce 速度要快 100 倍的理睬以及越發(fā)機(jī)動(dòng)利便的 API，一些人認(rèn)為這或者預(yù)示著 Hadoop MapReduce 的終結(jié)。

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

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

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

機(jī)能

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

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

與此相反， MapReduce 會(huì)在一個(gè)事情完成的時(shí)候當(dāng)即竣事該歷程，因此它可以很容易的和其它處事配合運(yùn)行而不會(huì)發(fā)生明明的機(jī)能低落。

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

小結(jié)：當(dāng)數(shù)據(jù)巨細(xì)適于讀入內(nèi)存，尤其是在專用集群上時(shí)，Spark 表示更好;Hadoop MapReduce 合用于那些數(shù)據(jù)不能全部讀入內(nèi)存的環(huán)境，同時(shí)它還可以與其它處事同時(shí)運(yùn)行。

利用難度

Spark 有著機(jī)動(dòng)利便的Java，Scala和 Python 的API，同時(shí)對(duì)已經(jīng)熟悉 SQL 的技能員工來說， Spark 還合用 Spark SQL(也就是之前被人熟知的 Shark)。多虧了 Spark 提供的簡(jiǎn)樸易用的結(jié)構(gòu)模塊，我們可以很容易的編寫自界說函數(shù)。它甚至還席卷了可以即時(shí)反饋的交互式呼吁模式。

Hadoop MapReduce 是用 Java 編寫的，但由于其難于編程而備受詬病。盡量需要一按時(shí)間去進(jìn)修語法，Pig 照舊在必然水平上簡(jiǎn)化了這個(gè)進(jìn)程， Hive也為平臺(tái)提供了 SQL 的兼容。一些 Hadoop 東西也可以無需編程直接運(yùn)行 MapReduce 任務(wù)。Xplenty 就是一個(gè)基于 Hadoop 的數(shù)據(jù)整合處事，并且也不需要舉辦任何編程和陳設(shè)。

盡量 Hive 提供了呼吁行接口，但 MapReduce 并沒有交互式模式。諸如 Impala，Presto 和 Tez 等項(xiàng)目都在實(shí)驗(yàn)但愿為 Hadoop 提供全交互式查詢模式。

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

小結(jié)：Spark 更易于編程，同時(shí)也包括交互式模式;Hadoop MapReduce 不易編程可是現(xiàn)有的許多東西使其更易于利用。

本錢

Spark 和 Hadoop MapReduce 都是開源的，可是呆板和人工的耗費(fèi)仍是不行制止的。

這兩個(gè)框架既可以在商用處事器上也可以運(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)存巨細(xì)合剛才氣發(fā)揮出其最優(yōu)的機(jī)能。所以假如然的需要處理懲罰很是大的數(shù)據(jù)，Hadoop 絕對(duì)是符合之選，究竟硬盤的用度要遠(yuǎn)遠(yuǎn)低于內(nèi)存的用度。

思量到 Spark 的機(jī)能尺度，在執(zhí)行溝通的任務(wù)的時(shí)候，需要的硬件更少而運(yùn)行速度卻更快，因此應(yīng)該是更合算的，尤其是在云端的時(shí)候，此時(shí)只需要即用即付。

在技能人員方面，縱然 Hadoop 從 2005 年就開始普及，可是 MapReduce 方面的專家仍然存在著短缺。而對(duì)付從 2010 年才開始普及的 Spark ，這又意味著什么呢? 或者投身 Spark 進(jìn)修的人正在快速增加，可是對(duì)比于 Hadoop MapReduce 仍然存在著更大的技能人才的缺口。