大白話strom——問題收集（持續更新ing）

本文導讀： 一、基於storm的應用 二、storm的單點故障解決 三、strom與算法的結合學習
四、雜記——常見問題的解答
五、http://www.blogchong.com/catalog.asp?tags=問題整理(storm)

---

 Storm存在的一些問題：（V 0.7.4以前）

一、編程門檻對普通用戶較高 二、框架無持久化存儲 三、框架不提供消息接入模塊 —— kafka 四、storm ui 功能簡單 五、跨topology的boit複用 六、nimbus單點故障
七、topology不支持動態部署

---

 storm業務需求：

1、條件過濾
    這是storm最基本的處理方式，對符合條件的數據進行實時過濾，將符合條件的數據保存下來，這種實時查詢的業務需求在實際應用中很常見。
2、中間件計算
    咱們須要改變數據中某一個字段（例如是數值），咱們須要利用一箇中間值通過計算（值比較、求和、求平均等）後改變該值，而後將數據從新輸出。
3、求TopN
    相信你們對TopN類的業務需求也是比較熟悉的，在規定的時間窗口內，統計數據出現的TopN，該類處理在購物及電商業務需求中，比較常見。
4、分佈式RPC
    storm有對RPC進行專門的設計，分佈式RPC用於對storm上大量的函數調用進行並行計算，最後將結果返回給客戶端。
5、推薦系統
    在實時處理時從mysql及hadoop中獲取數據庫中的信息，例如在電影推薦系統中，傳入數據爲用戶當前點播電影信息，從後數據庫中獲取的是該用戶以前的一些點播電影信息統計。
6、批處理
    所謂批處理就是數據積攢到必定觸發條件 ，就批量輸出，所謂的觸發條件相似事件窗口到了，統計數量夠了及檢測到某種數據傳入等等。
7、熱度統計
    熱度統計實現依賴於TimeCacheMap數據結構，該結構可以在內存中保持近期活躍的對象。咱們可使用它來實現例如論壇中的熱帖排行統計等。

---

一、基於storm的應用系統：

（1）基於storm的網絡爬蟲系統的設計與實現：

大致框架：

　　衆所周知，爬蟲系統裏幾個必不可少的模塊，像下載、解析、回寫待爬資源、存儲等，本質上他們像是一個責任鏈，但後一個module又基於前一個module，因此能夠理解爲一種流處理模型，從咱們拿到待爬URL一直處處理完畢存儲數據，這是一個完整的過程。如您看到的這張圖，若是咱們實現了storm化，那麼基於storm強大的功能，咱們的爬蟲能夠完美運行在storm集羣上，而且每類處理器咱們均可以很是靈活的分配其線程數，耗時的處理咱們多開幾個線程，能夠實現資源合理利用，固然既然是集羣，你的某個任務具體運行在哪裏，storm已經幫您分配好了，而且幫咱們實現了節點失效等處理。

　　最後若是bolt間傳輸的消息量比較大，有可能網絡是個瓶頸。

 

其餘應用：——基於storm的實時交通情況的設計與分析

1. 基於Storm實時路況分析和實時路徑推薦系統
2. 用storm來監測車輛速度是否超過80 km/h
3. 公共交通出行服務大數據平臺設計方案
4. 基於Storm雲平臺的地圖道路匹配算法研究

............ 

 

 

---

二、storm單點故障問題：

（1）採用master組解決單點故障

思路：

zookeeper解決方案仍是至關複雜的，最近想到使用master組來解決這一問題，一個系統只有一個master組，它由若干個節點組成，好處：
一、結構簡單，容易理解和實現
二、master組中的一個節點無論理集羣內全部元數據，而只分擔其中一部分，這樣系統的擴展能力更強，不會受限於元數據
三、master組中的節點互備，能夠解決單點故障問題
四、爲性能而優化，專一於解決小文件性能問題，目標是達到實時檢索

討論：P2P解決方案

問：master組的實現，hadoop的熱備份等都比較困難？

答：master數據備份能夠直接採用多寫方式，只有一個異常的master恢復時，才須要同步。

