关于clickhouse:ClickHouse-逻辑集群介绍

ClickHouse作为一个基于 OLAP 场景的数据库，对于集群的反对天然也是天经地义的。咱们通常所说的 ClickHouse 集群，指的是物理集群。即集群各节点之间被同一个 zookeeper 集群治理，数据的各种 DDL 操作都是针对整个集群无效的。

与物理集群绝对应的，还有一类集群，咱们叫它逻辑集群。它是指在物理上没有肯定的必然关系的物理集群，彼此又组成了一个逻辑集群。能够用上面这幅图形象地表白物理集群和逻辑集群的关系。

如上图所示，三个物理集群各自是互相独立的，对 cluster1 的各种数据操作，cluster2和 cluster3 并无奈感知，然而对于 logic 集群来说，任何一个物理集群的数据变动，逻辑集群都能通过查问获取到。

那么，既然有了物理集群，为什么还要逻辑集群呢？它能解决用户什么痛点？又能带来哪些益处？

咱们晓得，ClickHouse集群的数据一致性是通过 Zookeeper 集群来保障的。当集群的数据量特地大或者操作特地频繁的时候，带来的就是 zookeeper 的znode节点数量多，更新频繁。而 zookeeper 的压力是有下限的，如果集群过大，或者一个 zookeeper 集群治理的 clickhouse 集群过多的话，很容易造成 zookeeper 解体或者卡死。

正是因为“天下苦 zookeeper 久矣”，逻辑集群的呈现正好能解决这一问题。

比方，某个物理集群的数据量特地宏大，宏大到繁多的 zookeeper 集群无奈撑持其元数据管理，这时候咱们能够将这个物理集群拆分成多个物理集群，别离应用不同的 zookeeper 集群去治理，而后通过逻辑集群去查问数据。这样既分担了 zookeeper 的压力，也保留了各个物理集群之间的业务关联性，不影响业务数据的查问。

还有一种比拟常见的场景是多数据中心。随着企业数据规模的扩张，不可能把所有的数据都寄存在一个数据中心，面对这样的多数据中心的场景，如果只建设一个物理集群，那么首先面临的是网络的提早问题，其次还有昂扬的流量费用，这都是须要思考的问题。

那么比拟好的做法是在每一个数据中心都别离建设各自的物理集群，这样无论是数据的插入还是查问，都极大缩小了网络上的限度，从而把提早做到最小。

然而咱们思考这样一个场景：某银行机构在上海和合肥各有一个数据中心，别离建设了两个物理集群，叫做 bench_shanghai 和bench_hefei，当初总行机构须要综合上海和合肥的两个数据中心的数据做数据分析。那么咱们还必须别离查问上海的集群和合肥的集群，而后再进行汇总。如果数据中心比拟多，那么查问的次数也就特地多，这样显然是事倍功半的。

如果咱们建设一个逻辑集群，将上海的集群和合肥的集群蕴含在内，咱们就叫它 bench 集群，这样咱们只须要查问 bench 集群，就能一次将数据全副查出来，如下图所示：

逻辑集群节约老本是必定的。当然次要是网络流量方面的老本。尤其是云上的服务器，流量贵得惊人。构想一下，如果上海和合肥两个数据中心只有一个物理集群，而恰好一个 shard 中的不同正本又别离位于不同的数据中心，当每天数 TB 级别的数据写入数据库，在做正本之间数据同步的时候，产生的流量当有如许可怕。

咱们不倡议在逻辑集群进行 mutation 的相干操作。不倡议对数据进行插入、删除等。这些操作都应该在物理集群去实现。

事实上，逻辑集群天生也不善于做下面这些操作。这次要取决于以下这几层限度：

逻辑集群可能蕴含多个物理集群，这些物理集群不肯定在同一个 zookeeper 上，因而，不论是建表还是插入数据，一致性是肯定不能保障的。
即便逻辑集群的多个物理集群应用同一个zookeeper，依然无奈创立逻辑集群层面上的分布式表。因为有可能物理集群 A 应用了正本，创立的本地表引擎是ReplicatedMergeTree，然而物理集群 B 没有应用正本，创立的本地表是MergeTree，这样即便本地表构造截然不同，也无奈在逻辑集群上创立分布式表。
再退一步，就算物理集群 A 和B都应用了正本，建表的 schema 截然不同，应用的都是 ReplicatedMergeTree 引擎，在逻辑集群上创立分布式表依然不可避免问题。因为为了避免集群之间互相烦扰，咱们个别定义 zookeeper 的门路时，都会带上集群的名字，比方上面这样：

CREATE TABLE default.t1
(
    `@time` DateTime,
    `@item_guid` String,
    `@metric_name` LowCardinality(String),
    `@alg_name` LowCardinality(String)
)
ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/{cluster}/{shard}/default/t1', '{replica}')
PARTITION BY toYYYYMMDD(`@time`)
ORDER BY (`@time`, `@item_guid`, `@metric_name`)
SETTINGS index_granularity = 8192

因而不同的物理集群在 zookeeper 的门路其实是不同的，而分布式表之所以可能应用 ON CLUSTER xxx 这种语法创立，次要就是因为在 zookeeper 的task queue中保留了 DDL 语句，而不同的集群 task queue 的门路不同，就无奈做到同步。因而创立分布式表也会失败。

