前面介紹了流計算,在流計算領域,一個熱門的計算框架就是-Storm。仍是先介紹概念。。。html
在流處理過程當中,咱們除了考慮最重要的數據處理的邏輯,還須要維護消息隊列和消費者,考慮消息怎麼流、怎麼序列化等。而Storm就是這樣一個流式計算框架,它爲你完成了消息傳遞等這些通用模塊,讓你專一於實時處理的業務邏輯。web
Storm--一種分佈式實時計算系統。Storm之於流計算,相似於Hadoop之於批處理。Storm能夠簡單、高效、可靠的處理流數據,它提供了簡單的編程原語,而且支持多種語言,開發人員只須要關注業務邏輯。能夠應用到不少領域,例如實時分析、在線機器學習、分佈式RPC、ETL等。編程
下面進一步瞭解下Stormvim
在Storm裏面包含幾個組件:Streams, Sputs ,Bolts, Topology,Stream Groupings。數組
一、Streams(流)瀏覽器
Streams是Storm對數據的抽象。Storm處理的數據對象是「流數據」,流數據是一個無限的Tuple序列,這些Tuple序列會以分佈式的方式並行建立和處理。tomcat
熟悉Python的同窗可能對Tuple(元組)更容易理解一些,它就是一個元素的有序序列,每個Tuple就是一個值列表,列表裏的值的類型沒有嚴格的規定,能夠是基本類型、字符類型、字節數組也能夠是其餘可序列化的類型。網絡
二、Spouts(噴口)架構
Spouts是Storm對數據源頭的抽象。Spouts是stream的源頭,從外部讀取流數據並持續發出Tuple。併發
三、Bolts(螺栓)
Bolts是Storm對stream的狀態轉換過程的抽象。Bolts既能夠處理tuple,也能夠把處理之後的tuple做爲新的streams發送給其餘的bolts。對tuple的處理邏輯都被封裝在bolts中,在bolts中能夠對數據執行過濾、聚合、查詢等操做。
四、Topology(拓撲)
Topology是Storm對Spouts和Bolts組成的網絡的抽象。Topology是Storm中最高層次的抽象概念,能夠被提交到Storm集羣執行。一個Topology就是一個流轉換圖,圖中的節點是Spouts或Bolts,圖中的邊表示Bolts訂閱了哪一個Stream。當Spout或bolt發送元組的時候,會把元組發送到每一個訂閱了該stream的bolt上進行處理。
topology支持經過各類編程語言來建立、提交topology。
五、Stream Groupings
Stream Groupings是Strom對組件之間tuple傳送方式的抽象,用於告知topology如何在兩個組件之間進行tuple的傳送(組件之間能夠是spout和bolt之間或者不一樣bolt之間)。stream groupings決定了一個任務在何時、以什麼形式發送tuple。
Storm中的stream gouping有如下6種方式。
shuffleGrouping:隨機分組,把stream中的tuple隨機分發給各個bolts的task
fieldsGrouping:按字段分組,相同字段的tuple分配到同一個task中
all Grouping:廣播發送,每一個task收到全部的tuple
globalGrouping:全局分組,全部的tuple都發送到同一個task中
nonGrouping:不分組,和shuffleGrouping相似,當前task的執行和它的被訂閱者在同一個線程中執行
directGrouping:直接分組,直接指定某個task來執行tuple的處理。
對於Strom框架的理解,類比着hdp可能會更容易理解些。
Strom運行在分佈式集羣中,咱們能夠類比下hadoop,hdp上運行的是MR做業,Storm上運行的是Topology。不過MR是有限的,會結束,可是topology會對數據進行持續處理,直到人爲終止。
從集羣物理結構來看,一個Storm集羣包含Master節點和Worker節點。
Master節點
--Master節點上運行Nimbus後臺程序,相似MR中的JobTracker。負責集羣內代碼的分發、worker任務的分配和故障監測。
Worker節點
--Worker運行Supervisor後臺程序,負責監聽分配給當前機器的工做,根據Nimbus分配的任務來啓動或中止worker進程。每一個supervisor有n個worker進程,負責代理task給worker進程,worker再孵化執行線程最終運行task。
worker負責執行特定的task,worker自己不執行任務,而是孵化executors,讓executors執行task;executor本質上是worker進程孵化出來的線程,executor運行task都屬於同一spout或bolt。task是實際執行的任務處理,或者是Spout或者是Bolt。
節點間通訊
--storm使用內部消息系統在nimbus和supervisor之間進行通訊。
master和worker之間不會直接交互,爲了實現master和worker之間的協同,採用zookeeper做爲協調組件。zk中存儲master和worker的狀態信息,以便節點故障時根據zk中狀態信息進行快速恢復,保證storm的穩定性。
接下來從架構組件的角度總結下Strom架構:
Nimbus--Storm的核心組件,分析top並收集運行task,分發task給supervisor;監控top;無狀態,依靠zk監控top的運行情況
Supervisor--每一個supervisor有n個worker進程,負責代理task給worker;worker再孵化執行線程,最終運行task
Worker--執行特定的task,worker自己不執行任務,而是孵化executors,讓executors執行task。
Executor--本質上是由worker進程孵化出來的線程;executor運行task都屬於同一個spout或bolt。
Task--執行實際上的任務處理,或者spout或bolt
在這樣的架構下,storm的工做流程以下圖
一、client把topology提交到storm集羣
二、提交topo後nimbus收集task
三、Nimbus分發task,把分配給Supervisor的task寫入zk
四、Supervisor週期性發送心跳錶示本身還活着,若是Supervisor掛掉,nimbus將task分發給其餘supervisor
五、Supervisor從zk中獲取所分配的任務,啓動worker進程,woker進程執行任務。
六、task完成後,supervisor等待新的task
七、若是nimbus掛掉,supervisor繼續執行本身的task,task完成後,supervisor繼續等待新的task
Storm保證了拓撲中Spout產生的每一個元組都會被處理。Storm是經過跟蹤每一個Spout所產生的全部元組構成的樹形結構並得知這棵樹什麼時候被完整地處理來達到可靠性。每一個拓撲對這些樹形結構都有一個關聯的「消息超時」。若是在這個超時時間裏Storm檢測到Spout產生的一個元組沒有被成功處理完,那Sput的這個元組就處理失敗了,後續會從新處理一遍。
爲了發揮Storm的可靠性,須要你在建立一個元組樹中的一條邊時告訴Storm,也須要在處理完每一個元組以後告訴Storm。這些都是經過Bolt吐元組數據用的OutputCollector
對象來完成的。標記是在emit
函數裏完成,完成一個元組後須要使用ack
函數來告訴Storm。
這些都在「保證消息處理」一文中會有更詳細的介紹。
拓撲以一個或多個Worker進程的方式運行。每一個Worker進程是一個物理的Java虛擬機,執行拓撲的一部分任務。例如,若是拓撲的併發設置成了300,分配了50個Worker,那麼每一個Worker執行6個任務(做爲Worker內部的線程)。Storm會盡可能把全部的任務均分到全部的Worker上。
一、到storm官網下載安裝包,並解壓
二、爲storm配置環境變量 vim /etc/profile
export STORM_HOME=/usr/local/storm
export PATH=$PATH:${STORM_HOME}/bin
使配置生效 source /etc/profile
三、配置storm
進入storm安裝目錄下conf文件夾,修改配置文件 vim storm.yaml
配置項如:
#zookeeper集羣,注意空格,必須使用space,不可以使用製表符 # - 與 " 之間留有空格 storm.zookeeper.servers: - "192.168.119.141" - "192.168.119.142" - "192.168.119.143" #nimbus設置兩臺機器,最好使用主機名,使用IP在webui界面會出現重複節點 nimbus.seeds: ["hadoop-01","hadoop-02"] #設置slots端口 supervisor.slots.sport: - 6700 - 6701 - 6702 - 6703 #設置UI的端口,默認8080,避免與tomcat端口重複 ui.port: 8082
四、將storm拷貝到集羣內其餘節點上
五、啓動storm
nimubs節點上,
storm nimbus >/dev/null 2>&1 & storm ui >/dev/null 2>&1 &
supervisor節點上,
storm supervisor >/dev/null 2>&1 &
執行jps 命令
在沒有運行任務時,咱們必須應該要看到4個進程:
QuorumPeerMain、nimbus、core、supervisor
這樣以後就能夠在瀏覽器內經過訪問 nimbus_IP/8020 查看集羣狀況
6. 啓動logviewer(可選)
在全部從節點執行"nohup bin/storm logviewer >/dev/null 2>&1 &"啓動log後臺程序,並放到後臺執行。
(nimbus節點能夠不用啓動logviewer進程,由於logviewer進程主要是爲了方便查看任務的執行日誌,這些執行日誌都在supervisor節點上)。
參考: https://blog.51cto.com/xpleaf/2097682
https://blog.csdn.net/weixin_41715878/article/details/87912103