别了磁盘：ClickHouse Cloud 中无状态计算背后的架构

Meetup 活动

ClickHouse 北京第三届 Meetup 火热报名中，详见文末海报！

TL;DR

ClickHouse Cloud 的计算层现已实现完全无状态。本文将介绍实现这一突破的最后一环：一个由共享目录（Shared Catalog）驱动的全新内存数据库引擎，彻底消除了对本地磁盘的依赖。

我们将带你回顾这一演进过程，了解共享目录带来了哪些新能力，以及它如何支撑对任何数据源的无状态计算，甚至包括数据湖。

无状态计算，全面实现

ClickHouse Cloud 现在彻底告别了磁盘。计算节点不再存储任何本地数据，无需同步，无需预热。只需极速启动，执行查询，计算节点便可立刻销毁，真正实现了弹性、无状态的计算。

这不再是概念验证，而是当下的现实。

自 2022 年 10 月 ClickHouse Cloud 上线以来，我们持续致力于从计算层彻底剥离本地状态。本文将带你逐步回顾这一历程，看看我们如何一步步实现完全无状态的计算架构。

最后的关键拼图是共享目录，它实现了数据库元数据与磁盘的解耦。

这一突破带来了诸多立竿见影的好处，稍后我们将一一详述：

• 新的 DDL 能力，包括原子性的 INSERT … SELECT、跨数据库重命名、以及 UNDROP

• 无需依赖活跃计算节点的高可靠 DROP 操作

• 为极速、零预热的资源调度而生，奠定了低延迟的横向扩展、纵向扩展及快速唤醒的基础

• 支持原生及开放格式的数据，如 Iceberg 和 Delta Lake，实现无状态计算

这正是如今支撑 ClickHouse Cloud 部署的核心架构。

让我们从起点讲起：那时，一切数据都还存储在本地的节点上。

第 0 阶段：ClickHouse 的起点

ClickHouse 最初采用的是经典的 shared-nothing（无共享）架构，计算与存储紧密耦合。每台服务器在本地磁盘上存储并访问自身数据，依靠分片来实现横向扩展。

下图展示了在这种架构下，查询是如何被处理的。

在接下来的内容中，随着我们一步步介绍架构的演变，这张图也会不断调整，直到最终呈现出完全无状态、云原生的形态。

① DDL 语句与目录查询：由 Atomic 数据库引擎负责

在 ClickHouse 的早期版本中，DDL 语句以及像 SHOW TABLES、SHOW CREATE TABLE 这样的元数据查询，都是通过 Atomic 数据库引擎来处理的。从 20.10 版本开始，Atomic 替代了此前的 Ordinary 引擎，成为默认选项。

Atomic 为每张表分配一个持久的 UUID，实现了数据与表名的解耦，确保 DDL 操作的安全性与原子性。它会将所有元数据（以 .sql 文件形式保存）存储在本地磁盘，使得每个计算节点都与持久化状态紧密绑定。

（图中未展示：在集群模式下，CREATE、DROP、ALTER、RENAME 等 DDL 语句可以通过 ON CLUSTER 子句广播，由 Keeper 协调。该机制通过将 DDL 命令追加到 DDL 日志或队列中来实现，但不依赖具体的数据库引擎。不过，Keeper 不会保存完整的元数据状态，因此当新节点加入时，并不知道此前发生的变化，需通过手动操作来恢复表结构。）

这种方案在小型集群中运作良好，但在需要动态扩展时就变得困难。为了实现真正的无状态计算，我们必须去除对本地存储的依赖。

② 数据存储：由 MergeTree 表引擎负责

所有与表数据相关的操作（如插入、删除、更新）都由 MergeTree 系列表引擎来处理。该引擎将磁盘上的数据组织为一组不可变的数据部分。

ReplicatedMergeTree 表引擎通过 Keeper 中的复制日志实现数据的自动复制，从而支持高可用性。

③ 内存中的查询执行：依赖操作系统的页面缓存

