LinkedIn 把三套指標中繼資料系統併入單一 ClickHouse
ClickHouse 官方部落格（User stories） · 2026-10-01
LinkedIn 觀測團隊把原本由自製記憶體搜尋索引、Elasticsearch、自製記憶體 KV store 組成的指標中繼資料（metric metadata）查詢，全部換成單一 shard 的 ClickHouse。這套索引現在涵蓋 130 億以上的指標，每分鐘服務 15 萬次以上查詢，平均延遲 68ms。
這是 LinkedIn 繼分散式追蹤之後，第二個放上 ClickHouse 的觀測場景；內容整理自 staff software engineer Jacob Zelek 在 Open House SF 2026 的分享，由 ClickHouse 於 2026-10-01 發文。
原本的問題
LinkedIn 早年用 RRDtool 記錄與繪製時間序列，它的命名習慣一路留到現在：一個指標由 RRD 字串表示，把兩到六個標準化維度串成一條，例如 my-server/responses.status.200.rrd。後來又加入對多個指標套用 regex 的能力，一張圖或一次告警可以展開成多條序列。
規模讓這件事變得很痛：仍以 RRD 語意引用的指標超過 130 億個，每日約 30% 汰換，數百萬張圖表與告警都用這種方式定義，還有數十個工具與服務在查詢。工程師想問的問題包括「哪些主機送出某個指標」「某服務送出哪些 RRD」「跨所有服務符合某個 pattern 的指標有哪些」。
舊系統長成三個服務掛在同一個 gateway 後面。Jacob 加入時有自製記憶體搜尋索引與自製記憶體 KV store，他後來引入 Elasticsearch，希望一個系統就能取代其他兩個，結果它反而成了第三個要維運的服務：大範圍聚合表現不佳，回傳大型結果集也得在記憶體中序列化。到 2025 年，三個服務都碰到擴展上限，有些查詢三者合起來也答不出來。
採用的方法
團隊評估過的選項各有硬傷。再做一套自製系統，彈性不及通用方案，專業知識也只會留在少數人手上；分片 MySQL 則因為先前用 Vitess 當 source of truth 時讀取擴展不了而排除；Elasticsearch 早先遷移流量已失敗，只保留作探索用途。ClickHouse 支援所有既有查詢，在與自製記憶體資料庫的基準測試中大多更快，較慢的也在可接受範圍內。
新架構相當簡單：時間序列資料庫透過持續的變更捕捉（change capture）同步到 ClickHouse，原本的 gateway 改為把中繼資料查詢改寫成 SQL 送進 ClickHouse。因為公司內所有工具本來就走這個 gateway，遷移對下游是透明的，文中的說法是「Anyone using RRD is already using ClickHouse」。
- 表引擎：replicated
ReplacingMergeTree，排序鍵針對探索用的維度，以唯一 ID 去重。變更捕捉串流是 at-least-once，重複資料由 ClickHouse 在 merge 時丟棄，不用另外寫去重邏輯。 - 每日重建：從離線時間序列資料庫建出當天新表，補上變更捕捉資料後，用 alias 切換表指標、導流，再刪舊表。
- 重型聚合：用 projection 處理服務對指標數、服務對唯一 RRD 數、資料中心對主機清單這類舊系統做不到的查詢。
- 維度成欄：每個維度直接是欄位，原本對整條 RRD 字串跑 regex 的查詢，可改成欄位過濾。
-- 舊：對整條 RRD 字串做 regex
match(rrd, 'my-server/responses\\.status\\..*\\.rrd')
-- 新：直接過濾維度欄位（欄位名稱為示意，原文未公布 schema）
WHERE service = 'my-server' AND metric LIKE 'responses.status.%'實際效果
| 項目 | 舊（三系統） | 新（ClickHouse） |
|---|---|---|
| 系統數 | 3 個服務 | 1 個索引、單一 shard |
| 記憶體 | 基準 | 約 1/5（團隊估計） |
| 運算 | 基準 | 約 2/3 |
| 查詢量與延遲 | 已達擴展上限 | 15 萬+ 次/分鐘，平均 68ms |
| 擴充空間 | 無 | 可再容納兩倍指標量 |
68ms 是所有查詢類型的平均，包含舊系統根本答不出來的深度分析查詢；Jacob 說若攤開分布，會看到個位數毫秒的查詢。記憶體與運算的數字是他的估計，不是正式基準測試。
影響範圍
仍在大量使用 regex 的指標查詢使用者是最直接的受益對象：維度成欄後，主要客戶正把 regex 查詢改寫成原生查詢，叢集甚至可能隨使用方改寫而縮小。若你的團隊也有「先上 Elasticsearch 再補自製索引」的中繼資料系統，這個案例提供了評估項目：聚合是否需要跨整個基數、重複資料能否交給引擎 merge 去處理、是否有 quota 與 query log 可以追到是哪個團隊的查詢拖慢系統。
文中提到 ClickHouse 的 quota 與 query log 讓團隊能看出每個查詢來自哪個團隊或服務，不只擋掉濫用查詢，也能一起改寫。另外需要注意：這是廠商發布的客戶案例，成本與延遲數字皆為 LinkedIn 自述，原文未公布硬體規格、資料量對應的叢集大小，也沒有與舊系統同條件的對照測試。
前一階段：分散式追蹤
這次擴充的前提是兩年前的追蹤系統。OpenTelemetry 追蹤在 1% head sampling 下，每天仍產生約 0.8 兆個 span、200 TB 未壓縮資料。三個資料中心各有一個 22 shards 的叢集，採 red-black 配置（寫兩個叢集、讀一個，另一個待命，第三個做驗證），3x 本地複寫，壓縮約 5x，每節點穩態每秒吃 35 萬個 span，尖峰超過 120 萬。調整欄位順序、改以實際查詢欄位重新分區、收緊 Bloom filter 誤判率後，查詢壓到兩秒內。這段經驗讓第二個專案的導入門檻很低。
原始來源：ClickHouse：How LinkedIn extended ClickHouse from distributed tracing to metric discovery and analytics、ReplacingMergeTree 文件