揭开 ClickHouse 快的面纱

背景

其实早在去年我们就已经开始接触并研究clickhouse了，因为当时进行多表关联测试性能并不是特别优秀，所以并没有在线上大范围使用，当时研究的是分布式部署（感觉分布式会比单机好一些）最后发现性能并不怎么样而且分布式的sql也有很多限制，不支持单条删除和更新操作、不支持in和join（当时的版本，18.12.14之前），直到前几天看了携程一篇关于clickhouse的文章，将clickhouse的性能描述的神乎其神，再次勾起了我研究的欲望，附携程公众号文章干货 | 每天十亿级数据更新，秒出查询结果，ClickHouse在携程酒店的应用

测试

开始之前我们先看结果：

携程的case

clickhouse 版本：18.12.13

服务器配置：

参数	配置
CPU	40c
内存	128g
硬盘	SSD
虚拟内存	禁用

数据：

表	数据量
A	1000w
B	2000w
C	6000w
D	2.4亿

测试场景：

case	时间
A + B +C 三表关联聚合查询	190ms
B + D 关联聚合查询	390ms
A + B +D 三表关联聚合查询	640ms

根据携程给的一份查询统计数据来看他们基于clickhouse的分析需求90%在500ms内：

易企秀测试case

clickhouse 版本：18.12.13

服务器配置：

参数	配置
CPU	32c
内存	128g
硬盘	SSD
虚拟内存	禁用

数据：

表	数据量
A	4000w
B	1.3亿

测试场景：

case	时间
B 单表聚合排序	2s
B + D 关联聚合排序	11s

单表聚合：

多表关联聚合：

通过对比测试，在配置相当的情况下测试结果差距还是很大的，那么究竟是什么原因造成的呢？该如何进行优化...

过程再现

调参

网上有人说通过调大 max_memory_usage 与 max_bytes_before_external_group_by 的值可改善查询性能（主要是处理并发query或单次查询内存约束的）

SET max_memory_usage = 128000000000; #128G，SET max_memory_usage = 60000000000; #60G，

实际测试这种操作，性能并没有任何影响，但在16C 、68G、普通硬盘环境下的clickhouse调大这两个参数的值性能会有一倍提升。

优化建表语句

建表语句：

通过缩小分区数量性能略有提升，但不明显

优化SQL

JOIN操作时一定要把数据量小的表放在右边，ClickHouse中无论是Left Join 、Right Join还是Inner Join永远都是拿着右表中的每一条记录到左表中查找该记录是否存在，所以右表必须是小表。

优化engine

将普通的mergetree engin 改为特殊的memory engine，性能无任何变化。

memory engine：

io 排查

通过测试过程中对硬盘io的监控数据看，clickhouse在计算的过程中基本没有什么io操作，只是在最后一个阶段有1-2s的写io操作，这也侧面印证mergetree的强大。

那么问题来了，这些都没有明显改善，那携程的case是怎么快起来的呢？

初步怀疑携程case中的操作并没有使用到全表数据，应该在聚合前加了很多筛选条件，带着疑问邮件了上文的作者，结论如下：

邮件：

携程多表关联聚合的真实case：

我们调参后的case

秒查：

结论

1、使用SSD盘比普通盘性能会提升1倍
2、亿级别单表聚合排序最慢2s出结果，普通盘需4秒
3、多表关联需增加过滤条件，将聚合结果控制在千万级别内可秒出
4、join时大表在左小表在右
5、如果不想加where条件，那么可以提前构建大宽表或者预计算
6、按照我们业务量级上面服务器配置减半并不影响性能

其实clickhouse并不需要做什么优化，100个并发内单表分析可随意操作，体验极佳；多表分析需根据实际使用场景针对性优化

普通盘：

认为是对的坚持下去就是对的，认为是对的不去坚持最后可能就是错的

目前我们实时数仓除了使用clickhouse外，还在使用另外一个秒查引擎，亿级规模场景下分析，这个engine是真的秒查哦 SnappyData（https://www.jianshu.com/p/ccad1333c48d）

往期推荐

1、HBase最佳实践 | 聊聊HBase核心配置参数
2、Apache Hudi：剑指数据湖的增量处理框架
3、Hadoop社区比 Ozone 更重要的事情
4、MapReduce Shuffle 和 Spark Shuffle 结业篇

揭开 ClickHouse 快的面纱相关推荐

未来已来？揭开量子计算机的神秘面纱
从第一台现代计算机ENIAC的诞生到个人PC时代的降临,从互联网概念的提出到移动互联的疾跑,在这个信息年代里,变革正以前所未有的速度改变着我们熟悉的世界.熟悉的生活. 作为个人,我们早已习惯于智能计算 ...
冰河浅析 - 揭开木马的神秘面纱（下）
冰河浅析 - 揭开木马的神秘面纱(下) 作者:· shotgun·yesky 四.破解篇(魔高一尺.道高一丈) 本文主要是探讨木马的基本原理, 木马的破解并非是 ...
揭开木马的神秘面纱 2
揭开木马的神秘面纱zz 2 离冰河二的问世已经快一年了,大家对于木马这种远程控制软件也有了一定的认识,比如:他会改注册表,他会监听端口等等,和一年前几乎没有人懂得木马是什么东西相比,这是一个质 ...
Azure Stack技术深入浅出系列6：Azure Stack一体机探究 — 揭开黑盒子的神秘面纱
Azure Stack是微软公有云平台的延伸,为客户环境里提供接口和相关的功能.微软的Azure Stack安装在指定的合作伙伴的一体机中,并以一体机的形式部署到客户的混合云应用环境里的.2017年7 ...
揭开木马的神秘面纱 1
揭开木马的神秘面纱 1 前言在网上,大家最关心的事情之一就是木马:最近出了新的木马吗?木马究竟能实现哪些功能?木马如何防治?木马究竟是如何工作的?本文试图以我国最著名的木马之 - 冰河为例,向大 ...
揭开木马的神秘面纱一
前言在网上,大家最关心的事情之一就是木马:最近出了新的木马吗?木马究竟能实现哪些功能?木马如何防治?木马究竟是如何工作的?本文试图以我国最著名的木马之一 - 冰河为例,向大家剖析木马的基本原理,为大 ...
来，让我们一起揭开专利的神秘面纱
众所周知,知识产权市场如今的火热程度就不用多说了,除了商标注册量的逐渐增多以外,其中专利的注册量也是在不断增加的!但很多人觉得专利很神秘,今天就带大家来揭开专利的神秘面纱! 发明创造不单指发明专利以 ...
了解黑客的关键工具---揭开Shellcode的神秘面纱
2019独角兽企业重金招聘Python工程师标准>>> ref: http://zhaisj.blog.51cto.com/219066/61428/ 了解黑客的关键工具---揭开 ...
EntityFramework Core表名原理解析，让我来，揭开你神秘的面纱
上一节我们针对最开始抛出的异常只是进行了浅尝辄止的解析,是不是有点意犹未尽的感觉,是的,我也有这种感觉,看到这里相信您和我会有一些疑惑,要是我们接下来通过注解.Fluent APi.DbSet分别对表 ...

揭开 ClickHouse 快的面纱

往期推荐

揭开 ClickHouse 快的面纱相关推荐

最新文章

热门文章