storm

伴随着資訊科技日新月異的發展，資訊呈現出爆發式的膨脹，人們擷取資訊的途徑也更加多樣、更加便捷，同時對于資訊的時效性要求也越來越高。舉個搜尋場景中的例子，當一個賣家釋出了一條寶貝資訊時，他希望的當然是這個寶貝馬上就可以被賣家搜尋出來、點選、購買啦，相反，如果這個寶貝要等到第二天或者更久才可以被搜出來，估計這個大哥就要罵娘了。再舉一個推薦的例子，如果使用者昨天在淘寶上買了一雙襪子，今天想買一副泳鏡去遊泳，但是卻發現系統在不遺餘力地給他推薦襪子、鞋子，根本對他今天尋找泳鏡的行為視而不見，估計這哥們心裡就會想推薦你妹呀。其實稍微了解點背景知識的碼農們都知道，這是因為背景系統做的是每天一次的全量處理，而且大多是在夜深人靜之時做的，那麼你今天白天做的事情當然要明天才能反映出來啦。

實作一個實時計算系統

全量資料處理使用的大多是鼎鼎大名的hadoop或者hive，作為一個批處理系統，hadoop以其吞吐量大、自動容錯等優點，在海量資料處理上得到了廣泛的使用。但是，hadoop不擅長實時計算，因為它天然就是為批處理而生的，這也是業界一緻的共識。否則最近這兩年也不會有s4,storm,puma這些實時計算系統如雨後春筍般冒出來啦。先抛開s4,storm,puma這些系統不談，我們首先來看一下，如果讓我們自己設計一個實時計算系統，我們要解決哪些問題。

低延遲。都說了是實時計算系統了，延遲是一定要低的。

高性能。性能不高就是浪費機器，浪費機器是要受批評的哦。

分布式。系統都是為應用場景而生的，如果你的應用場景、你的資料和計算單機就能搞定，那麼不用考慮這些複雜的問題了。我們所說的是單機搞不定的情況。

可擴充。伴随着業務的發展，我們的資料量、計算量可能會越來越大，是以希望這個系統是可擴充的。

容錯。這是分布式系統中通用問題。一個節點挂了不能影響我的應用。

好，如果僅僅需要解決這5個問題，可能會有無數種方案，而且各有千秋，随便舉一種方案，使用消息隊列+分布在各個機器上的工作程序就ok啦。我們再繼續往下看。

容易在上面開發應用程式。親，你設計的系統需要應用程式開發人員考慮各個處理元件的分布、消息的傳遞嗎？如果是，那有點麻煩啊，開發人員可能會用不好，也不會想去用。

消息不丢失。使用者釋出的一個寶貝消息不能在實時處理的時候給丢了，對吧？更嚴格一點，如果是一個精确資料統計的應用，那麼它處理的消息要不多不少才行。這個要求有點高哦。

誕 生

在2011年Storm開源之前，由于Hadoop的火紅，整個業界都在喋喋不休地談論大資料。Hadoop的高吞吐，海量資料處理的能力使得人們可以友善地處理海量資料。但是，Hadoop的缺點也和它的優點同樣鮮明——延遲大，響應緩慢，運維複雜。

有需求也就有創造，在Hadoop基本奠定了大資料霸主地位的時候，很多的開源項目都是以彌補Hadoop的實時性為目标而被創造出來。而在這個節骨眼上Storm橫空出世了。

Storm帶着流式計算的标簽華麗麗滴出場了，看看它的一些賣點：

分布式系統：可橫向拓展,現在的項目不帶個分布式特性都不好意思開源。

運維簡單：Storm的部署的确簡單。雖然沒有Mongodb的解壓即用那麼簡單，但是它也就是多安裝兩個依賴庫而已。

高度容錯：子產品都是無狀态的，随時當機重新開機。

無資料丢失：Storm創新性提出的ack消息追蹤架構和複雜的事務性處理,能夠滿足很多級别的資料處理需求。不過，越高的資料處理需求，性能下降越嚴重。

多語言：實際上，Storm的多語言更像是臨時添加上去似的。因為，你的送出部分還是要使用Java實作。

下面，我們簡單地認識一下Storm這個産品。

認 識

Storm是一個免費開源、分布式、高容錯的實時計算系統。Storm令持續不斷的流計算變得容易，彌補了Hadoop批處理所不能滿足的實時要求。Storm經常用于在實時分析、線上機器學習、持續計算、分布式遠端調用和ETL等領域。Storm的部署管理非常簡單，而且，在同類的流式計算工具，Storm的性能也是非常出衆的。

Nimbus負責在叢集裡面發送代碼，配置設定工作給機器，并且監控狀态。全局隻有一個。

