淺談Storm流式處理框架

五柳-先生發表於2016-03-22
ORM框架

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

topology01

     下圖是Topology的提交流程圖。

topology02

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

topology03

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

二.Storm發展

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

  • 有50個大大小小的公司在使用Storm，相信更多的不留名的公司也在使用。這些公司中不乏淘寶，百度，Twitter，Groupon，雅虎等重量級公司。
  • 從開源時候的0.5.0版本，到現在的0.10.0，和即將到來的0.10.0+。先後新增了以下重大的新特性：
    • 使用kryo作為Tuple序列化的框架（0.6.0）
    • 新增了Transactional topologies（事務性拓撲）的支援（0.7.0）
    • 新增了Trident的支援（0.8.0）
    • 引入netty作為底層訊息機制（0.9.0）

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

  • 在GitHub上超過6000個專案負責人。Storm整合了許多庫，支援包括Kestrel、Kafka、JMS、Cassandra、Memcached以及更多系統。隨著支援的庫越來越多，Storm更容易與現有的系統協作。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的未來

      在流式處理領域裡，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給你帶來的簡單，可擴充等優勢了

轉載：http://blog.csdn.net/fanyun_01/article/details/50921678

相關文章