前言

本文介绍了ClickHouse的整体架构，并对ClickHouse中的一些重要的抽象对象进行了分析。然后此基础上，结合数据库的几个常用的操作，介绍了这些抽象对象的运作机制。

Clickhouse 架构简介

ClickHouse 使用的是MPP（Massively Parallel Processing，大规模并行处理）架构，该架构集群中的任意一台服务器都可以单独对外提供服务，是一个多主的结构。
ClickHouse 的体系结构图如下：

• 存储引擎负责将内存中的数据按照特定的规则持久化到磁盘（或HDFS、AWS S3）上，并在需要时将磁盘中的数据加载到内存中。
• 计算引擎则将用户提交的SQL语句转换成执行计划并对内存中的数据进行计算
• 服务接口对外提供服务，后台服务负责执行一些分区合并、数据删除等后台工作
• 管理工具则供系统运维工程师进行数据库的配置、管理

Clickhouse 的最小存储和计算单位为**块，**下图展示了各组件间通过块进行的交互逻辑：

Clickhouse 的核心抽象

列和字段

• Clickhouse 中的列是一个数组，可以通过索引获取对应列中的字段，索引下表从 1 开始。
• 列是不可变的，任何对列的操作都会产生一个全新的对象。
• 字段表示列数组中某一个独立的值，基于数仓的特性以及性能考虑，字段仅用于极少数情况。通常情况下，ClickHouse会将列当成整体去处理
  

数据类型

Clickhouse 支持很多种数据类型，多达100多种，数据类型的主要作用如下：

• 决定了数据在内存中的布局形式
• 决定了数据可以进行的运算方式
• 决定了数据持久化到磁盘上时数据文件的序列化和反序列化的方式

丰富的数据类型是 CLickhouse 进行强大的向量化计算的基础。

块

块是ClickHouse进行数据处理的基本单位。ClickHouse以块为单位对数据进行计算。
块由数据区(Data)的索引区(Index)组成，数据区由列紧密地堆叠而成，索引区存储数据区中列的索引，记录了列名、列的顺序等信息。
下图展示了块的布局示意：

表

Clickhouse 可以通过指定不同的表引擎创建不同的表存储结构，最流行的就是MergeTree存储引擎，下图展示了不同表引擎间的对比：

除了表引擎，Clickhouse 还支持对应的存储引擎来定义数据存储的位置，表引擎决定了数据的逻辑组成，存储引擎决定了文件的保存位置，下图对不同存储引擎特性进行了说明：

Clickhouse 的运作过程

数据插入过程

• 通过服务接口将 SQL 传给计算引擎
• 计算引擎将SQL 转换为 Pipeline 对象，在QueryPipeline中也保存了计算引擎格式化过的块数据，块对象会随着QueryPipeline一起传递到存储引擎中
• 存储引擎会将块中的数据保存到对应的数据文件中
  

数据查询过程

• 计算引擎会将SQL 编译转换为 QueryPipeline，该管道中包含一系列转换器，有的转换器可以通过存储引擎获取对应的数据块，然后再通过别的转换器实现过滤、转换、聚合等各种操作，最后通过服务接口将查询结果返回给用户。
  

数据更新和删除过程

• Clickhouse 对数据的更新和删除支持并不是很友好，不建议频繁删除和更新。
• Clickhouse 对数据的更新和删除，是对表结构的修改，而不是数据的变更。
• ClickHouse的解析器在收到UPDATE或DELETE语句时，会创建一个异步任务，同时立即返回执行完成。需要注意的是，此时数据并未完成更新或删除，而是会在未来的某个时刻由ClickHouse的后台进程完成数据表的重建。