clickhouse笔记04--快速理解分片和副本

1 介绍

Clickhouse 性能如此强大是离不开其副本和分片功能的，毕竟单节点总有性能天花板的。Clickhouse 中集群是副本和分片的基础，其定义了多个节点的拓扑关系。

从数据层面区分，假设ClickHouse的N个节点组成了一个集群，在集群的各个节点上，都有一张结构相同的数据表Y(如下图所示)。如果N1的Y和N2的Y中的数据完全不同，则N1和N2互为分片；如果它们的数据完全相同，则它们互为副本。换言之，分片之间的数据是不同的，而副本之间的数据是完全相同的。
从功能作用层面区分，使用副本的主要目的是防止数据丢失，增加数据存储的冗余；而使用分片的主要目的是实现数据的水平切分。

2 副本&分片核心要点

2.1 数据副本

ClickHouse 具备多种 MergerTree 引擎，加上 Replicated 后又形成了一些列的变种引擎，该引擎支持数据副本，如下图所示。

ReplicatedMergeTree 是MergeTree 的派生引擎，它在 MergeTree 的基础上新增发布数系统能力。 只有使用了Replicated * 复制表系列引擎，才能使用副本的能力。

相对于MergeTree， ReplicatedMergeTree 新增了ZooKeeper (后续简称ZK)相关的功能，它会在ZooKeeper内创建一系列的监听节点，并以此实现多个实例之间的通信。在整个通信过程中，ZooKeeper并不会涉及表数据的传输，因此我们也不用担心ZooKeeper 的压力太大。

ReplicatedMergeTree 在设计上具备如下特点：

• 依赖 ZooKeeper： 在执行 INSERT 和 ALTER 的时候需要借助 ZK 的分布式协同能力，在查询副本的时候不需使用ZK。
• 表级别的副本： 副本实在表级别定义的，每张表的副本配置可以按照需求定义(副本数量、在集群分布)
• 多主架构：在任何一个节点执行 INSERT 和 ALTER 效果是相同的
• Block 数据库： 执行 INSERT 命令时候会将数据切分成多个Block 数据块
• 原子性：一个Block数据块要么全部写入成功、要么全部失败
• 唯一性：写入数据块时候会按照数据顺序、数据行、数据大小等指标计算Hash信息摘要并记录在案; 可以预防异常原因引起的Block数据库块重复写入问题。

2.2 ReplicatedMergeTree 原理

在ReplicatedMergeTree的核心逻辑中，大量运用了ZooKeeper的能力，以实现多个ReplicatedMergeTree副本实例之间的协同，包括主副本选举、副本状态感知、操作日志分发、任务队列和BlockID去重判断等。在执行INSERT数据写入、MERGE分区和MUTATION操作的时候，都会涉及与ZooKeeper的通信。

ReplicatedMergeTree需要依靠ZooKeeper的事件监听机制以实现各个副本之间的协同。所以，在每张ReplicatedMergeTree表的创建过程中，它会以zk_path为根路径，在Zoo-Keeper中为这张表创建一组监听节点。按照作用的不同，监听节点可以大致分成如下几类：

