Storm：最火的流式處理框架

來源：懂視網(wǎng) 責編：小采時間：2020-11-09 13:18:29

Storm：最火的流式處理框架

Storm：最火的流式處理框架:誕生在2011年Storm開源之前，由于Hadoop的火紅，整個業(yè)界都在喋喋不休地談論大數(shù)據(jù)。Hadoop的高吞吐，海量數(shù)據(jù)處理的能力使得人們可以方便地處理海量數(shù)據(jù)。但是，Hadoop的缺點也和它的優(yōu)點同樣鮮明——延遲大，響應緩慢，運維復雜。有需求也就有創(chuàng)造，在

推薦度：

點擊下載本文 文檔為doc格式

導讀Storm：最火的流式處理框架:誕生在2011年Storm開源之前，由于Hadoop的火紅，整個業(yè)界都在喋喋不休地談論大數(shù)據(jù)。Hadoop的高吞吐，海量數(shù)據(jù)處理的能力使得人們可以方便地處理海量數(shù)據(jù)。但是，Hadoop的缺點也和它的優(yōu)點同樣鮮明——延遲大，響應緩慢，運維復雜。有需求也就有創(chuàng)造，在

在GitHub上超過4000個項目負責人。Storm集成了許多庫，支持包括Kestrel、Kafka、JMS、Cassandra、Memcached以及更多系統(tǒng)。隨著支持的庫越來越多，Storm更容易與現(xiàn)有的系統(tǒng)協(xié)作。

Storm的擁有一個活躍的社區(qū)和一群熱心的貢獻者。過去兩年，Storm的發(fā)展是成功的。

當前

　　Storm被廣泛應用于實時分析，在線機器學習，持續(xù)計算、分布式遠程調用等領域。來看一些實際的應用:

一淘-實時分析系統(tǒng)pora：實時分析用戶的屬性，并反饋給搜索引擎。最初，用戶屬性分析是通過每天在云梯上定時運行的MR job來完成的。為了滿足實時性的要求，希望能夠實時分析用戶的行為日志，將最新的用戶屬性反饋給搜索引擎，能夠為用戶展現(xiàn)最貼近其當前需求的結果。

攜程-網(wǎng)站性能監(jiān)控：實時分析系統(tǒng)監(jiān)控攜程網(wǎng)的網(wǎng)站性能。利用HTML5提供的performance標準獲得可用的指標，并記錄日志。Storm集群實時分析日志和入庫。使用DRPC聚合成報表，通過歷史數(shù)據(jù)對比等判斷規(guī)則，觸發(fā)預警事件。　　

如果，業(yè)務場景中需要低延遲的響應，希望在秒級或者毫秒級完成分析、并得到響應，而且希望能夠隨著數(shù)據(jù)量的增大而拓展。那就可以考慮下，使用Storm了。　　

試想下，如果，一個游戲新版本上線，有一個實時分析系統(tǒng)，收集游戲中的數(shù)據(jù)，運營或者開發(fā)者可以在上線后幾秒鐘得到持續(xù)不斷更新的游戲監(jiān)控報告和分析結果，然后馬上針對游戲的參數(shù)和平衡性進行調整。這樣就能夠大大縮短游戲迭代周期，加強游戲的生命力（實際上，zynga就是這么干的！雖然使用的不是Storm……Zynga研發(fā)之道探秘：用數(shù)據(jù)說話）。　

除了低延遲，Storm的Topology靈活的編程方式和分布式協(xié)調也會給我們帶來方便。用戶屬性分析的項目，需要處理大量的數(shù)據(jù)。使用傳統(tǒng)的MapReduce處理是個不錯的選擇。但是，處理過程中有個步驟需要根據(jù)分析結果，采集網(wǎng)頁上的數(shù)據(jù)進行下一步的處理。這對于MapReduce來說就不太適用了。但是，Storm的Topology就能完美解決這個問題。基于這個問題，我們可以畫出這樣一個Storm的Topology的處理圖。

用戶分詞

我們只需要實現(xiàn)每個分析的過程，而Storm幫我們把消息的傳送和接受都完成了。更加激動人心的是，你只需要增加某個Bolt的并行度就能夠解決掉某個結點上的性能瓶頸。

未來

　在流式處理領域里，Storm的直接對手是S4。不過，S4冷淡的社區(qū)、半成品的代碼，在實際商用方面輸給Storm不止一條街。

　如果把范圍擴大到實時處理，Storm就一點都不寂寞了。

Puma：Facebook使用puma和Hbase相結合來處理實時數(shù)據(jù),使批處理計算平臺具備一定實時能力。不過這不算是一個開源的產品。只是內部使用。

HStreaming：嘗試為Hadoop環(huán)境添加一個實時的組件HStreaming能讓一個Hadoop平臺在幾天內轉為一個實時系統(tǒng)。分商業(yè)版和免費版。也許HStreaming可以借Hadoop的東風，撼動Storm。

Spark Streaming：作為UC Berkeley云計算software stack的一部分，Spark Streaming是建立在Spark上的應用框架，利用Spark的底層框架作為其執(zhí)行基礎，并在其上構建了DStream的行為抽象。利用DStream所提供的api，用戶可以在數(shù)據(jù)流上實時進行count，join，aggregate等操作。

當然，Storm也有Yarn-Storm項目，能讓Storm運行在Hadoop2.0的Yarn框架上，可以讓Hadoop的MapReduce和Storm共享資源。

總結

知乎上有一個挺好的問答：問：實時處理系統(tǒng)（類似s4, storm）對比直接用MQ來做好處在哪里？? 答：好處是它幫你做了： 1) 集群控制。2) 任務分配。3) 任務分發(fā) 4) 監(jiān)控等等。

需要知道Storm不是一個完整的解決方案。使用Storm你需要加入消息隊列做數(shù)據(jù)入口，考慮如何在流中保存狀態(tài)，考慮怎樣將大問題用分布式去解決。解決這些問題的成本可能比增加一個服務器的成本還高。但是，一旦下定決定使用了Storm并解決了那些惱人的細節(jié)，你就能享受到Storm給你帶來的簡單，可拓展等優(yōu)勢了。

技術的發(fā)展日新月異，數(shù)據(jù)處理領域越來越多優(yōu)秀的開源產品。Storm的過去是成功的，將來會如何發(fā)展，我們拭目以待吧。