Supervisor會監聽配置設定給它那台機器的工作，根據需要啟動/關閉工作程序Worker。每一個要運作Storm的機器上都要部署一個，并且，按照機器的配置設定上面配置設定的槽位數。

Zookeeper是Storm重點依賴的外部資源。Nimbus和Supervisor甚至實際運作的Worker都是把心跳儲存在Zookeeper上的。Nimbus也是根據Zookeerper上的心跳和任務運作狀況，進行排程和任務配置設定的。

Storm送出運作的程式稱為Topology。

Topology處理的最小的消息機關是一個Tuple，也就是一個任意對象的數組。

Topology由Spout和Bolt構成。Spout是發出Tuple的結點。Bolt可以随意訂閱某個Spout或者Bolt發出的Tuple。Spout和Bolt都統稱為component。

下圖是一個Topology設計的邏輯圖的例子。

topology01

下圖是Topology的送出流程圖。

topology02

下圖是Storm的資料互動圖。可以看出兩個子產品Nimbus和Supervisor之間沒有直接互動。狀态都是儲存在Zookeeper上。Worker之間通過ZeroMQ傳送資料。

topology03

雖然，有些地方做得還是不太好，例如，底層使用的ZeroMQ不能控制記憶體使用(下個release版本，引入了新的消息機制使用netty代替ZeroMQ），多語言支援更多是噱頭，Nimbus還不支援HA。但是，就像當年的Hadoop那樣，很多公司選擇它是因為它是唯一的選擇。而這些先期使用者，反過來促進了Storm的發展。

發 展

Storm已經發展到0.8.2版本了，看一下兩年多來，它取得的成就：

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

從開源時候的0.5.0版本，到現在的0.8.0+，和即将到來的0.9.0+。先後添加了以下重大的新特性：

使用kryo作為Tuple序列化的架構（0.6.0）

添加了Transactional topologies（事務性拓撲）的支援（0.7.0）

添加了Trident的支援（0.8.0）

引入netty作為底層消息機制（0.9.0）

Transactional topologies和Trident都是針對實際應用中遇到的重複計數問題和應用性問題的解決方案。可以看出，實際的商用給予了Storm很多良好的回報。

在GitHub上超過4000個項目負責人。Storm內建了許多庫，支援包括Kestrel、Kafka、JMS、Cassandra、Memcached以及更多系統。随着支援的庫越來越多，Storm更容易與現有的系統協作。Storm的擁有一個活躍的社群和一群熱心的貢獻者。過去兩年，Storm的發展是成功的。

當 前

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

一淘-實時分析系統pora：實時分析使用者的屬性，并回報給搜尋引擎。最初，使用者屬性分析是通過每天在雲梯上定時運作的MR job來完成的。為了滿足實時性的要求，希望能夠實時分析使用者的行為日志，将最新的使用者屬性回報給搜尋引擎，能夠為使用者展現最貼近其目前需求的結果。

攜程-網站性能監控：實時分析系統監控攜程網的網站性能。利用HTML5提供的performance标準獲得可用的名額，并記錄日志。Storm叢集實時分析日志和入庫。使用DRPC聚合成報表，通過曆史資料對比等判斷規則，觸發預警事件。

如果，業務場景中需要低延遲的響應，希望在秒級或者毫秒級完成分析、并得到響應，而且希望能夠随着資料量的增大而拓展。那就可以考慮下，使用Storm了。

試想下，如果，一個遊戲新版本上線，有一個實時分析系統，收集遊戲中的資料，營運或者開發者可以在上線後幾秒鐘得到持續不斷更新的遊戲監控報告和分析結果，然後馬上針對遊戲的參數和平衡性進行調整。這樣就能夠大大縮短遊戲疊代周期，加強遊戲的生命力（實際上，zynga就是這麼幹的！雖然使用的不是Storm……Zynga研發之道探秘：用資料說話）。

除了低延遲，Storm的Topology靈活的程式設計方式和分布式協調也會給我們帶來友善。使用者屬性分析的項目，需要處理大量的資料。使用傳統的MapReduce處理是個不錯的選擇。但是，處理過程中有個步驟需要根據分析結果，采集網頁上的資料進行下一步的處理。這對于MapReduce來說就不太适用了。但是，Storm的Topology就能完美解決這個問題。基于這個問題，我們可以畫出這樣一個Storm的Topology的處理圖。

topology04

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

未 來

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

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

Puma：Facebook使用puma和Hbase相結合來處理實時資料,使批處理 計算平台具備一定實時能力。 不過這不算是一個開源的産品。隻是内部使用。

HStreaming：嘗試為Hadoop環境添加一個實時的元件HStreaming能讓一個Hadoop平台在幾天内轉為一個實時系統。分商業版和免費版。也許HStreaming可以借Hadoop的東風，撼動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的過去是成功的，将來會如何發展，我們拭目以待吧。