在执行 SQL SELECT 查询时，所有所需数据都会在内存中完成处理。如果数据尚未被缓存，系统会从本地磁盘读取，并自动加载到操作系统的页面缓存。随后，数据流入查询引擎，借助 CPU 与内存带宽，通过高度并行的方式完成处理，以实现最佳性能。

这种架构设计在单节点或小集群环境下运作良好，但元数据与数据都依赖本地磁盘的紧耦合模式，在云环境中反而成了瓶颈。要突破这一限制、实现无状态计算，我们必须彻底重构 ClickHouse 在各层面对元数据与数据的管理方式。

不过在深入讲解之前，我们需要先澄清一个贯穿全篇、至关重要的基础概念。

如何管理元数据与数据

在深入了解 ClickHouse Cloud 无状态计算的演进之前，有必要先澄清一个关键概念：数据库引擎与表引擎的分离。

• 数据库引擎负责管理数据库及表的定义，处理诸如 CREATE、DROP、RENAME 等 DDL 操作，以及支持 SHOW TABLES 等元数据查询。在集群环境下，不同数据库引擎还支持将 DDL 变更同步到多个节点。

• 表引擎则负责表的实际数据：数据如何存储、索引、读取与写入，涵盖 INSERT、DELETE、UPDATE 等操作，并负责对本地或远程存储的访问。

将元数据管理与数据存储解耦，能够在每一层实现更高的灵活性、可扩展性与专用优化。这种架构正是 ClickHouse Cloud 的核心，尤其在迈向无状态计算的过程中至关重要。

正如我们即将看到的，完全无状态的计算需要在这两个层面同时创新：表引擎负责数据解耦，数据库引擎负责元数据解耦。

接下来，让我们通过逐步拆解数据、缓存与元数据的演进过程，一探究竟。

阶段 1：借助 SharedMergeTree 解耦数据

迈向无状态计算的第一步，是将数据存储与计算彻底分离。这一步始于 SharedMergeTree —— 面向对象存储的表引擎，以及 Replicated —— 简化初始化流程的数据库引擎。

各层的功能如下：

① DDL 语句与目录查询：由 Replicated 数据库引擎负责

将存储与计算分离后，两者可以独立扩展。为了支持 ClickHouse Cloud 的弹性计算（节点可随时增删或替换），我们在 21.3 版本引入了全新的数据库引擎 Replicated。该引擎最初作为实验性功能推出，后经不断打磨，最终成熟应用于云环境。

Replicated 延续了 Atomic 引擎的思路，仍然将元数据以 .sql 文件形式保存在本地。但同时，它通过 Keeper 中的 DDL 日志，将 CREATE、DROP、RENAME 等元数据变更自动复制到所有节点，且不再依赖 ON CLUSTER 子句。

（注：为简化展示，图中未绘出 Keeper 中用于复制元数据变更的 DDL 日志。此外，表元数据也会缓存到本地磁盘，而访问过的表与数据库元数据则通过操作系统页面缓存透明地缓存在内存中，提升访问效率。）

与早期那种简单、长度受限的 DDL 日志机制不同，Replicated 能够在 Keeper 中记录每个数据库的完整元数据状态，使新节点能基于已有数据库实现全自动的自举，无需额外手动配置。

② 表元数据访问：由 SharedMergeTree 表引擎提供

通过 SharedMergeTree，表存储与计算彻底解耦。该引擎通过 Keeper 中的元数据层，协调对共享对象存储的访问，记录每张表有哪些数据部分及对应文件在对象存储中的位置。

里程碑：ClickHouse Cloud 初上线时，使用的是 ReplicatedMergeTree。之后所有新服务都切换到了 SharedMergeTree。时至今日，所有旧服务也已完成迁移，共享存储成为全线标准。

③ 共享表数据：存储在对象存储中

