ClickhouseClickHouseExplainer
How the D. E. Shaw group powers high-cardinality observability at scale with ClickHouse
Summary
Inside D. E. Shaw group, a global investment and technology development firm, millions of compute workloads run monthly across its high-performance computing infrastructure. To support capacity planning and resource allocation, it collects task-level metrics for requested and utilized compute, producing millions of distinct time series that its previous observability platform could not accommodate. Engineers benchmarked databases on identical hardware and datasets; ClickHouse ingested approximately 3.5 million samples per second on one node versus roughly 480,000 for a competing solution, while similar queries completed in seconds instead of timing out. They retained InfluxDB line protocol, batched messages into ClickHouse, and built disk-based tooling to transform and stream historical data; the resulting four-server NVMe cluster stores about 68 TB compressed and sustains 530k records per second on average. Materialized views support capacity-planning dashboards, while OpenTelemetry tracing extends the platform to other observability workloads, with SQL migration and data modeling requiring engineering effort.
Context
The firm needed longer-term capacity planning and strategic decision-making from increasingly granular resource metrics. Preserving a unique task ID for every workload created millions of distinct time series, and the previous observability platform could not accommodate the resulting high-cardinality workload or efficiently provide historical data at the required scale.
Approach / What changed
The team evaluated competing databases using identical hardware and datasets, measuring ingestion and query performance. It selected ClickHouse, retained InfluxDB line protocol, batched incoming messages through an internal service, and inserted them into a four-server replicated NVMe cluster. Custom tooling read historical data files directly from disk, transformed them into a column-oriented format, and streamed them into ClickHouse; materialized views pre-aggregate longer time horizons.
Takeaways
In the benchmark, a single ClickHouse node ingested approximately 3.5 million samples per second, compared with roughly 480,000 samples per second for a competing solution.
Historical backfill through the previous platform’s query API was impractical, so engineers built tooling to read data files directly, transform them, and stream the results into ClickHouse.
Unique task IDs reduce compression efficiency for some fields, but preserve workload-level visibility; the deployment stores about 68 TB of compressed metrics data and achieves up to 5x compression for those fields.
Source and freshness
- Source
- clickhouse.com
- Published
- Added to Yomu
- Last updated
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.