Clickhouse系列三：表引擎副本机制

背景概述

        Clickhouse通过表数据的冗余存储，来达到防止数据丢失的问题。这也就是常说的数据副本机制，但是副本数据和真实数据都存储了，服务器的容量就不够了，这时我们就需要实现数据的水平切分，来解决单个服务器容量不够的问题。这就是常说的数据分片机制

数据副本机制
ClickHouse依靠ReplicatedMergeTree引擎族与ZooKeeper实现了复制表机制, 成为其高可用的基础.ReplicatedMergeTree引擎族包含如下的表种类

• ReplicatedMergeTree
• ReplicatedSummingMergeTree
• ReplicatedReplacingMergeTree
• ReplicatedAggregatingMergeTree
• ReplicatedCollapsingMergeTree
• ReplicatedVersionedCollapsingMergetree
• ReplicatedGraphiteMergeTree

目前阶段只有上面这些表种类支持副本机制。副本是表级别的，不是整个服务器级的。所以，服务器里可以同时有复制表和非复制表。因为Clickhouse复制表机制是通过zookeeper实现的。所以要使用副本，需在配置文件中设置 ZooKeeper 集群的地址。后面会详细介绍下ReplicatedMergeTree表引擎在Clickhouse数据库中是怎么做的。

数据副本的特点

作为数据副本的主要实现载体，ReplicatedMergeTree在设计上有一些显著特点。

• 依赖ZooKeeper：在执行INSERT和ALTER查询的时候，ReplicatedMergeTree需要借助ZooKeeper的分布式协同能力，以实现多个副本之间的同步。但是在查询副本的时候，并不需要使用ZooKeeper。
• 表级别的副本：副本是在表级别定义的，所以每张表的副本配置都可以按照它的实际需求进行个性化定义，包括副本的数量，以及副本在集群内的分布位置等。
• 多主架构（Multi Master）：可以在任意一个副本上执行INSERT和ALTER查询，它们的效果是相同的。这些操作会借助ZooKeeper的协同能力被分发至每个副本以本地形式执行。
• Block数据块：在执行INSERT命令写入数据时，会依据max_insert_block_size的大小（默认1048576行）将数据切分成若干个Block数据块。所以Block数据块是数据写入的基本单元，并且具有写入的原子性和唯一性。
• 原子性：在数据写入时，一个Block块内的数据要么全部写入成功，要么全部失败。
• 唯一性：在写入一个Block数据块的时候，会按照当前Block数据块的数据顺序、数据行和数据大小等指标，计算Hash信息摘要并记录在案。在此之后，如果某个待写入的Block数据块与先前已被写入的Block数据块拥有相同的Hash摘要（Block数据块内数据顺序、数据大小和数据行均相同），则该Block数据块会被忽略。这项设计可以预防由异常原因引起的Block数据块重复写入的问题。

下面我们讲解下Clickhouse是如何通过ReplicatedMergeTree来达到数据复制高可用的。

ReplicatedMergeTree原理解析

上面说到clickhouse的副本机制是基于ReplicatedMergeTree表实现的. 用户在创建每张表的时候, 可以决定该表是否高可用。
表创建方式

CREATE TABLE table_name
(
EventDate DateTime,
CounterID UInt32,
UserID UInt32
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/table_name', '{replica}')
PARTITION BY toYYYYMM(EventDate)
ORDER BY (CounterID, EventDate, intHash32(UserID))
SAMPLE BY intHash32(UserID)