Storm：最火的流式處理框架

伴隨着信息科技突飛猛進的發展，信息呈現出爆發式的膨脹，人們獲取信息的途徑也更加多樣、更加便捷，同時對於信息的時效性要求也愈來愈高。舉個搜索場景中的例子，當一個賣家發佈了一條寶貝信息時，他但願的固然是這個寶貝立刻就能夠被賣家搜索出來、點擊、購買啦，相反，若是這個寶貝要等到次日或者更久才能夠被搜出來，估計這個大哥就要罵娘了。再舉一個推薦的例子，若是用戶昨天在淘寶上買了一雙襪子，今天想買一副泳鏡去游泳，可是卻發現系統在竭盡全力地給他推薦襪子、鞋子，根本對他今天尋找泳鏡的行爲視而不見，估計這哥們內心就會想推薦你妹呀。其實稍微瞭解點背景知識的碼農們都知道，這是由於後臺系統作的是天天一次的全量處理，並且大可能是在夜深人靜之時作的，那麼你今天白天作的事情固然要明天才能反映出來啦。

• 實現一個實時計算系統

全量數據處理使用的大可能是鼎鼎大名的hadoop或者hive，做爲一個批處理系統，hadoop以其吞吐量大、自動容錯等優勢，在海量數據處理上獲得了普遍的使用。可是，hadoop不擅長實時計算，由於它自然就是爲批處理而生的，這也是業界一致的共識。不然最近這兩年也不會有s4,storm,puma這些實時計算系統如雨後春筍般冒出來啦。先拋開s4,storm,puma這些系統不談，咱們首先來看一下，若是讓咱們本身設計一個實時計算系統，咱們要解決哪些問題。

1. 低延遲。都說了是實時計算系統了，延遲是必定要低的。
2. 高性能。性能不高就是浪費機器，浪費機器是要受批評的哦。
3. 分佈式。系統都是爲應用場景而生的，若是你的應用場景、你的數據和計算單機就能搞定，那麼不用考慮這些複雜的問題了。咱們所說的是單機搞不定的狀況。
4. 可擴展。伴隨着業務的發展，咱們的數據量、計算量可能會愈來愈大，因此但願這個系統是可擴展的。
5. 容錯。這是分佈式系統中通用問題。一個節點掛了不能影響個人應用。

好，若是僅僅須要解決這5個問題，可能會有無數種方案，並且各有千秋，隨便舉一種方案，使用消息隊列+分佈在各個機器上的工做進程就ok啦。咱們再繼續往下看。

1. 容易在上面開發應用程序。親，你設計的系統須要應用程序開發人員考慮各個處理組件的分佈、消息的傳遞嗎？若是是，那有點麻煩啊，開發人員可能會用很差，也不會想去用。
2. 消息不丟失。用戶發佈的一個寶貝消息不能在實時處理的時候給丟了，對吧？更嚴格一點，若是是一個精確數據統計的應用，那麼它處理的消息要很少很多才行。這個要求有點高哦。

   誕 生

    在2011年Storm開源以前，因爲Hadoop的火紅，整個業界都在喋喋不休地談論大數據。Hadoop的高吞吐，海量數據處理的能力使得人們能夠方便地處理海量數據。可是，Hadoop的缺點也和它的優勢一樣鮮明——延遲大，響應緩慢，運維複雜。

   有需求也就有創造，在Hadoop基本奠基了大數據霸主地位的時候，不少的開源項目都是以彌補Hadoop的實時性爲目標而被創造出來。而在這個節骨眼上Storm橫空出世了。

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

   • 分佈式系統：可橫向拓展,如今的項目不帶個分佈式特性都很差意思開源。
   • 運維簡單：Storm的部署的確簡單。雖然沒有Mongodb的解壓即用那麼簡單，可是它也就是多安裝兩個依賴庫而已。
   • 高度容錯：模塊都是無狀態的，隨時宕機重啓。
   • 無數據丟失：Storm創新性提出的ack消息追蹤框架和複雜的事務性處理,可以知足不少級別的數據處理需求。不過，越高的數據處理需求，性能降低越嚴重。
   • 多語言：實際上，Storm的多語言更像是臨時添加上去似的。由於，你的提交部分仍是要使用Java實現。

   下面，咱們簡單地認識一下Storm這個產品。

   認 識

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

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

   • 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設計的邏輯圖的例子。

   下圖是Topology的提交流程圖。

   下圖是Storm的數據交互圖。能夠看出兩個模塊Nimbus和Supervisor之間沒有直接交互。狀態都是保存在Zookeeper上。Worker之間經過ZeroMQ傳送數據。

   雖然，有些地方作得仍是不太好，例如，底層使用的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的處理圖。

    

   咱們只須要實現每一個分析的過程，而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的過去是成功的，未來會如何發展，咱們拭目以待吧。

   後記

   本文的重點是描述Storm的應用場景和將來的發展前景，讓你們對Storm有一個初步的印象。若是，要落地使用的朋友，在網上能夠找到不少優秀的Storm的技術文章。例如：Storm的核心貢獻者徐明明的博客和淘寶關於storm的文章。