ClickHouse 为何如此之快？

黑魔法， 也是黑科技

老板： “你听说过 ClickHouse 吗？简称叫 CK！！！”

我： “听说过，不是个内裤品牌吗？谁没听说过？你想干什么?！！”

老板： “不是内裤！！是一款 OLAP 数据库，给你看，这是它的测试报告。”

我： “假的吧，单机性能就这么高？怎么可能！！！”

老板： “不信你自己试试！！”

一番捣鼓之后

我： “。。。。。。。”

颠覆三观、陷入无限思考，心中只有三个字:

这是什么鬼！！

上述是我的一段亲身经历。

很多初识 CH 的人，内心都会经历这么几个阶段：

相遇，会被它那惊叹的性能所吸引；

疑惑，开始质疑它的真实性；

困惑，在亲自论证了可靠性后，身体虽然是相信了，但内心依然觉得不可思议，不明就里。

于是乎， 为什么 ClickHouse 这么快? 渐渐成了一个不解之谜。

作为一个拥有 ClickHouse 信仰标签的忠实粉丝 ，我自然也是追寻谜底的一份子。在我苦苦寻觅许久之后，今天，终于被我找到了答案。所以特地拿来与各位分享，谜底就在下面：

翻译过来的意思是:

这是纯魔法，是由前苏联科学家提供的技术.

他们曾经用来制造火箭.

看到没?！这就是 ClickHouse 的黑魔法。

好吧，这其实是我今天刚看到的一则笑话，来自于中科院计算所博士，郑天祺 (Amos Bird)，同时他也是一名 ClickHouse 的 Committer。

虽然刚才的谜底是假的，但疑问是真真切切存在的， 为什么 ClickHouse 这么快？

已经有很多人，对这个问题做出过科学合理的解释。

比如有人说，因为 ClickHouse 是列存数据库，所以快；

也有人说，因为 ClickHouse 使用了向量化引擎，所以快。

这些解释都站得住脚，但是依然不能消除我的疑问。因为这些技术并不是秘密，世面上有很多数据库同样使用了这些技术，但是依然被 ClickHouse 秒杀呀？

所以，今天我想从另外一个角度，来探讨一下 ClickHouse 的黑魔法，它到底是什么。

要找到问题的谜底，其实有一个很简单的办法，那就是听听作者们自己是怎么说的呗。

画外音： “说的轻巧，去哪里找作者倾诉呢？”

所以说，勤奋的人们总是容易被幸运眷顾，你看这不:

恰好，在 2019 的年末，在北京举行了 中国大数据技术大会（BDTC 2019）；

恰好又，这个大会邀请了 ClickHouse 项目的创始人兼开源社区创始人， Alexey Milovidov ；

恰恰好又， Alexey Milovidov 在大会上做了一次主题分享；

恰恰恰好又，这个分享主题就叫做 The Secrets of ClickHouse Performance Optimizations 。

各位说说，怎么就这么巧呢？简直做梦都要笑醒的节奏啊。

既然作者已经做了分享，那我就从这次分享出发，对 ClickHouse 的黑魔法做一番分析总结吧。(文末会附上 Alexey Milovidov 的分享视频)

开篇伊始，Alexey Milovidov 就抛出了一个灵魂的质问:

做设计的原则，到底应该是 自顶向下 的去设计，还是应该 自下而上 的去设计 ？

在传统观念中，或者说在我的观念中，自然是 自顶向下 的，做架构设计首先自然做的是顶层设计:

• 事先应该做高层次的抽象设计;

• 规划好各个模块的职责、切分的界面；

• 分配好工程结构、包结构，最好能再来一些设计图，等等。

而 ClickHouse 的设计，则采用了 自下而上 。

ClickHouse 的原型系统早在 2008 年就诞生了(有机会可以专门写一篇,聊聊关于 ClickHouse 的诞生历程)，在诞生之初，它并没有宏伟的规划。相反，它的目的很单纯，就是希望能以最快的速度进行 GROUP BY 查询和过滤。

他们是如何实践 自下而上 设计的呢？

着眼硬件，先想后做

从硬件功能层面着手设计，在设计伊始，就至少需要想清楚这么几个问题：

