資料系統的未來:拆開的資料庫、Kappa,與端到端的正確性(完結)

終章。前面十一章把儲存、複製、分區、交易、共識、批次、串流一塊塊講完,Kleppmann 在這章把它們收攏成一個大膽的視角:別再把「資料庫」當成一個盒子——把它拆開。 而讀到這裡你會發現,這個「未來」你其實已經住在裡面了。

Unbundling:你的資料平台,就是一台拆開的資料庫

一台資料庫,其實是一堆功能的捆綁包:儲存引擎、索引、快取、materialized view、複製 log——全部裝在一個盒子裡,由 DB 內部保證它們一致。Kleppmann 的觀察是:現代資料平台正在把這個盒子拆開——每個功能由一個特化系統負責,而讓它們一致的膠水,正是上一篇的那條 log:

這個視角的實用價值:「幫平台加一個搜尋功能」= 「幫這台大資料庫建一個索引」——做法也一樣:從 log 重放、長出一個新 follower,不碰現有系統。資料庫內建索引時你信任它自動維護;拆開之後,維護「索引跟上主資料」的責任落到了你頭上——這正是資料工程師這個職業存在的深層原因。

Lambda vs Kappa:兩套邏輯,還是一條 log

「同一份資料要同時算得準(批次)又算得快(即時)」,歷史上有兩個答案:

最誠實的一課:正確性的最後一哩,在端到端

全書最後的技術段落,Kleppmann 潑了一盆重要的冷水:別盲信任何中間件的保證。 exactly-once 很強,但它的保證有邊界——資料出了那個邊界(寫進外部系統、呼叫外部 API、使用者按兩次送出),語意就斷了。真正可靠的去重,只有端到端的做法:請求從源頭就帶一個唯一的 request id(冪等鍵),一路帶到最終寫入的地方,由終點做最後的把關——這是網路領域古老的 end-to-end argument 在資料系統的重演,也是 冪等那條紀律的理論根據。再往上一層,他主張系統要稽核(audit):定期驗證資料的完整性(數量對不對、加總對不對),而不是假設「pipeline 沒報錯 = 資料是對的」——沒報錯只代表沒發現錯。這句話,正是資料品質工程的起點。

反思

「平台是一台拆開的資料庫」——這個視角把我的整張地圖翻了過來

Unbundling 是我讀完全書後座力最強的觀念。回頭看我自己養的平台:Kafka 是 commit log、Elasticsearch 是索引、Redis 是快取、數倉的 Gold 層是 materialized view——我每天維運的,其實是一台攤開在 K8s 上的巨型資料庫,而我的職責,就是資料庫核心工程師的職責:保證這些「拆開的元件」跟主資料一致。這個視角立刻給了我兩條紀律:設計上,任何新元件都該是 log 的 follower,而不是另一個雙寫的受害者;債務上,資料庫用交易「免費」保證的一致性,拆開後每一分都要自己還——所以拆之前先問:這個功能,單機資料庫真的做不到了嗎?又是那道題。

「沒報錯 ≠ 資料是對的」——稽核是資料工程的下一站

end-to-end 那一課,對我這個角色是量身訂做的提醒。做 SRE 久了,很容易把「監控綠燈」當成「一切正常」;但 Kleppmann 點破:pipeline 全綠,只代表系統沒報錯,不代表資料是對的——筆數悄悄少了 2%、某個 join 默默對空、金額欄位單位錯了,監控一聲不吭。系統的可靠性靠監控,資料的正確性靠稽核——後者是獨立驗證(對帳、數量核對、不變量檢查),不是看 log。這正是我接下來想開的 Data Quality 系列要處理的主題:把「資料對不對」從一種祈禱,變成一門有指標、有告警、有 SLO 的工程。DDIA 的最後一章,剛好是那個系列最好的引言。

全書收官:它給的不是答案,是一套提問的框架

十二章讀完,如果要我說 DDIA 到底給了什麼,我的答案是:一套永遠不會過時的問題清單。 資料怎麼擺(讀的形狀)?狀態在哪、誰是 source of truth?順序由誰決定、被什麼保護?保證的邊界在哪、最後一哩誰把關?——工具會換(書裡不少範例已經老了),但這些問題會問到你退休。這也是整個部落格走到這裡的收束:DDIA 是原理層,Redis/Kafka/Spark/K8s 是實作層,SRE/LGTM 是維運層——同一張網,原理讓你看懂工具,工具讓你驗證原理,維運讓你為兩者付出代價、也收穫敬畏。最後,Kleppmann 選擇用整整一節倫理收尾:資料是權力,而權力需要自律——我們這行天天在決定「記錄什麼、留多久、給誰看」,那從來不只是技術決策。能力越大的系統,越需要克制的工程師——這本書,收在這裡。