数据仓库建模：ClickHouse MergeTree系列

可视化演示

存储引擎基础

图书馆开门营业前，要先定规矩：新书一律送到导流台，由工作人员按分类捆成小包，再交给管理员上架。ClickHouse 的世界里，这个「导流台规矩」就是 MergeTree 表引擎——它规定了数据进门后如何被对待：不覆盖旧书、不原地改，而是把新来的数据打包成一个个不可变的「小捆」，也就是 data part。

每个 data part 是磁盘上一个自包含的目录，里面有列数据文件、索引文件和元数据。你可以把它理解为一捆书：里面所有书都按同一套规则排好序，并且这捆书一旦捆好就不再拆开。新增数据永远产生新的小 part，旧 part 原封不动。这一设计的核心奥妙在于：写入变成了「只追加」，省去了随机写和行级锁的开销，天然适合海量日志、指标这类持续涌入的数据。

在存储层面，MergeTree 表的物理布局大致为：表目录下先按分区键拆成多个分区目录，每个分区目录下再挂多个 part 子目录。每次 INSERT 至少生成一个 part，后台再慢慢把这些 part 合并更大、更有序的 part。

一句话理解：MergeTree 表就是一堆不可变数据块（part）的集合；新数据只追加，合并交给后台。

排序键与主键

图书馆最怕的事，是读者要一本「数据库入门」，管理员却要从一楼找到顶楼。MergeTree 的解法很朴素：在把数据捆进 part 时，就按读者最常找的字段排好序。这个「最常找的字段」就是排序键（ORDER BY）。一本书在书架上的位置由它决定，数据行在 part 内部的物理顺序也由它决定。

但数据量动辄上亿行，就算有序，也不能逐行扫描。MergeTree 的做法是画一张「目录卡」：每 8192 行分成一个 granule（数据颗粒），索引文件只记录每个 granule 第一行的排序键值。这就是稀疏索引——它不精确到每一行，而是像一个「每排书架只记第一本书书名」的目录。查询时先在目录卡上二分查找，确定目标大概率落在哪几个 granule，再读取这几个数据块。

主键（PRIMARY KEY）这里要特别注意：它不等于 MySQL 里的主键，不保证唯一性。MergeTree 中主键只是排序键的一个前缀，专门用来构建稀疏索引。实际建表时，ORDER BY 是必备的，主键字段可以省略（默认沿用 ORDER BY）。选对了排序键，等值查询、范围查询都能走索引快速跳过大量数据。

数据在 part 内按排序键有序排列，每 index_granularity 行生成一条稀疏索引记录，指向对应数据块的起始行。

分区机制

大图书馆还有一个聪明的设计：按楼层分区。一楼是文学，二楼是科技，三楼是历史。新书进来先看类别送到对应楼层，读者要找计算机书时直奔二楼，绝不去一楼瞎逛。MergeTree 的分区（PARTITION BY）就是给数据盖「楼层标签」，按分区键的值将数据拆进不同目录。

在磁盘上，每个分区对应一个形如 202410_1_3_0 的目录名，由四个部分组成：分区 ID、最小块编号、最大块编号和合并层级。这个命名规则像图书馆的「楼层-区域-批次」编码，让人一眼看出这堆数据属于哪个时间范围、经历了多少次合并。分区键可以是日期、整数或任意表达式，最常用的是 toYYYYMM(date) 按月份分区。

分区最大的价值是分区裁剪：查询 WHERE 条件带分区键时，ClickHouse 直接从元数据层跳过无关分区目录，只扫描命中的分区。这相当于读者在图书馆门口先刷楼层门禁，根本不用进那些不相关的楼层。注意：分区和排序键是两个维度——分区决定「数据落在哪层楼」，排序键决定「楼里的书怎么排」。

part 目录名携带分区 ID 与块编号范围，ClickHouse 借此快速定位数据所属分区，并推断合并历史。

合并与突变

图书馆每天晚上闭馆后，管理员会做一件重要的事：把白天积攒的几十捆小书拆开，按统一排序规则合并成几捆大书，再插回书架。这个动作在 MergeTree 里叫后台合并。合并线程会定期扫描各分区下的 part，把多个小 part 读出、按排序键归并排序、写成一个更大的新 part，旧 part 随后被标记删除。

ClickHouse 的合并策略是分层的：新写入的小 part 属于 L0 层，合并后升到 L1、L2……层级越高 part 越大、数量越少。这有点像图书馆管理层级：先合并到「书籍区」再合并到「书架」。合并的好处显而易见：part 数量减少，查询要打开的文件少了，稀疏索引的覆盖范围更整齐，还能顺带压缩数据。

但「改动现有数据」就麻烦了。MergeTree 的设计哲学是数据不可变，所以 UPDATE 和 DELETE 不是同步逐行改，而是通过 Mutation（突变） 实现：后台把包含目标行的整个 part 重写一份，在重写过程中完成修改，再切换文件引用。这相当于管理员要把某本书的内容改了，必须把那捆书整个重新抄一遍，再换上新书捆。因此突变操作成本很高，尤其当目标行分散在大量 part 中时，写放大可能非常惊人。

合并是把多个小 part 归并排序成一个有序大 part；突变则是重写包含目标行的 part，二者都由后台异步完成。

