=Start=

缘由：

之前总是用Hive/Presto做离线分析，现在要用ClickHouse了，之前只是听说过但没用过，不太懂，所以买本书来了解学习一下。

正文：

参考解答：

推荐序一 <*>
推荐序二
推荐序三
推荐序四
推荐序五
赞誉
前言 <*>

第1章　ClickHouse的前世今生 <*>

1.1　传统BI系统之殇
1.2　现代BI系统的新思潮
1.3　OLAP常见架构分类
1.4　OLAP实现技术的演进
1.5　一匹横空出世的黑马
1.5.1　天下武功唯快不破
1.5.2　社区活跃
1.6　ClickHouse的发展历程
1.6.1　顺理成章的MySQL时期
1.6.2　另辟蹊径的Metrage时期
1.6.3　自我突破的OLAPServer时期
1.6.4　水到渠成的ClickHouse时代
1.7　ClickHouse的名称含义
1.8　ClickHouse适用的场景
1.9　ClickHouse不适用的场景
1.10　有谁在使用ClickHouse
1.11　本章小结

第2章　ClickHouse架构概述 <*>

2.1　ClickHouse的核心特性
2.1.1　完备的DBMS功能
2.1.2　列式存储与数据压缩
2.1.3　向量化执行引擎
2.1.4　关系模型与SQL查询
2.1.5　多样化的表引擎
2.1.6　多线程与分布式
2.1.7　多主架构
2.1.8　在线查询
2.1.9　数据分片与分布式查询
2.2　ClickHouse的架构设计
2.2.1　Column与Field
2.2.2　DataType
2.2.3　Block与Block流
2.2.4　Table
2.2.5　Parser与Interpreter
2.2.6　Functions 与Aggregate Functions
2.2.7　Cluster与Replication
2.3　ClickHouse为何如此之快
2.3.1　着眼硬件，先想后做
2.3.2　算法在前，抽象在后
2.3.3　勇于尝鲜，不行就换
2.3.4　特定场景，特殊优化
2.3.5　持续测试，持续改进
2.4　本章小结

第3章　安装与部署

3.1　ClickHouse的安装过程
3.1.1　环境准备
3.1.2　安装ClickHouse
3.2　客户端的访问接口
3.2.1　CLI
3.2.2　JDBC
3.3　内置的实用工具
3.3.1　clickhouse-local
3.3.2　clickhouse-benchmark
3.4　本章小结

第4章　数据定义

4.1　ClickHouse的数据类型
4.1.1　基础类型
4.1.2　复合类型
4.1.3　特殊类型
4.2　如何定义数据表
4.2.1　数据库
4.2.2　数据表
4.2.3　默认值表达式
4.2.4　临时表
4.2.5　分区表
4.2.6　视图
4.3　数据表的基本操作
4.3.1　追加新字段
4.3.2　修改数据类型
4.3.3　修改备注
4.3.4　删除已有字段
4.3.5　移动数据表
4.3.6　清空数据表
4.4　数据分区的基本操作
4.4.1　查询分区信息
4.4.2　删除指定分区
4.4.3　复制分区数据
4.4.4　重置分区数据
4.4.5　卸载与装载分区
4.4.6　备份与还原分区
4.5　分布式DDL执行
4.6　数据的写入
4.7　数据的删除与修改
4.8　本章小结

第5章　数据字典

5.1　内置字典
5.1.1　内置字典配置说明
5.1.2　使用内置字典
5.2　外部扩展字典
5.2.1　准备字典数据
5.2.2　扩展字典配置文件的元素组成
5.2.3　扩展字典的数据结构
5.2.4　扩展字典的类型
5.2.5　扩展字典的数据源
5.2.6　扩展字典的数据更新策略
5.2.7　扩展字典的基本操作
5.3　本章小结

第6章　MergeTree原理解析

