哪個(gè)大數(shù)據(jù)框架更適合你？

來(lái)自四面八方的數(shù)據(jù)席卷而來(lái)，將我們裹挾進(jìn)去。。隨著數(shù)據(jù)每?jī)赡攴环瑪?shù)字宇宙正以飛快的速度追趕物理宇宙。據(jù)估計(jì)，到2020年，數(shù)字宇宙將達(dá)到44澤塔字節(jié)——其數(shù)字位的數(shù)量相當(dāng)于宇宙中恒星的數(shù)量。

數(shù)據(jù)還在不斷增加，我們壓根無(wú)法擺脫。為了消化這些所有的數(shù)據(jù)，市場(chǎng)上的分布式系統(tǒng)越來(lái)越多。在這些系統(tǒng)中，Hadoop和Spark經(jīng)常作為直接競(jìng)爭(zhēng)對(duì)手相互競(jìng)爭(zhēng)。

在決定這兩個(gè)框架中哪個(gè)更適合你時(shí)，我們需要根據(jù)幾個(gè)基本參數(shù)對(duì)它們進(jìn)行比較。

性能

Spark的速度非常快，已經(jīng)優(yōu)于Hadoop框架。它在內(nèi)存和磁盤(pán)上的運(yùn)行速度分別比Hadhoop快100倍和10倍。此外，它對(duì)100 TB數(shù)據(jù)的排序速度是Hadoop的3倍。

Spark如此之快是因?yàn)樗幚韮?nèi)存中的所有東西。由于Spark的內(nèi)存處理，它提供了對(duì)營(yíng)銷(xiāo)活動(dòng)、物聯(lián)網(wǎng)傳感器、機(jī)器學(xué)習(xí)和社交媒體網(wǎng)站數(shù)據(jù)的實(shí)時(shí)分析。

然而，如果Spark和其他共享服務(wù)在YARN上運(yùn)行，它的性能可能會(huì)下降。這可能導(dǎo)致RAM內(nèi)存泄漏。另一方面，Hadoop則很容易處理這個(gè)問(wèn)題。如果用戶(hù)傾向于批處理，Hadoop要比Spark高效得多。

底線(xiàn)：Hadoop和Spark都有不同的處理方法。因此，是繼續(xù)使用Hadoop還是Spark完全取決于項(xiàng)目的需求。

Facebook及其與Spark框架的過(guò)渡之旅

Facebook上的數(shù)據(jù)每秒鐘都在增長(zhǎng)。為了處理并利用這些數(shù)據(jù)，F(xiàn)acebook使用了分析技術(shù)。為此，它利用了以下幾個(gè)平臺(tái)：

Hive平臺(tái)來(lái)執(zhí)行Facebook的一些批量分析。

用于自定義MapReduce實(shí)現(xiàn)的Corona平臺(tái)。

對(duì)于基于ansi - sql的查詢(xún)，很快就會(huì)占用內(nèi)存。

上面討論的Hive平臺(tái)在計(jì)算上是“資源密集型”的。所以，維護(hù)它挑戰(zhàn)巨大。因此，F(xiàn)acebook決定改用Apache Spark框架來(lái)管理他們的數(shù)據(jù)。今天，F(xiàn)acebook通過(guò)集成Spark為實(shí)體排名系統(tǒng)部署了一個(gè)更快的可管理管道。

安全

Spark的安全性問(wèn)題仍在不斷發(fā)展，因?yàn)樗壳爸恢С滞ㄟ^(guò)共享（密碼身份驗(yàn)證）進(jìn)行身份驗(yàn)證。Apache Spark的官方網(wǎng)站也聲稱(chēng)，“因?yàn)榇嬖谠S多不同類(lèi)型的安全問(wèn)題，Spark并不一定能保護(hù)所有的數(shù)據(jù)?！?/p>

Hadoop則具有以下安全特性：Hadoop身份驗(yàn)證、Hadoop授權(quán)、Hadoop審計(jì)和Hadoop加密。所有這些都與Hadoop安全項(xiàng)目集成，如Knox Gateway和Sentry。

底線(xiàn)：在Hadoop與Spark的安全大戰(zhàn)中，Spark的安全性比Hadoop稍差。但是，在與Hadoop集成Spark之后，Spark可以使用Hadoop的安全特性。

成本

首先，Hadoop和Spark都是開(kāi)源框架，因此都是免費(fèi)的。兩者都使用普通服務(wù)器，運(yùn)行在云上，并且似乎有一些相似的硬件需求：

那么，如何在成本的基礎(chǔ)上進(jìn)行評(píng)估呢？

請(qǐng)注意，Spark使用大量RAM在內(nèi)存中運(yùn)行所有數(shù)據(jù)。考慮到RAM的價(jià)格高于硬盤(pán)，這可能會(huì)影響成本。

