How LinkedIn extended ClickHouse from distributed tracing to metric discovery and analytics

ClickHouse · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài của nhà cung cấp (ClickHouse) kể lại hệ thống của khách hàng LinkedIn, qua hai talk của kỹ sư LinkedIn. Company ghi là ClickHouse theo sheet; nội dung là của LinkedIn, mọi nhận định là "theo LinkedIn qua lời kể của ClickHouse". Đọc cùng LinkedIn 2015 (thế hệ tracing trước).

Phần 1: tracing (từ 2024)

• Hệ tracing dựa trên OpenTelemetry theo request từ app của member xuống mọi service. Lấy mẫu đầu 1% mà vẫn sinh khoảng 0,8 nghìn tỉ span và 200 TB chưa nén mỗi ngày.
• Mục tiêu: ingest đầu-cuối dưới 10 giây; liệt kê trace trong cửa sổ 2 giờ p99 dưới 2,5 giây; lấy một trace theo ID dưới 750 ms; giữ 7 ngày, storage phân tầng, index tuỳ chỉnh, cô lập workload query, hỗ trợ KQL.
• Kiến trúc: 3 data center, mỗi nơi một cụm ClickHouse 22 shard, nạp từ PubSub qua tầng ingester. Red-black: ghi vào hai cụm, đọc một, cụm kia sẵn sàng thay; cụm thứ ba để kiểm tra. Schema phẳng, thuộc tính span đi kèm; replication cục bộ 3 bản; nén khoảng 5 lần; mỗi node nhận 350.000 span/giây ổn định, đỉnh hơn 1,2 triệu.
• Tối ưu: xếp cột cardinality thấp lên đầu khoá sắp xếp, partition lại theo trường thật sự hay query, chỉnh tỉ lệ dương tính giả của Bloom filter ở cột rẻ: query dưới 2 giây.

Phần 2: metadata của metric (2025–2026)

• Di sản RRDtool: mỗi metric vẫn được gọi bằng một chuỗi ghép 2–6 chiều (ví dụ my-server/responses.status.200.rrd), user dùng regex trên chuỗi để vẽ nhiều series. Hơn 13 tỉ metric, khoảng 30% thay mới mỗi ngày, hàng triệu graph và alert, hàng chục công cụ phụ thuộc.
• Hệ cũ là ba service sau một gateway: index tìm kiếm trong RAM tự viết, KV trong RAM tự viết, và Elasticsearch (thêm vào để thay hai cái kia nhưng thành cái thứ ba; kém với aggregation rộng và kết quả lớn). Tới 2025 cả ba chạm trần.
• Phương án bị loại: tự viết thêm (chỉ vài người hiểu); MySQL shard (trước đó dùng Vitess làm nguồn sự thật và không scale được đọc); Elasticsearch (đã thử chuyển và thất bại). Chọn ClickHouse vì chạy được mọi query cũ, có quota và query log theo team, và đội đã có kinh nghiệm từ dự án tracing.
• Kiến trúc mới: CDC liên tục từ time-series DB vào bảng ReplicatedReplacingMergeTree (khử trùng theo ID duy nhất khi merge, nên chịu được at-least-once). Mỗi ngày dựng bảng mới từ dữ liệu offline, bắt kịp bằng CDC, rồi đổi alias và xoá bảng cũ. Projection cho các aggregation nặng; tách từng chiều thành cột để bỏ regex.
• Gateway làm migration trong suốt: mọi công cụ vốn đi qua gateway, nên khi gateway chuyển sang viết SQL vào ClickHouse thay vì fan-out ra ba hệ thì không ai phía dưới phải đổi.
• Kết quả: hơn 150.000 query/phút, trung bình 68 ms (gồm cả query phân tích sâu mà hệ cũ không làm được), trên một shard; bộ nhớ còn khoảng 1/5, compute khoảng 2/3, đủ chỗ cho gấp đôi số metric.

Vì sao

• Kho cột đa dụng giữ mọi chiều thay được nhiều hệ chuyên biệt, và mở ra câu hỏi mới (Observability và monitoring).
• Một dự án thành công tạo đội ngũ biết vận hành, làm hệ thứ hai rẻ hơn hẳn so với đưa công nghệ mới vào.

Bài học cho SWE

• Ngay cả ở 1% lấy mẫu, tracing của hệ lớn là bài toán dữ liệu cỡ trăm TB/ngày; ngân sách latency ingest và query phải đặt từ đầu (Tracing phân tán và log theo request).
• Một gateway đứng trước mọi client là đòn bẩy migration: đổi backend phía sau mà client không biết (Migration không downtime).
• Quy ước đặt tên cũ (RRD) sống rất lâu; hệ mới phải phục vụ cách gọi cũ trong khi dần chuyển người dùng sang cách gọi mới.

Liên quan

• LinkedIn 2015 · ClickHouse 2025 · LinkedIn 2019
• Tracing phân tán và log theo request · Observability và monitoring · Migration không downtime