既然有了ES，为何还用ClickHouse——从原理万字总结ClickHouse为何这么快

ゞ浴缸里的玫瑰 2023-10-04 20:02 9阅读 0赞

> 通过了解 CH 的几大特性了解千亿级企业 ClickHouse 实时处理引擎架构设计、核心技术设计、运行机理全流程。

#### 文章目录 ####

*   *  1 初始 ClickHouse
     *   *  1.1 什么是 ClickHouse
         *  1.2 ClickHouse 的优缺点
         *  1.3 谁在用 ClickHouse
     *  3 数据引擎
     *   *  3.1 库引擎
         *  3.2 表引擎
         *  3.3 MergeTree 引擎
     *  4 工作原理
     *   *  4.1 数据分区
         *  4.2 列式存储
         *  4.3 一级索引
         *  4.4 二级索引
         *  4.5 数据压缩
         *  4.6 数据标记
     *  5 查询流程
     *  ref

### 1 初始 ClickHouse ###

#### 1.1 什么是 ClickHouse ####

**[ClickHouse][] 全称 Click Stream, Data WareHouse，是一个用于联机分析 (OLAP) 的列式数据库管理系统 (DBMS)**。由俄罗斯本土搜索引擎企业 Yandex 公司为了自己公司自家的 Web 流量分析产品 Yandex.Metrica 开发，后来经过演变，逐渐形成为现在的 ClickHouse。

#### 1.2 ClickHouse 的优缺点 ####

*  ClickHouse 的优点

ClickHouse 具有 ROLAP、在线实时查询、完整的 DBMS 功能支持、列式存储、不需要任何数据预处理、支持批量更新、拥有非常完善的 SQL 支持和函数、支持高可用、不依赖 Hadoop 复杂生态、开箱即用等许多特点。

在 1 亿数据集体量的情况下，ClickHouse 的平均响应速度是 Vertica 的 2.63 倍、InfiniDB 的 17 倍、MonetDB 的 27 倍、Hive 的 126 倍、MySQL 的 429 倍以及Greenplum 的 10 倍。测试结果：https://clickhouse.tech/benchmark/dbms/。

ClickHouse 虽然有这么多特点和优点，但显然也存在一些劣势：

1.  没有完整的事务支持；
2.  稀疏索引导致 ClickHouse 不擅长细粒度或者 key-value 类型数据的查询需求；
3.  缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据；
4.  不擅长 join 操作，且语法特殊；
5.  由于采用并行处理机制，即使一个查询也会使用一半 CPU 资源，所以不支持高并发。

#### 1.3 谁在用 ClickHouse ####

ClickHouse 非常适用于商业智能领域(也就是我们所说的 BI 领域)，除此之外，它也能够被广泛应用于广告流量、Web、App 流量、电信、金融、电子 商务、信息安全、网络游戏、物联网等众多其他领域。

ClickHouse 是近年来备受关注的开源列式数据库，主要用于数据分析(OLAP)领域。目前国内社区火热，各个大厂纷纷跟进大规模使用:

1.  今日头条内部用 ClickHouse 来做用户行为分析，内部一共几千个 ClickHouse 节点，单集群最大 1200 节点，总数据量几十 PB，日增原始数据 300TB 左右。
2.  腾讯内部用 ClickHouse 做游戏数据分析，并且为之建立了一整套监控运维体系。
3.  携程内部从 18 年 7 月份开始接入试用，目前 80% 的业务都跑在 ClickHouse 上。每天数据增量十多亿，近百万次查询请求。
4.  快手内部也在使用 ClickHouse，存储总量大约 10PB， 每天新增 200TB， 90% 查询小于 3S。

### 3 数据引擎 ###

ClickHouse 是一个 OLAP 分析型数据库，也有库和表的概念，而且库和表还都提供了不同类型的引擎，所以关于 ClickHouse 的底层引擎可以分为**数据库引擎**和**表引擎**两种。

#### 3.1 库引擎 ####

