[資料工程] ETL Batch & Streaming Pipeline 場景與選擇

Before you start reading this article, if you’d like to read the English version, please click below link and enjoy :)

[Data Engineering] ETL Batch Pipeline and Streaming Pipeline

前言

ETL (Extract, Transform, Load) 是資料工程師必備的技能之一，然而隨著場景的不同，哪些資料應該使用批次處理 (Batch)，何時又應該使用即時處理 (Streaming) 呢？

如果只能用一句話回答，最常聽到的答案不外乎是取決於資料被應用程式端取用時所能接受的延遲時間來決定。

批次處理 (Batch)

確保資料被正確更新，但對於延遲 (Data Latency) 有一定包容度的場景 (多以小時、天、週為單位)。例如：郵政包裹的配送進度查詢，系統只會在每個整點 10 分的時候更新狀態。

常見的特性包括：

1. 具體且反覆的執行條件。例如：明確的時間點(每週一上午8點)、時間間隔(每隔1小時)、資料量(每100MB)。
2. 面對需要等待資料完整收集後才能處理情境。例如：業務報表需要對全部銷售資料進行排序。
3. 對於最新資料、即時資料沒有迫切需求，但要求高度的資料正確性。

常見的業務場景：

1. 定期資料備份
2. 中長期趨勢預測
3. 鮮少更動的資訊與表格
4. 歷史交易紀錄與報表分析

即時處理 (Streaming)

資料需要在第一時間被處理然後使用，對於延遲 (Data Latency) 不具包容度 (多以毫秒至1 分鐘為基礎)。例如：金融機構對於詐騙或信用卡盜刷，會傾向更即時地提醒消費者留意財物安全。

常見的特性包括：

1. 接受持續性的事件觸發，且觸發後立即處理並反饋。
2. 使用者觸發的資料量與執行頻率無法預期且不規律。
3. 會紀錄每次觸發後執行的時間點。
4. 需要訊息佇列來保存因大量資料湧入造成的排隊現象。

常見的業務場景：

1. 影音與串流媒體的資料處理
2. 詐騙提醒與可疑刷卡通知
3. 基於使用者行為的即時廣告或推薦
4. 股市金融高頻交易

有沒有一種可能是我全都要？

在面對 Batch 的方案我們確保了資料的高度正確性，Streaming 則是更追求資料的低延遲，實務上，有可能同時達到兩者嗎？

答案是可以的。
Storm 的發表者 NathanMarz 提出了 Lambda Architecture，當時面臨的困境就如本題敘述所說，希望可以有一個架構可以兩全其美。Lambda 的核心概念就是將 Pipeline 複製成兩條(簡稱 S 與 B)，S 負責處理 Streaming，達到低延遲的需求，並將運算結果送至 Speed Layer。同時間 B 則按部就班的執行 Batch 運算，然後將結果依序送至 Batch Layer，最終兩者會匯集到 Serving Layer，一旦 Batch Layer 的結果出爐，便會將 Speed Layer 寫在 Serving Layer 的結果覆蓋，如此一來即使當初 Streaming 過程出現錯誤，最終應用端仍可以保證資料的高度正確性。

假設一個情況：

有個 Batch Processing 原先是每天執行一次，我們將他調整為每小時執行，再後來改為每分鐘執行，最後改為每秒就執行一次。那在極端條件的情形下，是否可以宣稱這個pipeline 就是一個 Streaming 的服務？ 差別在哪裡？

這提其實隱含了 Micro-Batch 的概念，與 Streaming 還是有差異的，底下分享一下我的觀點。

首先要釐清這是一個怎樣的服務，譬如說他是一份上個季度的業務報表，也就是說無論執行幾次結果都會是一樣的，那事實上只是在浪費運算資源而已。或者這是一個基於使用者行為的影片推薦系統，那我會詢問為何當初沒有採用 Streaming 的方案，有可能是因為運算資源有限，或是有特別的業務考量，又或是有其他資料流造成只能使用 Batch 的瓶頸。

