在過去的十年裡，資料處理發生了革命性的變化。MapReduce，Hadoop，以及相關的技術使我們可以儲存和處理以前不可想象規模的資料。很遺憾，這些資料處理系統都不是實時系統，命中註定也不是它們。根本沒辦法把Hadoop變成一個實時系統；實時資料處理和批處理的許多要求在根本上有很大不同。
然而，企業對大規模實時資料處理要求越來越多。缺乏“實時Hadoop”是資料處理生態系統中最大的窘境。
Storm解決了這個窘境。
Storm之前，你通常必須手動建立一個由許多佇列和許多worker組成的網路來實現實時處理。worker處理佇列訊息，更新資料庫，傳送新訊息給其它佇列以供後續處理。很遺憾，這種方法有很大的侷限性。
乏味：你大部份開發時間花費在配置訊息傳送，部署worker，部署中間佇列。你關心的實時處理邏輯對應到你的程式碼的比例相對較小 。
脆弱：沒有多少容錯。你負責保持每個worker和佇列正常工作。
痛苦伸縮：當單個worker或佇列的訊息吞吐量太高時，你需要分割槽，即資料如何分散。你需要重新配置其它worker，讓它們傳送訊息到新位置。這導致刪除或新增部件都可能失敗。
雖然佇列+workers的正規化能解決大量的訊息，訊息處理顯然是實時計算的基本正規化。問題是：你要怎麼做，才能在某種程度上保證資料不會丟失，對海量訊息輕鬆擴容，並且使用和運營工作都超級簡單呢？
Storm滿足這些目標。
Storm如此重要，為什麼？
Storm公開（expose）一組實時計算原語。類似MapReduce極大地簡化了編寫並行批處理程式，storm的原語極大地簡化了編寫並行實時計算程式。
Storm的關鍵特性：
用例非常廣泛：Storm可用於處理訊息和更新資料庫（流處理），在資料流上進行持續查詢，並以流的形式返回結果到客戶端（持續計算），並行化一個類似實時查詢的熱點查詢（分散式的RPC），還有更多的用例。Storm的一組很小的原語滿足了驚人數量的用例。
可伸縮：Storm隨時都可對大規模訊息進行擴容。擴容一個拓撲，你只需要新增機器和增加的拓撲結構的並行設定。看一個storm規模的例子，一個storm叢集有10個節點，一個最初的Storm應用每秒可以處理1,000,000個訊息（指spout和bolt總共發射的訊息總和），拓撲的其中一部分每秒數有數百個資料庫呼叫。Storm使用Zookeeper協調叢集，使其叢集可以擴容到非常大。
保證資料不丟失：實時系統必須對成功處理資料提供有力保證 。系統丟棄資料的用例非常有限。Storm保證每個訊息都被處理，這直接與其它系統截然不同，如S4。
非常健壯：Storm與Hadoop不同，Hadoop難於管理早已臭名昭著，Storm叢集只是幹活。使使用者儘可能方便地管理storm叢集是storm專案的一個明確目標。
容錯：計算的執行過程中如果發生故障，Storm將在必要時重新分配任務。Storm確保計算永遠執行（或者直到你kill此計算） 。
程式語言無關性：健壯和可伸縮的實時處理不應僅限於一個單一的平臺。Storm的拓撲結構和處理元件可以用任何語言定義，對任何人而言，Storm都是易接受的。