問：zookeeper是僅僅適用於hbase這種master slave模式仍是也適應於multi master？

答：ZooKeeper使用沒有限制的，好比它的分佈式鎖能力和配置能力，有普遍的應用。關於Master組騰訊的XFS就採用了，不過仍然有個單點的頂層Master，採用了ZooKeeper作主備切換。頂層的單點Master，一般有兩個備，在數據未同步時，叫Newbie（學習者），只有數據一致後才叫Standby，數據的一致是經過兩階段來保證的。

 

----討論-----後續見：storm源碼之一個class解決nimbus單點問題【轉】

--單點問題能夠參考hdfs的實現~

--hdfs的namenode也是單節點，secondnode也只是爲合併操做日誌以縮短namenode的啓動時間而設。目前hadoop的namenode單點問題也是下一代hadoop要解決的重要問題。

--那是2.0以前的版本，如今兩個namenode之間採用nfs共享元數據，經過zookeeper選舉一個做爲當前active，另外一個做爲standby，當active掛了以後，可以在短期內切換到standby節點，實現高可用~

--nimbus節點利用nfs共享存儲也是一種解決方案。能夠經過將Froastman實現的storage.clj做以下修改：

(^boolean isSupportDistributed [this]
true))))

　　Nathanmarz所以在0.8.2版本的基礎上，新開了storm-0.8.2-ha分支，專門用來解決nimbus單點問題，並將Frostman已完成的nimbus-storage代碼合併到該分支。

　　Rostman在nimbus-storage基礎上繼續增長了nimbus多節點選舉機制，(目前還沒有被Nathanmarz合併入storm-ha分支)。

　　nimbus單點問題的解決思路

　　一、Frostman的工做已爲完全解決nimbus單點問題奠基了重要基礎：

• • nimbus ip地址動態獲取
  • topology代碼存儲方案可定製
  • nimbus多節點選舉，宕機自動切換
  • nimbus leader狀態ui展現

　　在Frostman工做的基礎上繼續深刻，將極大減小工做量。
　　二、Frostman並未解決topology代碼如何在多個nimbus節點或集羣全部節點間共享的問題。Nathamarz的理想規劃是：實現storm集羣中全部nimbus、supervisor機器之間經過P2P協議共享topology代碼，但目前限於BitTorrent未完成的工做，目前暫停了nimbus-ha分支的開發。
　　三、最終選定的解決方案：實現定製的nimbus-storage插件NimbusCloudStorage，使得全部nimbus節點在啓動後均從leader 輪詢下載本地不存在的topology代碼。依次知足supervisor在nimbus節點切換後下載代碼的需求。

 

 

---

三、Storm與算法的結合： 

 　　...........

　　基於storm的聚類算法的分析與實現，基於storm的關聯規則的分析與實現，storm平臺一致性哈希算法的分析與研究等等...

 

 

---

四、雜記：

　　　　——storm常見問題解答

轉載於http://blog.csdn.net/hguisu/article/details/8454368#t3 （20121231）

1、我有一個數據文件，或者我有一個系統裏面有數據，怎麼導入storm作計算？

　　你須要實現一個Spout，Spout負責將數據emit到storm系統裏，交給bolts計算。怎麼實現spout能夠參考官方的kestrel spout實現：
https://github.com/nathanmarz/storm-kestrel

　　若是你的數據源不支持事務性消費，那麼就沒法獲得storm提供的可靠處理的保證，也不必實現ISpout接口中的ack和fail方法。

2、Storm爲了保證tuple的可靠處理，須要保存tuple信息，這會不會致使內存OOM？

　　Storm爲了保證tuple的可靠處理，acker會保存該節點建立的tuple id的xor值，這稱爲ack value，那麼每ack一次，就將tuple id和ack value作異或(xor)。當全部產生的tuple都被ack的時候， ack value必定爲0。這是個很簡單的策略，對於每個tuple也只要佔用約20個字節的內存。對於100萬tuple，也才20M左右。關於可靠處理看這個：
https://github.com/nathanmarz/storm/wiki/Guaranteeing-message-processing