6.1　MergeTree的创建方式与存储结构
6.1.1　MergeTree的创建方式
6.1.2　MergeTree的存储结构
6.2　数据分区
6.2.1　数据的分区规则
6.2.2　分区目录的命名规则
6.2.3　分区目录的合并过程
6.3　一级索引
6.3.1　稀疏索引
6.3.2　索引粒度
6.3.3　索引数据的生成规则
6.3.4　索引的查询过程
6.4　二级索引
6.4.1　granularity与index_granularity的关系
6.4.2　跳数索引的类型
6.5　数据存储
6.5.1　各列独立存储
6.5.2　压缩数据块
6.6　数据标记
6.6.1　数据标记的生成规则
6.6.2　数据标记的工作方式
6.7　对于分区、索引、标记和压缩数据的协同总结
6.7.1　写入过程
6.7.2　查询过程
6.7.3　数据标记与压缩数据块的对应关系
6.8　本章小结

第7章　MergeTree系列表引擎

7.1　MergeTree
7.1.1　数据TTL
7.1.2　多路径存储策略
7.2　ReplacingMergeTree
7.3　SummingMergeTree
7.4　AggregatingMergeTree
7.5　CollapsingMergeTree
7.6　VersionedCollapsingMergeTree
7.7　各种MergeTree之间的关系总结
7.7.1　继承关系
7.7.2　组合关系
7.8　本章小结

第8章　其他常见类型表引擎

8.1　外部存储类型
8.1.1　HDFS
8.1.2　MySQL
8.1.3　JDBC
8.1.4　Kafka
8.1.5　File
8.2　内存类型
8.2.1　Memory
8.2.2　Set
8.2.3　Join
8.2.4　Buffer
8.3　日志类型
8.3.1　TinyLog
8.3.2　StripeLog
8.3.3　Log
8.4　接口类型
8.4.1　Merge
8.4.2　Dictionary
8.4.3　Distributed
8.5　其他类型
8.5.1　Live View
8.5.2　Null
8.5.3　URL
8.6　本章小结

第9章　数据查询 <*>

9.1　WITH子句
9.2　FROM子句
9.3　SAMPLE子句
9.4　ARRAY JOIN子句
9.5　JOIN子句
9.5.1　连接精度
9.5.2　连接类型
9.5.3　多表连接
9.5.4　注意事项
9.6　WHERE与PREWHERE子句
9.7　GROUP BY子句
9.7.1　WITH ROLLUP
9.7.2　WITH CUBE
9.7.3　WITH TOTALS
9.8　HAVING子句
9.9　ORDER BY子句
9.10　LIMIT BY子句
9.11　LIMIT子句
9.12　SELECT子句
9.13　DISTINCT子句
9.14　UNION ALL子句
9.15　查看SQL执行计划
9.16　本章小结

第10章　副本与分片

10.1　概述
10.2　数据副本
10.2.1　副本的特点
10.2.2　ZooKeeper的配置方式
10.2.3　副本的定义形式
10.3　ReplicatedMergeTree原理解析
10.3.1　数据结构
10.3.2　副本协同的核心流程
10.4　数据分片
10.4.1　集群的配置方式
10.4.2　基于集群实现分布式DDL
10.5　Distributed原理解析
10.5.1　定义形式
10.5.2　查询的分类
10.5.3　分片规则
10.5.4　分布式写入的核心流程
10.5.5　分布式查询的核心流程
10.6　本章小结

第11章　管理与运维

11.1　用户配置
11.1.1　用户profile
11.1.2　配置约束
11.1.3　用户定义
11.2　权限管理
11.2.1　访问权限
11.2.2　查询权限
11.2.3　数据行级权限
11.3　熔断机制
11.4　数据备份
11.4.1　导出文件备份
11.4.2　通过快照表备份
11.4.3　按分区备份
11.5　服务监控
11.5.1　系统表
11.5.2　查询日志
11.6　本章小结

---

推荐序一

We released ClickHouse in open-source in 2016, four years ago. And as far as I know, this book is going to be the first published book on ClickHouse. Why do I appreciate that so much? When we released ClickHouse, we had only one goal in mind, to give people the fastest analytical DBMS in the world. But now, after a few years, I see many more opportunities. We can make ClickHouse an example of the most community and developers friendly open-source product.

