Zookeeper+Kafka+Storm+HDFS實踐

Kafka是一種高吞吐量的分佈式發佈訂閱消息系統，它能夠處理消費者規模的網站中的全部動做流數據。

Hadoop通常用在離線的分析計算中，而storm區別於hadoop，用在實時的流式計算中，被普遍用來進行實時日誌處理、實時統計、實時風控等場景，固然也能夠用在對數據進行實時初步的加工，存儲到分佈式數據庫中如HBase，便於後續的查詢。
面對的大批量的數據的實時計算，storm實現了一個可擴展的、低延遲、可靠性和容錯的分佈式計算平臺。
一、對象介紹
tuple：表示流中一個基本的處理單元，能夠包括多個field，每一個filed表示一個屬性
topology：一個拓撲是一個個計算節點組成的圖，每一個節點包換處理的邏輯，節點之間的連線表示數據流動的方向
spout：表示一個流的源頭，產生tuple
bolt：處理輸入流併產生多個輸出流，能夠作簡單的數據轉換計算，複雜的流處理通常須要通過多個bolt進行處理
nimnus：主控節點，負責在集羣中發佈代碼，分配工做給機器，而且監聽狀態
supervisor：一個機器，工做節點，會監聽分配給的工做，根據須要啓動和關閉工做進程。
woker：執行topology的工做進程，用於生成task
task：每一個spout和bolt均可以做爲task在storm中運行，一個task對應一個線程
storm拓撲topology的組成見下圖，

總體架構

客戶端提交拓撲到nimbus。

Nimbus針對該拓撲創建本地的目錄根據topology的配置計算task，分配task，在zookeeper上創建assignments節點存儲task和supervisor機器節點中woker的對應關係；

在zookeeper上建立taskbeats節點來監控task的心跳；啓動topology。

Supervisor去zookeeper上獲取分配的tasks，啓動多個woker進行，每一個woker生成task，一個task一個線程；根據topology信息初始化創建task之間的鏈接;Task和Task之間是經過zeroMQ管理的；後整個拓撲運行起來。

上述只是介紹了storn的整個工做流程，固然storm在可靠性、容錯性等方面考慮的比較全面，這後續再補充。

 

Storm的配置文件通常存放在$STORM_HOME/conf下，一般名爲storm.yaml，它符合yaml格式要求。

配置項詳解:

如下是從storm的config類中搜集的全部storm支持的配置項(Based storm 0.6.0):

