Apache Storm 與 Spark：對實時處理數據，如何選擇【翻譯】

原文地址

實時商務智能這一構想早已算不得什麼新生事物（早在2006年維基百科中就出現了關於這一律唸的頁面）。然而儘管人們多年來一直在對此類方案進行探討，我卻發現不少企業實際上還沒有就此規劃出明確發展思路、甚至沒能真正意識到其中蘊含的巨大效益。

爲何會這樣？一大緣由在於目前市場上的實時商務智能與分析工具仍然很是有限。傳統數據倉庫環境針對的主要是批量處理流程，這類方案要麼延遲極高、要麼成本驚人——固然，也可能兩者兼具。

然而已經有多款強大並且易於使用的開源平臺開始興起，欲完全扭轉目前的不利局面。其中最值得關注的兩大項目分別爲Apache Storm與Apache Spark，它們都能爲廣大潛在用戶提供良好的實時處理能力。兩套方案都歸屬於Apache軟件基金會，並且除了在功能方面的一部分交集以外、兩款工具還各自擁有着獨特的特性與市場定位。

Storm：實時處理領域的Hadoop

做爲一套專門用於事件流處理的分佈式計算框架，Storm的誕生能夠追溯到當初由BackType公司開發的項目——這家市場營銷情報企業於2011年被Twitter所收購。Twitter旋即將該項目轉爲開源並推向GitHub平臺，不過Storm最終仍是加入了Apache孵化器計劃並於2014年9月正式成爲Apache旗下的頂級項目之一。

Storm有時候也被人們稱爲實時處理領域的Hadoop。Storm項目的說明文檔看起來對這種稱呼也表示認同：「Storm大大簡化了面向龐大規模數據流的處理機制，從而在實時處理領域扮演着Hadoop之於批量處理領域的重要角色。」

爲了達成上述目標，Storm在設計思路中充分考慮到大規模可擴展能力、利用一套「故障快速、自動重啓」方案爲處理提供容錯性支持、從而有力地保證了每一個元組都能切實獲得處理。Storm項目默認爲消息採起「至少一次」的處理覆蓋保障，但用戶也可以根據須要實現「僅爲一次」的處理方式。

Storm項目主要利用Clojure編寫而成，且既定設計目標在於支持將「流」（例如輸入流）與「栓」（即處理與輸出模塊）結合在一塊兒並構成一套有向無環圖（簡稱DAG）拓撲結構。Storm的拓撲結構運行在集羣之上，而Storm調度程序則根據具體拓撲配置將處理任務分發給集羣當中的各個工做節點。

你們能夠將拓撲結構大體視爲MapReduce在Hadoop當中所扮演的角色，只不過Storm的關注重點放在了實時、以流爲基礎的處理機制身上，所以其拓撲結構默認永遠運行或者說直到手動停止。一旦拓撲流程啓動，挾帶着數據的流就會不斷涌入系統並將數據交付給栓（而數據仍將在各栓之間循流程繼續傳遞），而這也正是整個計算任務的主要實現方式。隨着處理流程的推動，一個或者多個栓會把數據寫入至數據庫或者文件系統當中，並向另外一套外部系統發出消息或者將處理得到的計算結果提供給用戶。

Storm生態系統的一大優點在於其擁有豐富的流類型組合，足以從任何類型的來源處獲取數據。雖然你們也能夠針對某些具有高度特殊性的應用程序編寫定製化流，但基本上咱們總能從龐大的現有源類型中找到適合須要的方案——從Twitter流API到Apache Kafka再到JMS broker，一切盡皆涵蓋於其中。

適配器的存在使其可以輕鬆與HDFS文件系統進行集成，這意味着Storm能夠在必要時與Hadoop間實現互操做。Storm的另外一大優點在於它對多語言編程方式的支持能力。儘管Storm自己基於Clojure且運行在JVM之上，其流與栓仍然可以經過幾乎全部語言進行編寫，其中包括那些可以充分發揮在標準輸入/輸出基礎上使用JSON、並由此實現組件間通訊協議優點的非JVM語言。

整體而言，Storm是一套極具可擴展能力、快速驚人且具有容錯能力的開源分佈計算系統，其高度專一於流處理領域。Storm在事件處理與增量計算方面表現突出，可以以實時方式根據不斷變化的參數對數據流進行處理。儘管Storm同時提供原語以實現通用性分佈RPC並在理論上可以被用於任何分佈式計算任務的組成部分，但其最爲根本的優點仍然表如今事件流處理方面。

Spark：適用於一切的分佈式處理方案

做爲另外一個專門面向實時分佈式計算任務的項目，Spark最初由加州大學伯克利分校的APMLab實驗室所打造，然後又加入到Apache孵化器項目並最終於2014年2月成爲其中的頂尖項目之一。與Storm相似，Spark也支持面向流的處理機制，不過這是一套更具泛用性的分佈式計算平臺。