1. 元数据， 包括 /metadata 、/columns 、 /replicas
2. 判断标识，包括 /leader_election 、/blocks 、/block_numbers 、/quorum
3. 操作日志，包括 /log 、/mutations 、/replicas/{replica_name}/* 、/queue 、/log_pointer 、/mutation_pointer

副本协同的核心流程主要有INSERT、MERGE、MUTATION和ALTER四种，分别对应了数据写入、分区合并、数据修改和元数据修改。INSERT和ALTER查询是分布式执行的。

1. INSERT 的核心执行流程
1.1 创建第一个副本
1.2 创建第二个副本实例
1.3 向第一个副本实例写入数据
1.4 由第一个副本推送Log日志
1.5 第二个副本实例拉取Log日志
1.6 第二个副本实例向其它副本发其下载请求
1.7 第一个副本实例响应数据下载
1.8 第二个副本实例下载数据并完成本地写入
2. Merge 的核心执行流程
2.1 创建远程连接，尝试与主副本通信
2.2 主副本接收通信
2.3 由主副本定制Merge 计划并推送log日志
2.4 各个副本分别拉取log日志
2.5 各个副本分别在本地执行 Merge
注意：乌兰合并动作在哪个副本触发，都会转交到主副本，再由主副本负责合并计划的定制、消息日志推送、对日志接收情况的监控。
3. MUTATION的核心执行流程
3.1 推送Mutation日志
3.2 所有副本实例各自监听mutation日志
3.3 由主副本实例响应Mutation日志并推送Log日志
3.4 各个副本实例分别拉取Log日志
3.5 各个副本实例分别在本地执行Mutation
4. ALTER 的核心执行流程
4.1 修改共享元数据
4.2 监听共享元数据变更并各自执行本地修改
4.3 确认所有副本完成修改
注意：ALTER 流程执行过程中不涉及 log日志的分发。

2.3 数据分片

通过数据副本能投降低数据丢失风险、提高查询性能，单无法提高数据容量。为了解决该问题就引入了数据分片的概念，它将数据水平切分，提高ClickHouse的横向扩展能力。

ClickHouse中的每个服务节点都可称为一个shard（分片）。从理论上来讲，假设有N(N>=1)张数据表A，分布在N个ClickHouse服务节点，而这些数据表彼此之间没有重复数据，那么就可以说数据表A拥有N个分片。
ClickHouse 的数据分片需要结合Distributed 表引擎一起使用。Distributed表引擎自身不存储任何数据，它能够作为分布式表的一层透明代理，在集群内部自动开展数据的写入、分发、查询、路由等工作。

ClickHouse 使用了集群配置后就可以使用其提供的分布式DDL执行相关命令了，例如可以过 CREATE/DROP/RENAME/ALTER TABLE ON CLUSTER cluster_name 来执行分布式DDL。启动cluster_name 对应了配置文件中集群名称，ClickHouse 会根据集群配置信息分别在各个节点执行 DDL语句。
分布式DDL核心执行流程和副本协同类似，大致包含如下步骤：

1. 推送DDL日志: 入口节点(ck01)将DDL日志信息推送到ZK；
2. 拉取并执行: 集群中节点(ck01 ck02 …) 监听ZK中的日志，并拉取日志到本地，加入执行流程；
3. 确认执行进度: 入口节点(ck01)确认执行进度，若超时则转入后台线程继续等待。

2.4 Distributed 原理解析

Distributed表引擎是分布式表的代名词，它自身不存储任何数据，而是作为数据分片的透明代理，能够自动路由数据至集群中的各个节点，所以Distributed表引擎需要和其他数据表引擎一起协同工作，如下图所示。
从图中可以发现分布式表和本地表是一对多的关系，ClickHouse中通过分布式表代理操作多张本地表。

对于分布式表与本地表之间表结构的一致性检查，Distributed表引擎采用了读时检查的机制，这意味着如果它们的表结构不兼容，只有在查询时才会抛出错误，而在创建表时并不会进行检查。

1. 分布式写入的核心流程
   通过 Distributed表引擎代理写入分片(此处假设一个集群2个分片 0个副本，对Distributed表执行 INSERT 操作)
   1.1 在第一个分片节点写入本地分片数据
   1.2 第一个分片建立远端连接，准备发送远端分片数据
   1.3 第一个分片向远端分片发送数据
   1.4 第二个分片接收数据并写入本地
   1.5 有第一个分片确认写入完成
2. 分布式查询的核心流程
   面向集群查询的时候，只能通过Distributed 表引擎实现。
   2.1 查询各个分片数据
   2.2 合并返回结果

3 注意事项

1. 对于ClickHouse集群，我们可以使用分布式DDL语句迅速在各个节点创建相应的本地表，而不用每个节点单独创建。
2. 进行分布式查询的时候，若在IN或者JOIN查询子句使用分布式表的时候容易将查询请求放大N的平方倍， 此时可以使用Global优化分布式子查询(例如在子查询中使用Global IN)。

4 说明

本文中绝大部分内容来自于官方文档和 ClickHouse原理解析与应用实战， 若想了解更多详细内容和查阅官方文档或者正版书籍。
ClickHouse官方文档
ClickHouse原理解析与应用实战