摘要：更新、更靈活的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è)也必然要跟隨。”