简介： 本文尝试解读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场景中性能劣势非常明显。

原文链接
本文为阿里云原创内容，未经容许不得转载。