誕 生

在2011年Storm開源之前，由于Hadoop的火紅，整個(gè)業(yè)界都在喋喋不休地談?wù)摯髷?shù)據(jù)。Hadoop的高吞吐，海量數(shù)據(jù)處理的能力使得人們可以方便地處理海量數(shù)據(jù)。但是，Hadoop的缺點(diǎn)也和它的優(yōu)點(diǎn)同樣鮮明——延遲大，響應(yīng)緩慢，運(yùn)維復(fù)雜。

有需求也就有創(chuàng)造，在Hadoop基本奠定了大數(shù)據(jù)霸主地位的時(shí)候，很多的開源項(xiàng)目都是以彌補(bǔ)Hadoop的實(shí)時(shí)性為目標(biāo)而被創(chuàng)造出來(lái)。而在這個(gè)節(jié)骨眼上Storm橫空出世了。

Storm帶著流式計(jì)算的標(biāo)簽華麗麗滴出場(chǎng)了，看看它的一些賣點(diǎn)：

• 分布式系統(tǒng)：可橫向拓展,現(xiàn)在的項(xiàng)目不帶個(gè)分布式特性都不好意思開源。
• 運(yùn)維簡(jiǎn)單：Storm的部署的確簡(jiǎn)單。雖然沒有Mongodb的解壓即用那么簡(jiǎn)單，但是它也就是多安裝兩個(gè)依賴庫(kù)而已。
• 高度容錯(cuò)：模塊都是無(wú)狀態(tài)的，隨時(shí)宕機(jī)重啟。
• 無(wú)數(shù)據(jù)丟失：Storm創(chuàng)新性提出的ack消息追蹤框架和復(fù)雜的事務(wù)性處理,能夠滿足很多級(jí)別的數(shù)據(jù)處理需求。不過，越高的數(shù)據(jù)處理需求，性能下降越嚴(yán)重。

• 多語(yǔ)言：實(shí)際上，Storm的多語(yǔ)言更像是臨時(shí)添加上去似的。因?yàn)椋愕奶峤徊糠诌€是要使用Java實(shí)現(xiàn)。

  下面，我們簡(jiǎn)單地認(rèn)識(shí)一下Storm這個(gè)產(chǎn)品。

認(rèn) 識(shí)

Storm是一個(gè)免費(fèi)開源、分布式、高容錯(cuò)的實(shí)時(shí)計(jì)算系統(tǒng)。Storm令持續(xù)不斷的流計(jì)算變得容易，彌補(bǔ)了Hadoop批處理所不能滿足的實(shí)時(shí)要求。Storm經(jīng)常用于在實(shí)時(shí)分析、在線機(jī)器學(xué)習(xí)、持續(xù)計(jì)算、分布式遠(yuǎn)程調(diào)用和ETL等領(lǐng)域。Storm的部署管理非常簡(jiǎn)單，而且，在同類的流式計(jì)算工具，Storm的性能也是非常出眾的。

Storm主要分為兩種組件Nimbus和Supervisor。這兩種組件都是快速失敗的，沒有狀態(tài)。任務(wù)狀態(tài)和心跳信息等都保存在Zookeeper上的，提交的代碼資源都在本地機(jī)器的硬盤上。

• Nimbus負(fù)責(zé)在集群里面發(fā)送代碼，分配工作給機(jī)器，并且監(jiān)控狀態(tài)。全局只有一個(gè)。
• Supervisor會(huì)監(jiān)聽分配給它那臺(tái)機(jī)器的工作，根據(jù)需要啟動(dòng)/關(guān)閉工作進(jìn)程Worker。每一個(gè)要運(yùn)行Storm的機(jī)器上都要部署一個(gè)，并且，按照機(jī)器的配置設(shè)定上面分配的槽位數(shù)。
• Zookeeper是Storm重點(diǎn)依賴的外部資源。Nimbus和Supervisor甚至實(shí)際運(yùn)行的Worker都是把心跳保存在Zookeeper上的。Nimbus也是根據(jù)Zookeerper上的心跳和任務(wù)運(yùn)行狀況，進(jìn)行調(diào)度和任務(wù)分配的。
• Storm提交運(yùn)行的程序稱為Topology。
• Topology處理的最小的消息單位是一個(gè)Tuple，也就是一個(gè)任意對(duì)象的數(shù)組。
• Topology由Spout和Bolt構(gòu)成。Spout是發(fā)出Tuple的結(jié)點(diǎn)。Bolt可以隨意訂閱某個(gè)Spout或者Bolt發(fā)出的Tuple。Spout和Bolt都統(tǒng)稱為component。

