摘要：更新、更靈活的Spark技術似乎在大數據架構將取代MapReduce。那么對于企業而言，其更新換代的步伐、范圍和規模又如何呢？

MapReduce已經開始在逐步退居二線了。采用MapReduce的企業用戶固然能夠實現良好的運行，但今天的大數據開發人員們對于處理速度和簡單性有著極為強烈的追求。所以，當談到為新的工作負載選擇一款處理框架，以便運行在其Hadoop環境中時，現如今的企業用戶開始越來越傾向于采用更新、更靈活的Spark技術。

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

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

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

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

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

“很長一段時間以來，MapReduce都是Hadoop領域公認的主力。”，Hortonworks公司的創始人兼架構師Arun Murthy表示說。

他指出，該技術是在谷歌的實驗室創建的，以解決一項非常具體的使用案例：網絡搜索。十多年來，其已經獲得了長足的發展，但也許仍尚不足以滿足企業對大數據應用程序的胃口。

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

處理速度和簡單性

那么，Spark的優勢究竟在何處呢?它提供的主要優點是能夠為開發人員提供很快的處理速度。Spark應用程序的處理速度比那些基于MapReduce的快100倍，根據其創作者Mathei Zaharia介紹。Mathei Zaharia現在是一家負責在云中提供Spark技術的Databricks公司的首席技術官，其不在Hadoop上運行，而是在Cassandra數據庫。

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

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

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

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

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

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

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

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

大多數用戶認為Spark是開發者更友好的，包括豐田的Kursar。他說：“這款API的使用比MapReduce明顯容易得多。”

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

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

這些包括Spark SQL，用于結構化的分析查詢，關系數據;Spark Streaming，通過頻繁的‘微批次’進行近實時的數據流處理;MLib機器學習;和GrapX作為一個圖表，數據以任意方式連接，例如社交媒體的用戶網絡。

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

但是現在，哈代已經開始在生產環境中不再使用Spark了。“我們現在正在開始遠離Spark了。”他說。“這是一個關乎成熟度的問題。該技術具有巨大潛力，我們將使用它，這一點毫無疑問 - 而且我們已經在使用它進行一些概念證明了。”

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

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

API和最佳實踐仍然在進展中，Heudecker補充說，而供應商們可能很難在Spark框架內同等支持所有可用的組件。企業用戶應該采取非常謹慎的態度，不要在關鍵任務應用程序上部署不支持或部分支持的功能。

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

但是，在Spark峰會后的幾個月，他依然堅持自己的觀點：在不遠的將來，Hadoop的最新的分析應用程序將建立在Spark 上，而不是基于MapReduce。

“在一般的Hadoop集群占主導地位市場份額的將是Spark，這一轉折點遲早會到來的。”奧爾森說。“現在，我不能準確預測這一天何時會到來，但我會說，我們的一些客戶，特別是在金融服務和消費品領域已經達到了臨界點。許多其他行業也必然要跟隨。”