ClickHouse MergeTree 原理深度解析：从存储结构到分布式机制

ClickHouse MergeTree 原理深度解析：从存储结构到分布式机制

声明：📝 作者：甜城瑞庄的核桃（ZMJ）
原创学习笔记，欢迎分享，但请保留作者信息及原文链接哦～

前言

在大数据分析领域，"查得快"始终是核心命题。传统数仓方案要么依赖 Hadoop 生态的复杂部署，要么依靠 MOLAP 的预聚合牺牲灵活性。ClickHouse 的出现打破了这一困局——它用列式存储 + 向量化执行在 ROLAP 模型上实现了接近 MOLAP 的查询性能，既保留了明细数据的灵活分析能力，又不依赖任何重量级生态。

本文是对《ClickHouse原理解析与应用实践》（朱凯 著）的系统性读书总结，整体章节结构尊重原文。由于原书出版于 2020 年，部分内容已随版本迭代有所变化，因此结合 ClickHouse 官方设计文档及社区 2024-2025 年最新实践做了补充修正。

系列说明：本文是 ClickHouse 系列的第二篇，以《ClickHouse 原理解析与应用实践》（朱凯 著）为框架，结合 2024-2025 年官方文档与社区最新实践，深度解析 MergeTree 存储结构、索引机制与分布式副本原理。如果你是第一次接触 ClickHouse，建议先阅读《ClickHouse 数据库入门指南》完成环境搭建和基础操作，再来阅读本文效果更佳。

一、书籍概览

作者简介：朱凯，ClickHouse 贡献者之一，资深架构师，腾讯云 TVP，公众号"ClickHouse的秘密基地"运营者。本书理论观点来自作者在 OLAP 领域 10 余年的工作思考与总结，原理解析部分来自对大量专业文献的钻研与源码级调试。

书籍定位：一本帮助读者深度理解 ClickHouse 运行原理并进行实践开发的工具书，既可作为 BI 新手的入门指南，也可作为中高级开发者的延伸读物。豆瓣评分 7.5，超六成读者给出 4 星及以上评价。

全书逻辑架构：

┌─────────────────────────────────────────────────────────────────┐ │ 《ClickHouse原理解析与应用实践》全书结构 │ ├──────────────────┬─────────────────┬──────────────────────────────┤ │ 第一部分·背景篇 │ 第二部分·基础篇 │ 第三部分·原理篇 │ │ （第1~2章） │ （第3~5章） │ （第6~11章） │ ├──────────────────┼─────────────────┼──────────────────────────────┤ │ 发展历程 │ 安装部署 │ MergeTree引擎原理 │ │ OLAP架构形态 │ 数据类型 │ 六大类表引擎 │ │ 八大核心特点 │ 数据表操作 │ 分布式与副本机制 │ │ ROLAP/MOLAP/HOLAP │ 视图与数据字典 │ 运维管理 │ └──────────────────┴─────────────────┴──────────────────────────────┘

全书共 11 章，约 270 页，采用浅显易懂的语言配合大量的演示案例和示意图例，力求让读者在最短时间内获得最核心的知识。

二、第一章：ClickHouse 的前世今生

2.1 传统 BI 系统之殇

在大量数据分析场景中，传统关系型数据库很快被 Hadoop 生态所取代。为了解决数据孤岛问题，人们提出了数据仓库的概念，即将分散的数据统一汇聚到一处。然而传统 BI 系统存在三大缺陷：

• 对企业信息化水平要求较高（通常只有中大型企业才有能力实施）
• 受众狭小（主要面向管理层或决策层）
• 研发过程冗长

2.2 现代 BI 系统的新思潮

现代 BI 系统在设计思路上发生了根本性变化：轻量化（即便根据简单的 Excel 文件也能进行数据分析）、受众多元化（人人都能做分析）、快速应答、简单易用。

2.3 OLAP 常见架构分类与工程取舍

OLAP 指的是通过多种不同的维度审视数据，进行深层次分析。基本操作包括：

上卷（Roll-up）：低层次 → 高层次汇聚（城市 → 省份 → 全国） 下钻（Drill-down）：高层次 → 明细数据穿透 切片/切块（Slice/Dice）：固定一个或多个维度进行观察 旋转（Pivot）：行列置换，换个视角看数据

