新興的Spark技術(shù)有望取代大數(shù)據(jù)框架中廣泛應(yīng)用的MapReduce技術(shù)。這種替代的速度如何，其范圍和規(guī)模又是怎樣的呢？
讓我們先說說MapReduce。它的確好用，但是現(xiàn)在大數(shù)據(jù)開發(fā)人員對(duì)速度和簡(jiǎn)潔性的需求變得越來越強(qiáng)烈。所以當(dāng)面臨選擇Hadoop 平臺(tái)上運(yùn)行的處理框架，以應(yīng)對(duì)新的工作負(fù)載時(shí)，他們?cè)絹碓絻A向于新興的框架技術(shù)Spark。
至少這是從大數(shù)據(jù)廠商那里獲取到的信息，他們?cè)诖罅χС諥pache Spark，稱其為大數(shù)據(jù)的下一個(gè)大事件。
在舊金山6月舉行的Spark峰會(huì)上，Cloudera首席戰(zhàn)略官M(fèi)ike Olson談到了Spark正以“驚人”的速度增長(zhǎng)，以及客戶偏好的明顯轉(zhuǎn)變，該公司作為Hadoop分銷商，親眼見證了這些變化。
“我們覺得不用多久Spark能夠成為占主導(dǎo)地位的Hadoop通用處理框架，”他說。”那時(shí)候，如果你想要找到一個(gè)好用、通用的引擎，你會(huì)選擇Apache Spark，而不是Apache MapReduce。”
Olson的話用詞十分準(zhǔn)確，特別是“通用”這個(gè)詞的使用。他的觀點(diǎn)是，雖然對(duì)于Hadoop專用處理引擎來說發(fā)展空間還很大，例如用于搜索的Apache Solr或用于SQL的查詢Cloudera Impala，但是，能夠讓開發(fā)者用來創(chuàng)建多樣化的分析工作負(fù)載(因此稱為“通用”)的處理框架競(jìng)爭(zhēng)，好似兩匹賽馬之間的競(jìng)爭(zhēng)，而Spark勝利在望。
其實(shí)Spark能贏原因很簡(jiǎn)單，它找到了那些MapReduce框架被開發(fā)人員長(zhǎng)期詬病的地方，尤其是MapReduce的高延遲及批處理響應(yīng)的模式。
“人們?cè)诤荛L(zhǎng)時(shí)間內(nèi)已經(jīng)達(dá)成了共識(shí)--MapReduce在Hadoop的世界中是一個(gè)很好的工作工具，”Arun Murthy--Hortonworks公司創(chuàng)始人兼架構(gòu)師說道。
他指出，該技術(shù)是谷歌實(shí)驗(yàn)室創(chuàng)造的，用來解決一個(gè)非常具體的用例:web搜索。十年以來,它歷經(jīng)演變——但或許仍不足以滿足企業(yè)對(duì)大數(shù)據(jù)應(yīng)用程序的要求。
“它的優(yōu)勢(shì)在于其良好的可延展性，能夠應(yīng)付更多用例,” Murthy補(bǔ)充道。“我們當(dāng)然知道MapReduce存在可以解決問題的用力,但卻不是以最優(yōu)的方式。如同當(dāng)初MapReduce取代其他技術(shù)一樣,技術(shù)間的更替是完全自然的,新技術(shù)的出現(xiàn)也將取代MapReduce。”
Spark的速度與簡(jiǎn)潔性那么Spark的偉大之處在什么地方呢?它對(duì)于開發(fā)人員來說最主要優(yōu)點(diǎn)就是速度。據(jù)該技術(shù)的發(fā)明者M(jìn)athei Zaharia所述，Spark應(yīng)用程序比那些基于MapReduce的應(yīng)用程序快上一個(gè)數(shù)量級(jí) –最高能快上100倍。Mathei Zaharia現(xiàn)在是Databricks公司的首席技術(shù)官，該公司提供基于云的Spark程序，這些程序并沒有運(yùn)行在Hadoop平臺(tái)上，而是運(yùn)行在Cassandra 數(shù)據(jù)庫上。
值得注意的是,Spark可以運(yùn)行在不同的文件系統(tǒng)和數(shù)據(jù)庫中,其中也包括Hadoop分布式文件系統(tǒng),(HFDS)。
Spark相對(duì)于MapReduce的優(yōu)勢(shì)在于它在內(nèi)存在完成了大部分操作的處理, 它把數(shù)據(jù)集從分布式物理存儲(chǔ)復(fù)制到更快的邏輯內(nèi)存中。相比之下,MapReduce是從硬盤寫入和讀取數(shù)據(jù)的。磁盤訪問1MB數(shù)據(jù)的速度以毫秒為單位，而內(nèi)存中訪問同樣大小的數(shù)據(jù)只需要亞毫秒級(jí)的時(shí)間。換句話說,Spark可以給企業(yè)帶來明顯的時(shí)間優(yōu)勢(shì)。
Gartner分析師Nick Heudecker說道:“我最近跟一個(gè)使用大規(guī)模Hadoop集群的客戶說,嘗試使用一下Spark,它能夠把工作從四個(gè)小時(shí)(使用MapReduce)降低至90秒(使用Spark)。”
對(duì)于許多企業(yè)來說,這種改進(jìn)是極具吸引力的,Heudecker說道。“這意味著，在之前他們只能在一天內(nèi)完成兩次分析，而用了Spark后，現(xiàn)在要進(jìn)行多少分析都輕而易舉。”
今年6月的Spark 峰會(huì)上，美國豐田汽車銷售公司的數(shù)據(jù)科學(xué)主管Brian Kursar,介紹了他的團(tuán)隊(duì)如何使用Spark運(yùn)行客戶體驗(yàn)分析程序后所帶來的改進(jìn)。這些程序平時(shí)要處理大約7億條記錄，這些記錄來自社會(huì)媒體,調(diào)查數(shù)據(jù)和呼叫中心業(yè)務(wù),運(yùn)行程序的目的為了找出客戶流失問題的原因以及識(shí)別需要關(guān)注的領(lǐng)域,以便員工能在必要時(shí)進(jìn)行干預(yù)。
使用MapReduce,完成分析需要160小時(shí)。也就是幾乎七天時(shí)間，Kursar指出。“屆時(shí),再改變就有點(diǎn)太晚了,”他說。相同的處理工作,使用Spark重寫，將會(huì)在四小時(shí)內(nèi)完成。
Spark相對(duì)于MapReduce的另一個(gè)優(yōu)勢(shì)是其具有更優(yōu)秀的易用性和靈活性。這不足為奇,Spark是Mathei Zaharia在加州大學(xué)伯克利分校攻讀博士學(xué)位時(shí)發(fā)明的，目的是為了解決他在MapReduce框架中受到的種種限制，而這些限制是其在MapReduce早期用戶-Facebook實(shí)習(xí)時(shí)發(fā)現(xiàn)的。
“我在這些企業(yè)中看到，其用戶想要使用大數(shù)據(jù)做更多事情，而MapReduce所提供的功能遠(yuǎn)遠(yuǎn)不能滿足他們的需要,”他說。“它有很大的局限性,例如不能做互動(dòng)查詢，不能處理先進(jìn)算法,如機(jī)器學(xué)習(xí)等。這些缺陷令人沮喪,所以我的目標(biāo)是解決這些問題,與此同時(shí),我想讓用戶更容易的使用大數(shù)據(jù)并從中獲取價(jià)值。”
大多數(shù)用戶認(rèn)為Spark對(duì)于開發(fā)者來說更加友好,包括豐田的Kursar,他說道:“Spark的API比起MapReduce來說，明顯更容易使用。”
Cloudera優(yōu)秀開發(fā)者Justin Kestelyn最近發(fā)表了一篇博客，表示Spark具有“豐富，表示清晰的API，和Scala ,Java和Python的API不相上下，相比MapReduce，使用Spark幾乎可以減少兩倍到五倍的代碼量,。
但是這種方便性并不意味著Spark犧牲了靈活性,正如Forrester分析師Mike Gualtieri今年早些時(shí)候發(fā)表的一份報(bào)告中指出。相反的，他寫道,Spark包括專門的工具，可單獨(dú)或協(xié)同構(gòu)建應(yīng)用程序。
這些工具包括Spark SQL,用于結(jié)構(gòu)化關(guān)系數(shù)據(jù)上進(jìn)行分析查詢，Spark Streaming;通過使用頻繁的micro-batches來進(jìn)行幾乎實(shí)時(shí)的數(shù)據(jù)流處理；MLib工具:用于機(jī)器學(xué)習(xí)；GrapX用于表示,圖表,以及數(shù)據(jù)在任意方面的聯(lián)系,例如網(wǎng)絡(luò)社交媒體的用戶。
Spark為時(shí)尚早？然而，使用Spark也面臨著巨大障礙，原因在于Spark是相對(duì)不成熟的。金融服務(wù)公司Northern Trust首席架構(gòu)師Len Hardy的團(tuán)隊(duì)是Cloudera Hadoop分布平臺(tái)的忠實(shí)用戶，他們?cè)谄渖线\(yùn)用各種工具，包括Hive(數(shù)據(jù)倉庫),Flume(大規(guī)模日志聚合)和Cloudera Impala(運(yùn)行SQL查詢)。
但現(xiàn)在，Hardy 是在生產(chǎn)環(huán)境中沒有使用Spark。“我們現(xiàn)在離Spark還很遠(yuǎn),”他說。“這是一個(gè)關(guān)于成熟度的問題。這項(xiàng)技術(shù)有很大的前景,我們也將使用它,毫無疑問,我們已經(jīng)準(zhǔn)備好在一些已被驗(yàn)證的領(lǐng)域使用它了。
“但是，對(duì)于我們的企業(yè)數(shù)據(jù)平臺(tái)來說，應(yīng)用spark可能還需要很長(zhǎng)時(shí)間,我們向合作伙伴和客戶提供數(shù)據(jù)，他們據(jù)此做出商業(yè)決策,為了保證數(shù)據(jù)的準(zhǔn)確性，我們需要所使用的工具堅(jiān)如磐石，我只是覺得Spark在成熟度上還差那么一點(diǎn)。”
謹(jǐn)慎是有道理的。所有主要的Hadoop廠商,正在努力提高他們企業(yè)支持Spark的能力,但Gartner的Heudecker指出:“Spark的商業(yè)支持似乎總是與其他數(shù)據(jù)管理產(chǎn)品捆綁,但信息經(jīng)理和業(yè)務(wù)分析人員必須意識(shí)到，Spark的發(fā)展速度讓廠商不斷支持最新組件版本的服務(wù)面臨著巨大挑戰(zhàn)。”
API和最優(yōu)化方法在很大程度上仍處于發(fā)展中,Heudecker補(bǔ)充道,另外廠商在同樣Spark框架中，可能難以支持所有的可用組件。企業(yè)用戶應(yīng)極其謹(jǐn)慎，不要把關(guān)鍵任務(wù)部署在不支持或部分支持的功能上，這將得不償失。
Cloudera的Olson承認(rèn)Spark仍然是一種年輕的技術(shù)。“這還為時(shí)尚早——仍然有大量的工作需要完成，比如安全需求方面,”他說道。
但在Spark峰會(huì)的幾個(gè)月后,他堅(jiān)持他的意見,在不遠(yuǎn)的將來,大多數(shù)Hadoop上的新的分析應(yīng)用程序?qū)?huì)構(gòu)建在Spark而不是MapReduce上。
“使用Spark的Hadoop集群所占的平均市場(chǎng)份額正在提升，超越的臨界點(diǎn)遲早會(huì)來,”Olson說。“現(xiàn)在,我不能預(yù)測(cè)這將在何時(shí)發(fā)生,但我都會(huì)告訴我們的一些客戶,特別是在金融服務(wù)和消費(fèi)品領(lǐng)域,幾乎已經(jīng)達(dá)到臨界點(diǎn)。而這些行業(yè)的很多人注定要追隨這一趨勢(shì)。”
京公網(wǎng)安備 11010502049343號(hào)