According to Eric S. Raymond, there are two models of software development：the “Cathedral” and the “Bazaar” model. In the first model, the software is developed by a closed team of a few developers who “do the right thing”. An example of the “Cathedral” model is SQLite that is developed mostly by a single person—Richard Hipp. In contrast, the “Bazaar” model is trying to benefit by invitation of as many independent developers as possible. An example of the “Bazaar” model is the Linux kernel. For ClickHouse, we practice the “Bazaar” model. But this model requires many efforts in building the community. These efforts are summarized in the following 8 points.

According to Eric S. Raymond, there are two models of software development：the “Cathedral” and the “Bazaar” model. In the first model, the software is developed by a closed team of a few developers who “do the right thing”. An example of the “Cathedral” model is SQLite that is developed mostly by a single person—Richard Hipp. In contrast, the “Bazaar” model is trying to benefit by invitation of as many independent developers as possible. An example of the “Bazaar” model is the Linux kernel. For ClickHouse, we practice the “Bazaar” model. But this model requires many efforts in building the community. These efforts are summarized in the following 8 points.

（1）The development process must be as open as possible, no secrets should be kept; we should do everything in public.

（2）The codebase must be well documented and understandable even for amateur developers. And amateur developers should be able to learn good practices from ClickHouse.

（3）We should be eager to try experimental algorithms and libraries, to be on edge and invite more enthusiastic people. As an example, today is 2020, so we are using C++20 language standard.

（4）We should move fast. Try 10 algorithms, throw off 9 of 10, and keep moving forward.

（5）To keep the codebase sane, we should define high-quality standards. And enforce these standards by automated tools in a continuous integration process, not by arguing with people.

（6）We should maintain a high accept rate of contributions. Even if a contribution is not ready, we should actively help each other. Even if the code is wrong, we keep the idea and make it right. Contributors should feel their efforts well received, and they should be proud of their contributions.

（6）We should maintain a high accept rate of contributions. Even if a contribution is not ready, we should actively help each other. Even if the code is wrong, we keep the idea and make it right. Contributors should feel their efforts well received, and they should be proud of their contributions.

（7） ClickHouse is for everyone. You can make a product on top of ClickHouse, and use it in your company, and we will welcome it. We love our users, and we are interested in ClickHouse widespread in any possible way.

（8）We need to provide good tutorials and educational materials for potential contributors. I hope that this book helps people to understand ClickHouse architecture.

The Cathedral model is easier to manage, but the Bazaar model definitely gives more fun!

We can make ClickHouse the best educational and research product in the area of database engineering.

If you look at the architectural details of ClickHouse, you will find that most of them are nothing new. Most of them are already well researched and implemented in some other systems. What’s unique in ClickHouse is the combination of these choices, how well they are integrated together, and the attention to implementation details. There are multiple books on computer science, on managing data, and so on. But you will not find many that describe the internals, the guts, and low-level details that differentiate one system from another. ClickHouse can be considered as a collection of good choices in implementation and also as a playground for experiments. And I hope that this book will guide you through these details.

If you look at the architectural details of ClickHouse, you will find that most of them are nothing new. Most of them are already well researched and implemented in some other systems. What’s unique in ClickHouse is the combination of these choices, how well they are integrated together, and the attention to implementation details. There are multiple books on computer science, on managing data, and so on. But you will not find many that describe the internals, the guts, and low-level details that differentiate one system from another. ClickHouse can be considered as a collection of good choices in implementation and also as a playground for experiments. And I hope that this book will guide you through these details.

ClickHouse should become a standard of good usability among database management systems.

A database management system is not an easy product to develop. And people get used to that it is neither easy to work with. Distributed systems are even harder. Working with a typical distributed system is a painful experience from the start. But we can try to break this stereotype. At least we can eliminate typical obstacles. ClickHouse is easy to set up and run, so you can start working in minutes. But what about further details like data replication, distributed set up, choosing of table engines, and indexes? Couldn’t they be so simple too? Probably not. But at least they can be understandable. This book covers these details, and you will understand what is under the hood of ClickHouse.

