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一樣堪稱構建實時分析與商務智慧系統的卓越平臺。
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一樣堪稱構建實時分析與商務智慧系統的卓越平臺。