Spark與MapReduce:哪一款更適合企業(yè)IT呢?

責(zé)任編輯:editor005

2015-11-19 14:47:53

摘自:機房360

摘要:更新、更靈活的Spark技術(shù)似乎在大數(shù)據(jù)架構(gòu)將取代MapReduce。獲勝原因很簡單,Spark極好的解決了開發(fā)人員對于MapReduce的一些長期的詬病——特別是其高延遲性,批處理模式響應(yīng)。

摘要:更新、更靈活的Spark技術(shù)似乎在大數(shù)據(jù)架構(gòu)將取代MapReduce。那么對于企業(yè)而言,其更新?lián)Q代的步伐、范圍和規(guī)模又如何呢?

MapReduce已經(jīng)開始在逐步退居二線了。采用MapReduce的企業(yè)用戶固然能夠?qū)崿F(xiàn)良好的運行,但今天的大數(shù)據(jù)開發(fā)人員們對于處理速度和簡單性有著極為強烈的追求。所以,當(dāng)談到為新的工作負(fù)載選擇一款處理框架,以便運行在其Hadoop環(huán)境中時,現(xiàn)如今的企業(yè)用戶開始越來越傾向于采用更新、更靈活的Spark技術(shù)。

至少,這是從大數(shù)據(jù)供應(yīng)商們那里所傳達出來的重大信息,他們現(xiàn)在已經(jīng)把寶壓在了Apache Spark上,并正在將其打造成為緊隨大數(shù)據(jù)之后的下一件大事。

今年六月,在舊金山舉辦的Spark峰會上,Cloudera公司首席戰(zhàn)略官麥克·奧爾森談到了Spark “驚人”的增長和客戶偏好的深刻轉(zhuǎn)變。他說他所在的企業(yè)作為一家Hadoop分銷商正在見證和經(jīng)歷著這一轉(zhuǎn)變結(jié)果。

“很久以前,我們希望Spark技術(shù)將成為Hadoop的占主導(dǎo)地位的通用處理架構(gòu)。”他說。“彼時,如果您企業(yè)想有一個良好的,通用用途的引擎,您可以選擇Apache Spark,而不是Apache MapReduce。”

奧爾森的談話顯然是經(jīng)過了仔細(xì)斟酌的,特別是他使用了“通用用途”這一短語。他的觀點是,盡管對于Hadoop的專有用途處理引擎仍然有足夠的空間,如用于搜索的Apache Solr或用于SQL查詢的Cloudera Impala,但當(dāng)前開發(fā)人員可以用來創(chuàng)建各種各樣的分析工作負(fù)載(即“通用用途”)的處理框架可以說是兩強相爭——而且目前看來Spark正在獲勝。

獲勝原因很簡單,Spark極好的解決了開發(fā)人員對于MapReduce的一些長期的詬病——特別是其高延遲性,批處理模式響應(yīng)。

“很長一段時間以來,MapReduce都是Hadoop領(lǐng)域公認(rèn)的主力。”,Hortonworks公司的創(chuàng)始人兼架構(gòu)師Arun Murthy表示說。

他指出,該技術(shù)是在谷歌的實驗室創(chuàng)建的,以解決一項非常具體的使用案例:網(wǎng)絡(luò)搜索。十多年來,其已經(jīng)獲得了長足的發(fā)展,但也許仍尚不足以滿足企業(yè)對大數(shù)據(jù)應(yīng)用程序的胃口。

“其強大之處在于其具備了足夠的延展性,以承擔(dān)更多的用例。”Murthy補充道。“但是,人們固然已經(jīng)熟知了MapReduce所能夠解決的用例,但卻不是以最適宜的方式。正如MapReduce會干擾其他技術(shù)一樣,新技術(shù)的出現(xiàn)也會破壞或取代的MapReduce也是非常自然的。”

處理速度和簡單性

