北京
同樣是跑分析查詢，為什么你的Postgres主庫一跑`GROUP BY`就喘不上氣，而同事的看板卻能在幾億行數據上亞秒級刷新？答案不只在查詢引擎，更在數據搬運的管道上。我們選擇ClickHouse做列式存儲加速，但真正棘手的是如何讓在線事務庫與列存分析庫保持準實時同步——這恰是變更數據捕獲要解的題。
原理其實很“物理”：Postgres為了崩潰恢復，會把每一次增、刪、改寫入預寫日志。CDC通過邏輯復制槽讀取這份日志，把它轉成有序的事件流，然后重放進另一個系統。相比用`WHERE updated_at > $last`輪詢，讀日志不僅能看到刪除記錄、不額外增加負載，還避免了時間列漏標的可靠性陷阱。所以基本前提是：別輪詢，讀日志。
打通Postgres和ClickHouse的CDC管道，業界常見三種走法。我們評估了全部，并在生產環境中實際跑過其中兩種，代價與取舍都來自實測。不論選哪條路，源頭Postgres的參數要先行：wal_level = logical開啟邏輯復制，合理設置發送者數、槽數以及WAL留存上限，避免失速的槽吃爆磁盤。再建一個帶復制權限的用戶，創建發布并納入需要同步的表，注意無主鍵表必須設置`REPLICA IDENTITY FULL`——這會讓更新和刪除時把整行舊值寫進WAL，寫入成本更高，所以能加主鍵的表盡量加上。
第一條路是Kafka加Debezium。Debezium通過復制槽訂閱WAL變更，把事件直接推入Kafka主題。獨立的消費者再從Kafka拉取數據寫入ClickHouse。這條鏈路的核心價值在于同一主題能扇出給搜索引擎、審計日志、數倉等多個下游，正因如此，團隊才愿意接受它實實在在的運維成本：Kafka集群、連接器、Schema注冊、監控、容量規劃，以及能搞定分區重分配的輪值。我們的判斷很明確——如果公司已經有Kafka技術棧，或需要事件流多路復用，這條路才劃算。不過，要特別注意連接方式：若采用ClickPipes這類組件，必須直連Postgres，PgBouncer事務模式、RDS Proxy或Supabase連接池都不可用。
另外兩條路徑同樣在考量之中：一條偏向輕量托管，另一條則是同構系統的直接對接。它們的取舍各不相同，但都繞不開對數據一致性、延遲和運維負擔的平衡。站在選擇的路口，真正需要解答的不是“能不能連上”，而是“哪套鏈路能和現有基礎設施摩擦最小”，這往往比單純的性能指標更值得反復推敲。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
