一、CK 分布式表和本地表
（1）CK是一個純列式存儲的數據庫，一個列就是硬盤上的一個或多個文件（多個分區有多個文件），關於列式存儲這里就不展開了，總之列存對於分析來講好處更大，因為每個列單獨存儲，所以每一列數據可以壓縮，不僅節省了硬盤，還可以降低磁盤IO。
（2）CK是多核並行處理的，為了充分利用CPU資源，多線程和多核必不可少，同時向量化執行也會大幅提高速度。
（3）提供SQL查詢接口，CK的客戶端連接方式分為HTTP和TCP，TCP更加底層和高效，HTTP更容易使用和擴展，一般來說HTTP足矣，社區已經有很多各種語言的連接客戶端。
（4）CK不支持事務，大數據場景下對事務的要求沒這么高。
（5）不建議按行更新和刪除，CK的刪除操作也會轉化為增加操作，粒度太低嚴重影響效率。
生產環境中通常是使用集群部署，CK的集群與Hadoop等集群稍微有些不一樣。如圖所示，CK集群共包含以下幾個關鍵概念:
（1）CK實例。可以一台主機上起多個CK實例，端口不同即可，也可以一台主機一個CK實例。
（2）分片。數據的水平划分，例如隨機划分時，圖5中每個分片各有大約一半數據。
（3）副本。數據的冗余備份，同時也可作為查詢節點。多個副本同時提供數據查詢服務，能夠加快數據的查詢效率，提高並發度。圖5中CK實例1和示例3存儲了相同數據。
（4）多主集群模式。CK的每個實例都可以叫做副本，每個實體都可以提供查詢，不區分主從，只是在寫入數據時會在每個分片里臨時選一個主副本，來提供數據同步服務，具體見下文中的寫入過程。
ck的表分為兩種:
-
分布式表
一個邏輯上的表, 可以理解為數據庫中的視圖, 一般查詢都查詢分布式表. 分布式表引擎會將我們的查詢請求路由本地表進行查詢, 然后進行匯總最終返回給用戶.
-
本地表:
實際存儲數據的表
1、Replication & Sharding
2、一般 不寫分布式表的原因
- 分布式表接收到數據后會將數據拆分成多個parts, 並轉發數據到其它服務器, 會引起服務器間網絡流量增加、服務器merge的工作量增加, 導致寫入速度變慢, 並且增加了Too many parts的可能性.
- 數據的一致性問題, 先在分布式表所在的機器進行落盤, 然后異步的發送到本地表所在機器進行存儲，中間沒有一致性的校驗, 而且在分布式表所在機器時如果機器出現down機, 會存在數據丟失風險.
- 數據寫入默認是異步的，短時間內可能造成不一致.
- 對zookeeper的壓力比較大(待驗證). 沒經過正式測試, 只是看到了有人提出.
3、Replicated Table & ReplicatedMergeTree Engines
ClickHouse的副本機制之所以叫“復制表”，是因為它工作在表級別，而不是集群級別（如HDFS）。也就是說，用戶在創建表時可以通過指定引擎選擇該表是否高可用，每張表的分片與副本都是互相獨立的。
目前支持復制表的引擎是ReplicatedMergeTree引擎族，它與平時最常用的MergeTree引擎族是正交的，如下圖所示。
不同於HDFS的副本機制(基於集群實現), Clickhouse的副本機制是基於表實現的. 用戶在創建每張表的時候, 可以決定該表是否高可用.
Local_table
CREATE TABLE IF NOT EXISTS {local_table} ({columns}) ENGINE = ReplicatedMergeTree('/clickhouse/tables/#_tenant_id_#/#__appname__#/#_at_date_#/{shard}/hits', '{replica}') partition by toString(_at_date_) sample by intHash64(toInt64(toDateTime(_at_timestamp_))) order by (_at_date_, _at_timestamp_, intHash64(toInt64(toDateTime(_at_timestamp_))))
ReplicatedMergeTree
CREATE TABLE IF NOT EXISTS test.events_local ON CLUSTER '{cluster}' ( ts_date Date, ts_date_time DateTime, user_id Int64, event_type String, site_id Int64, groupon_id Int64, category_id Int64, merchandise_id Int64, search_text String -- A lot more columns... ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/test/events_local','{replica}') PARTITION BY ts_date ORDER BY (ts_date_time,site_id,event_type) SETTINGS index_granularity = 8192;
其中，ON CLUSTER語法表示分布式DDL，即執行一次就可在集群所有實例上創建同樣的本地表。集群標識符{cluster}、分片標識符{shard}和副本標識符{replica}來自之前提到過的復制表宏配置，即config.xml中<macros>一節的內容，配合ON CLUSTER語法一同使用，可以避免建表時在每個實例上反復修改這些值。
ReplicatedMergeTree引擎族接收兩個參數：
- ZK中該表相關數據的存儲路徑，ClickHouse官方建議規范化，如上面的格式
/clickhouse/tables/{shard}/[database_name]/[table_name]。 - 副本名稱，一般用
{replica}即可。
支持復制表的引擎都是ReplicatedMergeTree引擎族, 具體可以查看官網:
作者：張永清 來源於博客園https://www.cnblogs.com/laoqing/p/15954171.html
ReplicatedMergeTree引擎族接收兩個參數:
- ZK中該表相關數據的存儲路徑, ClickHouse官方建議規范化, 例如:
/clickhouse/tables/{shard}/[database_name]/[table_name]. - 副本名稱, 一般用
{replica}即可.
ReplicatedMergeTree引擎族非常依賴於zookeeper, 它在zookeeper中存儲了大量的數據:
表結構信息、元數據、操作日志、副本狀態、數據塊校驗值、數據part merge過程中的選主信息...
同時, zookeeper又在復制表急之下扮演了三種角色:
元數據存儲、日志框架、分布式協調服務
可以說當使用了ReplicatedMergeTree時, zookeeper壓力特別重, 一定要保證zookeeper集群的高可用和資源.
3.1. 數據同步的流程
internal_replication配置項為true）。即先寫入一個副本，再通過config.xml中配置的interserver HTTP port端口（默認是9009）將數據復制到其他實例上去，同時更新ZK集群上記錄的信息。
- 寫入到一個節點
- 通過
interserver HTTP port端口同步到其他實例上 - 更新zookeeper集群記錄的信息
3.2. 重度依賴Zookeeper導致的問題
ck的replicatedMergeTree引擎方案有太多的信息存儲在zk上, 當數據量增大, ck節點數增多, 會導致服務非常不穩定, 目前我們的ck集群規模還小, 這個問題還不嚴重, 但依舊會出現很多和zk有關的問題(詳見遇到的問題).
實際上 ClickHouse 把 ZK 當成了三種服務的結合, 而不僅把它當作一個 Coordinate service(協調服務), 可能這也是大家使用 ZK 的常用用法。ClickHouse 還會把它當作 Log Service(日志服務)，很多行為日志等數字的信息也會存在 ZK 上；還會作為表的 catalog service(元數據存儲)，像表的一些 schema 信息也會在 ZK 上做校驗，這就會導致 ZK 上接入的數量與數據總量會成線性關系。
作者：張永清 來源於博客園https://www.cnblogs.com/laoqing/p/15954171.html
目前針對這個問題, clickhouse社區提出了一個mini checksum方案, 但是這並沒有徹底解決 znode 與數據量成線性關系的問題. 目前看到比較好的方案是字節的:
我們就基於 MergeTree 存儲引擎開發了一套自己的高可用方案。我們的想法很簡單，就是把更多 ZK 上的信息卸載下來，ZK 只作為 coordinate Service。只讓它做三件簡單的事情：行為日志的 Sequence Number 分配、Block ID 的分配和數據的元信息，這樣就能保證數據和行為在全局內是唯一的。
關於節點，它維護自身的數據信息和行為日志信息，Log 和數據的信息在一個 shard 內部的副本之間，通過 Gossip 協議進行交互。我們保留了原生的 multi-master 寫入特性，這樣多個副本都是可以寫的，好處就是能夠簡化數據導入。圖 6 是一個簡單的框架圖。
以這個圖為例，如果往 Replica 1 上寫，它會從 ZK 上獲得一個 ID，就是 Log ID，然后把這些行為和 Log Push 到集群內部 shard 內部活着的副本上去，然后當其他副本收到這些信息之后，它會主動去 Pull 數據，實現數據的最終一致性。我們現在所有集群加起來 znode 數不超過三百萬，服務的高可用基本上得到了保障，壓力也不會隨着數據增加而增加。
ClickHouse分布式表的本質並不是一張表，而是一些本地物理表（分片）的分布式視圖，本身並不存儲數據。
支持分布式表的引擎是Distributed，建表DDL語句示例如下，_all只是分布式表名比較通用的后綴而已。
CREATE TABLE IF NOT EXISTS test.events_all ON CLUSTER sht_ck_cluster_1 AS test.events_local ENGINE = Distributed(sht_ck_cluster_1,test,events_local,rand());
Distributed引擎需要以下幾個參數：
- 集群標識符
注意不是復制表宏中的標識符，而是<remote_servers>中指定的那個。 - 本地表所在的數據庫名稱
- 本地表名稱
- （可選的）分片鍵（sharding key）
該鍵與config.xml中配置的分片權重（weight）一同決定寫入分布式表時的路由，即數據最終落到哪個物理表上。它可以是表中一列的原始數據（如site_id），也可以是函數調用的結果，如上面的SQL語句采用了隨機值rand()。注意該鍵要盡量保證數據均勻分布，另外一個常用的操作是采用區分度較高的列的哈希值，如intHash64(user_id)。
在分布式表上執行查詢的流程簡圖如下所示。發出查詢后，各個實例之間會交換自己持有的分片的表數據，最終匯總到同一個實例上返回給用戶。
而在寫入時，我們有兩種選擇：一是寫分布式表，二是寫underlying的本地表。孰優孰劣呢？
直接寫分布式表的優點自然是可以讓ClickHouse控制數據到分片的路由，缺點就多一些：
- 數據是先寫到一個分布式表的實例中並緩存起來，再逐漸分發到各個分片上去，實際是雙寫了數據（寫入放大），浪費資源；
- 數據寫入默認是異步的，短時間內可能造成不一致；
- 目標表中會產生較多的小parts，使merge（即compaction）過程壓力增大。
相對而言，直接寫本地表是同步操作，更快，parts的大小也比較合適，但是就要求應用層額外實現sharding和路由邏輯，如輪詢或者隨機等。
在生產環境中總是推薦寫本地表、讀分布式表，采用了隨機路由，部分代碼如下
private Request buildRequest(ClickhouseRequestBlank requestBlank) { String resultCSV = String.join(" , ", requestBlank.getValues()); String query = String.format("INSERT INTO %s VALUES %s", requestBlank.getTargetTable(), resultCSV); String host = sinkSettings.getClickhouseClusterSettings().getRandomHostUrl(); BoundRequestBuilder builder = asyncHttpClient .preparePost(host) .setHeader(HttpHeaders.Names.CONTENT_TYPE, "text/plain; charset=utf-8") .setBody(query); if (sinkSettings.getClickhouseClusterSettings().isAuthorizationRequired()) { builder.setHeader(HttpHeaders.Names.AUTHORIZATION, "Basic " + sinkSettings.getClickhouseClusterSettings().getCredentials()); } return builder.build(); } public String getRandomHostUrl() { currentHostId = ThreadLocalRandom.current().nextInt(hostsWithPorts.size()); return hostsWithPorts.get(currentHostId); }
完整代碼參考：https://github.com/ivi-ru/flink-clickhouse-sink
作者：張永清 來源於博客園https://www.cnblogs.com/laoqing/p/15954171.html
二、ClickHouse實現時序數據管理和挖掘
ClickHouse在時序數據庫上的能力體現：
（1）時間：時間是必不可少的，按照時間分區能夠大幅降低數據掃描范圍；
（2）過濾：對條件的過濾一般基於某些列，對於列式存儲來說優勢明顯；
（3）降采樣：對於時序來說非常重要的功能，可以通過聚合實現，CK自帶時間各個粒度的時間轉換函數以及強大的聚合能力，可以滿足要求；
（4）分析挖掘：可以開發擴展的函數來支持。
另外CK作為一個大數據系統，也滿足以下基礎要求：
（1）高吞吐寫入；
（2）海量數據存儲：冷熱備份，TTL；
（3）高效實時的查詢；
（4）高可用；
（5）可擴展性：可以實現自定義開發；
（6）易於使用：提供了JDBC和HTTP接口；
（7）易於維護：數據遷移方便，恢復容易，后續可能會將依賴的ZK去掉，內置分布式功能。
時序查詢場景會有很多聚合查詢，對於特定場景，如果使用的非常頻繁且數據量非常大，我們可以采用物化視圖進行預聚合，然后查詢物化視圖
三、ClickHouse的監控
我們比較推薦使用grafana+prometheus 來進行監控：
github地址：https://github.com/597365581/clickhouse_exporter
未完待續，敬請期待.....