在2023年storm開源之前，由於hadoop的火紅，整個業界都在喋喋不休地談論大資料。hadoop的高吞吐，海量資料處理的能力使得人們可以方便地處理海量資料。但是，hadoop的缺點也和它的優點同樣鮮明——延遲大，響應緩慢，運維複雜。
有需求也就有創造，在hadoop基本奠定了大資料霸主地位的時候，很多的開源專案都是以彌補hadoop的實時性為目標而被創造出來。而在這個節骨眼上storm橫空出世了。
storm帶著流式計算的標籤華麗麗滴出場了，看看它的一些賣點：
storm主要分為兩種元件nimbus和supervisor。這兩種元件都是快速失敗的，沒有狀態。任務狀態和心跳資訊等都儲存在zookeeper上的，提交的**資源都在本地機器的硬碟上。
下圖是乙個topology設計的邏輯圖的例子。
下圖是topology的提交流程圖。
下圖是storm的資料互動圖。可以看出兩個模組nimbus和supervisor之間沒有直接互動。狀態都是儲存在zookeeper上。worker之間通過zeromq傳送資料。
雖然，有些地方做得還是不太好，例如，底層使用的zeromq不能控制記憶體使用(下個release版本，引入了新的訊息機制使用netty代替zeromq），多語言支援更多是噱頭，nimbus還不支援ha。但是，就像當年的hadoop那樣，很多公司選擇它是因為它是唯一的選擇。而這些先期使用者，反過來促進了storm的發展。
storm已經發展到0.8.2版本了，看一下兩年多來，它取得的成就：
從開源時候的0.5.0版本，到現在的0.8.0+，和即將到來的0.9.0+。先後新增了以下重大的新特性：
transactional topologies和trident都是針對實際應用中遇到的重複計數問題和應用性問題的解決方案。可以看出，實際的商用給予了storm很多良好的反饋。
我們只需要實現每個分析的過程，而storm幫我們把訊息的傳送和接受都完成了。更加激動人心的是，你只需要增加某個bolt的並行度就能夠解決掉某個結點上的效能瓶頸。
在流式處理領域裡，storm的直接對手是s4。不過，s4冷淡的社群、半成品的**，在實際商用方面輸給storm不止一條街。
如果把範圍擴大到實時處理，storm就一點都不寂寞了。
知乎上有乙個挺好的問答： 問：實時處理系統（類似s4, storm）對比直接用mq來做好處在**？ 答：好處是它幫你做了： 1) 集群控制。2) 任務分配。3) 任務分發 4) 監控 等等。
需要知道storm不是乙個完整的解決方案。使用storm你需要加入訊息佇列做資料入口，考慮如何在流中儲存狀態，考慮怎樣將大問題用分布式去解決。解決這些問題的成本可能比增加乙個伺服器的成本還高。但是，一旦下定決定使用了storm並解決了那些惱人的細節，你就能享受到storm給你帶來的簡單，可拓展等優勢了。
技術的發展日新月異，資料處理領域越來越多優秀的開源產品。storm的過去是成功的，將來會如何發展，我們拭目以待吧。
Storm 最火的流式處理框架
伴隨著資訊科技日新月異的發展，資訊呈現出爆發式的膨脹，人們獲取資訊的途徑也更加多樣 更加便捷，同時對於資訊的時效性要求也越來越高。舉個搜尋場景中的例子，當乙個賣家發布了一條寶貝資訊時，他希望的當然是這個寶貝馬上就可以被賣家搜尋出來 點選 購買啦，相反，如果這個寶貝要等到第二天或者更久才可以被搜出來，...
Storm流式處理框架概述
hadoop的高吞吐，海量資料處理的能力使得人們可以方便地處理海量資料。但是，hadoop的缺點也和它的優點同樣鮮明 延遲大，響應緩慢，運維複雜。有需求也就有創造，在hadoop基本奠定了大資料霸主地位的時候，很多的開源專案都是以彌補hadoop的實時性為目標而被創造出來。而在這個節骨眼上storm...
Storm 高效能流式計算處理框架
storm supervisor worker topology yarn mrstrom spout bolt mrdag有向無環圖 tuple stream spout bolt fields分組 all global none direct local or shuffle worker 程序...