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())"

架构图:
clickhouse集群部署方案分析_第1张图片
clickhouse集群部署方案分析_第2张图片

架构解析:

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())"

架构图:
clickhouse集群部署方案分析_第3张图片
clickhouse集群部署方案分析_第4张图片

架构解析:
分布式架构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())"

架构图
clickhouse集群部署方案分析_第5张图片

跨IDC的架构:
clickhouse集群部署方案分析_第6张图片
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表

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

你可能感兴趣的:(数据库,数据仓库)