Alexey Milovidov
Head of ClickHouse Development Team at Yandex

---

推荐序一（译文）

我们在2016年发布了ClickHouse的开源版本。据我所知，这本书将是关于ClickHouse的第一本正式出版的图书，对此我非常激动。因为当我们发布ClickHouse的时候，心中只有一个目标，即向人们提供世界上最快的分析型数据库。而现在，我看到了更多的可能性。我们可以把ClickHouse打造成面向社区与开发者的最友好的开源产品。

根据Eric S.Raymond的理论，目前主要有两种软件开发模式——Cathedral（大教堂）模式与Bazaar（集市）模式。在Cathedral模式中，软件由一个封闭的开发者小组进行开发。使用该模式开发的典型产品就是SQLite数据库，它是由Richard Hipp一个人开发的。而Bazaar模式则是邀请尽可能多的独立开发者进行开发，Linux内核就是采用这种模式开发出来的。对ClickHouse而言，我们采用了Bazaar模式。采用Bazaar模式，需要花费很大的精力来维护开发社区。对于在开发ClickHouse的过程中采用Bazaar模式，我总结出了以下8点经验。

（1）整个开发流程完全公开透明，没有任何秘密。

（2）有帮助理解代码的、新手开发者也可看懂的详细文档，这样新手开发者可从ClickHouse代码中学到有价值的实践经验。

（3）乐于尝试新的算法与第三方库，以保持ClickHouse的先进性，也只有这样才能吸引更多的开发热爱者。例如，刚刚进入2020年，我们就在ClickHouse中应用了C++20标准。

（4）虽然需要快速迭代ClickHouse，但是我们依然不会放低要求，比如我们为了使用1个算法，就会至少尝试10个算法。而且在选择了某个算法后，后续还会继续尝试其他更多算法，以便下次迭代时使用。

（5）为了保证代码的质量，我们始终向高标准看齐，并使用工具来确保这些标准得以实施，而不是人为干预。

（6）对于贡献者提交的补丁，我们保证有比较高的接收率。即使某个补丁还没有完成，我们也会适当参与，为贡献者提供帮助。若补丁的代码中有错误，我们会尝试修复。这样补丁的贡献者会感受到他们的努力获得了认可，并因此感到自豪。

（7）ClickHouse是提供给所有人的，你甚至可以用ClickHouse来实现其他产品，也可以把它部署在自己的公司。我们爱我们的用户，我们对ClickHouse在任何场景下的应用都表示支持，并且有兴趣了解你的使用情况。

（8）我们希望为潜在的贡献者提供高质量的教程和参考资料。我很高兴看到这本书上市，因为它能够帮助读者理解ClickHouse的架构。

Cathedral模式便于管理，但是Bazaar模式显然更有意思！我们可以把ClickHouse打造为最适合用于数据库教学与研究的产品。如果细看ClickHouse的架构，你会发现其中没有什么新颖的技术，其中使用的大部分技术都是经过了多年研究并已在其他数据库中实现了的成熟技术。ClickHouse独特的地方在于其高效地将这些技术结合了起来并灵活地加以运用，在此过程中我们十分注重具体的实现方式与细节。许多图书在介绍计算机科学或数据管理的知识时并不会在细节方面进行展开，也不会对不同的系统针对底层实现进行对比，为了对此进行补充，ClickHouse在上述两方面进行了尝试。作为一个比较好的技术实现集合，ClickHouse特别适合用来在细节方面做性能优化实验。我希望这本书能够引导你了解这些技术细节。

ClickHouse可以作为数据库中易用性的代表。数据库系统并不是一款容易开发的产品，这也使得人们认为数据库开发上手很难，分布式数据库的开发就更难了，甚至在刚开始使用分布式系统时会觉得非常烦琐。在开发ClickHouse的过程中，我们尝试打破这些固有的认识，至少扫清了一些常见的障碍。ClickHouse上手非常容易，你可以在几分钟内安装好并开始使用。然而如果你需要使用更多的功能，如数据副本、分布式、不同的表引擎、索引等，就不会那么简单了，但这些功能在理解与学习上相对于其他数据库还是简单的。本书介绍了理解和学习ClickHouse的方法，也介绍了ClickHouse的诸多细节。通过这本书你将会透彻理解ClickHouse是如何运行的。