ClickHouse 支持在创建库的时候指定库引擎，目前支持 5 种，分别是：Ordinary，Dictionary， Memory， Lazy， MySQL。其中 Ordinary 是默认库引擎，在此类型库引擎下，可以使用任意类型的表引擎。

![1c3ffa81cc66ec7f963ec7308f8d26a8.png][]

*  **Ordinary 引擎**：默认引擎，如果不指定数据库引擎创建的就是 Ordinary 数据库；
 *  **Dictionary 引擎**：此数据库会自动为所有数据字典创建表；
 *  **Memory 引擎**：所有数据只会保存在内存中，服务重启数据消失，该数据库引擎只能够创建 Memory 引擎表；
 *  **MySQL 引擎**：改引擎会自动拉取远端 MySQL 中的数据，并在该库下创建 MySQL 表引擎的数据表；
 *  **Lazy 延时引擎**：在距最近一次访问间隔 `expiration_time_in_seconds` 时间段内，将表保存在内存中，仅适用于 Log 引擎表。

#### 3.2 表引擎 ####

相比于库引擎，表引擎在 ClickHouse 中的地位更加核心，它直接决定了 CH 中数据如何存储和读取，是否支持并发读写和 Idex 等等。

具体可看官网:https://clickhouse.tech/docs/zh/engines/table-engines/

ClickHouse 的表引擎提供了四个系列(Log、MergeTree、Integration、Special)大约 28 种表引擎，各有各的用途。比如 Log 系列用来做小表数据分 析，MergeTree 系列用来做大数据量分析，而 Integration 系列则多用于外表数据集成。Log、Special、Integration 系列的表引擎相对来说，应用场景有限，功能简单，应用特殊用途，MergeTree 系列表引擎又和两种特殊表引擎(Replicated，Distributed)正交形成多种具备不同功能的 MergeTree 表引擎。

![6fa0398883ec6c05ac9121da4fef1b4f.png][]

#### 3.3 MergeTree 引擎 ####

MergeTree 系列是 ClickHouse 官方主推的存储引擎，几乎支持全部的核心功能，该系列中，常用的表引擎有：MergeTree、ReplacingMergeTree、 CollapsingMergeTree、 VersionedCollapsingMergeTree、 SummingMergeTree、 AggregatingMergeTree 等。

![fb5ca640b55ebcf7e142d2aef6a82470.png][]

**关于 MergeTree 的特性**

原生 MergeTree 表引擎主要用于海量数据分析，支持数据分区、存储有序、主键索引、稀疏索引、数据 TTL 等。MergeTree 支持所有ClickHouse SQL 语法，但是有些功能与 MySQL 并不一致，比如在 MergeTree 中主键并不用于去重。

为了解决 MergeTree 相同主键无法去重的问题，ClickHouse 提供了 ReplacingMergeTree 引擎，用来做去重。ReplacingMergeTree 确保数据最终被去重，但是无法保证查询过程中主键不重复。因为相同主键的数据可能被 shard 到不同的节点，但是 compaction 只能在一个节点中进行，而且 optimize 的时机也不确定。

解决删除场景，CollapsingMergeTree 引擎要求在建表语句中指定一个标记列 Sign（插入的时候指定为 1，删除的时候指定为 -1），后台 Compaction 时会将主键相同、Sign 相反的行进行折叠，也即删除。来消除 ReplacingMergeTree 的限制。

为了解决 CollapsingMergeTree 乱序写入情况下无法正常折叠问题，VersionedCollapsingMergeTree 表引擎在建表语句中新增了一 列 Version，用于在乱序情况下记录状态行与取消行的对应关系。主键相同，且 Version 相同、Sign 相反的行，在 Compaction 时会被删除。

解决聚合场景，ClickHouse 通过 SummingMergeTree 来支持对主键列进行预先聚合。在后台 Compaction 时，会将主键相同的多行进行 sum 求 和，然后使用一行数据取而代之，从而大幅度降低存储空间占用，提升聚合计算性能。同理还有 AggregatingMergeTree用来预聚合平均值。

**MergeTree 的建表语法**

