简介： 本文尝试解读 ClickHouse 存储层的设计与实现，分析它的性能奥秘
作者：和君
**
引言 **
ClickHouse 是近年来备受关注的开源列式数据库，次要用于数据分析（OLAP）畛域。目前国内各个大厂纷纷跟进大规模应用：
- 今日头条外部用 ClickHouse 来做用户行为剖析，外部一共几千个 ClickHouse 节点，单集群最大 1200 节点，总数据量几十 PB，日增原始数据 300TB 左右。
- 腾讯外部用 ClickHouse 做游戏数据分析，并且为之建设了一整套监控运维体系。
- 携程外部从 18 年 7 月份开始接入试用，目前 80% 的业务都跑在 ClickHouse 上。每天数据增量十多亿，近百万次查问申请。
- 快手外部也在应用 ClickHouse，存储总量大概 10PB，每天新增 200TB，90% 查问小于 3S。
- 阿里外部专门孵化了相应的云数据库 ClickHouse，并且在包含手机淘宝流量剖析在内的泛滥业务被宽泛应用。
在国外，Yandex 外部有数百节点用于做用户点击行为剖析，CloudFlare、Spotify 等头部公司也在应用。
在开源的短短几年工夫内，ClickHouse 就俘获了诸多大厂的“芳心”，并且在 Github 上的活跃度超过了泛滥老牌的经典开源我的项目，如 Presto、Druid、Impala、Geenplum 等；其受欢迎水平和社区炽热水平可见一斑。
而这些景象背地的重要起因之一就是它的极致性能，极大地减速了业务开发速度，本文尝试解读 ClickHouse 存储层的设计与实现，分析它的性能奥秘。
ClickHouse 的组件架构
下图是一个典型的 ClickHouse 集群部署结构图，合乎经典的 share-nothing 架构。
整个集群分为多个 shard（分片），不同 shard 之间数据彼此隔离；在一个 shard 外部，可配置一个或多个 replica（正本），互为正本的 2 个 replica 之间通过专有复制协定放弃最终一致性。
ClickHouse 依据表引擎将表分为本地表和分布式表，两种表在建表时都须要在所有节点上别离建设。其中本地表只负责以后所在 server 上的写入、查问申请；而分布式表则会依照特定规定，将写入申请和查问申请进行拆解，分发给所有 server，并且最终汇总申请后果。
ClickHouse 写入链路
ClickHouse 提供 2 种写入办法，1）写本地表；2）写分布式表。
写本地表形式，须要业务层感知底层所有 server 的 IP，并且自行处理数据的分片操作。因为每个节点都能够别离间接写入，这种形式使得集群的整体写入能力与节点数齐全成正比，提供了十分高的吞吐能力和定制灵活性。然而相对而言，也减少了业务层的依赖，引入了更多复杂性，尤其是节点 failover 容错解决、扩缩容数据 re-balance、写入和查问须要别离应用不同表引擎等都要在业务上自行处理。
而写分布式表则绝对简略，业务层只须要将数据写入繁多 endpoint 及繁多一张分布式表即可，不须要感知底层 server 拓扑构造等实现细节。写分布式表也有很好的性能体现，在不须要极高写入吞吐能力的业务场景中，倡议间接写入分布式表升高业务复杂度。
以下论述分布式表的写入实现原理。
ClickHouse 应用 Block 作为数据处理的外围形象，示意在内存中的多个列的数据，其中列的数据在内存中也采纳列存格局进行存储。示意图如下：其中 header 局部蕴含 block 相干元信息，而 id UInt8、name String、_date Date 则是三个不同类型列的数据表示。
在 Block 之上，封装了可能进行流式 IO 的 stream 接口，别离是 IBlockInputStream、IBlockOutputStream，接口的不同对应实现不同性能。
当收到 INSERT INTO 申请时，ClickHouse 会结构一个残缺的 stream pipeline，每一个 stream 实现相应的逻辑：
InputStreamFromASTInsertQuery #将 insert into 申请封装为 InputStream 作为数据源 -> CountingBlockOutputStream #统计写入 block count -> SquashingBlockOutputStream #积攒写入 block，直到达到特定内存阈值，晋升写入吞吐 -> AddingDefaultBlockOutputStream #用 default 值补全缺失列 -> CheckConstraintsBlockOutputStream #查看各种限度束缚是否满足 -> PushingToViewsBlockOutputStream #如有物化视图，则将数据写入到物化视图中 -> DistributedBlockOutputStream #将 block 写入到分布式表中
注：* 左右滑动阅览
在以上过程中，ClickHouse 十分重视细节优化，处处为性能思考。在 SQL 解析时，ClickHouse 并不会一次性将残缺的 INSERT INTO table(cols) values(rows)解析结束，而是先读取 insert into table(cols)这些短小的头部信息来构建 block 构造，values 局部的大量数据则采纳流式解析，升高内存开销。在多个 stream 之间传递 block 时，实现了 copy-on-write 机制，尽最大可能缩小内存拷贝。在内存中采纳列存存储构造，为后续在磁盘上间接落盘为列存格局做好筹备。
SquashingBlockOutputStream 将客户端的若干小写，转化为大 batch，晋升写盘吞吐、升高写入放大、减速数据 Compaction。
默认状况下，分布式表写入是异步转发的。DistributedBlockOutputStream 将 Block 依照建表 DDL 中指定的规定（如 hash 或 random）切分为多个分片，每个分片对应本地的一个子目录，将对应数据落盘为子目录下的.bin 文件，写入实现后就返回 client 胜利。随后分布式表的后盾线程，扫描这些文件夹并将.bin 文件推送给相应的分片 server。.bin 文件的存储格局示意如下：
ClickHouse 存储格局
ClickHouse 采纳列存格局作为单机存储，并且采纳了类 LSM tree 的构造来进行组织与合并。一张 MergeTree 本地表，从磁盘文件形成如下图所示。
本地表的数据被划分为多个 Data PART，每个 Data PART 对应一个磁盘目录。Data PART 在落盘后，就是 immutable 的，不再变动。ClickHouse 后盾会调度 MergerThread 将多个小的 Data PART 一直合并起来，造成更大的 Data PART，从而取得更高的压缩率、更快的查问速度。当每次向本地表中进行一次 insert 申请时，就会产生一个新的 Data PART，也即新增一个目录。如果 insert 的 batch size 太小，且 insert 频率很高，可能会导致目录数过多进而耗尽 inode，也会升高后盾数据合并的性能，这也是为什么 ClickHouse 举荐应用大 batch 进行写入且每秒不超过 1 次的起因。
在 Data PART 外部存储着各个列的数据，因为采纳了列存格局，所以不同列应用齐全独立的物理文件。每个列至多有 2 个文件形成，别离是.bin 和 .mrk 文件。其中.bin 是数据文件，保留着理论的 data；而.mrk 是元数据文件，保留着数据的 metadata。此外，ClickHouse 还反对 primary index、skip index 等索引机制，所以也可能存在着对应的 pk.idx，skip_idx.idx 文件。
在数据写入过程中，数据被依照 index_granularity 切分为多个颗粒（granularity），默认值为 8192 行对应一个颗粒。多个颗粒在内存 buffer 中积攒到了肯定大小（由参数 min_compress_block_size 管制，默认 64KB），会触发数据的压缩、落盘等操作，造成一个 block。每个颗粒会对应一个 mark，该 mark 次要存储着 2 项信息：1）以后 block 在压缩后的物理文件中的 offset，2）以后 granularity 在解压后 block 中的 offset。所以 Block 是 ClickHouse 与磁盘进行 IO 交互、压缩 / 解压缩的最小单位，而 granularity 是 ClickHouse 在内存中进行数据扫描的最小单位。
如果有 ORDER BY key 或 Primary key，则 ClickHouse 在 Block 数据落盘前，会将数据依照 ORDER BY key 进行排序。主键索引 pk.idx 中存储着每个 mark 对应的第一行数据，也即在每个颗粒中各个列的最小值。
当存在其余类型的稠密索引时，会额定减少一个 <col>_<type>.idx 文件，用来记录对应颗粒的统计信息。比方：
- minmax 会记录各个颗粒的最小、最大值；
- set 会记录各个颗粒中的 distinct 值；
- bloomfilter 会应用近似算法记录对应颗粒中，某个值是否存在；
在查找时，如果 query 蕴含主键索引条件，则首先在 pk.idx 中进行二分查找，找到符合条件的颗粒 mark，并从 mark 文件中获取 block offset、granularity offset 等元数据信息，进而将数据从磁盘读入内存进行查找操作。相似的，如果条件命中 skip index，则借助于 index 中的 minmax、set 等信念，定位出符合条件的颗粒 mark，进而执行 IO 操作。借助于 mark 文件，ClickHouse 在定位出符合条件的颗粒之后，能够将颗粒均匀分派给多个线程进行并行处理，最大化利用磁盘的 IO 吞吐和 CPU 的多核解决能力。
总结
本文次要从整体架构、写入链路、存储格局等几个方面介绍了 ClickHouse 存储层的设计，ClickHouse 奇妙地联合了列式存储、稠密索引、多核并行扫描等技术，最大化压迫硬件能力，在 OLAP 场景中性能劣势非常明显。
原文链接
本文为阿里云原创内容，未经容许不得转载。