Spyne 如何用 ClickPipes 取代 Debezium／Kafka，將 CDC 資料表上線時間從 1.5 小時壓縮到幾分鐘
ClickHouse Blog · 2026-06-22
印度 AI 汽車零售科技公司 Spyne 在 2026 年 1 月的 ClickHouse Gurgaon Meetup 上，由 DevOps 工程師 Abhash Solanki 分享了將 CDC 管線從自行維運的 Debezium／Kafka 架構全面遷移至 ClickPipes + ClickHouse Cloud 的完整歷程。遷移後，新增一張資料表的上線時間從超過 1.5 小時縮短至幾分鐘，schema 異動不再需要人工介入。
原本的問題
舊架構由 MySQL／MongoDB 作為來源，經 Debezium connector 抓取異動事件後推入 Kafka，再透過 ClickHouse Kafka Engine 表與 Materialized View 寫入 ReplacingMergeTree 目的表。這條鏈路在 schema 異動時極為脆弱：Materialized View 的欄位定義鎖定於最初的 DDL，一旦上游資料表新增欄位，新資料會被靜默丟棄，工程師往往數天後才察覺 schema drift。
新增一張資料表需要人工完成 DDL 映射、建立 Kafka Engine 表、撰寫 Materialized View，平均耗時超過 1.5 小時。此外，初始快照（snapshot）期間整條 CDC 串流會暫停，所有待上線的資料表都必須排隊等候。
採用的方法
遷移後的架構移除了 Debezium 與 Kafka，改由 ClickPipes 管理式攝取層直接連接 MySQL／MongoDB，並透過 ClickHouse Cloud UI 完成設定，無需撰寫任何 DDL 或 Materialized View。ClickPipes 內建自動 schema 演進功能，能即時偵測上游 DDL 變更並套用，不需重啟管線。
針對快照阻塞問題，Spyne 採取分組隔離策略：將 10 張體積最大、查詢最頻繁的資料表各自建立獨立的 ClickPipe，其餘優先度較低的資料表則合併為另一組，避免單一大表的快照拖慢整體進度。對於 ReplacingMergeTree 的最終一致性問題，則在下游查詢加上 FINAL 修飾符，強制在查詢時進行去重，代價是 CPU 用量上升。
-- 加 FINAL 強制去重，適用於需要精確計數的分析查詢
SELECT count(*)
FROM orders FINAL
WHERE status = 'completed';
實際效果
| 指標 | 遷移前 | 遷移後 |
|---|---|---|
| 資料表上線時間 | 1.5 小時以上（人工） | 幾分鐘（UI 操作） |
| Schema 異動處理 | 手動、易出錯 | 自動演進、零介入 |
| Schema drift 察覺時間 | 數天 | 即時 |
主要取捨在於：失去 Debezium 細粒度部分重同步能力。若發生非預期中斷，ClickPipes 目前只支援全資料表重新同步，對於 TB 級資料表這意味著較高的 ingress 費用與延遲。Solanki 的結論是整體穩定性與速度增益明顯超過這項代價。
可觀測性的未來不是單一萬能 AI Agent，而是各團隊自建的數千個領域 Agent
ClickHouse Blog · 2026-06-22
ClickHouse 工程師 Mike Shi 於 2026 年 6 月 22 日發文，反駁「單一通用 SRE Agent 將解決所有可觀測性問題」的主流敘事，主張未來的可觀測性平台應由各工程團隊圍繞自身系統與組織知識打造專屬 Agent 生態系，而非仰賴單一封閉的 AI 代理。
核心改動
傳統可觀測性工作流是「人 → 儀表板 → 資料」，Agent 驅動的模式則演變為「人 → Agent → 資料」。Agent 的查詢模式與人類截然不同：人類可能比對兩個時間窗口，Agent 可以同時比對二十個；人類憑直覺跳過某些假設，Agent 則傾向窮舉所有可能路徑，對底層資料庫的低延遲與吞吐要求因此大幅提升。
Shi 指出，Agent 無法像資深工程師一樣靠「組織直覺」補全缺失資訊，因此對完整、未降採樣（unsampled）的歷史資料有強依賴。若資料儲存層在高基數維度（如 trace ID、pod 名稱）上做了抽樣或聚合，Agent 的根因分析能力會顯著退化。
影響範圍
文章的核心論點是：可觀測性的難點從來不是技術，而是組織情境（organizational context）——runbook、事後檢討（postmortem）、部署系統、Slack 討論紀錄、以及各團隊特有的操作知識。這些情境高度異質，不同公司、不同業務線甚至無法共用同一套 Agent 邏輯。
Shi 認為可觀測性平台應提供一個持久可查的協作調查介面，讓 Agent 的每次調查過程可以被分享、審查、重跑與精煉，形成組織級的知識庫，供未來的工程師與 Agent 繼承。人類則保留對業務優先順序、風險評估與最終行動的控制權。
- Agent 需要能橫跨 metrics、logs、traces 的跨資料集查詢能力
- 底層儲存需支援高並發、低延遲的分析查詢
- 調查結果應可持久化並版本化，而非僅存於 Agent 的短暫上下文中
- 組織應主動建立並維護 Agent 可消費的結構化操作知識庫