Alexey Milovidov
Yandex公司ClickHouse开发团队负责人

（郑天祺译）

---

前言

生生不息，“折腾”不止。为什么新的技术层出不穷，一直会更替变换？因为人们总是乐于追求更加美好的事物，因此业务总会产生新的诉求。

在软件领域，技术与业务犹如一对不可拆分的双轨车道，承载着产品这辆火车稳步向前。一方面，业务的诉求必须得到满足，所以它倒逼技术提升；另一方面，技术的提升又为业务模式带来了新的可能。

第1章　ClickHouse的前世今生

Google于2003～2006年相继发表了三篇论文“Google File System”“Google MapReduce”和“Google Bigtable”，将大数据的处理技术带进了大众视野。2006年开源项目Hadoop的出现，标志着大数据技术普及的开始，大数据技术真正开始走向普罗大众。

1. 【IT系统从无到有】得益于IT技术的迅猛发展，各行各业开始置办IT系统以提高效率。
2. 【烟囱式发展——互不相通】早期发展没考虑太多，多呈烟囱式发展，数据散落在各个独立的系统之内，相互割裂、互不相通。
3. 【引入数据仓库】为了解决数据孤岛的问题，人们提出了数据仓库的概念。即通过引入一个专门用于分析类场景的数据库，将分散的数据统一汇聚到一处。
4. 【BI概念的诞生】于20世纪90年代，有人第一次提出了BI（商业智能）系统的概念。自此以后，人们通常用BI一词指代这类分析系统。相对于联机事务处理系统，我们把这类BI系统称为联机分析（OLAP）系统。
5. 【传统BI系统的设计想法很美好，实际应用场景和效果却有限】原因很多在此不赘述。
6. 【技术创新让部分想法可落地】2003年起，Google陆续发表的三篇论文开启了大数据的技术普惠，Hadoop生态由此开始一发不可收拾，数据分析开启了新纪元。
7. 【ClickHouse的横空出世让BI产品的选型又多了一个选择】天下武功唯快不破。

1.8　ClickHouse适用的场景

可以说ClickHouse具备了人们对一款高性能OLAP数据库的美好向往，所以它基本能够胜任各种数据分析类的场景，并且随着数据体量的增大，它的优势也会变得越为明显。

ClickHouse非常适用于商业智能领域（也就是我们所说的BI领域），除此之外，它也能够被广泛应用于广告流量、Web、App流量、电信、金融、电子商务、信息安全、网络游戏、物联网等众多其他领域。

1.9　ClickHouse不适用的场景

ClickHouse作为一款高性能OLAP数据库，虽然足够优秀，但也不是万能的。我们不应该把它用于任何OLTP事务性操作的场景，因为它有以下几点不足。

·不支持事务。
·不擅长根据主键按行粒度进行查询（虽然支持），故不应该把ClickHouse当作Key-Value数据库使用。
·不擅长按行删除数据（虽然支持）。

这些弱点并不能视为ClickHouse的缺点，事实上其他同类高性能的OLAP数据库同样也不擅长上述的这些方面。因为对于一款OLAP数据库而言，上述这些能力并不是重点，只能说这是为了极致查询性能所做的权衡。

参考链接：

ClickHouse原理解析与应用实践
https://book.douban.com/subject/35091211/
https://github.com/nauu/clickhousebook

《clickhouse原理解析与应用实践》读书笔记
https://blog.csdn.net/lonelymanontheway/article/details/108181649

https://clickhouse.tech/#quick-start

https://clickhouse.tech/docs/zh/

ClickHouse大数据分析技术与实战
https://www.jianshu.com/p/560bb382f91a

ClickHouse深度解析
https://www.cnblogs.com/zfwwdz/p/13151727.html

=END=