《ClickHouse原理解析与应用实践》读书总结

本文是对《ClickHouse原理解析与应用实践》一书的概括性总结，整体章节和结构尊重原文，由于书的出版在2019年，版本较旧，所以对应部分有修正，修正来源于clickhouse官方设计文档。因此本文是该书与clickhouse官方文档的一个互补结合。

两个有用的小工具：

clickhouse-benchmark： echo 'SELECT count(*) from tutorial.visits_v1' | clickhouse-benchmark -i 20000 可以对指定查询做一次benchmark。我在1核2G的服务器上跑了下，得到结果：

clickhouse常量类型推断：最小存储代价

各种长度的整数、浮点数，定点数，字符串、定长字符串、32位UUID、三种时间类型（精度最高就到亚秒）

其中array和nested两种嵌套类型，可以之后再用SQL(array [left] join)打平成多行数据。

clickhouse共有5种库引擎：

数据库本质上就是文件目录。

表也要自选引擎。

有三种默认值表达式：

只支持MEMORY表引擎，不属于任何数据库，生命周期和Session绑定，连接断掉，表就废掉。 一般不用，主要是内核用。

概念同HIVE分区表，但是它只作用于本地，没有什么分布式的概念。 只有MergeTree家族的表引擎才支持分区。 分区可以在不同的表间进行复制迁移，但两个表的结构和分区键必须一致。 第六章详细介绍。

可以将一个分区内的某列数据清空，设置为初始值。 也可以将分区卸载/装载，本质上，是分区文件夹位置的迁移，不会真正的删除。

需要主动声明ON CLUSTER xx_cluster，才会把DDL的SQL语句在某集群内统一执行。 数据块为单位进行操作，在块级别有原子性

由于列存储，clickhouse的修改和删除非常的重。会把一个表的所有分区的目录copy一次，去掉那些删除的行，直到写一次merge时，原先inactive的数据才会被删除。 而且，异步、非原子性。

存于内存的一个scheme，可以build on top of many externel sources(clickhouse, mysql, linux file...)。 scheme以key-attributes形式存储，key是一个/多个属性，attributes就是一组属性 默认惰性读取（用到时从外部source读进内存），可以改配置为启动时读取。 外部source包括本地文件、远程文件、可执行文件、clickhouse、ODBC、DBMS(mysql/postgres/mongoDB/redis)。 这意味着，传统的ETL功能，很大程度上被代替了。但是实际上数据主要在内存，没有真正落入clickhouse表（虽然我们能以类似表的SQL去访问它）。 在2020年及之后的clickhouse中，诞生了dictionary表引擎，使得访问dictionary和访问普通数据库表的操作，完全一致。

一定时间范围内随机定期更新，能增量就增量，不能增量就全量。

MergeTree在写入数据时，是以block为单位写入的，而且block是immutable的。clickhouse通过后台线程，定期合并这些block，属于同一个分区的block会被合成新的block，因此被称为MergeTree。

几个参数：

物理存储结构如下：

如果分区key是整数、日期，则转化为字符串作为分区id，浮点、字符串要哈希之后作为分区id。多个key作为分区key用'-'来连接。

MergeTree的一个重要特征就是，每次写入的时候，都会根据分区key产生一批新的分区目录，这和原先有的分区目录可能会有重复。比如，同样是'202104'的分区，可能最后产生了多个分区目录，而不是在一个分区目录下追加文件。 然后，这些相同分区的目录，通过后台任务进行合并，称为新的分区目录。旧分区目录延迟一段时间再删除。

每一个分区目录都有三个属性：

一般来说ORDER KEY和PRIMARY KEY都是一致的，他们指定了主索引和数据的排序顺序。 主索引是稀疏索引，默认粒度8192. 由于占用空间极小，所以常驻内存，访问速度极快。 数据文件(.bin)也是按照索引粒度进行数据块的压缩；标记文件也会被索引粒度所影响。 primary.idx按照索引粒度，将相应位置的PRIMARY KEY读出来，按照顺序紧密拼接起来，没有一个多余的字节。多个key之间也不分隔。

