How ByteHouse Evolved From ClickHouse Into a Next‑Gen Cloud‑Native Data Warehouse

Background

ClickHouse was open‑sourced in 2016 and quickly became popular in the analytical database space because of its strong performance. ByteDance, a heavy ClickHouse user, operates the largest domestic ClickHouse cluster with more than 18,000 nodes and over 700 PB of data as of February 2022, supporting a wide range of growth‑analysis workloads.

Challenges with ClickHouse

Despite its performance, ClickHouse suffers from limited scalability, poor elasticity, and high operational complexity. The lack of elastic scaling and the increasing size of clusters make management and fault‑tolerance increasingly difficult.

From ClickHouse to ByteHouse

To meet internal business needs, ByteDance invested heavily in extending ClickHouse, eventually delivering the commercial product ByteHouse on the Volcano Engine platform. The evolution involved deep interviews with the ByteHouse core team to reveal the technical journey.

Early Adoption and Evaluation

The first use case in 2017 was user‑growth analysis, a scenario demanding real‑time, interactive queries. The team evaluated several OLAP engines (Kylin, Druid, Spark) before selecting ClickHouse for its millisecond‑level query latency, despite its later scalability limits.

Key Requirements

High availability and strong performance (seconds‑level interactive response).

Reusability – a customizable engine that can serve many scenarios.

Ease of use – enabling users to adopt the product autonomously.

Scaling Beyond a Single Business

ByteHouse expanded from a single growth‑analysis workload to BI, A/B testing, model prediction, and more, driving a ten‑fold increase in cluster size and exposing storage and write‑path bottlenecks.

Storage Architecture Improvements

The team introduced hot‑cold tiered storage, moving infrequently accessed data to remote cold storage while keeping recent data locally. Data ingestion was decoupled from query services: a dedicated import service formats and writes data to shared storage, allowing ClickHouse nodes to focus on query execution.

High‑Availability Redesign (HaMergeTree)

To reduce ZooKeeper pressure, a custom high‑availability layer called HaMergeTree was built. ZooKeeper now only handles three simple tasks—sequence number allocation, block ID allocation, and metadata storage—while node‑to‑node gossip synchronizes data and logs, preserving multi‑master writes.

Operational Enhancements

Metadata persistence was improved, cutting restart time from hours to minutes and raising SLA to 99.95 %. Automation of deployment, health checks, fault alerts, and UI‑driven DDL reduced manual effort and lowered the barrier for business users.

Cloud‑Native Architecture

The redesign focused on elastic compute and storage, multi‑tenant isolation, and cloud‑native deployment. Key components include:

Distributed KV for independent metadata management.

Integration with shared storage systems using a custom abstraction layer.

Full ACID support and fine‑grained locking (DB/Table/Partition/Part) with MVCC.

Multi‑level caching on server and worker nodes to mitigate remote data latency.

Compact data format to avoid small‑file overhead in object storage.

Containerized services orchestrated by Kubernetes, enabling dynamic resource scaling and isolation.

Product Positioning

ByteHouse is positioned as a next‑generation cloud‑native data warehouse competing with Snowflake, aiming for multi‑cloud neutrality and SaaS delivery. It was publicly released in August 2021 and is gradually migrating internal workloads while co‑existing with the original ClickHouse deployment.