探尋流式計算
一、靜態資料和流資料
靜態資料:為了支援決策分析而構建的資料倉儲系統,其中存放的大量歷史資料就是靜態資料。
流資料:以大量、快速、時變的流形式持續到達的資料。(例如:實時產生的日誌、使用者實時交易資訊)
流資料具有以下特點:
(1)、資料快速持續到達,潛在大小也許是無窮無盡的。 (2)、資料來源眾多,格式複雜。 (3)、資料量大,但是不十分關注儲存,一旦經過處理,要麼被丟棄,要麼被歸檔儲存(儲存於資料倉儲)。 (4)、注重資料的整體價值,不過分關注個別資料。 (5)、資料順序顛倒,或者不完整,系統無法控制將要處理的新到達的資料元素的順序。
在傳統的資料處理流程中,總是先收集資料,然後將資料放到DB中。然後對DB中的資料進行處理。
流計算:為了實現資料的時效性,實時消費獲取的資料。
二、批量計算和流計算
批量計算:充裕時間處理靜態資料,如Hadoop。實時性要求不高。
流計算:實時獲取來自不同資料來源的海量資料,經過實時分析處理,獲得有價值的資訊(實時、多資料結構、海量)。
流計算秉承一個基本理念,即資料的價值隨著時間的流逝而降低,如使用者點選流。因此,當事件出現時就應該立即進行處理,而不是快取起來進行批量處理。流資料資料格式複雜、來源眾多、資料量巨大,不適合採用批量計算,必須採用實時計算,響應時間為秒級,實時性要求高。批量計算關注吞吐量,流計算關注實時性。
流計算的特點:
1、實時(realtime)且無界(unbounded)的資料流。流計算面對計算的 是實時且流式的,流資料是按照時間發生順序地被流計算訂閱和消費。且由於資料發生的持續性,資料流將長久且持續地整合進入流計算系統。例如,對於網站的訪問點選日誌流,只要網站不關閉其點選日誌流將一直不停產生並進入流計算系統。因此,對於流系統而言,資料是實時且不終止(無界)的。
2、持續(continuos)且高效的計算。流計算是一種”事件觸發”的計算模式,觸發源就是上述的無界流式資料。一旦有新的流資料進入流計算,流計算立刻發起並進行一次計算任務,因此整個流計算是持續進行的計算。
3、流式(streaming)且實時的資料整合。流資料觸發一次流計算的計算結果,可以被直接寫入目的資料儲存,例如將計算後的報表資料直接寫入RDS進行報表展示。因此流資料的計算結果可以類似流式資料一樣持續寫入目的資料儲存。
三、流計算框架
為了及時處理流資料,就需要一個低延遲、可擴充套件、高可靠的處理引擎。對於一個流計算系統來說,它應達到如下需求:
-
高效能:處理大資料的基本要求,如每秒處理幾十萬條資料。
-
海量式:支援TB級甚至是PB級的資料規模。
-
實時性:保證較低的延遲時間,達到秒級別,甚至是毫秒級別。
-
分散式:支援大資料的基本架構,必須能夠平滑擴充套件。
-
易用性:能夠快速進行開發和部署。
-
可靠性:能可靠地處理流資料。
目前有三類常見的流計算框架和平臺:商業級的流計算平臺、開源流計算框架、公司為支援自身業務開發的流計算框架。
(1)商業級: InfoSphere Streams(IBM)和StreamBase(IBM)。
(2)開源流計算框架,代表如下:Storm(Twitter)、 S4(Yahoo)。
(3)公司為支援自身業務開發的流計算框架:Puma(Facebook)、Dstream(百度)、銀河流資料處理平臺(淘寶)。
四、流計算框架Storm
Storm是Twitter開源的分散式實時大資料處理框架,隨著流計算的應用日趨廣泛, Storm的知名度和作用日益提高。接下來介紹Storm的核心元件以及效能對比。
Storm的核心元件
-
Nimbus:即Storm的Master,負責資源分配和任務排程。一個Storm叢集只有一個Nimbus。
-
Supervisor:即Storm的Slave,負責接收Nimbus分配的任務,管理所有Worker,一個Supervisor節點中包含多個Worker程式。
-
Worker:工作程式,每個工作程式中都有多個Task。
-
Task:任務,在 Storm 叢集中每個 Spout 和 Bolt 都由若干個任務(tasks)來執行。每個任務都與一個執行執行緒相對應。
-
Topology:計算拓撲,Storm 的拓撲是對實時計算應用邏輯的封裝,它的作用與 MapReduce 的任務(Job)很相似,區別在於 MapReduce 的一個 Job 在得到結果之後總會結束,而拓撲會一直在叢集中執行,直到你手動去終止它。拓撲還可以理解成由一系列通過資料流(Stream Grouping)相互關聯的 Spout 和 Bolt 組成的的拓撲結構。
-
Stream:資料流(Streams)是 Storm 中最核心的抽象概念。一個資料流指的是在分散式環境中並行建立、處理的一組元組(tuple)的無界序列。資料流可以由一種能夠表述資料流中元組的域(fields)的模式來定義。
-
Spout:資料來源(Spout)是拓撲中資料流的來源。一般 Spout 會從一個外部的資料來源讀取元組然後將他們傳送到拓撲中。根據需求的不同,Spout 既可以定義為可靠的資料來源,也可以定義為不可靠的資料來源。一個可靠的 Spout能夠在它傳送的元組處理失敗時重新傳送該元組,以確保所有的元組都能得到正確的處理;相對應的,不可靠的 Spout 就不會在元組傳送之後對元組進行任何其他的處理。一個 Spout可以傳送多個資料流。
-
Bolt:拓撲中所有的資料處理均是由 Bolt 完成的。通過資料過濾(filtering)、函式處理(functions)、聚合(aggregations)、聯結(joins)、資料庫互動等功能,Bolt 幾乎能夠完成任何一種資料處理需求。一個 Bolt 可以實現簡單的資料流轉換,而更復雜的資料流變換通常需要使用多個 Bolt 並通過多個步驟完成。
-
Stream grouping:為拓撲中的每個 Bolt 的確定輸入資料流是定義一個拓撲的重要環節。資料流分組定義了在 Bolt 的不同任務(tasks)中劃分資料流的方式。在 Storm 中有八種內建的資料流分組方式。
-
Reliability:可靠性。Storm 可以通過拓撲來確保每個傳送的元組都能得到正確處理。通過跟蹤由 Spout 發出的每個元組構成的元組樹可以確定元組是否已經完成處理。每個拓撲都有一個“訊息延時”引數,如果 Storm 在延時時間內沒有檢測到元組是否處理完成,就會將該元組標記為處理失敗,並會在稍後重新傳送該元組。
(圖1:Storm核心元件)
(圖2:Storm程式設計模型)
主流計算引擎的對比
目前比較流行的實時處理引擎有 Storm,Spark Streaming,Flink。每個引擎都有各自的特點和應用場景。 下表是對這三個引擎的簡單對比。
(圖3:主流引擎效能對比)
總結:流計算的出現拓寬了我們應對複雜實時計算需求能力。Storm作為流計算的利器,極大方便了我們的應用。流計算引擎還在不斷髮展,基於Storm和Flink開發的JStorm,Blink等計算引擎在效能各方面都有極大的提高。流計算值得我們繼續關注。
參考資料:
【1】http://storm.apache.org/releases/current/Concepts.html
【2】https://en.wikipedia.org/wiki/Storm (eventprocessor)
【3】https://toutiao.io/posts/88a6nt
【4】https://blog.csdn.net/fjse51/article/details/53886516
【5】https://www.cnblogs.com/xuwujing/p/8584684.html
【6】https://www.douban.com/note/642346037/
【7】https://www.cnblogs.com/ostin/articles/7256003.html
【8】https://tech.meituan.com/real timedatameasure.html
【9】http://www.cnblogs.com/jiyukai/p/9471944.html
作者:姚遠
來源:宜信技術學院
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69918724/viewspace-2657691/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 說說實時流式計算
- Java如何使用實時流式計算處理?Java
- 亞信安慧AntDB資料庫與流式計算資料庫
- 試圖探尋JavaScript的非同步設計JavaScript非同步
- 使用流式計算引擎 eKuiper 處理 Protocol Buffers 資料UIProtocol
- Golang框架實戰-KisFlow流式計算框架(4)-資料流Golang框架
- TDengine3.0 流式計算引擎語法規則介紹
- 探尋 webpack 外掛機制Web
- 簡單探討Golang中defer預計算引數Golang
- 圖片跨域規律探尋跨域
- [AI]探尋高等生命的多面驅動AI
- .NETCore微服務探尋(一) - 閘道器NetCore微服務
- 探尋多機任務分配機制
- 淺談探尋企業數字化
- 探尋 JavaScript 精度問題以及解決方案JavaScript
- macOS 探尋檔案擴充套件屬性Mac套件
- ReactiveX流式程式設計—從xstream講起React程式設計
- 萬字詳解 | Java 流式程式設計Java程式設計
- 搜尋線上服務的儲存計算分離
- 飛算雲PCDN邊緣計算機頂盒尋求代理加盟合作伙伴計算機
- 探尋京東雲核心競爭力的源泉
- iOS底層原理總結 - 探尋KVO本質iOS
- 流式介面
- 風格化與一體感——探尋《只狼》的戰鬥系統設計思路
- Java8 新特性 —— Stream 流式程式設計Java程式設計
- Flutter文字標籤TextTagWidget,搜尋記錄流式佈局顯示文字標籤Flutter
- “淘寶京東”構建流式計算賣家日誌系統架構的應用實踐架構
- 百度愛番番基於圖技術、流式計算的實時CDP建設實踐
- iOS底層原理總結 – 探尋Runtime本質(三)iOS
- iOS底層原理總結 - 探尋Runtime本質(四)iOS
- iOS底層原理總結 - 探尋Runtime本質(二)iOS
- iOS底層原理總結 - 探尋Runtime本質(一)iOS
- iOS底層原理總結 - 探尋Runtime本質(三)iOS
- 運用第一性原理探尋AI本質AI
- iOS底層原理總結 – 探尋Runtime本質(二)iOS
- VDI市場:探尋企業影子IT風險來源|
- iOS底層原理總結 - 探尋Class的本質iOS
- 無服務計算應用場景探討及 FaaS 應用實戰