因而，逻辑集群存在的意义次要是用来查问。这也是它惟一能做的事件。

那么，既然逻辑集群在创立分布式表上有这么多的限度（简直就是不可能创立胜利），为什么咱们还能应用逻辑集群进行查问呢？这不是自圆其说的么？

事实上，咱们能够在物理集群上别离创立跨逻辑集群的分布式表，只有表的 schema 一样，是能够实现查问的。如上面这样的写法：

 -- 上海集群创立：CREATE TABLE default.dist_logic_t123 on cluster bench_shanghai as t123 ENGINE = Distributed('bench', 'default', 't123', rand());
 
 -- 合肥集群创立
  CREATE TABLE default.dist_logic_t123 on cluster bench_hefei as t123 ENGINE = Distributed('bench', 'default', 't123', rand());

这样不论是往上海集群还是合肥集群插入数据，咱们都能从 dist_logic_t123 表中查问进去。

创立逻辑集群的形式和一般的物理集群相似，只须要在 metrika.xml 配置文件中退出逻辑集群的相干信息即可。如下所示：

上海集群 metrika.xml 配置文件：

合肥集群 metrika.xml 配置文件：

创立逻辑集群不简单，简单的是对逻辑集群的后续运维。

假如咱们当初要减少一个成都的数据中心，须要创立一个成都物理集群，并将成都物理集群减少到 bench 逻辑集群中去，那么还要同步批改上海和合肥集群所有节点的配置文件。

与之类似的操作还有减少节点、删除节点、销毁集群等，有可能是某一个物理集群的渺小改变，就要连带着所有逻辑集群的配置文件的刷新，真堪称“牵一发而动全身”。

这也是没有方法的事，世上没有美中不足的事件。既然想要应用逻辑集群带来的便当，就得承受繁琐的配置工作。

ckman是擎创科技自主研发的一款用来治理和监控 clickhouse 集群的运维工具。它的全称是 ”ClickHouse Manager Console“，它通过直观的可视化界面，能够十分不便地对集群进行创立、启停、降级，以及增删节点等操作，运维人员无需关注 clickhouse 配置文件变动的细节，所有都由 ckman 被动实现。同时它还提供了数据表、会话以及节点级别的监控，能够直观的察看到集群的应用状况。

在最新公布的 ckman2.0beta 版中，ckman退出了对逻辑集群的反对。

诚如下面所说，对逻辑集群的运维动作，比方增删节点、减少和销毁物理集群，都须要同步刷新逻辑集群里所有节点的配置，这项工作不仅费时费力，且容易出错，人工去操作的话，很难保障效率。而 ckman 的呈现，恰好解决了这一问题。咱们只须要在界面上进行简略的点击，所有的配置文件刷新操作都会由 ckman 去自主实现，从而大大简化了操作步骤。

应用 ckman 创立逻辑集群非常简单，只须要在 ” 逻辑名称 ” 输入框中输出逻辑集群的名称即可。

逻辑集群创立胜利后，会在首先的集群列表中展现进去。

同时，这些信息会长久化到硬盘中，在 conf/clusters.json 文件中，有如下选项：

"logic_clusters": {
    "bench": [
      "bench_shanghai",
      "bench_hefei"
    ]
  }

它的意思是说 bench 逻辑集群由 bench_shanghai 和bench_hefei的物理集群组成，该逻辑集群的节点也就是其物理集群的所有节点。

ckman反对逻辑集群的减少节点、删除节点、降级集群以及销毁集群等操作。尽管这些操作是针对物理集群的，然而如果设置了逻辑集群，也会同步刷新逻辑集群所有节点的 metrika.xml 配置，从而保障逻辑集群的节点实时同步。

后面提到过，咱们能够在每个物理集群创立跨逻辑集群的分布式表，然而当逻辑集群内的物理集群比拟多时，上述的建表操作还是很繁琐的，ckman提供了一个 dist_table 的API，这是一个 POST 接口。

URL： /api/v1/ck/dist_logic_table/{clusterName}

METHOD: POST

BODY:

{
    "database":"default",
    "table_name":"t123"
}

该接口会在逻辑集群的每个物理集群上创立跨逻辑集群的分布式表，应用该分布式表，就能够实现在逻辑集群上进行数据查问。

本文简略介绍了逻辑集群的玩法，不可否认的是，逻辑集群的引入，的确能解决不少客户的痛点，但同样也带来了不小的运维阻力。尽管有相似于 ckman 这样的运维工具能够帮忙解决，但某些高端的玩法，比方由多个逻辑集群组成的父级逻辑集群，也是 ckman 不能反对的。但随着 clickhouse 周边生态的原来越欠缺，置信会有更多优良的集群玩法诞生，兴许下一个亮眼的点子就是你提出的，谁说不是呢？

关于clickhouse:ClickHouse-逻辑集群介绍

什么是逻辑集群

为什么须要逻辑集群

首先，逻辑集群能解决 zookeeper 压力问题

其次，逻辑集群解决了多数据中心问题

再次，逻辑集群能节约老本

逻辑集群能做什么

如何创立一个逻辑集群

ckman 对逻辑集群的反对

创立逻辑集群

其余运维操作

创立跨逻辑集群的分布式表

写在最初