1. 我们将要使用的硬件水平是怎样的？包括 CPU、内存、硬盘、网络等等；

2. 在这样的硬件上，我们需要达到怎样的性能？包括延迟、吞吐量等等;

3. 我们准备使用怎样的数据结构？包括 String、HashTable、Vector 等等；

4. 选择的这些数据结构，在我们的硬件上会如何工作？

如果你能想清楚上面的问题，那么在动手实现功能之前，就已经能够计算出粗略的性能了。

所以，基于将硬件功效最大化的目的，ClickHouse 会在内存中进行 GROUP BY，并且使用 HashTable 装载数据。于此同时，他们非常在意 CPU L3 级别的缓存，因为一次 L3 cache miss 会带来 70~100 纳秒的延迟。这意味着，在单核 CPU 上，它会浪费 4000 万/每秒的运算；而在一个 32 线程的 CPU 上，则可能会浪费 5 亿/每秒的运算。

所以别小看这些细节，一点一滴的将它们累加起来，数据是非常可观的。也正因为注意了这些细节，所以 ClickHouse 在基准查询中，能做到 1.75 亿/每秒的数据扫描性能。

算法在前，抽象在后

最近常听人念叨， “有时候，选择比努力更重要”。 确实，路线选错了，再努力也是白搭。

在 ClickHouse 的底层实现中，经常会面对这些场景：字符串子串查询；数组排序；使用 HashTable 等。

如何才能在实现性能的最大化呢？算法的选择是重中之重！！！

以字符串为例，有一本专门讲解字符串搜索的书，叫做 " Handbook of Exact String Matching Algorithms "，这本书列举了 35 种常见的字符串搜索算法，你猜 ClickHouse 使用了其中的哪一种？

一种都没用！！ 为什么？因为性能不够快。

在字符串搜索方面，针对不同的场景，ClickHouse 最终选择了这些算法：

对于常量，使用 Volnitsky 算法；

对于非常量，使用 CPU 的向量化执行 SIMD ，暴力优化;

正则匹配使用 re2 和 hyperscan 算法。

勇于尝鲜，不行就换

除了字符串之外，其余的场景也与它类似，ClickHouse 会使用最合适、最快的算法。如果世面上出现了，号称性能强大的新算法，他也会将其纳入，进行验证。如果效果可行，就保留使用；如果性能不尽人意，就将其抛弃。

特定场景，特殊优化

针对在同一个场景的，不同的状况，选择使用不同的实现方式，尽可能的将性能最大化。关于这一点，其实在刚才介绍字符串查询时候，针对不同场景，选择不同的算法就能体现了。类似的例子还有很多，例如去重计数 uniqCombined 函数，根据数据量的不同，会选择不同的算法:

当数据量较小的时候，会选择 Array 保存;

当数据量中等时候，则会选择 HashSet;

而当数据量很大的时候,则使用 HyperLogLog 算法。

包括对于数据结构比较清晰的场景，会通过代码生成技术，实现循环展开，以减少循环次数。

还包括大家熟知的大杀器，向量化执行了。SIMD 被广泛的应用于文本转换、数据过滤、数据解压和 JSON 转换等场景。利用寄存器暴力优化，相较于单纯的使用 CPU 而言，也算是一种降维打击了。

持续测试，持续改进

如果只是单纯的，在上述的细节上下功夫，还不足以构建出如此强大的 ClickHouse，这里还需要拥有一个能够持续验证、持续改进的机制。由于 Yandex 的天然优势，ClickHouse 经常会使用真实的数据做测试，这一点很好的保证了测试场景的真实性。于此同时，ClickHouse 也是我见过发版速度最快的开源软件了，差不多每个月都能发布一个版本，没有一个可靠的持续集成环境，这一点也是做不到的。也正因为拥有这样的发版频率，他们能够快速迭代、快速改进。

好了，上述这些，就是我对 Alexey Milovidov 这次分享的一些总结和个人理解了。

最后，就以 ClickHouse 的口号，作为结束吧：

The ClickHouse Style:

As efficient as possible

As fast as possible

正如口号所言，他们做到了。

所以，ClickHouse 的黑魔法并不是一项单一的技术，而是一种 自底向上 的，追求极致性能的设计思路。