CREATE TABLE [IF NOT EXISTS] [db_name.]table_name ( name1 [type] [DEFAULT|MATERIALIZED|ALIAS expr], name2 [type] [DEFAUErEMAMLERLALLIZED|ALIAS expr], 省略...
    ) ENGINE = MergeTree()
    [PARTITION BY expr]
    [ORDER BY expr]
    [PRIMARY KEY expr]
    [SAMPLE BY expr]
    [SETTINGS name=value, 省略...]

其中几个关键选项：

<table> 
 <thead> 
  <tr> 
   <th>键</th> 
   <th>名称</th> 
   <th>必填</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><strong>PARTITION BY</strong></td> 
   <td>分区键</td> 
   <td>否</td> 
   <td>指定表数据以何种标准进行分区，分区键既可以是单个列字段，也可以是多个列字段，同时也支持使用列表达式。如果没有执行分区字段，则所有数据都在一个分区里</td> 
  </tr> 
  <tr> 
   <td><strong>ORDER BY</strong></td> 
   <td>排序键</td> 
   <td>是</td> 
   <td>用于指定在一个数据片段内，数据以何种标准排序。通常与主键相同</td> 
  </tr> 
  <tr> 
   <td><strong>PRIMARY KEY</strong></td> 
   <td>主键</td> 
   <td>是</td> 
   <td>声明后会依照主键字段生成一级索引。通常与主键相同</td> 
  </tr> 
  <tr> 
   <td><strong>SETTINGS</strong></td> 
   <td>索引粒度</td> 
   <td>否</td> 
   <td>默认值为 8192，即 MergeTree 索引在默认每间隔 8192 行数据才生成一条索引</td> 
  </tr> 
  <tr> 
   <td><strong>SAMPLE BY</strong></td> 
   <td>抽样表达式</td> 
   <td>否</td> 
   <td>用于声明数据以何种标准进行采样</td> 
  </tr> 
 </tbody> 
</table>

注意 **settings** 中的重要参数：

*  `index_granularity` 默认是 8192 = 1024 \* 8， 推荐不修改
 *  `index_granularity_bytes` 默认 10M，需要通过 enable\_mixed\_granularity\_parts 来开启
 *  `enable_mixed_granularity_parts` 默认开启自适应索引粒度
 *  `merge_with_ttl_timeout` 提供数据 TTL 功能。

**值得注意的是，MergeTree 主键索引是稀疏索引（一段数据创建一条索引）**。而每一条数据都生成索引则是**稠密索引**。

### 4 工作原理 ###

ClickHouse 从 OLAP 场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据 Sharding、数据 Partitioning、TTL、主备复制等丰富功能。这些功能共同为 ClickHouse 极速的分析性能奠定了基础。

#### 4.1 数据分区 ####

从物理结构来看，所谓**数据分区**，就是将所有一张表的说有数据按照某个维度划分成多个子文件夹。**与其他数据库以追加方式写入不同的是，MergeTree 每一批数据的写入（insert）都会生成一批新的分区目录**。在之后的某个时刻（写入后的 10～15 分钟，也可以手动执行 optimize 查询语句），ClickHouse 会通过后台任务再将属于相同分区的多个目录合并成一个新的目录。已经存在的旧分区目录也不会立即被删除，而是在之后的某个时刻通过后台任务被删除（默认 8 分钟）。

**分区文件夹的命名规则**

![f3d9ce37dce15330638b56a5cf3bf790.jpeg][]

分区的命名规则：`PartitionID_MinBlockNum_MaxBlockNum_Level`：

1）partition\_id：2021905，具体分区生成规则如下；

1）不指定分区键：如果建表时不指定分区键，则数据默认不分区，所有数据写到一个默认分区 all 里面。
    
    2）使用整型：如果分区键取值属于整型且无法转换为日期类型 YYYVYMMDD 格式，则直接按照该整型的字符形式输出作为分区 ID 的取值。
    
    3）使用日期类型：如果分区键取值属于日期类型，或者是能够转换为 YYYYMMDD 日期格式的整型，则按照分区表达式逻辑格式化后作为分区ID的取值。
    
    4）使用其它类型：如果分区键取值既不属于整型，也不屋于日期类型，如 String、Float 等，则通过 128 位 Hash 算法取其 Hash 值作为分区 ID 的取值。

