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 理论”。