配置項	配置說明
storm.zookeeper.servers	ZooKeeper服務器列表
storm.zookeeper.port	ZooKeeper鏈接端口
storm.local.dir	storm使用的本地文件系統目錄(必須存在而且storm進程可讀寫)
storm.cluster.mode	Storm集羣運行模式([distributed|local])
storm.local.mode.zmq	Local模式下是否使用ZeroMQ做消息系統，若是設置爲false則使用java消息系統。默認爲false
storm.zookeeper.root	ZooKeeper中Storm的根目錄位置
storm.zookeeper.session.timeout	客戶端鏈接ZooKeeper超時時間
storm.id	運行中拓撲的id,由storm name和一個惟一隨機數組成。
nimbus.host	nimbus服務器地址
nimbus.thrift.port	nimbus的thrift監聽端口
nimbus.childopts	經過storm-deploy項目部署時指定給nimbus進程的jvm選項
nimbus.task.timeout.secs	心跳超時時間，超時後nimbus會認爲task死掉並重分配給另外一個地址。
nimbus.monitor.freq.secs	nimbus檢查心跳和重分配任務的時間間隔.注意若是是機器宕掉nimbus會當即接管並處理。
nimbus.supervisor.timeout.secs	supervisor的心跳超時時間,一旦超過nimbus會認爲該supervisor已死並中止爲它分發新任務.
nimbus.task.launch.secs	task啓動時的一個特殊超時設置.在啓動後第一次心跳前會使用該值來臨時替代nimbus.task.timeout.secs.
nimbus.reassign	當發現task失敗時nimbus是否從新分配執行。默認爲真，不建議修改。
nimbus.file.copy.expiration.secs	nimbus判斷上傳/下載連接的超時時間，當空閒時間超過該設定時nimbus會認爲連接死掉並主動斷開
ui.port	Storm UI的服務端口
drpc.servers	DRPC服務器列表，以便DRPCSpout知道和誰通信
drpc.port	Storm DRPC的服務端口
supervisor.slots.ports	supervisor上可以運行workers的端口列表.每一個worker佔用一個端口,且每一個端口只運行一個worker.經過這項配置能夠調整每臺機器上運行的worker數.(調整slot數/每機)
supervisor.childopts	在storm-deploy項目中使用,用來配置supervisor守護進程的jvm選項
supervisor.worker.timeout.secs	supervisor中的worker心跳超時時間,一旦超時supervisor會嘗試重啓worker進程.
supervisor.worker.start.timeout.secs	supervisor初始啓動時，worker的心跳超時時間，當超過該時間supervisor會嘗試重啓worker。由於JVM初始啓動和配置會帶來的額外消耗，從而使得第一次心跳會超過supervisor.worker.timeout.secs的設定
supervisor.enable	supervisor是否應當運行分配給他的workers.默認爲true,該選項用來進行Storm的單元測試,通常不該修改.
supervisor.heartbeat.frequency.secs	supervisor心跳發送頻率(多久發送一次)
supervisor.monitor.frequency.secs	supervisor檢查worker心跳的頻率
worker.childopts	supervisor啓動worker時使用的jvm選項.全部的」%ID%」字串會被替換爲對應worker的標識符
worker.heartbeat.frequency.secs	worker的心跳發送時間間隔
task.heartbeat.frequency.secs	task彙報狀態心跳時間間隔
task.refresh.poll.secs	task與其餘tasks之間連接同步的頻率.(若是task被重分配,其餘tasks向它發送消息須要刷新鏈接).通常來說，重分配發生時其餘tasks會理解獲得通知。該配置僅僅爲了防止未通知的狀況。
topology.debug	若是設置成true，Storm將記錄發射的每條信息。
topology.optimize	master是否在合適時機經過在單個線程內運行多個task以達到優化topologies的目的.
topology.workers	執行該topology集羣中應當啓動的進程數量.每一個進程內部將以線程方式執行必定數目的tasks.topology的組件結合該參數和並行度提示來優化性能
topology.ackers	topology中啓動的acker任務數.Acker保存由spout發送的tuples的記錄，並探測tuple什麼時候被徹底處理.當Acker探測到tuple被處理完畢時會向spout發送確認信息.一般應當根據topology的吞吐量來肯定acker的數目，但通常不須要太多.當設置爲0時,至關於禁用了消息可靠性,storm會在spout發送tuples後當即進行確認.
topology.message.timeout.secs	topology中spout發送消息的最大處理超時時間.若是一條消息在該時間窗口內未被成功ack,Storm會告知spout這條消息失敗。而部分spout實現了失敗消息重播功能。
topology.kryo.register	註冊到Kryo(Storm底層的序列化框架)的序列化方案列表.序列化方案能夠是一個類名,或者是com.esotericsoftware.kryo.Serializer的實現.
topology.skip.missing.kryo.registrations	Storm是否應該跳過它不能識別的kryo序列化方案.若是設置爲否task可能會裝載失敗或者在運行時拋出錯誤.
topology.max.task.parallelism	在一個topology中可以容許的最大組件並行度.該項配置主要用在本地模式中測試線程數限制.
topology.max.spout.pending	一個spout task中處於pending狀態的最大的tuples數量.該配置應用於單個task,而不是整個spouts或topology.
topology.state.synchronization.timeout.secs	組件同步狀態源的最大超時時間(保留選項,暫未使用)
topology.stats.sample.rate	用來產生task統計信息的tuples抽樣百分比
topology.fall.back.on.java.serialization	topology中是否使用java的序列化方案
zmq.threads	每一個worker進程內zeromq通信用到的線程數
zmq.linger.millis	當鏈接關閉時,連接嘗試從新發送消息到目標主機的持續時長.這是一個不經常使用的高級選項,基本上能夠忽略.
java.library.path	JVM啓動(如Nimbus,Supervisor和workers)時的java.library.path設置.該選項告訴JVM在哪些路徑下定位本地庫.

提交topology成功後，發現運行不正常

1. 驗證topology提交成功：打開nimbus ui，看看提交的topology是否存在
2. 檢查本身的topology，在ui中點擊本身的topology後查看spout是否有emit計數，若是有，那麼storm集羣ok，若是不正常，那是程序的問題
3. 在ui中看看是否有可用的supervisor
4. 在ui中看是否有free slot
5. 在ui中檢查本身的topology，看看是否顯示了spout和bolt運行在哪兒，若是沒有說明根本沒起來，若是重啓集羣后，依然沒法起來，那麼是你的程序問題

程序問題排查

1. submit日誌在nimbus.log
2. 生成work命令行的日誌輸出在supervisor.log
3. 程序運行時的日誌在work-xxx.log

參考 ：

　　zookeeper集羣搭建

     Kafka+Storm+HDFS整合實踐

　　Storm 入門簡介

      Storm Kafka