Twitter Storm簡介
網址: http://xumingming.sinaapp.com/109/twitter-storm簡介/
本文翻譯自storm官方wiki: https://github.com/nathanmarz/storm/wiki/Rationale
背景
過去的十年是數據處理變革的十年， MapReduce, Hadoop以及一些相關的技術使得我們能處理的數據量比以前要大得多得多。但是這些數據處理技術都不是實時的系統 — 它們設計的目的也不是爲了實時計算。沒有什麼辦法可以簡單地把hadoop變成一個實時計算系統。實時數據處理系統和批量數據處理系統在需求上有着本質的差別。
然而大規模的實時數據處理已經越來越成爲一種業務需求了， 而缺少一個“實時版本的hadoop”已經成爲數據處理整個生態系統的一個巨大缺失。
Storm填補了這個缺失。
Storm出現之前，你可能需要自己手動維護一個由消息隊列和消息處理者所組成的實時處理網絡， 消息處理者從消息隊列取出一個消息進行處理， 更新數據庫，發送消息給其它隊列， 等等等等。不幸的是，這種方式有以下幾個缺陷：
1. 單調乏味： 你花費了絕大部分開發時間去配置把消息發送到哪裏， 部署消息處理者，部署中間消息節點 — 你的大部分時間花在設計， 配置這個數據處理框架上， 而你真正關心的消息處理邏輯在你的代碼裏面佔的比例很少。
2. 脆弱： 不夠健壯， 你要自己寫代碼保證所有的消息處理者和消息隊列正常運行。
3. 伸縮性差： 當一個消息處理者的消息量達到閥值，你需要對這些數據進行分流， 你需要配置這些新的處理者以讓他們處理分流的消息。
雖然對於一個大量消息處理系統來說，分解到最後就是消息隊列和消息處理者的組合，而消息處理無疑是實時計算的基礎。那麼現在問題就是：怎樣去做才能不丟失數據，可以很好的擴展到更大的消息量並且非常容易操作呢？
Storm滿足你的需求。
爲什麼我們說Storm很重要呢？
Storm定義了一批實時計算的原語。如同hadoop大大簡化了並行批量數據處理，storm的這些原語大大簡化了並行實時數據處理。storm的一些關鍵特性如下：
1. 適用場景廣泛： storm可以用來處理消息和更新數據庫(消息流處理), 對一個數據量進行持續的查詢並返回客戶端（持續計算）， 對一個耗資源的查詢作實時並行化的處理(分佈式方法調用）， storm的這些基礎原語可以滿足大量的場景。
2. 可伸縮性高: Storm的可伸縮性可以讓storm每秒可以處理的消息量達到很高。爲了擴展一個實時計算任務，你所需要做的就是加機器並且提高這個計算任務的並行度設置(parallelism setting)。作爲Storm可伸縮性的一個例證， 一個Storm應用在一個10個節點的集羣上每秒處理1000000個消息 — 包括每秒一百多次的數據庫調用。Storm使用ZooKeeper來協調集羣內的各種配置使得Storm的集羣可以很容易的擴展很大。
3. 保證無數據丟失： 實時系統必須保證所有的數據被成功的處理。 那些會丟失數據的系統的適用場景非常窄， 而storm保證每一條消息都會被處理， 這一點和S4相比有巨大的反差。
4. 異常健壯： 不像Hadoop — 出了名的難管理， storm集羣非常容易管理。容易管理是storm的設計目標之一。
5. 容錯性好：如果在消息處理過程中出了一些異常， storm會重新安排這個出問題的處理邏輯。 storm保證一個處理邏輯永遠運行 — 除非你顯式殺掉這個處理邏輯。
6. 語言無關性： 健壯性和可伸縮性不應該侷限於一個平臺。Storm的topology和消息處理組件可以用任何語言來定義， 這一點使得任何人都可以使用storm.