2）min\_block\_number：1，最小块编号，MergeTree引|擎从1开始计数，每次+1；

3）max block\_number：1，最大块编号，新插入的数据，最小与最大编号一致；

4）level：0，这个可以理解为合并的次数，新插入的数据都是0，每合并1次+1。

**分区文件夹的合并规则**

![在这里插入图片描述][0faf81a047ef41cbb17f589713ca217a.png_pic_center]

**分区文件夹中文件含义**

![a7a4e72d8763963f93d41570191911e0.png][]

*（这里是新版 mergtree 引擎，bin 和 mrk3 只有一个文件，老版本的是表中的每一个列都会有各自的一个 bin 和 mrk2 文件）*

*  checksums.txt 校验文件。使用二进制格式存储。它保存了余下各类文件(primary.idx、count.txt等)的 size 大小及 size 的哈希值，用于快速校 验文件的完整性和正确性。
 *  columns.txt 列信息文件，使用明文格式存储。用于保存此数据分区下的列字段信息 。
 *  count.txt 计数文件，使用明文格式存储。用于记录当前数据分区目录下数据的总行数。
 *  primary.idx 一级索引文件，主键索引文件。
 *  xxx.bin 数据文件，使用压缩格式存储，默认为 LZ4 压缩格式，用于存储某一列的数据，每一列都对应一个该文件，如列 date 为 date.bin。
 *  xxx.mrk2 列字段标记文件，如果使用了自适应大小的索引间隔，则标记文件以 .mrk2 命名，否则以 .mrk 命名。
 *  还有二级索引 和 分区键相关信息文件，跳数索引文件等等

此处不展开，后面会详细介绍。

#### 4.2 列式存储 ####

因为 OLAP 一般都是对大量行、少量列做聚合分析，所以列式存储基本是必选方案，并且相比行式存储有以下几个优势：

*  **分析场景中往往需要读大量行但是少数几个列**。在行存模式下，数据按行连续存储，所有列的数据都存储在一个 block 中，不参与计算的列在 IO 时也要全部读出，读取操作被严重放大。而列存模式下，只需要读取参与计算的列即可，极大的减低了IO cost，加速了查询。
 *  同一列中的数据属于同一类型，**压缩比高，数据压缩效果显著**。列存往往有着高达十倍甚至更高的压缩比，节省了大量的存储空间，降低了存储成本。
 *  高压缩比意味着更小的 data size，从磁盘中读取相应数据耗时更短。同时也意味着同等大小的内存能够存放更多数据，系统cache效果更好。
 *  根据不同类型自由选择压缩算法，可以针对不同列类型，选择最合适的压缩算法。

![在这里插入图片描述][06ec0bb6eefa43ccacea26d14adb0b96.png_pic_center]

#### 4.3 一级索引 ####

使用 PRIMARY KEY 定义 MergeTree 的主键后，**会依据 index\_granularity** 间隔（默认 8192 行）为数据表生成**一级索引**并保存至 `primary.idx` 文件内。一级索引是稀疏索引，其好处就是少量的索引标记就能记录大量的数据区间位置信息，在 ClickHouse 中，一级索引常驻内存。总的来说：一级索引和标记文件一一对齐，两个索引标记之间的数据就是一个数据区间，在数据文件中，这个数据区间的所有数据，生成一个压缩数据块。

![在这里插入图片描述][baf2407f377748d785d877cb184b023a.png_pic_center]

当然稀疏索引也有一个缺点就它并**不去重**。要想实现去重效果，需要结合具体的表引擎 ReplacingMergeTree、CollapsingMergeTree、VersionedCollapsingMergeTree 实现。

#### 4.4 二级索引 ####