下圖是一個(gè)Topology設(shè)計(jì)的邏輯圖的例子。

下圖是Topology的提交流程圖。

　 　

下圖是Storm的數(shù)據(jù)交互圖。可以看出兩個(gè)模塊Nimbus和Supervisor之間沒有直接交互。狀態(tài)都是保存在Zookeeper上。Worker之間通過ZeroMQ傳送數(shù)據(jù)。

雖然，有些地方做得還是不太好，例如，底層使用的ZeroMQ不能控制內(nèi)存使用(下個(gè)release版本，引入了新的消息機(jī)制使用netty代替ZeroMQ），多語(yǔ)言支持更多是噱頭，Nimbus還不支持HA。但是，就像當(dāng)年的Hadoop那樣，很多公司選擇它是因?yàn)樗俏ㄒ坏倪x擇。而這些先期使用者，反過來(lái)促進(jìn)了Storm的發(fā)展。

#p#

發(fā) 展

Storm已經(jīng)發(fā)展到0.8.2版本了，看一下兩年多來(lái)，它取得的成就：

• 有50個(gè)大大小小的公司在使用Storm，相信更多的不留名的公司也在使用。這些公司中不乏淘寶，百度，Twitter，Groupon，雅虎等重量級(jí)公司。

• 從開源時(shí)候的0.5.0版本，到現(xiàn)在的0.8.0+，和即將到來(lái)的0.9.0+。先后添加了以下重大的新特性：

  • 使用kryo作為Tuple序列化的框架（0.6.0）
  • 添加了Transactional topologies（事務(wù)性拓?fù)洌┑闹С郑?.7.0）
  • 添加了Trident的支持（0.8.0）
  • 引入netty作為底層消息機(jī)制（0.9.0）

Transactional topologies和Trident都是針對(duì)實(shí)際應(yīng)用中遇到的重復(fù)計(jì)數(shù)問題和應(yīng)用性問題的解決方案?？梢钥闯觯瑢?shí)際的商用給予了Storm很多良好的反饋。

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

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

當(dāng) 前

Storm被廣泛應(yīng)用于實(shí)時(shí)分析，在線機(jī)器學(xué)習(xí)，持續(xù)計(jì)算、分布式遠(yuǎn)程調(diào)用等領(lǐng)域。來(lái)看一些實(shí)際的應(yīng)用:

• 一淘-實(shí)時(shí)分析系統(tǒng)pora：實(shí)時(shí)分析用戶的屬性，并反饋給搜索引擎。最初，用戶屬性分析是通過每天在云梯上定時(shí)運(yùn)行的MR job來(lái)完成的。為了滿足實(shí)時(shí)性的要求，希望能夠?qū)崟r(shí)分析用戶的行為日志，將最新的用戶屬性反饋給搜索引擎，能夠?yàn)橛脩粽宫F(xiàn)最貼近其當(dāng)前需求的結(jié)果。

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

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

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

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

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

未 來(lái)

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

　如果把范圍擴(kuò)大到實(shí)時(shí)處理，Storm就一點(diǎn)都不寂寞了。

• Puma：Facebook使用puma和Hbase相結(jié)合來(lái)處理實(shí)時(shí)數(shù)據(jù),使批處理 計(jì)算平臺(tái)具備一定實(shí)時(shí)能力。 不過這不算是一個(gè)開源的產(chǎn)品。只是內(nèi)部使用。
• HStreaming：嘗試為Hadoop環(huán)境添加一個(gè)實(shí)時(shí)的組件HStreaming能讓一個(gè)Hadoop平臺(tái)在幾天內(nèi)轉(zhuǎn)為一個(gè)實(shí)時(shí)系統(tǒng)。分商業(yè)版和免費(fèi)版。也許HStreaming可以借Hadoop的東風(fēng)，撼動(dòng)Storm。

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

  當(dāng)然，Storm也有Yarn-Storm項(xiàng)目，能讓Storm運(yùn)行在Hadoop2.0的Yarn框架上，可以讓Hadoop的MapReduce和Storm共享資源。

總 結(jié)

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

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

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

后記

本文的重點(diǎn)是描述Storm的應(yīng)用場(chǎng)景和未來(lái)的發(fā)展前景，讓大家對(duì)Storm有一個(gè)初步的印象。如果，要落地使用的朋友，在網(wǎng)上可以找到很多優(yōu)秀的Storm的技術(shù)文章。例如：Storm的核心貢獻(xiàn)者徐明明的博客和淘寶關(guān)于storm的文章。

原文鏈接：http://tech.uc.cn/?p=2159