clickhouse执行join（本地）时会把右表当做小表完全拉进内存与左表比较；而且JOIN没有任何缓存，频繁使用的右表，最好都做成JOIN引擎表来进行缓存；clickhouse是大表模式，join非常吃力，如果需要连续补充多个维度，可以将维度表作为数据字典来join。

插入数据时，数据首先写入内存缓冲，然后刷到磁盘tmp目录，全部刷完后，整合进正式分区，然后将日志entry同步至zookeeper。数据写入以block为基本单元和最小粒度（max_insert_block_size），对block的写入保持原子性。 clickhouse副本写入依赖zk，但是查询并不依赖zk。同一个shard写进同一个zk_path，各个副本保持不一样的replica_name。 ch的副本是表级别的，而且是多主架构，这种架构使得副本不仅仅为了容错，每个副本都可以作为读写的入口，用以负载均衡。

replicatedMergeTree会在zk_path上为这张表创建一组监听节点，分成以下几类：

LogEntry包含以下信息：

MutationEntry包含以下信息：

需要主副同步的操作主要有INSERT,MERGE,MUTATION,ALTER四种，即数据写入，分区合并，数据修改，元数据修改四种。 对于其他SQL指令，如SELECT,CREATE,DROP,RENAME,ATTACH等，不支持分布式，要不然登录每台机器结点分别执行，要不然用一些trick，后面讲。

clickhouse可以灵活配置多个cluster，在每个cluster，一个表可以由多个shard（水平数据分区），每个shard内部还可以有数据副本（垂直数据冗余）。 有了cluster name的配置后，一些DDL语句可以用ON CLUSTER cluster_name进行分布式执行，原理就是根据配置，在每个replica都执行相同的指令。 其中{replica}，{shard}可以以宏的形式写，因为在集群每台机器内，都有表存储了当前机器的replica shard分别是什么值。

DDL的分布式执行也是借助于zk，task的发布、状态、完成情况都记录在zk，秉着谁发起谁负责的策略，发起者负责监视是否cluster内所有节点任务完成，完成则结束返回，否则要转入后台执行。

分布式表对应多个本地表，在多个本地shard表提供一个分布式透明性的服务。分布式表的INSERT SELECT直接作用于其管理的本地表，但是CREATE DROP RENAME之类的元数据操作只作用于自身，不作用与本地表。不支持MUTATION。 分布式表要求所有本地表结构一致，命名相同，仅shard和replica参数不同，在读时检查； 分布式表创建时也要指定ON CLUSTER，在集群所有节点创建分布式表，使得整个集群都可以成为读写入口。 分布式表创建时要指定一个sharding key和sharding function进行分区，function最终返回一个整数即可; 每个shard在配置文件中都有一个权重，代表数据流入的比率，clickhouse按照weights将sharding function的值域划分为几个连续区间，承接数据写入。

DISTRIBUTED表的数据写入一个shard节点，首先是，把本shard内的数据写入分区，然后把其他shard分区的挑出来，分别写到一个固定位置去，形成分区；本shard内有一个对固定位置的监视器，监测到分区目录变化后，会根据目录名，立即与远程shard建立联系，压缩传递数据。秉着谁执行谁负责的原则，写入shard负责确保数据都已经正确写入，结束返回。 写入的过程可以设置同步/异步，异步不用等待远程写完，同步需要设置超时。

上面的过程只考虑了sharding，没有考虑replica，replica的同步写入可以有两种模式，通过配置文件写死配置。第一种可以通过上述的方式，由distribute引擎写入replica，然而这种方式，写入节点要传输和写入的replica太多了，容易造成单点瓶颈；另一种方式是通过Repliacted-MergeTree，利用zk传输日志来进行同步，这样写入节点只需在每个shard选一个replica写入即可，具体选哪个可以根据一个全局计数器errors_count来选择。

分布式查询，要在每一个shard选择一个replica，这就涉及一个负载均衡算法，由参数控制，有以下四种

可想而知，查询也是谁执行谁负责，谁是入口查询节点，谁就要串联整个查询过程。包括分割分布式查询为本地子查询，选择连接其他shard的节点，传递SQL，收到结果数据，UNION返回结果。