一、前言

架构, 软件开发中最熟悉不过的名词, 遍布在我们的日常开发工作中, 大到项目整体, 小到功能组件, 想要实现高性能、高扩展、高可用的目标都需要优秀架构理念辅助. 所以本人尝试编写架构系列文章, 去剖析市面上那些经典优秀的开源项目, 学习优秀的架构理念来积累架构设计的经验与思考, 在后续日常工作中遇到相同问题时能有更深一层的认知.

本章以实时 OALP 引擎 Clickhouse(简称 ck)为例, 以其面向场景, 架构设计, 细节实现等方面来介绍, 深度了解其如何成为了 OLAP 引擎中的性能之王.

二、Clickhouse 简介

Clickhouse 是俄罗斯 Yandex(俄罗斯网络用户最多的网站)于 2016 年开源的一个用于联机分析(OLAP)的列式数据库管理系统,采用 C++语言编写, 主要用于在线分析处理查询, 通过 SQL 查询实时生成分析数据报告.

主要面向场景是快速支持任意指标、任意维度并且可以在大数据量级下实现秒级反馈的 Ad-hoc 查询(即席查询).

三、Clickhouse 架构原理

clickhouse 以其卓越的性能著称, 在相关性能对比报告中, ck 在单表 SQL 查询的性能是 presto 的 2.3 倍、impala 的 3 倍、greenplum 的 7 倍、hive 的 48 倍. 可以看出 ck 在单表查询是非常出色的, 那么 ck 究竟是如何实现高效查询的呢?

1. 引子

介绍 ck 查询原理之前先以最常见的 mysql 为例, 一条简单的查询语句是如何执行的, 然后再以 ck 架构师的角度去考虑 ck 应该如何优化. mysql 查数据时会先从磁盘读出数据所在页(innodb 存储单元) 到内存中, 然后再从内存中返回查询结果, 所以在我们的认知中 sql 查询(排除语法词法解析,优化等步骤)总结起来可以为以下两点:

1. 磁盘读取数据到内存

2. 内存中解析数据匹配结果返回

在现代计算机中, CPU 参与运算的时间远小于磁盘 IO 的时间. 所以现代 OLAP 引擎大部分也选择通过降低磁盘 IO 的手段来提高查询性能, 举例如下:

2. 架构

通过以上推导分析, 我们可以得出 OLAP 查询瓶颈在于磁盘 IO, 那么 ck 的优化手段也是借鉴了以上措施, 采用了 MPP 架构(大规模并行处理)+列式存储, 拥有类似架构设计的其他数据库产品也有很多, 为什么 ck 性能如此出众? 接下来我们具体分析 ck 的核心特性, 进一步体会 ck 架构师的巧妙的架构理念.

2.1 列式存储

行式存储: 把同一行数据放到同一数据块中, 各个数据块之间连续存储.

列式存储: 把同一列数据放到同一数据块中, 不同列之间可以分开存储.

如同上述所讲, 分析类查询往往只需要一个表里很少的几个字段, Column-Store 只需要读取用户查询的 column, 而 Row-Store 读取每一条记录的时候会把所有 column 的数据读出来, 在 IO 上 Column-Store 比 Row-Store 效率高得多, 因此性能更好.

2.2 block

clickhouse 能处理的最小单位是 block, block 是一群行的集合, 默认最大为 8192 行. 因为每一列单独存储, 因此每个数据文件相比于行式存储更有规律, 通过对 block 采用 LZ4 压缩算法, 整体压缩比大致可以 8:1. 可以看出, clickhouse 通过出色的压缩比与 block 结构实现了批处理功能, 对比海量数据存储下每次处理 1 行数据的情况, 大幅减少了 IO 次数, 从而达到了存储引擎上的优化.

2.3 LSM

LSM 的思想: 对数据的修改增量保持在内存中，达到指定的限制后将这些修改操作批量写入到磁盘中，相比较于写入操作的高性能，读取需要合并内存中最近修改的操作和磁盘中历史的数据，即需要先看是否在内存中，若没有命中，还要访问磁盘文件

LSM 的原理: 把一颗大树拆分成 N 棵小树，数据先写入内存中，随着小树越来越大，内存的小树会 flush 到磁盘中。磁盘中的树定期做合并操作，合并成一棵大树，以优化读性能。

Clickhouse 通过 LSM 实现数据的预排序, 从而减少磁盘的读取量. 原理就是将乱序数据通过 LSM 在村中排序, 然后写入磁盘保存, 并定期合并有重合的磁盘文件. clickhouse 的写入步骤可以总结为以下几点:

1. 每一批次数据写入,先记录日志, 保证高可用机制

2. 记录日志之后存入内存排序, 后将有序结果写入磁盘,记录合并次数 Level=0

