iT邦幫忙

2021 iThome 鐵人賽

DAY 28
0
AI & Data

資料工程師修煉之路 Part II系列 第 28

Stream Processing (1-1) - Transmitting Event Streams

Transmitting Event Streams

最後一個章節是 串流處理 (stream processing),Day 23 ~ Day 27 講的 批次處理 (batch processing) 之輸入都是有限的,而串流處理要做的就是處理無限的輸入,放棄固定以時間片段執行,選擇當事件發生時執行。

但其實我們可以把時間切成極細的片段(每 1 奈秒),這樣批次處理就會等於串流處理了 XDD。

Messaging Systems

一般來說,串流 (stream) 是指會隨著時間逐漸增加且可用的數據,此概念有被運用在很多地方,如 Unix 系統的 stdinstdout ,程式語言的 lazy list 等等。

事件 (event) 可以是字串、JSON、或二進位數據,端看系統使用的編碼方式為何,而事件代表的意義很廣泛,以串流處理的角度來看,事件是按日歷鐘時間逐漸發生的數據;以 Java 的 FileInputStream 來看,事件就是每一行的 byte;以 Day 23 的 log 分析例子來看,事件就是每一筆 log,它們都是相同的概念:一個小的、自我包含的、不可變的對象。

在串流處理的術語中,一個事件被 生產者 (producer) 產生,然後會有多個 消費者 (consumer) 處理事件,相關的事件通常被組合到同一個 topic 中。

直接訊息傳遞

一般常見方法是使用 訊息系統 (messaging system) 來通知消費者有新事件發生,然而有一些訊息系統不會透過中間層節點,生產者透過網路直接將訊息通知消費者,像無代理訊息系統 ZeroMQnanomsg 透過 TCP 或 IP multicast 實作 發佈/訂閱 (publish/subscribe) 模型。

訊息代理

另一個被廣泛使用的寄送訊息之選擇就是 訊息代理 (message broker) 啦,生產者和消費者都透過 broker 作業。

當多個消費者想從同一個 topic 讀取訊息時,這裡有 2 種訊息傳遞模式可選擇,如下圖 11-1:

  • Load balancing

    每一條訊息只會傳遞給其中之一個消費者,所以消費者可以並行分散的處理訊息,適合用在訊息處理是昂貴的場景上。

  • Fan-out

    每一條訊息都會傳遞給所有消費者,這個就像同時從同一個輸入資料中執行多個批次處理作業一樣,消費者之間不會彼此干擾。

但實務上會組合這 2 個模式,像 Kafka 就能多個消費者群組註冊同一個 topic,每條訊息都會傳遞給這些消費者群組,消費者群組中是並行的接收訊息來處理。


未完喔!


上一篇
Batch Processing (4) - Materialization of Intermediate State
下一篇
Stream Processing (1-2) - Acknowledgments & Partitioned Logs
系列文
資料工程師修煉之路 Part II30

尚未有邦友留言

立即登入留言