zk目錄結構
ClickHouse配置信息
創建基於zk的ClickHouse集羣（3zk-2shards-2replicas），主要信息如下：
<?xml version="1.0" encoding="utf-8"?>
<yandex>
<clickhouse_remote_servers>
<default>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>172.17.0.8</host>
<port>9000</port>
</replica>
<replica>
<host>172.17.0.7</host>
<port>9000</port>
</replica>
</shard>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>172.17.0.6</host>
<port>9000</port>
</replica>
<replica>
<host>172.17.0.5</host>
<port>9000</port>
</replica>
</shard>
</default>
</clickhouse_remote_servers>
<zookeeper-servers>
<node index="1">
<host>172.17.0.4</host>
<port>2181</port>
</node>
<node index="2">
<host>172.17.0.3</host>
<port>2181</port>
</node>
<node index="3">
<host>172.17.0.2</host>
<port>2181</port>
</node>
</zookeeper-servers>
<listen_host>::</listen_host>
<listen_host>0.0.0.0</listen_host>
<listen_try>1</listen_try>
<macros>
<shard>1</shard>
<replica>172.17.0.8</replica>
</macros>
</yandex>
其它3個實例的macros會不同
然後創建ReplicatedMergeTree表，Distributed表，再插入5條記錄，如下：
CREATE TABLE log_test ON CLUSTER default
(
ts DateTime,
uid String,
biz String
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/log_test','{replica}') PARTITION BY toYYYYMMDD(ts) ORDER BY (ts) SETTINGS index_granularity = 8192;
CREATE TABLE log_test_all ON CLUSTER default(
ts DateTime,
uid String,
biz String
) ENGINE= Distributed(default, default, log_test, rand());
INSERT INTO log_test VALUES ('2019-06-07 20:01:01', 'a', 'show');
INSERT INTO log_test VALUES ('2019-06-07 20:01:02', 'b', 'show');
INSERT INTO log_test VALUES ('2019-06-07 20:01:03', 'a', 'click');
INSERT INTO log_test VALUES ('2019-06-08 20:01:04', 'c', 'show');
INSERT INTO log_test VALUES ('2019-06-08 20:01:05', 'c', 'click');
select * from log_test;
select * from log_test_all;
最終zk的目錄結構爲
clickhouse
└── tables
├── 1
│ ├── log_test
│ │ ├── metadata #log_test表的元數據信息
│ │ ├── temp #臨時節點，存儲過程中的臨時數據
│ │ └── mutations #表的變更信息，ClickHouse爲區別標準SQL特定的一個名詞
│ ├── log #寫block時記錄的log
│ │ ├── log-0000000003
│ │ ├── log-0000000001
│ │ └── log-0000000002
│ ├── leader_election #副本選舉leader時使用
│ │ ├── leader_election-0000000001
│ │ └── leader_election-0000000003
│ ├── colums #列信息
│ ├── blocks #和log是對應的，用於block去重
│ │ ├── 201908_12150410223201606212_2366670524718677664
│ │ ├── 201908_15367370223201604745_5325320524718463637
│ │ └── 201907_34543779872932958925_1436457470273464774
│ ├── nonincrement_block_numbers
│ ├── replicas #存儲各個副本的相關信息
│ │ └── 10.0.0.71
│ │ ├── is_lost #標記副本是否過時
│ │ ├── metadata #log_test表的元數據信息
│ │ ├── is_active #標記副本是否存活
│ │ ├── mutation_pointer
│ │ ├── colums #列信息
│ │ ├── max_processed_insert_time
│ │ ├── host #主機名或域名
│ │ ├── parts #存儲數據所有的parts
│ │ │ └── 201908_0_0_0
│ │ │ ├── checksums
│ │ │ └── colums
│ │ ├── flags #用於數據恢復
│ │ ├── log_pointer #log指針
│ │ ├── min_unprocessed_insert_time
│ │ └── queue #臨時處理隊列
│ ├── quorum #與是否配置insert_quorum有關
│ │ ├── last_part
│ │ └── failed_parts
│ └── block_number #存儲所有的分區值，會根據merge實時更新
│ └── 201908
└─ 2
目錄說明
根目錄：/clickhouse/tables
下一級時是分片信息目錄，其中的1和2是根據配置中的shard生成的
<macros>
<shard>1</shard>
</macros>
分片信息目錄中包括所有的表目錄，例如：
/clickhouse/tables/1/log_test
/clickhouse/tables/1/log_test2
/clickhouse/tables/1/log_test3
...
以/clickhouse/tables/1/log_test爲例，log_test表目錄包含以下節點，可以通過zkCli.sh的ls命令查看
[metadata, temp, mutations, log, leader_election, columns, blocks, nonincrement_block_numbers, replicas, quorum, block_numbers]
表目錄說明
metadata
存的是log_test表的元數據信息，如下：
metadata format version: 1
date column:
sampling expression:
index granularity: 8192
mode: 0
sign column:
primary key: ts
data format version: 1
partition key: toYYYYMMDD(ts)
granularity bytes: 10485760
temp
臨時目錄，用於存儲ck工作時的一些臨時文件的存儲，比如mutation過程等
mutations
記錄數據的變更，ClickHouse的更新和刪除的語法是非標準SQL，新的更新和刪除是異步執行的批處理操作，自定義了這樣一個名字是爲了與傳統SQL做區分。
正常情況下這個節點是沒有數據的，但如果執行了
ALTER TABLE log_test UPDATE uid='aa' where uid='a';
此時在mutations下會多一個0000000000節點，信息爲：
format version: 1
create time: 2020-03-25 07:45:08
source replica: 172.17.0.8
block numbers count: 2
20190607 3
20190608 2
commands: UPDATE uid = \'aa\' WHERE uid = \'a\'
alter version: -1
log
每一個insert語句（嚴格來說是每一個block）就會生成一個log文件，無論哪個副本寫入數據都會產生log，其他副本會watch這個節點去檢查自己的數據是否有延遲，如果有會去同分片有該數據的副本中去clone
log-0000000005 中的信息，如下：
format version: 4
create_time: 2020-03-24 15:21:28
source replica: 172.17.0.7
block_id: 20190909_7580776809554376778_6946384220985995348
get
20190909_0_0_0
leader_election
決定哪個副本作爲主副本，查詢時優先選擇該副本，另一個副本根據這個副本同步，在同步過程中還有很多邏輯判斷，是否要重新選主，主副本是否是最新的等等，這裏不細說。這裏包含所有可用的副本
leader_election-0000000003 中的信息，如下：
172.17.0.8
這個值也是根據配置文件生成的
<macros>
<replica>172.17.0.8</replica>
</macros>
leader_election-xxxx是臨時節點，如果實例異常，會自動刪除，如果實例恢復，會再次寫入。如何知道哪個replica是leader可以通過查詢system.replicas的is_leader，爲1則爲leader，爲0則不是leader，該表還有個can_become_leader字段標明是否可以成爲leader，這個就與副本延遲程度有關了
columns
存儲了該表有哪些列，信息如下：
columns format version: 1
3 columns:
`ts` DateTime
`uid` String
`biz` String
blocks
和logs是對應的，log裏面包含着block_id，這個id會存一定的數量，作用是爲了數據去重，它的格式是patition_hash[0]_hash[1]，就是通過hash值來判斷是否重複，如果有重複就不再向zk插入相關數據的元信息
20190608_12150410223201606212_2366670524718677664中的信息是：
20190608_0_0_0
這裏就對應着/var/lib/clickhouse/data/default/log_test/20190608_0_0_0這個part
replicas
存儲各個副本的相關信息，節點的名稱也是根據這個值也是根據配置文件生成的
<macros>
<replica>172.17.0.8</replica>
</macros>
172.17.0.8目錄包含
[is_lost, metadata, is_active, mutation_pointer, columns, max_processed_insert_time, host, parts, flags, log_pointer, min_unprocessed_insert_time, queue]
每個節點的作用：
-
is_lost：標記副本是否過時，依據log_pointer是否是最新的，0爲正常，-1爲過時，1爲修復中
-
metadata：元數據信息，同上述的metadata
-
is_active：是否存活，如果服務器異常，會不存在這個節點，恢復後會重新添加進來
-
columns：列信息
-
max_processed_insert_time：最大的insert執行時間
-
host：主機名或域名
-
parts：存儲數據的所有parts，每個part中包含checksums和columns信息
-
flags：主要用於強制數據恢復
-
log_pointer：log指針，標記該副本應該處理的log-xxx是哪個
-
min_unprocessed_insert_time：最小的未處理的延時時間
-
queue：插入數據量大時，數據會添加到隊列中
quorum
與是否配置insert_quorum 有關
block_numbers
存儲所有的分區，會根據merge實時更新