storm,13.storm理論-Storm介紹以...
959
2023-08-07
Storm是個實時的、分布式以及具備高容錯的計算系統
Storm進程常駐內存
Storm數據不經過磁盤,在內存中處理
Storm架構架構Nimbus(老板)
負責資源調度和任務分配,接收jar包
Supervisor(監工)
負責接受nimbus分配的任務,啟動和停止屬于自己管理的worker進程
Worker(工人)
運行具體處理組件邏輯的進程
Task
worker中每一個spout/bolt的線程稱為一個task. 在storm0.8之后,task不再與物理線程對應,同一個spout/bolt的task可能會共享一個物理線程,該線程稱為executor
zookpeer(CEO)
Nimbus做任務的規劃設計,相當于公司老板
zk負責維護集群健康,具體調度Supervisor相關作業
計算模型DAG (Topology)
– 有向無環圖
對于Storm實時計算邏輯的封裝
即,由一系列通過數據流相互關聯的Spout、Bolt所組成的拓撲結構
生命周期:此拓撲只要啟動就會一直在集群中運行,直到手動將其kill,否則不會終止(區別于MapReduce當中的Job,MR當中的Job在計算執行完成就會終止)
Tuple
– 元組
Stream中最小數據組成單元
Stream
– 數據流
從Spout中源源不斷傳遞數據給Bolt、以及上一個Bolt傳遞數據給下一個Bolt,所形成的這些數據通道即叫做Stream
Stream聲明時需給其指定一個Id(默認為Default)
實際開發場景中,多使用單一數據流,此時不需要單獨指定StreamId
Spout
– 數據源
1. 拓撲中數據流的來源。一般會從指定外部的數據源讀取元組(Tuple)發送到拓撲(Topology)中
2. 一個Spout可以發送多個數據流(Stream)
可先通過OutputFieldsDeclarer中的declare方法聲明定義的不同數據流,發送數據時通過SpoutOutputCollector中的emit方法指定數據流Id(streamId)參數將數據發送出去
3. Spout中最核心的方法是nextTuple,該方法會被Storm線程不斷調用、主動從數據源拉取數據,再通過emit方法將數據生成元組(Tuple)發送給之后的Bolt計算
Bolt
– 數據流處理組件
1. 拓撲中數據處理均有Bolt完成。對于簡單的任務或者數據流轉換,單個Bolt可以簡單實現;更加復雜場景往往需要多個Bolt分多個步驟完成
2. 一個Bolt可以發送多個數據流(Stream)
可先通過OutputFieldsDeclarer中的declare方法聲明定義的不同數據流,發送數據時通過SpoutOutputCollector中的emit方法指定數據流Id(streamId)參數將數據發送出去
3. Bolt中最核心的方法是execute方法,該方法負責接收到一個元組(Tuple)數據、真正實現核心的業務邏輯
Stream Grouping
– 數據流分組(即數據分發策略)
數據傳輸ZMQ(twitter早期產品)
ZeroMQ 開源的消息傳遞框架,并不是一個MessageQueue
Netty
Netty是基于NIO的網絡框架,更加高效。(之所以Storm 0.9版本之后使用Netty,是因為ZMQ的license和Storm的license不兼容。)
優勢高可靠性
異常處理
消息可靠性保障機制(ACK)
可維護性
StormUI 圖形化監控接口
應用場景流式處理流式處理(異步 與 同步)
客戶端提交數據進行結算,并不會等待數據計算結果
逐條處理例:ETL(數據清洗)extracted transform load
統計分析例:計算PV、UV、訪問熱點 以及 某些數據的聚合、加和、平均等
客戶端提交數據之后,計算完成結果存儲到Redis、HBase、MySQL或者其他MQ當中,
客戶端并不關心最終結果是多少。
實時請求實時請求應答服務(同步)
客戶端提交數據請求之后,立刻取得計算結果并返回給客戶端
Drpc
實時請求處理
例:圖片特征提取
計算框架對比Strom vs mapreduceStorm:進程、線程常駐內存運行,數據不進入磁盤,數據通過網絡傳遞。
MapReduce:為TB、PB級別數據設計的批處理計算框架。
Strom vs Spark StreamingStorm:純流式處理
專門為流式處理設計
數據傳輸模式更為簡單,很多地方也更為高效
并不是不能做批處理,它也可以來做微批處理,來提高吞吐
Spark Streaming:微批處理
將RDD做的很小來用小的批處理來接近流式處理
基于內存和DAG可以把處理任務做的很快
發表評論
暫時沒有評論,來搶沙發吧~