DuckDB Quack 遠端協議：HTTP 為基礎的多程序並行寫入架構，60M 列傳輸 4.94 秒
DuckDB · 2026-05-12
DuckDB 團隊在 2026 年五月十二日發表 Quack 遠端協議，讓多個 DuckDB 實例可以透過 HTTP 互相通訊，首次在官方支援下解鎖多程序同時寫入同一資料庫的使用場景。DuckDB 過去作為嵌入式資料庫運作，多程序並行修改同一 .duckdb 檔案一直是已知限制。協議名稱 Quack 指定預設通訊埠為 9494，致敬 Netscape Navigator 於 1994 年誕生。
規格細節
Quack 建立在標準 HTTP 之上，而非自訂 TCP 協議，使其可直接與現有的負載均衡器、防火牆規則和身份驗證中介軟體整合。序列化格式採用 DuckDB 內部的 application/duckdb MIME 類型，複用 WAL（Write-Ahead Log）系統的成熟序列化原語，避免了 Arrow 格式的 schema 協商與轉換開銷。通訊模式為客戶端驅動的請求-回應，一般查詢可在單一往返內完成。
安全模型預設使用隨機 token 驗證，並僅綁定 localhost；擴充機制允許接入 LDAP、檔案型驗證或自訂回調。伺服器端透過 LOAD quack; SELECT quack_listen(...) 啟動，客戶端以 ATTACH 'http://token@host:port' AS remote (TYPE quack) 連線。
效能數據
| 情境 | Quack | 對照組 |
|---|---|---|
| 批次傳輸（6000 萬列） | 4.94 秒 | Arrow Flight SQL：17.40 秒 |
| 小型寫入（8 並行執行緒） | 5,434 tx/秒 | PostgreSQL 在相同並行下更低 |
批次傳輸比 Arrow Flight SQL 快約 3.5 倍，差距主要來自 DuckDB 原生序列化格式避免了 Arrow 轉換開銷。小型寫入的高吞吐來自 HTTP/1.1 keep-alive，每個查詢的協議開銷極低。
影響範圍
Quack 最直接的應用是集中式遙測收集（多個 worker 寫入同一個 DuckDB 資料庫並同時查詢）和輕量級資料服務。由於協議基於 HTTP，現有的 API 閘道（Nginx、Envoy）和服務網格（Istio）可以不修改地接入流量管理與 mTLS。目前 Quack 作為 DuckDB 擴充發布，安裝後需明確 LOAD quack。
原始來源：DuckDB News
Meta 每日 PB 級 MySQL 增量擷取系統遷移：三階段影子測試消除萬級任務遷移風險
Meta Engineering · 2026-05-12
Meta 工程部落格在 2026 年五月揭露其資料擷取系統遷移的技術細節：將每日數 PB 資料量、數萬個 MySQL 增量擷取任務，從用戶自管的遺留管線遷移至統一的自管資料倉儲服務架構，最終達成 100% 工作負載覆蓋率，無重大資料損失事件。
原本的問題
舊架構讓各業務團隊自行維護 MySQL→資料倉儲的擷取管線，導致系統間缺乏一致的監控標準、資料品質驗證邏輯和故障處理機制。數萬個任務的差異化配置使得跨任務的問題診斷和版本升級極為困難。CDC（Change Data Capture）在完整 dump、增量 delta、目標資料表管理等方面沒有集中的最佳化，且壞資料一旦注入，可能沿整個 delta 鏈污染下游分區。
採用的方法
遷移採用三階段生命週期。第一階段「影子階段」：新服務在不影響舊管線的前提下，以接近生產規模的流量平行執行並比較輸出。第二階段「反向影子」：交換主從關係，新服務成為主要資料流，舊管線降為驗證角色，同時監控兩個系統的行為差異。第三階段「清除」：最終驗證後下線舊管線。資料品質的自動化驗證是核心挑戰：系統透過比對列數（row count）和 checksum 決定任務的自動晉升或降級，避免人工逐一確認數萬個任務。對於 CDC 特有的壞資料傳播問題，新系統在分區層級設置元資料標記，讓下游系統可以識別並隔離問題分區而不必停止整個擷取任務。
實際效果
遷移達成 100% 工作負載覆蓋，資料落地延遲持平或改善，資源使用效率提升。集中化後的統一監控儀表板（整合 Scuba 分析系統）使問題定位時間顯著縮短。Meta 強調整個過程沒有出現大規模資料遺失事件，這在如此規模的系統切換中並不常見。