撇除資料延遲與實務場景的考量之後，可以進一步思考架構層面，Streaming 架構下會需要 Message Queue 來處理同時間大量的事件請求，也就是說在沒有 Kafka 作為橋樑的前提下，大量的請求可能造成 Service 超出負荷而出現預期外的錯誤。

事實上，Micro-Batch 也就是如果不想等太久，且幾分鐘的資料延遲又不會影響服務，那也許可以考慮這種架構。雖然名稱當中有 Batch，但因為資料聚集的時間非常短，所以提供一種趨近於 Streaming 的感受。

Spark Streaming 就是一種 Micro-Batch 的實現，雖名為 Streaming 但卻是由我們自行決定 Batch 的大小，而這個數值大小正好體現了 Latency 與 Throughput 間的取捨，探究根本，仍要透過了解實際場景才能決定。

而關於 Kafka Stream 的討論，有些人認為這才是真正的 Streaming，原因就是它是真的 record-by-record 的進行處理，即便該底層 API 仍然有透過 Batch 對 Throughput 進行優化，但那便不在我們需要設定或煩惱的範疇了。細節我覺得這篇 Stackoverflow 說的很透徹。

Why so much criticism around Spark Streaming micro-batch (when using kafka as source)?

順帶一提，Streaming Pipeline 會有一個 Acknowledge 的機制，也就是當任務完成時會通知 Producer，否則在超過一定時間後，Producer 會再次發送相同的訊息，也就是 At-Least-Once 的機制，但由於這可能造成數據重複的情況，所以有一種說法是會藉由 Micro-Batch 的架構來達成 Exactly-once semantics 的需求。

身為團隊的資料工程師

如果正準備要開發一個新產品，在與團隊成員討論的過程中，有哪些面向可能影響 Batch 或 Streaming 方案的抉擇？

效率&可行性

在還沒有很明確的 Data Latency 要求的前提，也就是說使用 Batch 或是 Streaming 都可以的時候，不妨先把心力放在完成整段 data pipeline 的邏輯可能更為務實，此時先以 Batch 的方法進行測試通常是明智之舉。畢竟產品初期使用者不多，而且Streaming 勢必要維護更多的服務，例如: Message Queue，很容易把心力花費在處理追蹤資料或是避免訊息重複 (Duplicate) 的瑣碎事項。

成本

許多的 Cloud Service 提供 Pay-as-you-use 的服務，也就是需要運算的時候才會啟用該服務，並依照使用量收費，此時 Batch 運算的成本比起必須隨時待機的 Streaming Pipeline 往往更經濟實惠。與團隊架構師和 Leader 討論整體方案的預算還是很重要的，很多時候預算直接決定了方案。(畢竟成本考量對於公司往往是更重要)

應用場景

以 Netflix 的推薦系統為例，依照 User 的歷史行為計算出足夠的推薦清單，即便該計算是以 Batch 的方式運作然後更新，User 通常不會察覺。但 Netflix 提供了家庭方案，甚至其實有許多用戶私下將帳號外借給朋友使用 (不要學)，這時候便需要 Streaming Pipeline 去更即時推薦符合當下用戶的喜好內容了。

結語

透過這次紀錄，想加深自己對於抉擇 Batch 或 Streaming 的看法。事實上，就如同以上述 Netflix 推薦系統的舉例，同樣是推薦系統，也會因為用戶習慣、使用場景、產品定位而因此調整 Pipeline 的建置，所以說與團隊成員溝通想法，往往是遊走各種解決方案時的最佳良藥！

Reference:
1. https://stackoverflow.com/questions/65491431/why-so-much-criticism-around-spark-streaming-micro-batch-when-using-kafka-as-so

2. https://zhuanlan.zhihu.com/p/38483883

3. https://blog.devgenius.io/building-a-streaming-data-pipeline-on-ubuntu-20-04-8fa9e6f9cced

4. https://ithelp.ithome.com.tw/articles/10161494

如果你覺得文章對你有幫助，請給我一些掌聲。按住拍手不放 10 秒，每人最多可以拍 50下哦！文章會陸續更新，主要關於數據分析、資料開發筆記，以及一些個人想法的文章，歡迎有興趣的朋友們追蹤分享呦！