ClickHouse 存算分离改造：小红书自研云原生数据仓库实践

ClickHouse 作为业界性能最强大的 OLAP 系统，在小红书内部被广泛应用于广告、社区、直播和电商等多个业务领域。然而，原生 ClickHouse 的 MPP 架构在运维成本、弹性扩展和故障恢复方面存在较大局限性。为应对挑战，小红书数据流团队基于开源 ClickHouse 自主研发了云原生实时数据仓库 RED ClickHouse（以下简称“REDck”）。

在保持 ClickHouse 原有超高性能的基础上，我们对其进行深度的云原生改造，实现了计算和存储层的弹性扩缩容能力，从而有效减轻运维负担并降低成本。REDck 具备支持 PB 级别数据的用户交互式分析能力，能够灵活满足各类数据分析需求，以满足小红书日益增长的业务和数据分析需求。

目前，REDck 已成功在公司电商、广告、社区、直播等 10+ 个业务场景上落地，总存储规模达到 30+PB。它在降本增效方面取得显著成效，特别是在实验平台和用户行为分析平台等典型场景中。以实验平台为例，在过去 2 年里，实验平台的数据存储周期从 2 个月增长到 2 年，实验指标数量和分析场景也增长 10 倍以上。在如此快速的业务增长下，REDck 为实验平台提供了 99.9% 的可用性保障，其强大的可扩展性成为了业务扩展的有力支撑。

1.1 小红书实时 OLAP 的发展

小红书从诞生之日起，整个基建体系全部搭建在公有云之上，是云上的原住民。

如上图所示，小红书的云原生大数据架构体系，自上而下分别是应用层、计算引擎层、计算资源层、数据层和存储层。

● 存储层核心是各大云厂商提供的对象存储服务，数据层采用通用的数据格式如 Parquet、ORC、Avro 等，并通过 Hive Metastore 提供统一的元信息服务。

● 在计算层，小红书利用 Kubernetes、YARN 等计算资源框架提供资源池化和弹性扩展能力。

● 在计算引擎层，借助 Spark、Flink 等技术实现离线和实时 ETL 链路，并通过 Presto、SparkSQL 等工具对外提供离线报表和数据分析功能。

这种典型的云原生架构为小红书的数据处理提供了高度的灵活性和可扩展性。然而，在此架构体系中，实时 OLAP 引擎的缺失限制了小红书数据分析业务的发展；亟需引入拥有强大分析性能的实时 OLAP 引擎，以满足不断增长的数据分析需求。

ClickHouse 作为一款高性能的实时 OLAP 数据库，以其出色的极致性能、快速稳定的更新迭代、积极响应的开源社区等优势，受到各大公司的青睐。为了实现更快速的查询和分析，小红书数据流团队为公司的实验平台构建了 ClickHouse 集群。

1.2 面临的问题

在初期阶段 ClickHouse 展示了出色的性能，具备极快的查询响应速度，提供了灵活性和实时性，为小红书的数据分析服务提供了更强大的 Ad-Hoc 分析能力。但随着数据的累积，集群规模不断膨胀，现有的实时 OLAP 系统在使用中遇到以下问题：

● 弹性扩展困难

随着小红书业务的快速发展，扩容成为团队频繁进行的运维操作。ClickHouse 采用 Share-Nothing 架构， 每个节点的计算和存储资源强绑定，导致集群扩容受限于机器的调度周期。同时，扩容过程中会引入以周甚至以月为单位的数据迁移工作，对用户的查询产生影响，包括稳定性和一致性问题。

● 资源利用率低

ClickHouse 通过多副本机制来提高整体的可靠性，但也导致资源几何倍增。由于存储和计算比例失调， 在大多数场景下，数据存储量的需求远大于计算需求，却因为存算绑定而造成算力严重浪费。此外，许多业务存在明显的波峰和波谷，缺乏弹性扩展能力导致严重的资源冗余。

● 稳定性问题

ClickHouse 在资源隔离能力方面较弱，容易引发用户查询体验的不稳定性问题。在查询高峰期，资源紧张会导致查询失败率和查询时延显著增加。另外，ClickHouse 的多副本机制重度依赖 Zookeeper，当集群规模达到一定程度时，Zookeeper 的故障频率增高，限制了集群的扩展能力。

● 数据同步问题

ClickHouse 一直被用户诟病的问题就是缺乏成熟的分布式事务系统，数据同步时经常出现数据不一致的现象。

● 可维护性问题<