Clickhouse 技术分享

“ClickHouse works 100-1000x faster than traditional approaches”,这是官方网站首页的一句话,clickhouse 比传统方式快 100 到 1000 倍,本次分享会围绕一个快字,了解 clickhouse 究竟有多快以及它是怎么做到这么快的。
一、Clickhouse 是什么?

这里说一下 OLAP 和 OLTP 这两个概念,OLTP(On-Line transaction processing):传统的关系型数据库,主要操作增删改查,强调事务一致性,比如银行系统、电商系统;OLAP(On-Line Analytical Processing):仓库型数据库,主要是读取数据,做复杂数据分析(多维),侧重技术决策支持,提供直观简单的结果。


Apache Doris 前身是百度 Palo,是百度开发的面向在线报表和分析的数据仓库系统,在百度内部一些数据分析的场景有着广泛的应用,自 2017 年在 GitHub 上开源以来(比 ClickHouse 晚了 1 年),先后被国内十多家互联网公司使用,不过它和 Clickhouse 的关系就是“既生瑜何生亮”,对于这两个高性能的 OLAP 分析引擎选型,可以结合自己公司的一些场景或者是技术栈,比如公司内部是高并发的场景,则可以考虑下 Doris,毕竟目前来看高并发是 Clickhouse 的短板,其他方面这里不展开对比,网上有人做了比较全面的对比。

CloudFlare、阿里云、头条、携程、腾讯、快手、华为、Uber、爱奇艺、苏宁、趣头条、有赞、百分点

从上图来看,Clickhouse 在最近几年提交的代码数越来越多,基本上现在每个月保持一个版本的发布,主要原因是了解或者使用 Clickhouse 的用户越来越多,ClickHouse 社区越来越活跃,社区的活跃反过来助力推动 Clickhouse 的向前发展。DB-Engines
二、Clickhouse 有多快?


MySQL 单条 SQL 是单线程的,只能跑满一个 core,ClickHouse 相反,有多少 CPU,吃多少资源;IO 方面,MySQL 是行存储,ClickHouse 是列存储,列存储在 count()这类操作天然有优势,同时,在 IO 方面,MySQL 需要大量随机 IO,ClickHouse 基本是顺序 IO,所以 Clickhouse 会跑得飞快,这些我们在后面讲述 Clickhouse 为什么会这么快时会再提及。

详细数据参考:为什么我们要从ES迁移到ClickHouse?

非官方对比数据,参考:ClickHouse vs. Spark
三、Clickhouse 怎么这么快?

Mysql 基于行存储的结构,这样存储的好处是比如你要查询账号是 3645 这个人的信息,你只需要一次磁盘的查找,找到 3645 然后再顺序读取到 Luce,21 就可以了;不过加入你要查询所有用户的年龄的话,你需要走全表扫描,遍历很多不必要的数据。而列存储有什么好处呢?其实分析场景中,我们一般会读大量的行而取少量的列,在列式存储结构下,我们只需要取对应的列数据就可以,不参与计算的列完全不会被扫描到,这会极大的降低磁盘 IO 的消耗。

基于列式存储的结构,同一列中的数据属于同一类型,压缩效果会更加显著。列存往往有着高达十倍甚至更高的压缩比,节省了大量的存储空间,降低了存储成本
上图中的 ORC 文件格式是一种 Hadoop 生态圈中的列式存储格式,它的产生早在 2013 年初,最初产生自 Apache Hive,用于降低 Hadoop 数据存储空间和加速 Hive 查询速度

SIMD(Single Instruction Multiple Data)即单条指令操作多条数据,它是通过数据并行以提高性能的一种方式,可以简单理解为在寄存器层面对程序中的数据做并行处理,Clickhouse 在能够提升计算效率的地方大量使用了 SIMD,通过使用 SIMD,基本上能带来几倍的性能提升,像阿里云的 PolarDB-X 也引入了向量化执行引擎,为表达式计算带来了几十倍的性能提升。

分布式领域存在一条定律,计算移动比数据移动更加划算,这也是其核心所在,将数据的计算直接发放到数据所在的服务器,多机并行处理,再把最终的结果汇集在一起;另外 Clickhouse 也通过线程级别并行的方式为效率进一步提速,极致去利用服务器的自源。

关于 Clickhouse 表引擎,Clickhouse 支持的种类比较多,需要根据不同的业务场景选择不同的引擎,这里不展开介绍,可以参考Clickhouse官方文档。上图中的 LSM-Trss 并不是真实的 mergetree 的结构,只能说 mergetee 借鉴了 LSM-tree 的思想,在《Clickhouse 原理解析与应用实践》一书中给出了详细的图例,远远比 LSM-tree 复杂很多。
集成引擎补充一点:Mysql 数据库引擎,例如允许将远程的 MySQL 服务器中的表映射到 ClickHouse 中,并允许对表进行 INSERT 和 SELECT 查询,MySQL 数据库引擎会将对其的查询转换为 MySQL 语法并发送到 MySQL 服务器中,让你可以执行诸如 SHOW TABLES 或 SHOW CREATE TABLE 之类的操作
四、Clickhouse 有哪些应用场景?

正是 Clickhouse 的一些优缺点决定了它的一些应用场景,比如正式因为采用了并行处理机制,即使一个查询,也会用服务器一半的 CPU 去执行,所以 ClickHouse 不能支持高并发的使用场景;ClickHouse 集群自身虽然可以方便的水平增加节点,但并不支持自动的数据均衡,需要过度的人工介入运维;Clickhouse 不适合有实时写入需求的业务,过小的数据据写入会导致底层产生大量的小文件,影响查询性能,最好能够用批量写入等。
但总的来说目前还没有一个 OLAP 引擎能够满足各种场景的需求,其本质原因是,没有一个系统能同时在查询效率、时效性、可维护性三个方面做到完美,只能说是 Clickhouse 为了极致的查询性能所做的权衡,类似“分布式 CAP 理论”。

五、Clickhouse 快速入门

Clickhouse 官方镜像:https://hub.docker.com/r/yandex/clickhouse-server/
Clickhouse 分布式部署:https://www.yht7.com/news/34852

更多图形管理工具:https://my.oschina.net/taogang/blog/4973018
六、重新思考大数据架构


如上图所示,Clickhouse 自带 Kafka 集成引擎,可以及时消费同步 Kafka 数据,减少数据同步链路,加快数据同步流程(理论上可以消除离线层);同时利用 Clickhouse 快速聚合能力,加速上层数据查询分析能力,目前已经在业务中接入使用。
说明:本文参考了朱凯老师的《ClickHouse 原理解析与应用实践》,个人觉得内容非常不错也易于理解,感兴趣的同学可以买来学习研究下
评论