在 ClickHouse 中瞬时克隆超大数据表并安全实验

转载声明原文标题：Clone massive tables instantly and experiment safely in ClickHouse原始 Markdown 来源：table-cloning.md原文发布时间：2026-02-24原作者：Tom Schreiber（ClickHouse）本文为中文翻译与整理，技术细节以原文为准。在 ClickHouse 中瞬时克隆超大数据表并安全实验 TL;DR CREATE TABLE staging CLONE AS prod; 可以在不复制任何数据字节的情况下，瞬间创建一个克隆表。它有点像给数据表做一次 Git fork：初始状态完全一致，写入后才分叉（copy-on-write），非常适合做破坏性测试。一种安全做实验的方法 {#a_safe_way_to_experiment} 你在生产环境里有一张非常大的 ClickHouse 表。现在你想在预发环境里测试一些“有破坏性”的改动：删除、更新、改 schema，甚至更激进的优化。但你绝对不想碰到生产数据。如果你能把这张超大表“瞬间”复制出一份完全一致的副本，而且可以反复做，还能随意测试所有破坏性变更，同时不影响生产数据，并且不复制任何一个字节，是不是很理想？在 ClickHouse 里，这件事可以做到。这个能力看起来像魔法，但它其实是 ClickHouse 存储模型的一个非常自然、非常干净的结果。虽然这个特性在文档里已经有说明（文档链接），但在真实使用中它仍然被低估。在 ClickHouse Cloud 里，这个模式还能更进一步。你可以克隆生产表，然后放到隔离计算资源的独立服务上做测试。这篇文章会深入解释表克隆在底层是怎么工作的，以及“不可变数据 part”为什么能让它成立。想先看快速讲解？ Mark 录了一段简短视频：视频讲解（YouTube）回顾：不可变 data part 模型 {#reminder_the_immutable_data_part_model} 在 ClickHouse 中，每次向一张表插入数据，都会在磁盘上生成一个新的、独立的、不可变的 data part。下面用一个 orders 表举例，记录每个客户的订单总额：CREATE TABLE orders ( order_id UInt32, customer String, total UInt32 ) ENGINE = MergeTree ORDER BY order_id; 执行下面这次插入：INSERT INTO orders VALUES (1001, 'Liam', 31000), (1002, 'Ben', 7500), (1003, 'Anna', 12000); ClickHouse 会在磁盘上创建一个新的 part：在底层，这个 part 是磁盘上的一个目录，里面包含按列存储的压缩列文件，每列一个文件（例如 order_id、customer、total）。part 内的行会按照表的排序键（这里是 order_id）进行物理排序。 Data part 是自包含的：它内部携带了解析数据所需的全部元信息，不依赖中心化 catalog。上图没有画出的是，part 还会包含很多元文件，比如稀疏主键索引、二级 data skipping 索引、列统计、校验和、分区场景下的 min-max 索引等。随着新数据到来，ClickHouse 从不原地修改已有 part，而是始终写入新 part。后台会执行 merge 把多个 part 合并成更大的 part，以控制 part 数量并做数据整合；但 merge 本身也会产出全新的 part。（这种设计也解释了 ClickHouse 为什么能有很高的写入吞吐：不同写入可并行生成独立 part，再在后台 consolidate。）同样地，删除数据……DELETE FROM orders WHERE order_id = 1001; ……或者更新数据……UPDATE orders SET total = 3600 WHERE order_id = 36043; ……在实现上（参考）都是：找到受影响行所在的 part，写一个应用修改后的新 part（或 part fragment），再在后续流程中移除旧 part。这种严格不可变性，正是“零拷贝瞬时克隆表”能够实现的核心前提。从不可变 part 到瞬时克隆 {#from_immutable_parts_to_instant_clones} 当你执行：CREATE TABLE staging CLONE AS production; ClickHouse 并不会复制生产表数据。不复制数据因为 data part 是不可变…