ClickHouse 的**二级索引**又被称作**跳数索引**，其目的与**一级索引**一样，为了减少查找范围。但二级索引默认是关闭的，通过 `granularity` 参数控制粒度，开启后会在分区目录生成 `skp_idx_[Column].idx` 与 `skp_idx_[Column].mrk` 文件。二级索引的生成规则也很简单：每隔 `granularity * index_granularity` 条数据，就会 生成一条二级。

一张表支持声明多个二级索引，并且支持多种类型：minmax(最大最小)、set(去重集合)、 ngrambf\_v1(ngram 分词布隆索引) 和 tokenbf\_v1(标点符号分词布隆索引)。

*  minmax:以 index\_granularity 为单位，存储指定表达式计算后的 min、max 值;在等值和范围查询中能够帮助快速跳过不满足要求的块，减少 IO。
 *  set(max\_rows):以 index granularity 为单位，存储指定表达式的 distinct value 集合，用于快速判断等值查询是否命中该块，减少 IO。
 *  ngrambf\_v1(n, size\_of\_bloom\_filter\_in\_bytes, number\_of\_hash\_functions, random\_seed):将 string 进行 ngram 分词后，构建 bloom filter，能够优化 等值、like、in 等查询条件.
 *  tokenbf\_v1(size\_of\_bloom\_filter\_in\_bytes, number\_of\_hash\_functions, random\_seed):与 ngrambf\_v1 类似，区别是不使用 ngram 进行分词，而是通过标点符号进行词语分割。
 *  bloom\_filter(\[false\_positive\]):对指定列构建 bloom filter，用于加速 等值、like、in 等查询条件的执行。

![在这里插入图片描述][3bc321f871884ded8f9cc0c42eddc3da.png_pic_center]

#### 4.5 数据压缩 ####

`column.bin` 是 ClickHouse 的数据存储文件，其中存储是一列的数据，由于一列是相同类型的数据，所以方便高效压缩。在进行压缩的时候，一个压缩**数据块**由**头信息**和**压缩数据**两部分组成。

*  头信息固定使用 9 位字节表示，具体由 1 个 UInt8(1字节)整型和 2 个 UInt32(4字节)整型组成，分别代表使用的压缩算法类型、压缩后的数据大小和压缩前的数据大小。
 *  每个压缩数据块的体积，按照其压缩前的数据字节大小，都被严格控制在 64KB~1MB，其上下限分别由 min\_compress\_block\_size(默认65536=64KB) 与 max\_compress\_block\_size(默认1048576=1M)参数指定。

**具体压缩规则**

1.  单个批次数据 size < 64KB：如果单个批次数据小于 64KB，则继续获取下一批数据，直至累积到size >= 64KB时，生成下一个压缩数据块。如果平均每条 记录小于8byte，多个数据批次压缩成一个数据块；
2.  单个批次数据 64KB <= size <=1MB：如果单个批次数据大小恰好在 64KB 与 1MB 之间，则直接生成下一个压缩数据块；
3.  单个批次数据 size > 1MB：如果单个批次数据直接超过 1MB，则首先按照 1MB 大小截断并生成下一个压缩数据块。剩余数据继续依照上述规则执行。此时，会出现一个批次数据生成多个压缩数据块的情况。再如果平均每条记录的大小超过 128byte，则会把当前这一个批次的数据压缩成多个数据块。

![在这里插入图片描述][615c2d8ef16346afac709218ff09e816.png_pic_center]

#### 4.6 数据标记 ####

**数据标记文件**与 `.bin` 文件一一对应，**是一级索引和数据之间的映射**。即每一个列字段 `[Column].bin` 文件都有一个与之对应的 `[Column].mrk2` 数据标记文件，用于记录数据在 `.bin` 文件中的偏移量信息。一行标记数据使用一个元组表示，元组内包含两个整型数值的偏移量信息。它们分别表示在此段数据区间内，在对应的 .bin 压缩文件中，压缩数据块的起始偏移量，以及将该数据压缩块解压后，其未压缩数据的起始偏移量。标记数据与一级索引数据不同，它并不能常驻内存，而是使用 LRU 策略加快其取用速度。