常见 OLAP 架构三类，每类背后都有它选择存在、又选择消亡的工程原因：

为什么 Kylin 没能成为最终答案？

Kylin（Apache Kylin）曾经是大数据分析领域的明星产品，在 2014-2018 年间在各大公司落地。它通过提前构建 Cube（预聚合所有维度组合）实现毫秒级查询，但随着业务复杂度上升，工程团队发现了不可回避的瓶颈：

Kylin 维度爆炸问题示意： 维度数量 预计算 Cube 数量 存储膨胀率 5 维 2^5 = 32 可接受 10 维 2^10 = 1024 较高 15 维 2^15 = 32768 极高，构建时间以天计 20 维 2^20 > 100万 工程上已不可行

随着业务分析诉求增多（从 5 个维度扩展到 20 个），Kylin 方案的构建周期越来越长，新增指标需要等待数小时甚至数天的 Cube 重建，无法满足"今天上线需求、明天看数据"的敏捷迭代节奏。

2.4 ClickHouse 打破困局的技术本质

ClickHouse 横空出世，既使用 ROLAP 模型（面向明细数据），同时又拥有比肩 MOLAP 的查询性能——这个"不可能三角"是如何实现的？

答案在于：不是用空间换时间（MOLAP），而是让 CPU 和 I/O 配合得更高效。

┌──────────────────────────────────────────────────────────────────┐ │ ClickHouse 突破"不可能三角"的三把刀 │ │ │ │ 第1把刀：列式存储 │ │ 只读查询涉及的列 → I/O 减少 80%～95% │ │ 同列数据类型一致 → LZ4/ZSTD 压缩比达 5～10x │ │ │ │ 第2把刀：向量化执行引擎 │ │ SIMD 一次处理 8192 行 → 计算密集型操作速度提升 4～8x │ │ 避免逐行虚函数调用 → 减少 CPU 分支预测失败 │ │ │ │ 第3把刀：多核并行 + 数据本地化 │ │ 数据按 ORDER BY 物理排序 → 相关数据连续存放，缓存命中率高 │ │ 单机多线程 / 集群多节点同时扫描 → 线性扩展吞吐 │ └──────────────────────────────────────────────────────────────────┘

三把刀叠加的效果是：即便不做任何预聚合，在百亿行数据上的 GROUP BY 聚合也能在秒级完成，而 Presto（ROLAP）同样的查询可能需要几分钟，Kylin（MOLAP）则需要等待预计算完成才能给出结果。

OLAP 产品选型决策树（工程视角）：

需要查询的数据有多少维度？ ├── 维度 < 10，且维度变动极少 → Kylin（Cube 预聚合，极速点查） └── 维度 ≥ 10，或维度经常新增 → 继续判断 │ ▼ 是否需要全文检索 / 关键词搜索？ ├── 是 → Elasticsearch └── 否 → 继续判断 │ ▼ 数据量级和实时性要求？ ├── TB 级以内，延迟要求分钟以上 → Spark / Hive └── 百亿行以上，需要秒级响应 → ClickHouse ✅

三、第二章：ClickHouse 核心架构与特性归纳

ClickHouse 采用多主对等网络结构，避免了单点故障问题，适用多数据中心、异地多活的场景。

3.1 八大核心特性

3.2 不足与不适用的场景

ClickHouse 并非万能，以下场景需避免使用：

• 不支持事务：不适用于对 ACID 有强要求的业务（如支付、下单）
• 不擅长点查：不能当作 Key-Value 数据库使用，高并发点查性能差
• 不擅长按行删除数据：删除操作通过 Mutation 实现，代价高昂

架构选型建议：ClickHouse 的正确使用姿势是与 OLTP 数据库配合，而非替代。OLTP 负责写入和事务，ClickHouse 负责分析。

四、第三章：ClickHouse 的部署与工具

4.1 核心可执行文件

在/usr/bin路径下的主要可执行文件：

/usr/bin/ ├── clickhouse # 主程序的可执行文件 ├── clickhouse-client # 软链接，供客户端连接使用（CLI交互） ├── clickhouse-server # 软链接，供服务端启动使用 └── clickhouse-compressor # 内置压缩工具，可用于数据的正压反解

4.2 两个非常实用的内置工具