有鑑於此，咱們不妨將Spark視爲Hadoop當中一套足以取代MapReduce的潛在備選方案——兩者的區別在於，Spark可以運行在現有Hadoop集羣之上，但須要依賴於YARN對於資源的調度能力。除了Hadoop YARN以外，Spark還可以以Mesos爲基礎實現一樣的資源調度或者利用自身內置調度程度做爲獨立集羣運行。值得注意的是，若是不將Spark與Hadoop配合使用，那麼運行在集羣之上時某些網絡/分佈式文件系統（包括NFS、AFS等）仍然必要，這樣每一個節點纔可以切實訪問底層數據。

Spark項目由Scala編寫而成，並且與Storm同樣都支持多語言編程——不過Spark所提供的特殊API只支持Scala、Java以及Python。Spark並不具有「流」這樣的特殊抽象機制，但卻擁有可以與存儲在多種不一樣數據源內的數據實現協做的適配器——具體包括HDFS文件、Cassandra、HBase以及S3。

Spark項目的最大亮點在於其支持多處理模式以及支持庫。沒錯，Spark固然支持流模式，但這種支持能力僅源自多個Spark模塊之一，其預設模塊除了流處理以外還支持SQL訪問、圖形操做以及機器學習等。

Spark還提供一套極爲便利的交互shell，容許用戶利用Scala或者Python API以實時方式快速創建起原型及探索性數據分析機制。在使用這套交互shell時，你們會很快發現Spark與Storm之間的另外一大差別所在：Spark明顯表現出一種偏「功能」的取向，在這裏大部分API使用都是由面向原始操做的連續性方法調用來實現的——這與Storm遵循的模式徹底不一樣，後者更傾向於經過建立類與實現接口來完成此類任務。先不論兩種方案孰優孰劣，單單是風格的巨大差別已經足以幫助你們決定哪款系統更適合本身的需求了。

與Storm相似，Spark在設計當中一樣高度重視大規模可擴展能力，並且Spark團隊目前已經擁有一份大型用戶文檔、其中列出的系統方案都運行着包含成千上萬個節點的生產性集羣。除此以外，Spark還在最近的2014年Daytona GraySort競賽當中得到了優勝，成爲目前承載100TB級別數據工做負載的最佳選擇。Spark團隊還保留了多份文檔，其中記錄着Spark ETL如何負責數PB級別生產工做負載的運營。

Spark是一套快速出色、可擴展能力驚人且極具靈活性的開源分佈式計算平臺，與Hadoop以及Mesos相兼容而且支持多川計算模式，其中包括流、以圖形爲核心的操做、SQL訪問外加分佈式機器學習等。Spark的實際擴展記錄使人滿意，並且與Storm同樣堪稱構建實時分析與商務智能系統的卓越平臺。

如何選擇

若是你們的需求主要集中在流處理與CEP（即復瑣事件處理）式處理層面，並且須要從零開始爲項目構建一套目標明確的集羣設施，那麼我我的更傾向於選擇Storm——特別是在現有Storm流機制可以確切知足你們集成需求的狀況下。這一結論並不屬於硬性要求或者強制規則，但上述因素的存在確實更適合由Storm出面打理。

在另外一方面，若是你們打算使用現有Hadoop或者Mesos集羣，並且/或者既定流程須要涉及與圖形處理、SQL訪問或者批量處理相關的其它實質性要求，那麼Spark則值得加以優先考慮。

另外一個須要考量的因素是兩套系統對於多語言的支持能力，舉例來講，若是你們須要使用由R語言或者其它Spark沒法原生支持的語言所編寫的代碼，那麼Storm無疑在語言支持寬泛性方面佔據優點。同理可知，若是你們必須利用交互式shell經過API調用實現數據探索，那麼Spark也能帶來Storm所不具有的優秀能力。

最後，你們可能但願在作出決定前再對兩套平臺進行一番詳盡分析。我建議你們先利用這兩套平臺各自創建一個小規模概念驗證項目——然後運行本身的基準工做負載，藉此在最終選擇前親身體驗兩者的工做負載處理能力是否與預期相一致。

固然，你們也不必定非要從兩者之中選擇其一。根據各位工做負載、基礎設施以及具體要求的不一樣，咱們可能會找出一種將Storm與Spark加以結合的理想方案——其它一樣可能發揮做用的工具還包括Kafka、Hadoop以及Flume等等。而這正是開源機制的最大亮點所在。

不管你們選擇哪一套方案，這些工具的存在都切實代表實時商務智能市場的遊戲規則已經發生了變化。曾經只能爲少數精英所掌握的強大選項現在已經進入尋常百姓家——或者說，至少適用於多數中等規模或者大型企業。不要浪費資源，充分享受由此帶來的便利吧。