性能优化

图书馆经营久了，总有一些「过期书」：去年的旧杂志、三年前的促销传单。馆长会在夜里安排管理员把这些书下架销毁——这就是 MergeTree 的 TTL（生存时间） 机制。建表时可以对某列或整表声明 TTL 表达式，到期后数据会被自动删除或移动到冷存储，既节省空间又让热数据查询更快。

除了 TTL，MergeTree 还提供了丰富的压缩编码：列式存储天然能让同类数据聚在一起，配合 LZ4、ZSTD 等压缩算法，以及 Delta、Gorilla 等专用编码，数值型数据的压缩比可以做到 5~10 倍甚至更高。这相当于把旧书换成了更薄的纸张，同样的书架能装下更多书。物化视图（Materialized View） 则是另一个省心工具：数据写入时自动触发聚合计算，把预聚合结果存成一张隐式表，查询高并发报表时不必现算。

最后一个关键调优点在索引：index_granularity 默认 8192，调大会减少索引体积但增加扫描粒度，调小则反之；还可以通过 INDEX 声明跳过索引（Skip Index），对高基数列做布隆过滤。优化的核心思想是：让「目录卡」更聪明、让「楼层」更合理、让「书页」更薄，三者配合才能榨干硬件性能。

TTL 为数据设定自动过期时间；压缩比衡量列存储的瘦身效果。两者共同目标是降低成本、提升热查询速度。

副本与分布式

当图书馆规模大到一座楼放不下时，馆长会开分馆。为了不让读者扑空，每个分馆都会存一份完整的藏书——这就是副本。MergeTree 的兄弟引擎 ReplicatedMergeTree 专门干这事：多台机器各存一份相同数据，任何一台挂了，读者还能从其他馆借到书。

副本同步的「总协调员」是 ZooKeeper（ZK）。所有分馆的元数据、part 清单、合并任务、突变版本都登记在 ZK 上。实际上，每个分馆的机器只负责在自己本地执行合并和写入，一旦本地产生了新 part，就向 ZK 注册，其他副本看到后异步拉取。数据文件本身由各副本直接传输，ZK 不扛数据流量——它只是那个「互通有无的公告栏」。

如果数据量大到单机放不下，则需要 分布式表。它本身不存数据，只是一个「查询路由器」：像图书馆的中央检索系统，把请求转发到后端多个本地 MergeTree 表，再汇总结果。注意区分：副本解决的是「可用性」（一馆挂掉还有别馆），分布式解决的是「扩展性」（数据多到需要分馆各存一部分）。两者可以叠加：先按分片拆到不同机器组，每组内部再用 ReplicatedMergeTree 做副本。

假设单副本故障率为 f，有 r 个副本时整体不可用概率约为 f 的 r 次方，副本数越多可用性越高，但 ZK 协调压力也越大。

AI 应用场景

Python 演示

""“模拟 ClickHouse MergeTree 的 part 合并与稀疏索引查找”""import random  class SparseIndex:    ""“稀疏索引：每 granularity 行记录一个索引条目”""     def init(self, granularity=2):        self.granularity = granularity        self.index = []     def build(self, sorted_data):        self.index = []        for i in range(0, len(sorted_data), self.granularity):            self.index.append(sorted_data[i])        return self.index     def search(self, sorted_data, key):        # 二分定位候选区间，再顺序扫描        lo, hi = 0, len(self.index) - 1        while lo < hi:            mid = (lo + hi) // 2            if self.index[mid] <= key:                lo = mid + 1            else:                hi = mid        start = max(0, (lo - 1) * self.granularity)        end = min(len(sorted_data), (lo + 1) * self.granularity + 1)        return [v for v in sorted_data[start:end] if v == key]  class MergeTreeSim:    ""“最小 MergeTree 模拟：写入小 part，后台合并为有序大 part”""     def init(self):        self.parts = []          # 每个元素是一个有序 list        self._count = 0          # 写入总行数     def insert(self, rows):        for row in rows:            self.parts.append([row])   # 每次写入一个 1 行小 part            self._count += 1        self._background_merge()     def _background_merge(self):        # 模拟后台合并：优先合并两个最小的 part        while len(self.parts) >= 2:            self.parts.sort(key=len)            a = self.parts.pop(0)            b = self.parts.pop(0)            merged = sorted(a + b)            self.parts.append(merged)            # 若最大 part 已超过阈值，本轮合并停止（模拟分段合并）            if len(self.parts[-1]) >= 8:                break     def query(self, key):        result = []        for part in self.parts:            idx = SparseIndex(granularity=2)            idx.build(part)            result.extend(idx.search(part, key))        return result  if name == "main":    random.seed(42)    mt = MergeTreeSim()    for _ in range(10):        mt.insert([random.randint(1, 50) for _ in range(3)])     print(“合并后 parts 数量：”, len(mt.parts))    print(“各 part 行数：”, [len(p) for p in mt.parts])    print(“查询 7 的结果：”, mt.query(7))     data = sorted(random.sample(range(1, 100), 10))    idx = SparseIndex(granularity=2)    index_entries = idx.build(data)    print(“\n排序数据：”, data)    print(“稀疏索引条目：”, index_entries)    print(“等值查找 42:”, idx.search(data, 42))

常见误区

面试题