原文地址：http://storm.apache.org/documentation/Rationale.html

過去的10年見證了數據處理領域的1次革命。MapReduce，Hadoop和其它相干的技術使得我們可以存儲與處理的數據到達了過去想都不敢想的量級。不幸的是，這些數據處理技術其實不能用于實時系統。本身這些技術也不是為了用于實時系統而生的。我們也沒有任何方式可以將Hadoop改造以用于實時系統；實時數據處理與批處理截然不同。

但是大范圍實時數據處理的需求與日俱增，缺少1個“實時的Hadoop”已成為數據處理領域最大的缺憾。

Storm彌補了這個缺憾。

在Storm出現之前，通常你需要手工建立1個隊列節點與工作節點的網絡來進行實時數據處理。工作節點處理隊列中的消息，更新數據庫，發送消息到另外一個隊列以進行進1步的處理。這樣的方式有許多問題：

1. 編碼枯燥。你需要花費很多時間去做配置，消息要發送到哪，怎樣部署隊列節點，怎樣部署工作節點。而你真正關心的實時處理邏輯只占你代碼的1小部份。
2. 系統脆弱。容錯性太差，你需要自己去注意每個隊列節點和工作節點的狀態。
3. 不容易擴大。當單個節點的消息吞吐量太高時，你需要對消息進行切分。對其他工作節點則需要進行重新配置，這樣才能將消息發送給新的節點。其中引入的節點變更都有可能失敗。

雖然在處理大量消息時，隊列節點與工作節點這樣的處理方式運轉得不是太好，但消息處理無疑是實時計算的基本范式。問題是應當怎樣樣才能讓消息處理可以做到不丟數據，可以處理超大范圍的數據，并且可以很簡單的來使用和運維？

Storm可以解決這些問題。

Storm的重要性

Storm暴露了1系列的原語用于實時計算。就像MapReduce極大的簡化了并行批處理程序的編寫，Storm的原語也極大的簡化了并行實時計算程序的編寫。

Storm的關鍵特性：

1. 使用處景非常廣泛。Storm可以用于處理消息，更新數據庫（流式處理），對數據流進行連續查詢并將結果流式的返回給客戶端（連續計算），散布式RPC等等。少許的原語滿足了大量的使用需求。
2. 擴大性。Storm可以擴大到每秒鐘可處理大量的消息。要擴大1個拓撲，你只需要添加機器并修改拓撲的設置就能夠。作為例子，Storm的1個初始利用，在具有10個節點的集群上面，每秒鐘可以處理1,000,000條消息，其中還包括了每秒鐘幾百次的數據庫訪問。通過使用ZooKeeper，Storm的集群可以擴大到1個更大的范圍。
3. 可靠性。1個實時系統必須能夠保證所有的數據都被成功處理，如果沒法保證將會限制它的使用處景。Storm可以保證每條消息都被處理。這是Storm與其他系統，比如S4，最大的不同。
4. 魯棒性。Hadoop是出了名的難管理，而Storm不1樣。讓用戶盡量不費力氣的來管理Storm集群是Storm項目的1個目標。
5. 容錯性。當計算進程中產生了故障，如果有必要的話Storm會重新分配任務。Storm會確保計算任務1直進行下去，除非你去終止它。
6. 編程語言無關性。具有魯棒性與擴大性的實時處理系統不應當局限在單1的平臺上。可使用任何的語言來定義Storm的拓撲邏輯和組件，這使得幾近所有人都可使用Storm。