那么,Spark的優(yōu)勢究竟在何處呢?它提供的主要優(yōu)點是能夠為開發(fā)人員提供很快的處理速度。Spark應(yīng)用程序的處理速度比那些基于MapReduce的快100倍,根據(jù)其創(chuàng)作者Mathei Zaharia介紹。Mathei Zaharia現(xiàn)在是一家負(fù)責(zé)在云中提供Spark技術(shù)的Databricks公司的首席技術(shù)官,其不在Hadoop上運行,而是在Cassandra數(shù)據(jù)庫。

需要注意的是,Spark可以運行在多種文件系統(tǒng)和數(shù)據(jù)庫,這一點是相當(dāng)重要的。其中包括Hadoop分布式文件系統(tǒng)(HFDs)。

賦予Spark較之MapReduce比較優(yōu)勢的原因就在于其能夠處理其大部分業(yè)務(wù)在“內(nèi)存”中,從分布式物理存儲復(fù)制數(shù)據(jù)集到更快的邏輯內(nèi)存。相比之下,MapReduce則是從硬盤驅(qū)動器讀寫。而磁盤訪問可以在毫秒之間訪問1MB的數(shù)據(jù),內(nèi)存訪問數(shù)據(jù)則是以亞毫秒的速率。換句話說,Spark能給企業(yè)帶來重要的洞察時間優(yōu)勢。

Gartner的分析師Nick Heudecker表示說:“我的一位客戶最近說,在一個非常大的Hadoop集群,完成一項工作使用MapReduce需要花費四個小時,而使用Spark僅僅只需90秒。”

對于許多企業(yè)而言,這方面的改善是非常有吸引力的,Heudecker說。“這意味著他們可以不再一天之內(nèi)僅僅只能運行2個分析了,只要他們愿意,可以在一個給定的數(shù)據(jù)集運行盡可能多的分析了。”

在六月份舉辦的Spark峰會上,豐田汽車美國銷售部門數(shù)據(jù)科學(xué)負(fù)責(zé)人Brian Kursar介紹了他的團隊在運行其客戶體驗分析應(yīng)用程序方面的改進。該款應(yīng)用程序是用來處理從社交媒體,調(diào)查數(shù)據(jù)和呼叫中心所收集的約7億條記錄,以便發(fā)現(xiàn)客戶流失問題,并確定關(guān)注特定領(lǐng)域,讓員工可以在必要的情況下進行干預(yù)。

使用MapReduce,該分析花了160個小時運行。這幾乎是七天的時間,Kursar向與會代表們指出。“等到該分析結(jié)束,所獲得的洞察已經(jīng)有點太遲了。”他說。而同樣的處理工作改用Spark,在短短四小時內(nèi)就完成了。

Spark較之MapReduce的另一大優(yōu)勢在于其相對易用性和靈活性。這不足為奇,正如Mathei Zaharia在加利福尼亞大學(xué)伯克利大學(xué)攻讀博士學(xué)位期間創(chuàng)造Spark時所回應(yīng)的那樣,通過在包括Facebook在內(nèi)的Hadoop的早期用戶那里進行暑期實習(xí)工作的過程中,他看到了MapReduce的局限性。

“我在這些企業(yè)中所看到的是:用戶想要借助大數(shù)據(jù)做更多的工作,而這遠(yuǎn)遠(yuǎn)超出了MapReduce所能支持的范疇。”他說。“它有很多的局限性,它不能進行交互式查詢,也不能處理高級的算法,如機器學(xué)習(xí)。這是一種無奈,所以我的目標(biāo)是要解決這些問題,同時,我想讓用戶采用大數(shù)據(jù)變得更容易,并開始從中獲得價值。”

大多數(shù)用戶認(rèn)為Spark是開發(fā)者更友好的,包括豐田的Kursar。他說:“這款A(yù)PI的使用比MapReduce明顯容易得多。”

