一 概述

ClickHouse不同于Elasticsearch、HDFS這類主從架構(gòu)的分布式系統(tǒng)，它采用多主（無中心）架構(gòu)，集群中的每個節(jié)點角色對等，客戶端訪問任意一個節(jié)點都能得到相同的效果。

ClickHouse借助分片將數(shù)據(jù)進行橫向切分，而分片依賴集群，每個集群由1到多個分片組成，每個分片對應(yīng)了CH的1個服務(wù)節(jié)點；分片數(shù)量的上限取決與節(jié)點數(shù)量（1個分片只能對應(yīng)1個服務(wù)節(jié)點）。

但是ClickHouse并不像其他分布式系統(tǒng)那樣，擁有高度自動化的分片功能；CH提供了本地表與分布式表的概念；一張本地表等同于一個數(shù)據(jù)分片。而分布式表是張邏輯表，本身不存儲任何數(shù)據(jù)，它是本地表的訪問代理，其作用類似分庫中間件。借助分布式表，能夠代理訪問多個數(shù)據(jù)分片，從而實現(xiàn)分布式查詢。當然，也可以在應(yīng)用層實現(xiàn)數(shù)據(jù)分發(fā)。

ClickHouse同時支持數(shù)據(jù)副本，其副本概念與Elasticsearch類似，但在CH中分片其實是一種邏輯概念，其物理承載是由副本承擔的。

ClickHouse的數(shù)據(jù)副本一般通過ReplicatedMergeTree復(fù)制表系列引擎實現(xiàn)，副本之間借助ZooKeeper實現(xiàn)數(shù)據(jù)的一致性。此外也可通過分布式表負責(zé)同時進行分片和副本的數(shù)據(jù)寫入工作。

二 集群部署架構(gòu)

以四節(jié)點實現(xiàn)多分片和雙副本為例：

方案一

方案一.png

（上圖中shard作為主副本）
在每個節(jié)點創(chuàng)建一個數(shù)據(jù)表，作為一個數(shù)據(jù)分片，使用ReplicatedMergeTree表引擎實現(xiàn)數(shù)據(jù)副本，而分布表作為數(shù)據(jù)寫入和查詢的入口。
這是最常見的集群實現(xiàn)方式。

方案二

方案二.png

在每個節(jié)點創(chuàng)建一個數(shù)據(jù)表，作為一個數(shù)據(jù)分片，分布表同時負責(zé)分片和副本的數(shù)據(jù)寫入工作。
這種實現(xiàn)方案下，不需要使用復(fù)制表，但分布表節(jié)點需要同時負責(zé)分片和副本的數(shù)據(jù)寫入工作，它很有可能稱為寫入的單點瓶頸。

方案三

方案三.png

在每個節(jié)點創(chuàng)建一個數(shù)據(jù)表，作為一個數(shù)據(jù)分片，同時創(chuàng)建兩個分布表，每個分布表只納管一半的數(shù)據(jù)。
副本的實現(xiàn)仍需要借助ReplicatedMergeTree類表引擎。

方案四

方案四.png

在每個節(jié)點創(chuàng)建兩個數(shù)據(jù)表，同一數(shù)據(jù)分片的兩個副本位于不同節(jié)點上，每個分布式表納管一般的數(shù)據(jù)。
這種方案可以在更少的節(jié)點上實現(xiàn)數(shù)據(jù)分布與冗余，但是部署上略顯繁瑣。

三 總結(jié)

• CH的分片與副本功能完全靠配置文件實現(xiàn)，無法自動管理，所以當集群規(guī)模較大時，集群運維成本較高
• 數(shù)據(jù)副本依賴ZooKeeper實現(xiàn)同步，當數(shù)據(jù)量較大時，ZooKeeper可能會稱為瓶頸
• 如果資源充足，建議使用方案一，主副本和副副本位于不同節(jié)點，以更好地實現(xiàn)讀寫分離與負載均衡
• 如果資源不夠充足，可以使用方案四，每個節(jié)點承載兩個副本，但部署方式上略復(fù)雜

參考：《ClickHouse原理解析與應(yīng)用實踐》