所以数据的读取流程就是：

1.  先根据一级索引，找到标记文件中的对应数据压缩块信息，并在 `[Column].bin` 文件中找到对应压缩数据块，读取并解压；
2.  从解压缩的数据块中，以 `index_granularity` 的粒度加载数据到内存中，执行查询，直至找到结果数据。

### 5 查询流程 ###

数据查询的本质，可以看作一个不断减小数据范围的过程。在最理想的情况下，MergeTree 首先可以依次借助分区索引、一级索引和二级索引，将数据 扫描范围缩至最小。然后再借助数据标记，将需要解压与计算的数据范围缩至最小。

![在这里插入图片描述][4cf2cb2d9f5e4291aa20e406209ee92b.png_pic_center]

1.  指定分区
2.  指定字段（\[Column\].bin）
3.  根据一级索引（primary.idx）定位到标记文件（\[Column\].mrk2）中的一条记录
4.  扫描对应字段的 mark 标记文件，获取两个偏移量信息
5.  根据第一个偏移量（查找数据所在压缩数据块处于这个 `.bin` 文件中的偏移量）定位到一个压缩数据块
6.  读取数据到内存执行解压缩
7.  根据第二个偏移量（查找数据在压缩数据块解压后的偏移量）去内存解压缩数据中找到对应的数据

当然上述为理想情况，如果一次查询没有命中任何索引（分区、一级和二级索引），那么 MergeTree 就不能预先减少数据范围。不过 ClickHouse 依旧可以借助数据标记，以多线程的形式同时读取多个压缩数据块，提升查询速度。

### ref ###

[为什么ClickHouse这么快？][ClickHouse 1]  
[Clickhouse工作原理][Clickhouse]

[ClickHouse]: https://clickhouse.tech
[1c3ffa81cc66ec7f963ec7308f8d26a8.png]: https://img-blog.csdnimg.cn/img_convert/1c3ffa81cc66ec7f963ec7308f8d26a8.png
[6fa0398883ec6c05ac9121da4fef1b4f.png]: https://img-blog.csdnimg.cn/img_convert/6fa0398883ec6c05ac9121da4fef1b4f.png
[fb5ca640b55ebcf7e142d2aef6a82470.png]: https://img-blog.csdnimg.cn/img_convert/fb5ca640b55ebcf7e142d2aef6a82470.png
[f3d9ce37dce15330638b56a5cf3bf790.jpeg]: https://img-blog.csdnimg.cn/img_convert/f3d9ce37dce15330638b56a5cf3bf790.jpeg
[0faf81a047ef41cbb17f589713ca217a.png_pic_center]: https://img-blog.csdnimg.cn/0faf81a047ef41cbb17f589713ca217a.png#pic_center
[a7a4e72d8763963f93d41570191911e0.png]: https://img-blog.csdnimg.cn/img_convert/a7a4e72d8763963f93d41570191911e0.png
[06ec0bb6eefa43ccacea26d14adb0b96.png_pic_center]: https://img-blog.csdnimg.cn/06ec0bb6eefa43ccacea26d14adb0b96.png#pic_center
[baf2407f377748d785d877cb184b023a.png_pic_center]: https://img-blog.csdnimg.cn/baf2407f377748d785d877cb184b023a.png#pic_center
[3bc321f871884ded8f9cc0c42eddc3da.png_pic_center]: https://img-blog.csdnimg.cn/3bc321f871884ded8f9cc0c42eddc3da.png#pic_center
[615c2d8ef16346afac709218ff09e816.png_pic_center]: https://img-blog.csdnimg.cn/615c2d8ef16346afac709218ff09e816.png#pic_center
[4cf2cb2d9f5e4291aa20e406209ee92b.png_pic_center]: https://img-blog.csdnimg.cn/4cf2cb2d9f5e4291aa20e406209ee92b.png#pic_center
[ClickHouse 1]: https://www.modb.pro/db/37700
[Clickhouse]: https://blog.csdn.net/u013933879/article/details/118753265