由Cloudera公司開發(fā)者關(guān)系負(fù)責(zé)人Justin Kestelyn最近撰寫的博客聲稱,Spark是對于Java、Scala、Python而言,“富有表現(xiàn)力的”API。較之MapReduce,可以減少兩倍到五倍之間的代碼量。

但這種易用性并不意味著靈活性被犧牲了,正如Forrester的分析師Mike Gualtieri在今年早些時候發(fā)表的一份報告所指出的。他寫道,相反,Spark包括了專業(yè)的工具,可單獨或一起用來構(gòu)建應(yīng)用程序。

這些包括Spark SQL,用于結(jié)構(gòu)化的分析查詢,關(guān)系數(shù)據(jù);Spark Streaming,通過頻繁的‘微批次’進行近實時的數(shù)據(jù)流處理;MLib機器學(xué)習(xí);和GrapX作為一個圖表,數(shù)據(jù)以任意方式連接,例如社交媒體的用戶網(wǎng)絡(luò)。

然而, Spark的一個顯著障礙是其相對不成熟。在金融服務(wù)公司北美信托銀行,其首席架構(gòu)師萊恩·哈代的團隊是Cloudera的Hadoop發(fā)行版的用戶中,他們采用了一系列的工具,包括Hive(數(shù)據(jù)倉庫)、Flume(大規(guī)模的日志聚合)和Cloudera的Impala(運行SQL查詢)。Early days

但是現(xiàn)在,哈代已經(jīng)開始在生產(chǎn)環(huán)境中不再使用Spark了。“我們現(xiàn)在正在開始遠(yuǎn)離Spark了。”他說。“這是一個關(guān)乎成熟度的問題。該技術(shù)具有巨大潛力,我們將使用它,這一點毫無疑問 - 而且我們已經(jīng)在使用它進行一些概念證明了。”

“對于我們的企業(yè)數(shù)據(jù)平臺,我們將需要利用企業(yè)數(shù)據(jù)平臺將數(shù)據(jù)傳送到合作伙伴和客戶,以便他們可以做出商業(yè)決策,我們需要的工具是堅如磐石的,我只是感到Spark在這一點上還沒有達到我們的要求。”

這種謹(jǐn)慎不是沒有必要的。自然,所有主要的Hadoop供應(yīng)商均爭先恐后地加強了他們對Spark的支持,但Gartner 的Heudecker指出:“對Spark的商業(yè)支持幾乎都是與其他數(shù)據(jù)管理產(chǎn)品捆綁在一起的,而信息管理人員和業(yè)務(wù)分析人員必須意識到Spark的發(fā)展步伐使得捆綁供應(yīng)商不斷支持最新版本的組件是具有挑戰(zhàn)性的。”

API和最佳實踐仍然在進展中,Heudecker補充說,而供應(yīng)商們可能很難在Spark框架內(nèi)同等支持所有可用的組件。企業(yè)用戶應(yīng)該采取非常謹(jǐn)慎的態(tài)度,不要在關(guān)鍵任務(wù)應(yīng)用程序上部署不支持或部分支持的功能。

Cloudera的奧爾森承認(rèn),Spark仍然是一項很新的技術(shù)。“這仍然是使用的早期,例如,在安全方面有很多工作要做。”他說。

但是,在Spark峰會后的幾個月,他依然堅持自己的觀點:在不遠(yuǎn)的將來,Hadoop的最新的分析應(yīng)用程序?qū)⒔⒃赟park 上,而不是基于MapReduce。

“在一般的Hadoop集群占主導(dǎo)地位市場份額的將是Spark,這一轉(zhuǎn)折點遲早會到來的。”奧爾森說。“現(xiàn)在,我不能準(zhǔn)確預(yù)測這一天何時會到來,但我會說,我們的一些客戶,特別是在金融服務(wù)和消費品領(lǐng)域已經(jīng)達到了臨界點。許多其他行業(yè)也必然要跟隨。”

鏈接已復(fù)制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號-6京公網(wǎng)安備 11010502049343號