另一方面，Hadoop是磁盤(pán)綁定的。這樣，就能夠節(jié)省購(gòu)買(mǎi)昂貴RAM的成本。然而，Hadoop需要更多的系統(tǒng)來(lái)分發(fā)磁盤(pán)I/O。

因此，在比較Spark和Hadoop框架的成本參數(shù)時(shí)，必須考慮它們的需求。

如果需求傾向于處理大量的大型歷史數(shù)據(jù)，Hadoop是繼續(xù)使用的最佳選擇，因?yàn)橛脖P(pán)空間的價(jià)格要比內(nèi)存空間便宜得多。

另一方面，當(dāng)我們處理實(shí)時(shí)數(shù)據(jù)的選項(xiàng)時(shí)，Spark可以節(jié)省成本，因?yàn)樗褂玫挠布?，能以更快的速度?zhí)行相同的任務(wù)。

底線(xiàn)：在Hadoop與Spark成本之爭(zhēng)中，Hadoop的成本肯定更低，但當(dāng)企業(yè)不得不處理更低數(shù)量的實(shí)時(shí)數(shù)據(jù)時(shí)，Spark是很劃算的。

易用性

Spark框架最大的USPs之一是它的易用性。Spark為Scala Java、Python和Spark SQL（也稱(chēng)為Shark）提供了友好而舒適的api。

Spark的簡(jiǎn)單構(gòu)建塊使編寫(xiě)用戶(hù)定義函數(shù)變得很容易。此外，由于Spark支持批處理和機(jī)器學(xué)習(xí)，因此很容易簡(jiǎn)化數(shù)據(jù)處理的基礎(chǔ)設(shè)施。它包括一個(gè)交互式模式，用于運(yùn)行帶有即時(shí)反饋的命令。

Hadoop是用Java編寫(xiě)的，在編寫(xiě)沒(méi)有交互模式的程序時(shí)，是編寫(xiě)程序絆腳石。雖然Pig（一個(gè)附加工具）使編程更容易，但它需要一些時(shí)間來(lái)學(xué)習(xí)語(yǔ)法。

一句話(huà)：在Hadoop與Spark的“易用性”之爭(zhēng)中，兩者都有自己的用戶(hù)友好方式。然而，如果我們必須選擇一個(gè)，Spark更容易編程并包含交互模式。

Apache Hadoop和Spark有可能實(shí)現(xiàn)協(xié)同關(guān)系嗎？

是的，這是非常有可能的，所以我們推薦它。讓我們?cè)敿?xì)了解一下它們?nèi)绾螀f(xié)同工作。

Apache Hadoop生態(tài)系統(tǒng)包括HDFS、Apache Query和HIVE。讓我們看看Apache Spark如何使用它們。

Apache Spark和HDFS的合并

Apache Spark的目的是處理數(shù)據(jù)。但是，為了處理數(shù)據(jù)，引擎需要從存儲(chǔ)中輸入數(shù)據(jù)。為此，Spark使用HDFS。（這不是唯一的選擇，但卻是最流行的選擇，因?yàn)锳pache是它們背后的大腦）。

Apache Hive和Apache Spark的混合

Apache Spark和Apache Hive是高度兼容的，它們可以一起解決許多業(yè)務(wù)問(wèn)題。

例如，假設(shè)一個(gè)企業(yè)正在分析消費(fèi)者行為。現(xiàn)在，該公司需要從各種來(lái)源收集數(shù)據(jù)，如社交媒體、評(píng)論、點(diǎn)擊流數(shù)據(jù)、客戶(hù)移動(dòng)應(yīng)用程序等等。

企業(yè)就可以使用HDFS存儲(chǔ)數(shù)據(jù)，Apache hive作為HDFS和Spark之間的橋梁。

Uber及其合并的方式

為了處理消費(fèi)者數(shù)據(jù)，Uber結(jié)合了Spark和Hadoop。它使用實(shí)時(shí)交通狀況來(lái)提供特定時(shí)間和地點(diǎn)的司機(jī)。為了實(shí)現(xiàn)這一目標(biāo)，Uber使用HDFS將原始數(shù)據(jù)上傳至Hive，并使用Spark處理數(shù)十億個(gè)事件。

Hadoop vs Spark：贏家是……

雖然Spark快速易用，但Hadoop的安全性、巨大的存儲(chǔ)容量和低成本的批處理能力更勝一籌。從兩個(gè)選項(xiàng)中選擇一個(gè)完全取決于項(xiàng)目的需求。兩者的結(jié)合將產(chǎn)生一個(gè)不可戰(zhàn)勝的組合。