clickhouse集群部署方案分析

常见的三种集群架构方案

注：本文摘自网上内容，原文地址：https://zhuanlan.zhihu.com/p/161242274

ClickHouse分布式集群常见方案一：MergeTree + Distributed

建表方式：

1，本地表：数据存储在建表节点的本地

CREATE TABLE db.tb (date Date, ……) ENGINE = MergeTree(date, (date, hour, datetime), 8192)

2，分布式表：查询这个表，引擎自动把整个集群数据计算后返回

CREATE TABLE db.tb_all (date Date, ……) ENGINE = Distributed(bip_ck_cluster, 'ck_cluster', 'test', rand())"

架构图：

架构解析：

MergeTree + Distributed的分布式架构方案，利用的是Distributed表的特性+MergeTree表的特性，分布式表不存储数据，数据来自本地表，将分布式表的数据分为3个shard，每台节点存储三分之一的数据，用户查询的时候是从分布式表所在的节点聚合从Ck1，CK2，CK3的查询结果，然后返回用户，写入数据可以写入分布式表，当然这样的写入方式问题很多，一般是禁止写入分布式表的，那么选择写入本地表的化，需要将数据轮询或者其他方式，将数据分散写入Ck1，CK2，CK3，当然你也可以只写入其中一台，那么使用方式就是单机版的

1：优势：架构简单，可以单机使用，可以分布式使用，关键在于表引擎的选择，并行的查询分布式表，性能非常棒

2：问题：

(1):本地表+分布式表，分布式表如果某个节点宕机就会丢失数据，用户查询服务就会报错，如果节点磁盘损坏，那么数据将大概率丢失，无法恢复，即使恢复也会付出极大的成本

(2):对于查询节点的选择需要慎重的考虑，毕竟需要聚合所有查询节点的结果

ClickHouse分布式集群常见方案二：MergeTree + Distributed+集群复制

结合分布式方案一的优势和问题，分布式方案二，考虑数据的安全性，设置了副本

建表方式：

1，本地表：数据存储在建表节点的本地

CREATE TABLE db.tb (date Date, ……) ENGINE = MergeTree(date, (date, hour, datetime), 8192)

2，分布式表：查询这个表，引擎自动把整个集群数据计算后返回

CREATE TABLE db.tb_all (date Date, ……) ENGINE = Distributed(bip_ck_cluster, 'ck_cluster', 'test', rand())"

架构图：

架构解析：
分布式架构2采用了架构1的特点和解决了架构1的问题，数据安全性得到了解决，集合CLickHouse集群的复制，有了副本，3个shard各自拥有三分之一的数据，每个shard有2个副本，数据一样。其中CK1的Shard有两副本，分别在CK1，CK2；CK2的shard也有两副本，分别在CK2，CK3；CK3的shard也是两副本，分别在CK1和CK3

1：优势：数据的安全性有了保障，每一个shard有两个副本；数据的查询的并行度没有改变，但是因为副本的存在，shard节点数据的查询选择性多了。即使CK1挂了，不影响集群的查询服务

2：问题：

如果IP1临时宕机，从宕机开始到恢复，期间的增量数据是可以补全的，依赖的IP2上的推送机制，会有临时目录，但是，如果IP1彻底玩完，硬盘坏了，无法恢复，只能重做，引入一个IP5来替换IP1，这时候问题就来了，存量数据无法恢复

这个方案社区有过争议，从CK原理上来讲，的确存在上述的问题，根据社区的相关的使用者遇到的问题，经常会遇到DistrDirMonitor导致的故障

ClickHouse分布式集群常见方案三：ReplicatedMergeTree + Distributed

建表方式

1，本地表：

CREATE TABLE db.tb (date Date, ……) ENGINE = ReplicatedMergeTree('/clickhouse/db/tb/name', 'ck_name', date, (date, hour, datetime), 8192)

2，分布式表：

CREATE TABLE db.tb_all (date Date, ……) ENGINE = Distributed(bip_ck_cluster, 'test', 'test', rand())"

架构图

跨IDC的架构：

metrika.xml配置文件

metrika.xml配置文件和架构2的配置文件一样

架构解析

ReplicatedMergeTree + Distributed的架构把MergeTree换成了ReplicatedMergeTree，本质上是将副本的数据同步的策略，从基于Cluster的方式换成了基于复制表引擎+Zookeeper的方式，基于ReplicatedMergeTree + Distributed的架构方案，在查询并行度，数据的安全性，副本的安全性，数据的一致性上都考虑的比较好，也避免了社区提出的DistrDirMonitor的故障问题

优点：ReplicatedMergeTree里，共享同一个ZK路径的表，会相互，注意是，相互同步数据，数据安全，查询性能不会有太大的问题

如果能机器再考虑IDC的化，那么数据的容灾就能跨机房，数据安全性能得到更好的保证

问题：

(1):需要注意：写本地表，读分布式表

(2):结合业务及数据的特性及所需的机器的资源，合理的选择分布式表的建表的CK节点

(3):SELECT 查询并不需要借助 ZooKeeper ，复本并不影响 SELECT 的性能，查询复制表与非复制表速度是一样的。查询分布式表时，ClickHouse的处理方式可通过设置 max_replica_delay_for_distributed_queries 和 fallback_to_stale_replicas_for_distributed_queries 修改。

(4):对于数据的写入需要注意：对于每个 INSERT 语句，会通过几个事务将十来个记录添加到 ZooKeeper。（确切地说，这是针对每个插入的数据块; 每个 INSERT 语句的每 max_insert_block_size = 1048576 行和最后剩余的都各算作一个块。）相比非复制表，写 zk 会导致 INSERT 的延迟略长一些。但只要你按照建议每秒不超过一个 INSERT 地批量插入数据，不会有任何问题。一个 ZooKeeper 集群能给整个 ClickHouse 集群支撑协调每秒几百个 INSERT。数据插入的吞吐量（每秒的行数）可以跟不用复制的数据一样高。

(5):集群配置里，我们用了域名，本想着方便切换，但是CK只有在启动的时候，才会做解析。那故障了怎么切换? CK有一个厉害的地方，节点变动，无需重启，会自动加载。利用上述特性，我们先去掉一个节点的配置，再加上这个节点的配置（DNS变更后），即可不重启就完成fail over

ClickHouse分布式集群常见方案分析总结

基于ClickHouse的集群的常见方案，结合业界的架构方案，优质的选择是基于ReplicatedMergeTree + Distributed的集群架构方案，也是分布式高可用的集群架构方案，但是在使用该集群架构的过程中，需要注意：

写表的方式：写本地表，读分布式表

由于分布式表的逻辑简单，仅仅是转发请求，所以在转发安全性上，会有风险，并且rand的方式，可能会造成不均衡，业界建议，通过DNS轮训，写本地表，这样最保险和均衡

统一的建表，表管理入口

CK的分布式，完全依赖配置文件，即每个节点，都共享同样的配置文件，建表要区分集群，又要区分副本，建议写一个脚本来统一建表，或者开发一个可视化的页面，操作管理CK表

建议结合查询的负载均衡做，分布式查询的节点可以在每一个节点都建分布式表，查询的选择性更多