3、Storm計算後的結果保存在哪裏？能夠保存在外部存儲嗎？

　　Storm不處理計算結果的保存，這是應用代碼須要負責的事情，若是數據不大，你能夠簡單地保存在內存裏，也能夠每次都更新數據庫，也能夠採用NoSQL存儲。storm並無像s4那樣提供一個Persist API，根據時間或者容量來作存儲輸出。這部分事情徹底交給用戶。

　　數據存儲以後的展示，也是你須要本身處理的，storm UI只提供對topology的監控和統計。

4、Storm怎麼處理重複的tuple？

　　由於Storm要保證tuple的可靠處理，當tuple處理失敗或者超時的時候，spout會fail並從新發送該tuple，那麼就會有tuple重複計算的問題。這個問題是很難解決的，storm也沒有提供機制幫助你解決。一些可行的策略：
　　（1）不處理，這也算是種策略。由於實時計算一般並不要求很高的精確度，後續的批處理計算會更正實時計算的偏差。
　　（2）使用第三方集中存儲來過濾，好比利用mysql,memcached或者redis根據邏輯主鍵來去重。
　　（3）使用bloom filter作過濾，簡單高效。

5、Storm的動態增刪節點

　　我在storm和s4裏比較裏談到的動態增刪節點，是指storm能夠動態地添加和減小supervisor節點。對於減小節點來講，被移除的supervisor上的worker會被nimbus從新負載均衡到其餘supervisor節點上。在storm 0.6.1之前的版本，增長supervisor節點不會影響現有的topology，也就是現有的topology不會從新負載均衡到新的節點上，在擴展集羣的時候很不方便，須要從新提交topology。所以我在storm的郵件列表裏提了這個問題，storm的開發者nathanmarz建立了一個issue 54並在0.6.1提供了rebalance命令來讓正在運行的topology從新負載均衡，具體見：
https://github.com/nathanmarz/storm/issues/54
　　和0.6.1的變動：
http://groups.google.com/group/storm-user/browse_thread/thread/24a8fce0b2e53246

　　storm並不提供機制來動態調整worker和task數目。

6、Storm UI裏spout統計的complete latency的具體含義是什麼？爲何emit的數目會是acked的兩倍？

　　這個事實上是storm郵件列表裏的一個問題。Storm做者marz的解答：

　　The complete latency is the time from the spout emitting a tuple to that
tuple being acked on the spout. So it tracks the time for the whole tuple
tree to be processed.

　　If you dive into the spout component in the UI, you'll see that a lot of
the emitted/transferred is on the __ack* stream. This is the spout
communicating with the ackers which take care of tracking the tuple trees. 

　　簡單地說，complete latency表示了tuple從emit到被acked通過的時間，能夠認爲是tuple以及該tuple的後續子孫（造成一棵樹）整個處理時間。其次spout的emit和transfered還統計了spout和acker之間內部的通訊信息，好比對於可靠處理的spout來講，會在emit的時候同時發送一個_ack_init給acker，記錄tuple id到task id的映射，以便ack的時候能找到正確的acker task。

 

7、strom不能實現不一樣topology之間stream的共享

　　Storm中Stream的概念是Topology內惟一的，只能在Topology內按照「發佈-訂閱」方式在不一樣的計算組件（Spout和Bolt）之間進行數據的流動，而Stream在Topology之間是沒法流動的。

　　對於不一樣topology前半部分共用Spouts和Bolts不能直接複用，解放方案有如下三種：

　　（1）kill原topology，共用前半部分的Spouts和Bolts，在分支Bolt處分別處理，從新打包造成新的topology並提交；

　　（2）從相同的外部數據源單獨讀取數據，設計與前一個topology相同的新topology處理後面的新任務；

　　（3）經過Kafka消息中間件實現不一樣topology的Spout共享數據源，從新部署運行新的topology便可。

參考連接：Storm數據流模型的分析及討論

 

 

---

 參考連接：

大白話storm——幾點問題