背景知識：Batch、Pipeline 與 Lambda/Kappa 架構｜RisingWave 不踩坑實戰 Day 00

前言

任何工具都可以「接上去跑」，但接上去跑（能動）是一件事；跑得穩、用得對，甚至發揮它該有的效益 — — 又是完全不同的幾件事。

在做即時數據系統評估與落地時，我反覆看到一個很常見的情況：服務部署起來了、SQL 也寫了，但延遲、資源占用或結果一致性卻始終不如預期。這時候最直覺的反應，往往是懷疑是不是工具選錯了；但很多時候，真正的問題不是工具本身，而是我們還沒有用對理解它的方式。物化視圖怎麼拆、Join 怎麼寫、狀態怎麼管理，最後都會直接反映在系統的表現上。

這個系列想做的事很簡單：從底層運作出發，理解 RisingWave 的設計邏輯到底是什麼。理解了 Actor 怎麼調度、Barrier 怎麼流動、狀態怎麼存，遇到效能問題時才有辦法對症下藥，而不是靠猜測或無止盡的試錯。

希望這 30 篇能幫你把工具真正用到位，而不只是用起來。也希望對於正在評估或導入 RisingWave 的團隊來說，這個系列能提供一個更全面的參考視角 — — 不只是「能不能用」，而是「怎麼用才對」。

1. 先釐清兩個名詞：Batch 和 Pipeline 差在哪？

在進入 RisingWave 之前，有兩個名詞幾乎每一篇都會出現 — — 如果對它們的理解不一致，後面所有討論都會歪掉。

Batch Processing（批次處理）

DDIA 第 10 章的定義：

「In batch processing, the input is bounded — it has a known, fixed size… A batch job usually reads some input data and produces some output data, without modifying the input.」

批次處理的核心特徵是資料是有界的（bounded）：你知道這次要處理多少資料，跑完就結束，下次再來一批。

典型的批次流程長這樣：

收集一段時間的資料（例如一天的訂單）
        ↓
觸發一個 Job（Spark / dbt / SQL 腳本）
        ↓
全量掃描、計算、輸出結果
        ↓
Job 結束，等待下次排程

批次的優點是語意簡單、結果準確 — — 只要資料收齊了，重跑就能得到完全一致的結果。代價是延遲高：如果凌晨跑報表，你最快只能在隔天早上看到昨天的數字。

Stream Processing / Pipeline（串流處理 / 管線）

DDIA 第 11 章的定義：

「In stream processing, the input is unbounded — the data arrives gradually over time, and the job is never ‘done’ in the same sense as in a batch job.」

串流處理的核心特徵是資料是無界的（unbounded）：資料持續流入，系統不等收齊再算，而是每來一筆就立刻處理。

Kleppmann 進一步用 Pipeline（管線） 來描述這個模式 — — 資料在一連串算子（Filter → Join → Aggregate）裡流動，每個算子收到上游的變更就立刻計算並往下傳，整條管線永遠不會停。

典型的串流管線長這樣：

Kafka 持續有新事件進來
        ↓
Pipeline 第一個算子：Filter（這筆符合條件嗎？）
        ↓
Pipeline 第二個算子：Join（去查對應的 user 資料）
        ↓
Pipeline 第三個算子：Aggregate（更新目前的計數）
        ↓
結果即時更新，下一筆進來繼續

優點是延遲極低，事件發生後毫秒內就能反映在結果裡。代價是語意更複雜：資料是逐筆處理的，中間狀態要妥善維護，亂序、重複、失敗恢復都要想清楚。

兩者的本質差異

Batch V.S. Stream Pipeline

DDIA 第 11 章有一個關鍵洞察值得記住：「The two approaches are not mutually exclusive… you can use a stream processing system as a layer on top of a batch system.」 這正是 Lambda 架構的理論依據 — — 也是它後來被批評「維護成本太高」的根源。

理解了這個底層差異，後面我們在說 Lambda 架構為什麼「兩套邏輯各維護一次」、以及 RisingWave 為什麼能把這兩件事合而為一，才會真正看懂。

2. Lambda vs. Kappa，差在哪？

在聊架構演進之前，先快速同步一下這兩個名詞，後面會一直用到：

1. Lambda 架構：因早期沒有任何一個系統能同時搞定「海量歷史數據的準確計算」和「亞秒級的實時響應」，所以只好拆成兩條腿走路 — — Batch Layer 負責跑準確的全量結果，Speed Layer 負責快速給近似的實時結果。代價是：兩套引擎、兩套邏輯、可能永遠對不齊的數字，同時開發上只要有功能迭代就必續維護兩邊。 Martin Kleppmann 在 Designing Data-Intensive Applications（DDIA）第 11 章直接點出這個架構的核心矛盾：「The lambda architecture proposes running two different systems in parallel… The downside is that you have to maintain the same logic in two different processing systems.」
2. Kappa 架構：旨在簡化 Lambda，核心理念是一切皆流，用單一串流引擎統一處理所有數據，需要重算時從 Kafka 重播歷史消息即可。這個概念最早由 Jay Kreps 在 2014 年的文章〈Questioning the Lambda Architecture〉中系統化提出，是對 Lambda 複雜度的直接回應。概念上很簡潔，但實作時遇到大型 Backfill 或長視窗，傳統引擎的狀態管理往往就成了瓶頸。

▶ 下一篇：Day 01：有了這些背景，進入正題 — — 為什麼 RisingWave 值得認識？