借助 SharedMergeTree，表数据不再依附本地磁盘，而是直接存放在持久、容量几乎无限的共享对象存储中，任何计算节点均可访问。这样不仅实现了弹性扩展与故障容错，也简化了运维流程，计算节点无需再维护本地数据副本。

幕后技术：为了达到 ClickHouse 的性能标准，我们在对象存储的读取上做了大量优化。系统支持激进的重试，将大对象切分成并行处理的块，多线程读取，并结合异步预取，全方位提升吞吐量与稳定性。（关于读取优化的细节，推荐演讲《Reading from object storage 100× faster》[https://youtu.be/gA5U6RZOH_o?si=uBS9EY_Q4VXSyVhw]。）

④ 查询加速：借助文件系统缓存降低对象存储延迟

对象存储虽然具备持久性和扩展性，但访问延迟较高。为此，ClickHouse Cloud 引入了本地文件系统缓存：从对象存储流入的数据会被本地缓存，便于后续复用。文件系统缓存与操作系统页面缓存协同，确保重复查询能以接近内存的速度执行。

⑤ 查询执行：依托操作系统页面缓存，在内存中并行处理

与传统的 shared-nothing 服务器类似，ClickHouse Cloud 将查询数据全程在内存中处理，数据通过操作系统页面缓存流入查询引擎，实现快速、并行的执行。

不过，本地文件系统缓存虽能加速重复查询，但仅对发起该查询的同一计算节点有效。面对弹性计算的需求，这种单节点缓存机制已无法满足。

第 2 阶段：通过分布式缓存实现缓存解耦

将热点数据缓存得更靠近查询引擎，是加速分析任务最有效的手段之一。但在 ClickHouse Cloud 中，缓存一直是本地化的，绑定在特定的计算节点上。为了让缓存具备云原生的弹性特性，我们决定更进一步，于是开发了分布式缓存。

下图展示了分布式缓存在 ClickHouse Cloud 架构中的位置。它将热点数据从计算节点中解耦，实现了所有节点对缓存数据的即时访问。

为了帮助理解每个阶段的变化，图中新增的组件会以全彩显示，已经介绍过的部分则以暗色呈现。随着架构的不断演进，这种呈现方式也会延续下去。

① 共享热点数据：存储在分布式缓存服务中

分布式缓存是一个共享的网络服务，专门的缓存节点会存储已经访问过的表数据。计算节点可以并行从缓存中获取所需数据，从而规避对象存储的访问延迟，同时让先前缓存的数据即使在不同的计算节点间也能被快速复用。

② 内存中执行：用户态页面缓存全面加速

本地内存始终是速度最快的存储层，因此将热点数据缓存于内存对查询性能至关重要。由于 ClickHouse Cloud 的计算节点已不再依赖本地磁盘进行缓存，也就无法使用操作系统自带的页面缓存。为此，我们引入了用户态页面缓存（userspace page cache），这是一个基于内存的缓存层，专门用于存储从分布式缓存中读取的数据。

虽然热点数据缓存已经与计算节点完全解耦，但系统仍存在最后一处依赖：数据库元数据依然保存在本地磁盘上。要真正实现无状态的架构，我们还需要对这一部分进行彻底的重构。

第 3 阶段：通过共享目录（Shared Catalog）解耦元数据

Replicated 数据库引擎让 ClickHouse Cloud 更易于弹性地添加或替换计算节点，节点可以自动引导，掌握数据库中已存在的表。但它仍然距离“真正的云原生”存在不足：

• 依赖本地磁盘与手动编排：元数据存储在本地文件系统，且每个节点都需提前创建数据库。

• 故障恢复脆弱：一旦节点崩溃，容易遗留孤立或不一致的元数据。

• DDL 扩展性不足：如 DROP 操作要求所有节点在线，跨数据库的 RENAME、原子性的 INSERT … SELECT 等特性也难以完善实现，因此当时并未支持。

因此，正如我们当初为 SharedMergeTree 表引擎所做的那样，我们重新设计了一套全新的云原生、无状态的 Shared 数据库引擎，并以共享目录（Shared Catalog）作为核心支撑。

在深入探讨 Shared 数据库引擎及目录的工作原理之前，先看下图，了解它们如何融入整体架构：这一演进彻底解耦了数据库元数据与本地磁盘，真正让计算节点变得无状态：

Shared 数据库引擎仍负责 ① 处理所有 DDL 语句与目录查询，不过如今它依托的是 Shared Catalog，而不再依赖本地文件。

这种架构转型确立了 Shared 引擎的又一核心理念：完全无状态、无磁盘的计算。

真正实现无状态：不需要磁盘，也没有问题

在旧的 Replicated 引擎下，数据库元数据是计算节点仍需本地磁盘的最后原因。而新的 Shared 数据库引擎完全消除了这层依赖：它是一个纯内存引擎。这样一来，计算节点只需具备 CPU 与内存，不再需要磁盘。

集中式元数据：在 Keeper 中复制与版本化

Shared 数据库引擎会将所有数据库及表的定义统一存储在以 Keeper 支持的中央 Shared Catalog 中。不再写入本地磁盘，而是维护一个全局的版本化状态，供所有计算节点共享。

每个节点只需跟踪上一次应用的版本，启动时就能直接拉取最新状态，不需要本地文件，也不需额外手动配置，便能快速、一致地完成引导。

（尽管图中未展示，元数据实际上也会自动缓存在内存中，以加速 SHOW TABLES 或 DESCRIBE 这样的元数据查询。我们将在后文的“架构实战”动画环节中再详细介绍。）

通过这一架构变革，ClickHouse Cloud 的计算层终于实现了真正的无状态。而这种变革带来的价值，远不止“无磁盘引导”这么简单。

共享目录（Shared Catalog）带来了哪些能力

随着元数据实现了集中化与版本化，我们也重新设计了 DDL 在云规模下的工作机制。最终，我们构建出一种全新的协调与对象生命周期模型，解锁了以下能力：

• 云规模的 DDL 协调，即便在高并发场景下也能稳定应对

• 更加稳健的删除操作，以及全新的 DDL 功能

• 无状态节点不再依赖磁盘，实现极速启动与唤醒

• 支持原生及开放格式（如 Iceberg 和 Delta Lake）的无状态计算

接下来，我们将逐一拆解这些能力的实现方式。

温馨提示：从这里开始将进入技术深水区

接下来的两节内容将深入讲解共享数据库引擎与共享目录的底层原理，涉及协调机制、一致性保证，以及我们遇到的各种复杂边界情况。

如果你对这些底层“魔法”的运作机制感兴趣，不妨继续阅读，绝对值得一探究竟！如果你只是关注高层结论，可以直接跳到后文，我们完全理解。

通过细粒度协调，实现云规模的 DDL

首先解锁的能力，是实现云规模的 DDL 协调，即使在高并发、节点频繁变动的环境下，也能稳定一致。

面临的挑战：如何在多节点间实现元数据的快速一致协调

在云环境中，不同客户端可能同时向不同计算节点发送 DDL 命令。系统需要确保，不论是现有节点，还是扩缩容过程中新加入的节点，都能拥有一致的全局元数据视图。这样的协调机制，既要“快”，也必须支持“高并发”。

一种直接但笨重的方案是引入全局锁：哪个节点先获得锁，就先同步最新的元数据状态，避免与其他节点产生冲突（比如刚被其他节点删除的数据库又被重命名）。变更应用后再释放锁。这种方式虽可保证正确性，但会将所有 DDL 串行化，既不高效，也难以同时兼顾速度与并发性。

选择性失效：一种更智能的解决方案

相比全局锁，我们选择了更聪明的方法：每类 DDL 命令只会让与其可能产生冲突的、并发发起的其他 DDL 命令暂时失效，直到这些节点拉取并应用了最新的全局状态。

Keeper 如何保障并发下的正确性

共享目录通过 Keeper 的共识算法来实现这一机制，该算法保证所有写入操作的线性一致性。每个计算节点会将自己的 DDL 变更作为一个 multi-write（多操作）事务提交。Keeper 会确保某个节点的事务先被应用。如果后续有其他节点提交了与之冲突的变更请求，因为它引用的对象版本已经过期，其多操作事务就会被拒绝。此时，节点会先同步最新的全局状态，再重新尝试应用变更。这种机制，既保障了全局一致性，又不会牺牲并发性能。

架构实战

下方的动画简要展示了我们的架构方案。它演示了共享目录（Shared Catalog）在 Keeper 中的全局状态。该状态由 Keeper 中的三个核心节点组成：

• /uuids：映射 UUID 与对象的元数据（如 CREATE 查询、版本信息）

• /names：将对象名称映射到对应 UUID，便于查找与重命名

• /replicas：记录每个计算节点应用的最新元数据版本

全局数据库元数据的版本由 /uuids 节点的 Znode-version 决定，它是系统的唯一可信源。

在共享目录之上，可以看到三个计算节点，每个都维护着本地的内存数据库元数据。这些节点通过 Keeper 的 watch 通知机制订阅目录的变化，实时保持同步。

① 节点 3 接收到 DDL 命令并开始执行

节点 3 收到了一个 DDL 命令，在数据库 db2 中创建表 tbl。该表中有一列 val，定义了一个 DEFAULT 表达式，插入时会通过 db1 中已有的 dic 字典进行查找计算。

为完成这个操作，节点 3 的 DDL 执行线程向 Keeper 发送了一个 multi-request（多操作请求），包含以下步骤：

• ② 校验依赖：检查所需的所有对象（db1、dic、db2）是否存在且版本匹配。如果其他节点刚好对这些对象执行了重命名或删除操作，版本校验会失败，系统会将错误返回给用户。但与此同时，节点会在后台自动同步最新元数据，这样当用户重试时，操作就能顺利执行。

• ③ 版本递增：每个依赖对象的版本号都会递增，起到细粒度锁的作用。只有被本次 DDL 命令影响的对象版本会更新，其他未涉及的全局状态保持不变。若其他节点尝试修改相同对象，将会因版本不一致而中止操作，从而实现并发安全。

• ④ 应用变更：新建表 tbl 的元数据信息被写入全局状态，全局元数据版本也随之递增（比如从 5 增至 6），并通过 Keeper 的 watch 通知机制告知其他所有节点。

⑤ 后台线程自动同步所有计算节点的状态

每个计算节点都有后台线程监听 Keeper 的版本变化。一旦发现全局元数据版本更新（如从 5 到 6），节点会：

• 从 Keeper 拉取最新的元数据

• 将更新合并到本地内存

• 在 Keeper 的 /replicas 节点更新自己的版本号，表明状态已同步

本例中，发起变更的是节点 3，因此它只需更新版本标记，无需合并变更。

确保 DDL 跨节点一致可见：通过 distributed_ddl_output_mode 参数，可以控制 DDL 执行线程在完成变更（步骤④）后是否等待所有（或所有活跃）计算节点都完成最终的本地同步（步骤⑤）再向客户端返回成功。最大等待时间由 distributed_ddl_task_timeout 参数限定[https://clickhouse.com/docs/operations/settings/settings#distributed_ddl_task_timeout]。

为了简化，步骤④中省略了部分内部机制。实际上，每个对象都会经历生命周期的多个阶段，例如从“准备创建”到“已创建”，这些状态记录在对象的 stage 字段中（动画中已有简单展示）。在接下来的章节里，我们将深入讲解这种分阶段设计的意义，以及它带来的更多能力。

通过分阶段的元数据生命周期，实现可靠的删除与 DDL

Shared 数据库引擎引入了分阶段对象生命周期（staged object lifecycle），这是一种全新的内部机制，能够显式跟踪每个对象的状态。这项设计解决了旧引擎在可靠删除、数据恢复以及跨对象一致性上的顽疾——这些问题都源于计算与元数据的紧耦合。

先来说删除。在早期的引擎中，删除操作严重依赖节点的存活状态：

• MergeTree 表引擎：执行 DROP 命令的节点会立即删除数据，因为数据就存储在本地磁盘。

• SharedMergeTree 表引擎：在多节点配合共享存储的场景下，最后一个同步到 DROP 操作的节点负责删除数据。利用共享存储的特性，这延迟机制确保只有当所有节点都不再需要数据时，才会实际删除。

然而，在计算与计算分离的部署中，这套机制就显得非常脆弱。比如，一个服务发起了 DROP 操作，虽然该服务逻辑上不再“看到”这张表，但实际的物理删除要等到所有节点都确认。如果有任何一个节点或服务处于空闲或卡顿状态，删除操作就会被阻塞，有时甚至会拖延数周。

分阶段的生命周期设计彻底解决了这个痛点：删除操作不再依赖节点的即时响应，而是通过独立的后台线程异步处理，且对生命周期有严格管理。下面，我们来看看具体的生命周期机制。

理解对象的生命周期

在 Shared Catalog 中，每个对象都会经历几个定义清晰的阶段。这些阶段记录在对象的 stage 字段里（如前文“架构实战”动画所示），保证对象从创建到删除的每一步都安全、可控：

① INTENTION：准备创建

这是所有对象的起始阶段。比如执行 CREATE TABLE 命令时，DDL 执行线程会将新表的元数据（如 create_query 语句）写入 Keeper，同时将对象的阶段标记为 INTENTION。此时，表实际上还未真正创建。

• 如果创建成功，阶段会更新为 ② CREATED。

• 如果失败，阶段会直接转为 ④ DROP_IN_PROGRESS，并清理相关元数据。

避免孤立元数据：如果 DDL 线程在执行过程中崩溃（比如节点宕机或 Keeper 连接中断），对象就会停留在 INTENTION 阶段。为此，系统设计了独立的后台清理线程，专门监控这种情况，一旦发现元数据长时间滞留在此阶段，就会自动清除。

通过这种机制，Shared 数据库引擎有效避免了孤立元数据的遗留，彻底解决了 Replicated 数据库引擎中孤立条目可能长期残留在 Keeper 的问题。

② CREATED：对象已激活

在对象成功创建后，它会进入 CREATED 阶段，这是元数据对象的正常、活跃状态。

• 执行 DETACH 命令，对象会被移动到 ⑤ DETACHED 阶段；而 ATTACH 命令会让对象回到 CREATED。

• 如果执行 DROP，对象会进入 ③ DROP_SCHEDULED 阶段，删除会异步处理。而执行 UNDROP 则可以让对象回到 CREATED（详见下文）。

③ DROP_SCHEDULED：软删除，宽限期内保留

此阶段，对象（如表）已对所有计算节点不可见，逻辑上被视为删除。

• 经过一个可配置的宽限时间（例如 8 小时）后，系统会启动一个独立于计算节点的后台删除线程，物理清理对象的数据。

• 这种延迟机制让表在宽限期内仍可安全地通过 UNDROP 恢复，因为元数据和数据都尚未被删除。只要恢复成功，对象就会回到 ② CREATED 阶段。

彻底解耦的删除机制：整个删除过程不再依赖某个特定计算节点，避免了旧引擎中节点存活状态对删除可靠性的影响。

④ DROP_IN_PROGRESS：最终删除中

一旦进入这个阶段，就意味着彻底删除已启动，不可逆转。后台删除线程会依次清除对象：先删除对象存储中的数据，再移除 Keeper 中的元数据。

生命周期阶段赋能的全新 DDL 操作

得益于这一分阶段的模型，许多过去难以实现或容易出错的 DDL 操作，如今都可以实现得干净、可靠。

UNDROP:

处于 DROP_SCHEDULED 阶段的表，只要元数据和数据仍在，就可以安全地恢复。

原子性的 CREATE TABLE AS SELECT (CTAS):

过去 CTAS 若 SELECT 查询失败，可能会残留部分创建的表。现在流程变得严谨：

• 表先处于 INTENTION 阶段

• 然后填充数据

• 若成功，阶段晋升为 CREATED

• 若失败，直接转入 DROP_IN_PROGRESS 丢弃

这样就实现了真正的全有或全无（all-or-nothing）语义，无需人工清理半成品表。

跨数据库 RENAME

早期的引擎因元数据分散在不同数据库的日志中，导致跨库操作难以协调。Shared Catalog 通过 Keeper 支持的单一元数据源及 multi-write（多写）事务，轻松解决了这一挑战。

所有这些能力，背后都有同一保障：生命周期感知的元数据，确保了对象状态转换的可靠与一致，哪怕工作负载再复杂、再分布式也不例外。

当然，生命周期协调只是 Shared Catalog 的一部分优势。它还打通了即时资源调度的最后一环，让计算节点的启动速度突破了以往极限。

为极速而生的资源调度，并持续提速

自 ClickHouse Cloud 诞生以来，降低启动延迟始终是我们努力的方向。本次发布为彻底解决这一难题奠定了基础。有了 Shared Catalog，计算节点不再依赖本地磁盘或手动配置。节点可以在任何位置快速启动，无需同步磁盘数据，真正实现轻量、敏捷的调度。

跨原生与开放格式的无状态计算

Shared Catalog 的作用远不止管理内部元数据。它还支撑了如 DataLakeCatalog 这样的集成数据库引擎，使无状态计算节点可以无缝对接外部目录，如 Hive、AWS Glue、Unity、Polaris 等。借助这些集成，ClickHouse 可以直接列出并查询如 Iceberg、Delta Lake 等开放表格式。

原生表上的性能加速机制，同样适用于数据湖查询：

① Shared Catalog 支撑无缝访问外部表的元数据② 分布式缓存加速远程对象存储中的冷数据读取③ 用户态页面缓存保障 ④ 高度并行、内存中的查询执行

这些性能优化层，原先为原生表设计，如今同样为数据湖查询提速。ClickHouse Cloud 的计算节点已随时准备好，立即查询任何类型的数据。无论是你自建的 MergeTree 表，还是外部的 Iceberg 或 Delta Lake 表，底层的引擎与执行路径都保持一致。

未来之路

Shared Catalog 是无状态架构的最后一块拼图。有了它，我们不仅完整实现了无状态计算，还在架构层面取得了全面突破：

• 弹性：无需预热，支持无磁盘依赖的横向与纵向弹性扩展，计算节点可随时随地启动

• 韧性：即便计算节点宕机，DROP 操作也能稳定、干净地完成

• 正确性：如 INSERT … SELECT、UNDROP、跨数据库 RENAME 等原子性 DDL 操作，均可确保成功或自动回滚

• 开放性：无状态计算全面支持原生表及如 Iceberg、Delta Lake 等开放格式

无状态计算，全面达成。

而我们，才刚刚起步。

想象一下，一个由无状态计算节点组成的“计算集群”，可以随需随启，瞬间加速你的查询。又或者，体验真正的**无服务器（Serverless）**形态，根本无需关心集群、机器的存在，只需发起查询，便能快速获得结果。

这正是我们的目标。有了 Shared Catalog 打下的坚实基础，我们已经准备好，迈入无状态计算的全新篇章。敬请期待。

Meetup 活动报名通知

好消息：ClickHouse Beijing User Group 第 3 届 Meetup 火热报名中，将于 2025 年 09 月 20 日在北京海淀永泰福朋喜来登酒店（北京市海淀区远大路 25 号 1 座）举行，扫码免费报名

/END/

征稿启示

面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出 &图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com。