3. 定期将磁盘上 Level=0 或 1 的文件合并,并标记删除. 后续物理删除

2.4 索引

clickhouse 的采用一级索引(稀疏索引)+二级索引(跳数索引)来实现索引数据定位与查询. 一级索引记录每个 block 块的第一个, 每次基于索引字段查询只需要确定查询第几个 block 块即可, 避免一个查询遍历所有数据. 如上述介绍,一个 block 块为 8192 行,那么 1 亿条数据只需要 1 万行索引, 所以一级索引占用存储较小, 可常驻内存, 加速查询. 二级索引由数据的聚合信息构建而成，根据索引类型的不同，其聚合信息的内容也不同，跳数索引的目的与一级索引一样，也是帮助查询时减少数据扫描的范围, 原则都是“排除法”，即尽可能的排除那些一定不满足条件的索引粒度

另一方面可以发现, 因 ck 存储引擎按有序集合存储, 所以在索引结构上, 并不需要再利用 B+树排序特性来定位. 所以在实际使用过程中, 也不需要满足最左原则匹配, 只要过滤条件中包含索引列即可.

2.5 向量化执行

向量化计算(vectorization)，也叫 vectorized operation，也叫 array programming，说的是一个事情：将多次 for 循环计算变成一次计算。 为了实现向量化执行，需要利用 CPU 的 SIMD 指令。SIMD 的全称是 Single Instruction Multiple Data，即用单条指令操作多条数据。现代计算机系统概念中，它是通过数据并行以提高性能的一种实现方式 ( 其他的还有指令级并行和线程级并行 )，它的原理是在 CPU 寄存器层面实现数据的并行操作。

在计算机系统的体系结构中，存储系统是一种层次结构。典型服务器计算机的存储层次结构如图 1 所示。一个实用的经验告诉我们，存储媒介距离 CPU 越近，则访问数据的速度越快。

从左至右,距离 CPU 越远，则数据的访问速度越慢。从寄存器中访问数据的速度，是从内存访问数据速度的 300 倍，是从磁盘中访问数据速度的 3000 万倍。所以利用 CPU 向量化执行的特性，对于程序的性能提升意义非凡。 ClickHouse 目前利用 SSE4.2 指令集实现向量化执行。

四、Clickhouse 总结

1. clickhouse 的舍与得

clickhouse 在追求极致性能的路上, 采取了很多优秀的设计. 如上述讲的列存、批处理、预排序等等. 但是架构都有两面性, 从一另方面也带来了一些缺点

• 高频次实时写入方面, 因 ck 会将批量数据直接落盘成小文件, 高频写入会造成大量小文件生成与合并, 影响查询性能. 所以 ck 官方也是建议大批低频的写入, 提高写入性能. 实际场景中建议在业务与数据库之间引入一层数据缓存层,来实现批量写入

• 查询并发问题, clickhouse 是采用并行处理机制, 即一个查询也会使用一半 cpu 去执行, 在安装时会自动识别 cpu 核数, 所以在发挥查询快的优势下, 也带来了并发能力的不足. 如果过多的查询数堆积达到 max_concurrent_queries 阈值, 则会报出 too many simultaneous queries 异常, 这也是 ck 的一种限流保护机制. 所以日常使用过程中注意慢 sql 的排查, 并发请求的控制是保证 ck 高可用的关键.

我们了解其原理之后, 能够对 clickhouse 有更深的认知, 也能够解释生产工作中曾经遇到的问题, 站在 clickhouse 架构师的角度去合理使用, 规避劣势, 发挥其特性.

2. clickhouse 在实际生产中遇到的问题

2.1 zookeeper 高负载影响

目前 clickhouse 开源版本 ReplicatedMergeTree 引擎强依赖 zookeeper 完成多副本选主, 数据同步, 故障恢复等功能, zookeeper 在负载较高的情况下,性能表现不佳, 甚至会出现副本无法写入, 数据无法同步问题. 分析 clickhouse 对 zookeeper 相关的使用, 以副本复制流程为例, ck 对 zookeeper 频繁的分发日志、数据交换是引起瓶颈原因之一.

解决通用方案:

京东零售: 自研基于 Raft 分布式共识算法的 zookeeper 替代方案.

2.2 资源管控问题

ClickHouse 的资源管控能力不够完善，在 insert、select 并发高的场景下会导致执行失败，影响用户体验。这是因为社区版 ClickHouse 目前仅提供依据不同用户的最大内存控制，在超过阈值时会杀死执行的 query。

易观性能对比: https://zhuanlan.zhihu.com/p/54907288

官网性能对比: https://clickhouse.com/

作者：京东科技 李丹枫

来源：京东云开发者社区 转载请注明来源