在GitHub上超過4000個項目負責人。Storm集成了許多庫,支持包括Kestrel、Kafka、JMS、Cassandra、Memcached以及更多系統。隨著支持的庫越來越多,Storm更容易與現有的系統協作。
Storm的擁有一個活躍的社區和一群熱心的貢獻者。過去兩年,Storm的發展是成功的。
Storm被廣泛應用于實時分析,在線機器學習,持續計算、分布式遠程調用等領域。來看一些實際的應用:
攜程-網站性能監控:實時分析系統監控攜程網的網站性能。利用HTML5提供的performance標準獲得可用的指標,并記錄日志。Storm集群實時分析日志和入庫。使用DRPC聚合成報表,通過歷史數據對比等判斷規則,觸發預警事件。
如果,業務場景中需要低延遲的響應,希望在秒級或者毫秒級完成分析、并得到響應,而且希望能夠隨著數據量的增大而拓展。那就可以考慮下,使用Storm了。
試想下,如果,一個游戲新版本上線,有一個實時分析系統,收集游戲中的數據,運營或者開發者可以在上線后幾秒鐘得到持續不斷更新的游戲監控報告和分析結果,然后馬上針對游戲的參數和平衡性進行調整。這樣就能夠大大縮短游戲迭代周期,加強游戲的生命力(實際上,zynga就是這么干的!雖然使用的不是Storm……Zynga研發之道探秘:用數據說話)。
除了低延遲,Storm的Topology靈活的編程方式和分布式協調也會給我們帶來方便。用戶屬性分析的項目,需要處理大量的數據。使用傳統的MapReduce處理是個不錯的選擇。但是,處理過程中有個步驟需要根據分析結果,采集網頁上的數據進行下一步的處理。這對于MapReduce來說就不太適用了。但是,Storm的Topology就能完美解決這個問題。基于這個問題,我們可以畫出這樣一個Storm的Topology的處理圖。
我們只需要實現每個分析的過程,而Storm幫我們把消息的傳送和接受都完成了。更加激動人心的是,你只需要增加某個Bolt的并行度就能夠解決掉某個結點上的性能瓶頸。
在流式處理領域里,Storm的直接對手是S4。不過,S4冷淡的社區、半成品的代碼,在實際商用方面輸給Storm不止一條街。
如果把范圍擴大到實時處理,Storm就一點都不寂寞了。
Spark Streaming:作為UC Berkeley云計算software stack的一部分,Spark Streaming是建立在Spark上的應用框架,利用Spark的底層框架作為其執行基礎,并在其上構建了DStream的行為抽象。利用DStream所提供的api,用戶可以在數據流上實時進行count,join,aggregate等操作。
當然,Storm也有Yarn-Storm項目,能讓Storm運行在Hadoop2.0的Yarn框架上,可以讓Hadoop的MapReduce和Storm共享資源。
知乎上有一個挺好的問答: 問:實時處理系統(類似s4, storm)對比直接用MQ來做好處在哪里?? 答:好處是它幫你做了: 1) 集群控制。2) 任務分配。3) 任務分發 4) 監控 等等。
需要知道Storm不是一個完整的解決方案。使用Storm你需要加入消息隊列做數據入口,考慮如何在流中保存狀態,考慮怎樣將大問題用分布式去解決。解決這些問題的成本可能比增加一個服務器的成本還高。但是,一旦下定決定使用了Storm并解決了那些惱人的細節,你就能享受到Storm給你帶來的簡單,可拓展等優勢了。
技術的發展日新月異,數據處理領域越來越多優秀的開源產品。Storm的過去是成功的,將來會如何發展,我們拭目以待吧。
本文的重點是描述Storm的應用場景和未來的發展前景,讓大家對Storm有一個初步的印象。如果,要落地使用的朋友,在網上可以找到很多優秀的Storm的技術文章。例如:Storm的核心貢獻者徐明明的博客和淘寶關于storm的文章。
原文地址:Storm:最火的流式處理框架, 感謝原作者分享。
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com