一提到大數(shù)據(jù)處理，相信很多人第一時(shí)間想到的是 Hadoop MapReduce。沒錯(cuò)，Hadoop MapReduce 為大數(shù)據(jù)處理技術(shù)奠定了基礎(chǔ)。近年來，隨著 Spark 的發(fā)展，越來越多的聲音提到了 Spark。而Spark相比Hadoop MapReduce有哪些優(yōu)勢(shì)?
Spark與Hadoop MapReduce在業(yè)界有兩種說法 ：一是 Spark 將代替 Hadoop MapReduce，成為未來大數(shù)據(jù)處理發(fā)展的方向 ;二是 Spark 將會(huì)和 Hadoop 結(jié)合，形成更大的生態(tài)圈。其實(shí) Spark 和 Hadoop MapReduce 的重點(diǎn)應(yīng)用場(chǎng)合有所不同。相對(duì)于 Hadoop MapReduce 來說，Spark 有點(diǎn)“青出于藍(lán)”的感覺，Spark 是在Hadoop MapReduce 模型上發(fā)展起來的，在它的身上我們能明顯看到 MapReduce的影子，所有的 Spark 并非從頭創(chuàng)新，而是站在了巨人“MapReduce”的肩膀上。千秋功罪，留于日后評(píng)說，我們暫且擱下爭(zhēng)議，來看看相比 Hadoop MapReduce，Spark 都有哪些優(yōu)勢(shì)。
1、計(jì)算速度快
大數(shù)據(jù)處理首先追求的是速度。Spark 到底有多快?用官方的話說，“Spark 允許 Hadoop 集群中的應(yīng)用程序在內(nèi)存中以 100 倍的速度運(yùn)行，即使在磁盤上運(yùn)行也能快 10 倍”?？赡苡械淖x者看到這里會(huì)大為感嘆，的確如此，在有迭代計(jì)算的領(lǐng)域，Spark 的計(jì)算速度遠(yuǎn)遠(yuǎn)超過 MapReduce，并且迭代次數(shù)越多，Spark 的優(yōu)勢(shì)越明顯。這是因?yàn)?Spark 很好地利用了目前服務(wù)器內(nèi)存越來越大這一優(yōu)點(diǎn)，通過減少磁盤 I/O 來達(dá)到性能提升。它們將中間處理數(shù)據(jù)全部放到了內(nèi)存中，僅在必要時(shí)才批量存入硬盤中?；蛟S讀者會(huì)問 ：如果應(yīng)用程序特別大，內(nèi)存能放下多少 GB ?答曰 ：什么? GB ?目前 IBM 服務(wù)器內(nèi)存已經(jīng)擴(kuò)展至幾 TB 了。
2、應(yīng)用靈活，上手容易
知道 AMPLab 的 Lester 為什么放棄 MapReduce 嗎?因?yàn)樗枰押芏嗑Ψ诺組ap和Reduce的編程模型上，極為不便。 Spark在簡(jiǎn)單的Map及Reduce操作之外，還支持 SQL 查詢、流式查詢及復(fù)雜查詢，比如開箱即用的機(jī)器學(xué)習(xí)算法。同時(shí)，用戶可以在同一個(gè)工作流中無(wú)縫地搭配這些能力，應(yīng)用十分靈活。
Spark 核心部分的代碼為 63 個(gè) Scala 文件，非常的輕量級(jí)。并且允許 Java、Scala、Python 開發(fā)者在自己熟悉的語(yǔ)言環(huán)境下進(jìn)行工作，通過建立在Java、Scala、Python、SQL(應(yīng)對(duì)交互式查詢)的標(biāo)準(zhǔn) API 以方便各行各業(yè)使用，同時(shí)還包括大量開箱即用的機(jī)器學(xué)習(xí)庫(kù)。它自帶 80 多個(gè)高等級(jí)操作符，允許在 Shell中進(jìn)行交互式查詢。即使是新手，也能輕松上手應(yīng)用。
3、兼容競(jìng)爭(zhēng)對(duì)手
Spark 可以獨(dú)立運(yùn)行，除了可以運(yùn)行在當(dāng)下的 YARN 集群管理外，還可以讀取已有的任何 Hadoop 數(shù)據(jù)。它可以運(yùn)行在任何 Hadoop 數(shù)據(jù)源上，比如 HBase、HDFS 等。有了這個(gè)特性，讓那些想從 Hadoop 應(yīng)用遷移到 Spark 上的用戶方便了很多。Spark 有兼容競(jìng)爭(zhēng)對(duì)手的胸襟，何愁大事不成?
4、實(shí)時(shí)處理性能非凡
MapReduce 更 加 適 合 處 理 離 線 數(shù) 據(jù)( 當(dāng) 然， 在 YARN 之 后，Hadoop也可以借助其他工具進(jìn)行流式計(jì)算)。Spark 很好地支持實(shí)時(shí)的流計(jì)算，依賴Spark Streaming 對(duì)數(shù)據(jù)進(jìn)行實(shí)時(shí)處理。Spark Streaming 具備功能強(qiáng)大的 API，允許用戶快速開發(fā)流應(yīng)用程序。而且不像其他的流解決方案，比如Storm，Spark Streaming 無(wú)須額外的代碼和配置，就可以做大量的恢復(fù)和交付工作。
5、社區(qū)貢獻(xiàn)力量巨大
從 Spark 的版本演化來看，足以說明這個(gè)平臺(tái)旺盛的生命力及社區(qū)的活躍度。尤其自 2013 年以來，Spark 一度進(jìn)入高速發(fā)展期，代碼庫(kù)提交與社區(qū)活躍度都有顯著增長(zhǎng)。以活躍度論，Spark 在所有的 Apache 基金會(huì)開源項(xiàng)目中位列前三，相較于其他大數(shù)據(jù)平臺(tái)或框架而言，Spark 的代碼庫(kù)最為活躍。
Spark 非常重視社區(qū)活動(dòng)，組織也極為規(guī)范，會(huì)定期或不定期地舉行與 Spark相關(guān)的會(huì)議。會(huì)議分為兩種 ：一種是 Spark Summit，影響力極大，可謂全球 Spark頂尖技術(shù)人員的峰會(huì)，目前已于 2013—2015 年在 San Francisco 連續(xù)召開了三屆Summit 大會(huì) ;另一種是 Spark 社區(qū)不定期地在全球各地召開的小型 Meetup 活動(dòng)。Spark Meetup 也會(huì)在我國(guó)的一些大城市定期召開，比如北京、深圳、西安等地，讀者可以關(guān)注當(dāng)?shù)氐奈⑿殴娞?hào)進(jìn)行參與。
Spark 的適用場(chǎng)景
從大數(shù)據(jù)處理需求來看，大數(shù)據(jù)的業(yè)務(wù)大概可以分為以下三類 ：
(1)復(fù)雜的批量數(shù)據(jù)處理，通常的時(shí)間跨度在數(shù)十分鐘到數(shù)小時(shí)之間。
(2)基于歷史數(shù)據(jù)的交互式查詢，通常的時(shí)間跨度在數(shù)十秒到數(shù)分鐘之間。
(3)基于實(shí)時(shí)數(shù)據(jù)流的數(shù)據(jù)處理，通常的時(shí)間跨度在數(shù)百毫秒到數(shù)秒之間。
目前已有很多相對(duì)成熟的開源和商業(yè)軟件來處理以上三種情景 ：第一種業(yè)務(wù)，可以利用 MapReduce 來進(jìn)行批量數(shù)據(jù)處理 ;第二種業(yè)務(wù)，可以用 Impala 來進(jìn)行交互式查詢 ;對(duì)于第三種流式數(shù)據(jù)處理，可以想到專業(yè)的流數(shù)據(jù)處理工具Storm。但是這里有一個(gè)很重要的問題 ：對(duì)于大多數(shù)互聯(lián)網(wǎng)公司來說，一般會(huì)同時(shí)遇到以上三種情景，如果采用不同的處理技術(shù)來面對(duì)這三種情景，那么這三種情景的輸入/ 輸出數(shù)據(jù)無(wú)法無(wú)縫共享，它們之間可能需要進(jìn)行格式轉(zhuǎn)換，并且每個(gè)開源軟件都需要一支開發(fā)和維護(hù)團(tuán)隊(duì)，從而提高了成本。另外一個(gè)不便之處就是，在同一個(gè)集群中對(duì)各個(gè)系統(tǒng)協(xié)調(diào)資源分配比較困難。
那么，有沒有一種軟件可以同時(shí)處理以上三種情景呢? Spark 就可以，或者說有這樣的潛力。Spark 同時(shí)支持復(fù)雜的批處理、互操作和流計(jì)算，而且兼容支持HDFS 和 Amazon S3 等分布式文件系統(tǒng)，可以部署在 YARN 和 Mesos 等流行的集群資源管理器上。
從 Spark 的設(shè)計(jì)理念(基于內(nèi)存的迭代計(jì)算框架)出發(fā)，其最適合有迭代運(yùn)算的或者需要多次操作特定數(shù)據(jù)集的應(yīng)用場(chǎng)合。并且迭代次數(shù)越多，讀取的數(shù)據(jù)量越大，Spark 的應(yīng)用效果就越明顯。因此，對(duì)于機(jī)器學(xué)習(xí)之類的“迭代式”應(yīng)用，Spark 可謂拿手好戲，要比 Hadoop MapReduce 快數(shù)十倍。另外，Spark Streaming因?yàn)閮?nèi)存存儲(chǔ)中間數(shù)據(jù)的特性，處理速度非?？欤部梢詰?yīng)用于需要實(shí)時(shí)處理大數(shù)據(jù)的場(chǎng)合。
當(dāng)然，Spark 也有不適用的場(chǎng)合。對(duì)于那種異步細(xì)粒度更新狀態(tài)的應(yīng)用，例如 Web 服務(wù)的存儲(chǔ)或增量的 Web 爬蟲和索引，也就是對(duì)于那種增量修改的應(yīng)用模型不適合。Spark 也不適合做超級(jí)大的數(shù)據(jù)量的處理，這里所說的“超級(jí)大”是相對(duì)于這個(gè)集群的內(nèi)存容量而言的，因?yàn)?Spark 要將數(shù)據(jù)存儲(chǔ)在內(nèi)存中。一般來說，10TB 以上(單次分析)的數(shù)據(jù)就可以算是“超級(jí)大”的數(shù)據(jù)了。
一般來說，對(duì)于中小企業(yè)的數(shù)據(jù)中心而言，在單次計(jì)算的數(shù)據(jù)量不大的情況下，Spark 都是很好的選擇。另外，Spark 也不適合應(yīng)用于混合的云計(jì)算平臺(tái)，因?yàn)榛旌系脑朴?jì)算平臺(tái)的網(wǎng)絡(luò)傳輸是很大的問題，即便有專屬的寬帶在云端 Cluster和本地 Cluster 之間傳輸數(shù)據(jù)，相比內(nèi)存讀取速度來說，依然不抵。
京公網(wǎng)安備 11010502049343號(hào)