串流:雙寫的陷阱、CDC,與流表二象性

批次處理「已經齊了」的資料;串流處理「一直來」的資料。這章很多地基我在別處鋪過了:log 與 offset 在 Kafka 系列、投遞保證在 delivery 那篇、視窗與 event time 在 Spark Streaming——都不重複。DDIA Ch11 真正的獨門,是三個更根本的觀念:為什麼「分頭寫兩份」注定出事、怎麼讓資料庫自己變成事件的源頭(CDC)、以及「流」和「表」其實是同一個東西的兩面。

雙寫的陷阱:同一份資料,分頭寫進三個系統

真實系統裡,同一份資料常要同時存在好幾個地方:DB 是主存放、Redis 是快取、Elasticsearch 是搜尋索引。最直覺的做法是應用程式自己分頭寫三份(dual write)——而這正是最常見的沉默資料事故的源頭:

CDC:讓資料庫自己變成事件源頭

「log 先行」聽起來要改寫整個應用——但有個聰明的捷徑:資料庫本來就有一條寫入順序的 log(WAL / binlog,複製 follower 就是靠它同步的)。CDC(change data capture)就是把這條內部的複製 log 接出來、變成人人可訂閱的事件流——Debezium 之類的工具偽裝成一個 replication follower,把每筆變更寫進 Kafka。應用程式一行不用改、照常寫 DB;快取、索引、數倉全部改吃這條流。DB 仍是 source of truth,但它的每一次心跳,全世界都聽得見——這也是現代資料平台把 OLTP 資料餵進分析側的主流姿勢。

流表二象性:表是流的積分,流是表的微分

這章最漂亮的觀念,是流(stream)和表(table)是同一個東西的兩面:

這個等價的實用後果:你可以永遠保留「流」,把「表」當成隨時可拋、隨時可重建的衍生品。 快取壞了?從 log 重摺一次。想加一個新的搜尋索引?從 log 的開頭重放一遍,新 follower 就長出來了。批次那章的「人為容錯」——輸入不可變、錯了重跑——被 log 原封不動帶進了串流世界:只要 log 還在,一切狀態都只是快取。

反思

「誰是 source of truth?」——一題問倒九成的資料架構

雙寫那張圖,是我工作裡見過最多次的事故原型:DB 和快取不一致、ES 索引跟主庫對不上、數倉數字跟線上差一截——追到根,幾乎都是某個地方在分頭寫兩份,而沒有人是誰的 follower。所以我現在看任何資料架構,第一個問題永遠是:這份資料的 source of truth 是誰?其他副本是「照同一條有序 log 跟隨」,還是「各寫各的、祈禱一致」? 是後者,就只是還沒出事。而 CDC 之所以優雅,是它不要求你改寫應用——它把資料庫既有的複製機制,從內部設施升級成公共接口,讓「加一個 follower」從大工程變成訂閱一條流。

「表是流的積分」——第三個看懂一票的等價

這系列我收集到第三個「一個等價、看懂一票」了:共識=一條大家同意的 log、批次=不可變輸入的純函數、現在表=流的摺疊。它一下子把散落的東西串起來:Kafka 的 compacted topic 為什麼能當 KTable 的底、materialized view 為什麼叫「物化」(把流凍成表)、Redis 複製為什麼傳的是命令流而不是整份資料、Kafka Streams 的 state store 為什麼敢放本地(反正 changelog 在 Kafka,掉了重摺)。連 Medallion 都能用它重新敘述:Bronze 是流的存檔,Silver/Gold 是不同深度的摺疊。抽象的等價關係,是知識最高的壓縮率。

「只要 log 還在,一切狀態都只是快取」——這句話值一個架構

寫完這篇,我想把這個系列裡最有殺傷力的一句話單獨拎出來:把不可變的 log 當唯一的真相,把所有狀態(快取、索引、報表、甚至資料庫本身)當成可重建的衍生品。 它把「壞了怎麼辦」這個最難的問題,降維成「重放一次 log」;把「想加新視圖」從遷移專案,降維成「起一個新 consumer 從頭讀」。這正是 log vs queue 那條軸的最終回報——當年選了「留著」而不是「拿走」,今天才有資格說「一切皆可重建」。當然它不免費:log 要留多久、schema 要能演化、重放要冪等,全是要繳的稅。但作為架構的預設傾向,我已經完全站在 log 這邊。下一篇是全書終章:把這些拼圖兜成 Kleppmann 對資料系統未來的想像。