专栏首页ClickHouse的秘密基地ClickHouse为何如此之快?

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,暴力优化;

正则匹配使用re2hyperscan算法。

勇于尝鲜,不行就换

除了字符串之外,其余的场景也与它类似,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的黑魔法并不是一项单一的技术,而是一种自底向上的,追求极致性能的设计思路。

查看阅读原文,即可找到分享视频地址。

本文分享自微信公众号 - ClickHouse的秘密基地(chcave),作者:朱凯

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-01-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 从ClickHouse的名字由来讲起

    <ClickHouse原理解析和开发实战>,可以说2019年的绝大部分深夜,都与写作共度春宵了。现在写作临近尾声,终于有时间来扯些闲篇了。

    Nauu
  • 使用ClickHouse Playground进行交互式学习

    最近,ClickHouse的官网进行了一次改版更新,与旧版相比现在的信息更为聚焦。

    Nauu
  • ClickHouse 的 LTS 版本是什么?

    我们都知道 ClickHouse 不仅查询速度快,他的迭代发版速度也是相当 “变态”,我粗略统计了下今年的 CHANGELOG,目前已经发布了 39 次 sta...

    Nauu
  • 从ClickHouse的名字由来讲起

    <ClickHouse原理解析和开发实战>,可以说2019年的绝大部分深夜,都与写作共度春宵了。现在写作临近尾声,终于有时间来扯些闲篇了。

    Nauu
  • ClickHouse和他的朋友们(1)编译、开发、测试

    原文出处:https://bohutang.me/2020/06/05/clickhouse-and-friends-development/

    老叶茶馆
  • 干货 | 性能提升400%,ClickHouse在携程酒店数仓的实践

    随着时间推移和业务的快速发展,携程酒店数据累积越来越多。目前流量日数据在3T左右,再加上各种订单、价、量、态等数据更是庞大。现有Hive(Spark引擎)执行速...

    携程技术
  • ClickHouse实时场景分析及调优

    ClickHouse使用越来越多,这里给咱们分享下ClickHouse实时场景分析及调优

    用户1410343
  • ClickHouse的核心特性及架构

    导读:随着业务的迅猛增长,Yandex.Metrica目前已经成为世界第三大Web流量分析平台,每天处理超过200亿个跟踪事件。能够拥有如此惊人的体量,在它背后...

    zhisheng
  • [业界方案] ClickHouse业界解决方案学习笔记

    本文通过分析总结几篇文章来看目前工业界可能偏好的解决方案。学习目的是:大致知道其应用领域,技术特点和未来方向,看看目前工作中是否可以用到,或者当以后选型时候能够...

    罗西的思考
  • 交互式分析领域,为何ClickHouse能够杀出重围?

    导语 | 在百花齐放的交互式分析领域,ClickHouse 绝对是后起之秀,它虽然年轻,却有非常大的发展空间。本文将分享 PB 级分析型数据库 ClickHou...

    Spark学习技巧

扫码关注云+社区

领取腾讯云代金券