編者按
ClickHouse自從2016年開源以來，在數據分析（OLAP）領域火熱，各個大廠紛紛跟進大規模使用。百分點在某國家級項目中的完成了多數據中心的ClickHouse集羣建設，目前存儲總量超10PB，日增數據100TB左右，預計流量今年會擴大3倍。本文是結合百分點在前期設計中的經驗對ClickHouse做的整理，其中，第二章節最佳實踐部分是基於我們的業務場景以及數據規模，經過大量的測試及總結後得到的結論，並且充分保證了整個系統日後的穩定運行，極具參考意義。
目錄 ClickHouse介紹
- 特點
- 適用場景
- 核心概念
百分點最佳實踐
- 部署安裝
- 服務器的選擇
- 分佈式集羣
- 表的創建
- 數據的寫入
- 業務查詢
- 跨中心訪問
- 最佳參數實踐
- 集羣監控
- 版本升級
附常用引擎
- MergeTree
- ReplacingMergeTree
- SummingMergeTree
- Replicated*MergeTree
- Distributed
ClickHouse是“戰鬥民族”俄羅斯搜索巨頭Yandex公司開源的一個極具"戰鬥力"的實時數據分析數據庫，是面向 OLAP 的分佈式列式DBMS，圈內人戲稱爲“喀秋莎數據庫”。ClickHouse簡稱"CH",但在中文社區裏大家更偏愛“CK”,反饋是因爲有“AK”的感覺！與Hadoop、Spark這些巨無霸組件相比，ClickHouse很輕量級，其特點：列式存儲數據庫，數據壓縮；關係型、支持SQL；分佈式並行計算，把單機性能壓榨到極限；高可用；數據量級在PB級別。
適用場景從社區分享的案例看主要有以下3類：日誌數據的行爲分析，標籤畫像的分析，數據集市層分析。百分點除了以上應用場景應用外，還作爲存儲引擎集成在了產品內部，應用於知識圖譜作爲本體數據存儲，及標籤數據的存儲引擎等。
- 絕大多數請求都是用於讀訪問
- 表很“寬”，即表中包含大量的列
- 在處理單個查詢時需要高吞吐量
- 每次查詢中大多數場景查詢一個大表
- 查詢結果顯著小於數據源，即數據有過濾或聚合
在使用ClickHouse之前我們需要明確一些核心概念，在此我們梳理了五個概念進行分享：
（1）表引擎（Engine）
表引擎決定了數據在文件系統中的存儲方式，常用的也是官方推薦的存儲引擎是MergeTree系列，如果需要數據副本的話可以使用ReplicatedMergeTree系列，相當於MergeTree的副本版本，讀取集羣數據需要使用分佈式表引擎Distribute。常用的引擎見【附常用引擎】的內容。
（2）表分區（Partition）
表中的數據可以按照指定的字段分區存儲，每個分區在文件系統中都是都以目錄的形式存在。常用時間字段作爲分區字段，數據量大的表可以按照小時分區，數據量小的表可以在按照天分區或者月分區，查詢時，使用分區字段作爲Where條件，可以有效的過濾掉大量非結果集數據。
（3）分片（Shard）
一個分片本身就是ClickHouse一個實例節點，分片的本質就是爲了提高查詢效率，將一份全量的數據分成多份（片），從而降低單節點的數據掃描數量，提高查詢性能。這裏先埋一個問題，當其中一個分片查詢出現異常情況，我們如何處理呢？選擇1返回異常；選擇2跳過異常節點；詳情見【參數實踐】的內容。
（4）複製集（Replication）
簡單理解就是相同的數據備份，在ClickHouse中通過複製集，我們實現了保障數據可靠性外，也通過多副本的方式，增加了ClickHouse查詢的併發能力。這裏一般有2種方式：1.基於ZooKeeper的表複製方式；2.基於Cluster的複製方式。由於我們推薦的數據寫入方式本地表寫入，禁止分佈式表寫入，所以我們的複製表只考慮ZooKeeper的表複製方案。
（5）集羣（Cluster）
可以使用多個ClickHouse實例組成一個集羣，並統一對外提供服務。
百分點最佳實踐
部署安裝
（1）部署包的獲取
ClickHouse官方並沒有提供RPM安裝包，這裏就爲大家提供一個標準渠道。資源地址：https://packagecloud.io/Altinity。頁面提供2個目錄：
ClickHouse目錄下多爲測試版更新，更新速度快；clickhouse-altinity-stable目錄爲穩定版發佈目錄。
（2）部署包說明
ClickHouse安裝部署需要四個安裝包：
clickhouse-client.rpm
clickhouse-common-static.rpm
clickhouse-server.rpm
clickhouse-server-common4.rpm
（3）部署方式
下載安裝包時要對應版本下載四個安裝包，將四個安裝包拷貝到統一目錄下，執行rpm -ivh * 即可完成安裝。
安裝完成後的主要目錄以及文件說明：
/etc/clickhouse-server：配置文件目錄，包括：config.xml和users.xml
/etc/clickhouse-client：客戶端配置文件目錄
/var/lib/clickhouse：默認數據目錄
/var/log/clickhouse-server：默認日誌目錄
/etc/init.d/clickhouse-server：啓動shell腳本
/etc/security/limits.d/clickhouse.conf：最大文件打開數的配置
/etc/cron.d/clickhouse-server：定時任務配置，默認沒有任務
/usr/bin/clickhouse-client：clickhouse客戶端
服務器的選擇
如上圖，是我們的線上服務器情況，ClickHouse查詢使用並行處理機制，對CPU和內存的要求還是比較高的。不建議單臺機器上部署多個節點，同時也要求ClickHouse節點與集羣中ZooKeeper節點分開。防止高負載下相互影響。
由於當時使用的ClickHouse版本不支持多數據盤，所以選擇一個合適的Raid方式也是很多人關心的問題，這裏我們直接建議Raid5，注意配置熱備盤，這樣無論從磁盤IO，數據可靠性，數據恢復，及運維複雜度來說都提供了很好的保障。這裏也給出了Raid5情況下的磁盤恢復的影響，供大家參考。
此外， 19.15 版本開始，ClickHouse 開始實現多卷存儲的功能。它具有多種用途，其中最重要的用途是將熱數據和冷數據存儲在不同類型的存儲中。這種配置被稱爲分層存儲，如何很好的利用多卷存儲能力，實現結合業務實現分層存儲，也期待大家能分享自己的經驗。
分佈式集羣
如【圖1、圖2】，ClickHouse分佈式集羣有4個節點，2個Shard，副本數爲2。其中節點example1,example2屬於同一Shard,互爲副本，他們的數據一致。example3,example4屬於同一Shard。查詢時，分佈從2個Shard中隨機取一個節點進行訪問。其中任何單節點異常時，寫入和查詢都能保障數據完整性，高可用，業務無感知。
ClickHouse的分佈式也是一個有意思的設計方式，多個節點部署完成後，節點與節點之間並沒有聯繫。通過ClickHouse集羣的配置文件來實現，即節點與節點之間通過配置文件來形成成集羣，配置中包含集羣的節點信息，複製節點，分片節點，同構成一個Cluster。
這樣就形成了一個有意思的現象。我們可以抽象爲：“集羣定義節點，和節點關係，節點不知道集羣”。這樣一個引用關係，表現爲ClickHouse的分佈式在使用上就很靈活。
舉個例子，一個集羣裏有30節點，我可以挑選其中2個配置整個集羣的分佈式關係，這樣你會發現每個節點都是獨立的，並不知道整個集羣的全貌，集羣的調整我只要關注2個節點的配置就行。包括基於之上的，數據安全，外部訪問控制等等。
如上，從高可用的角度，我們默認都是採用分佈式集羣方式，數據做分片，保證數據寫入不中斷。數據副本提供可靠性，同時提升併發查詢能力。
- 集羣配置
有四個節點，example1、example2、example3、example4，可以在config.xml中配置，配置文件中搜索remote_servers，在remote_servers內即可配置字集羣，也可以提出來配置到擴展文件中。incl屬性表示可從外部文件中獲取節點名爲clickhouse_remote_servers的配置內容。
通常，我們採用擴展文件的方式來配置集羣，首先，在config.xml文件中添加外部擴展配置文件metrika.xml的配置信息，在config.xml文件中加入以下內容允許使用擴展文件metrika.xml來配置信息。
<!-- 依賴外部metrika.xm依賴外部metrika.xml -->
<include_from>/etc/clickhouse-server/metrika.xml</include_from>
然後，在/etc/clickhouse-server下新建metrika.xml文件，並且插入以下內容。
<yandex>
<!-- 集羣配置 -->
<clickhouse_remote_servers>
<cluster_with_replica>
<!-- 數據分片1 -->
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>example1</host>
<port>9000</port>
</replica>
<replica>
<host>example2</host>
<port>9000</port>
</replica>
</shard>
<!-- 數據分片2 -->
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>example3</host>
<port>9000</port>
</replica>
<replica>
<host>example4</host>
<port>9000</port>
</replica>
</shard>
</cluster_with_replica>
</clickhouse_remote_servers>
<macros>
<shard>1</shard>
<replica>01</replica>
</macros>
<!-- ZK -->
<zookeeper-servers>
<node index="1">
<host>example1</host>
<port>2181</port>
</node>
<node index="2">
<host>example2</host>
<port>2181</port>
</node>
<node index="3">
<host>example3</host>
<port>2181</port>
</node>
</zookeeper-servers>
<!-- 數據壓縮算法 -->
<clickhouse_compression>
<case>
<min_part_size>10000000000</min_part_size>
<min_part_size_ratio>0.01</min_part_size_ratio>
<method>lz4</method>
</case>
</clickhouse_compression>
</yandex>
說明：
- clickhouse_remote_servers與config.xml中的incl屬性值對應；
- cluster_with_replica是集羣名，可以自定義；
- Shard即爲數據分片；
- internal_replication=true 這個參數和數據的寫入，自動複製相關。從生產環境角度考慮，我們都是複製表，通過本地表寫入，這裏配置true就好。 不推薦也不需要考慮其他情況 ；
- macros是使用複製引擎時指定的ZooKeeper路徑中佔位符替換的信息。（注意這裏的配置在創建Distribute表時會用到，見【表的創建】，注意這裏不同的shard和replica需要區分開來，通常集羣中的每個節點都不一樣的；
- ZooKeeper-servers來同步數據，指定當前集羣的ZooKeeper信息即可；
- clickhouse_compression數據的壓縮。
表的創建
我們這裏以有副本模式的數據寫入爲例，首先在每一個節點創建本地表，可以到每個實例上運行一次建表語句。
（1） 創建本地表
- /clickhouse/tables/{shard}/test：代表的是這張表在ZooKeeper上的路徑。即配置在相同Shard裏面的不同replica的機器需要配置相同的路徑，不同Shard的路徑不同；
- {replica}：分片的名稱，可以理解是機器名,即需要每臺機器都不同；
- 集羣的配置,{shard}{replica}配置在配置文件metrika.xml中。
此時，將internal_replication設置爲true，這種配置下，寫入不需要通過分佈式表，而是將數據直接寫入到每個Shard內任意的一個本地表中，如圖所示。
（2）創建分佈式表
我們只借助於分佈式表提供分佈式查詢能力，與數據寫入無關，類似創建DB的View命令，所以這裏只需要在提供查詢入口的機器上創建，並不一定在所有機器上創建。
（3）藉助集羣的指令
oncluster {cluster_name} 這個指令使得操作能在集羣範圍內的節點上都生效。這裏使用類似create table xxx oncluster cluster_name ENGINE = ReplicatedMergeTree()。
在任意一個節點上運行，ClickHouse會根據集羣裏面配置的分片信息在每一個節點上將表格創建好。有些日常批量維護的命令可以通過類似方式執行。
如果需要通過此方式進行維護，需要注意維護一個專門用戶發送集羣指令的節點列表。
實際生產運維中，我們並不推薦集羣指令的方式，建議通過運維的方式，從管理規範上，準備日常維護的批量腳本，配置文件的分發和命令的執行，從操作機上，使用腳本批量遠程登陸執行。
數據的寫入
禁止分佈式寫入，採用本地表寫入。
社區很多夥伴在分享時，也都提到了禁止使用分佈式表寫入，我們也一樣。
禁止使用的原因是需要設計及減少Part的生成頻率，這對整個集羣的穩定性和整體性能有着決定的作用，這個在之前我司的分享中曾經介紹過，我們控制批次的上線和批次的時間窗口，保障寫入操作對每個節點的穩定壓力。
這裏也分享下我們在做評估寫入穩定性測試的結果，作爲大家可借鑑的評估思路，其本質是平衡好合並速度和Part數量的關係，一定是需要相對均衡的。
（1）寫本地表
數據寫入時，可以由客戶端控制數據分佈，直接寫入集羣中ClickHouse實例的本地表，也可以通過LB組件（如LVS，Nginx）進行控制。
（2）寫分佈式表
數據寫入時，先寫入集羣中的分佈式表下的節點臨時目錄，再由分佈式表將Insert語句分發到集羣各個節點上執行，分佈式表不存儲實際數據。
ClickHouse在分佈式寫入時，會根據節點數量在接收請求的節點的下創建集羣節點的臨時目錄，數據（Insert語句）會優先提交的本地目錄下，之後同步數據到對應的節點。此過程好處是提交後，數據不會丟失。我們模擬同步過程中節點異常，重啓後數據也會自動恢復，如果你的數據量及集羣壓力並不大，分佈式也可以認爲是一種簡單的實現方式。
（3）寫入副本同步
在集羣配置中，Shard標籤裏面配置的replica互爲副本，將internal_replication設置成true，此時寫入同一個Shard內的任意一個節點的本地表，ZooKeeper會自動異步的將數據同步到互爲副本的另一個節點。
業務查詢
業務查詢入口要保障查詢高可用，需要提供負載均衡和路由的能力。一些大廠都會有自己的LB基礎設施。其實大家可以能夠觀察ClickHouse提供兩個網絡端口分別是：
HTTP默認8123；
TCP默認9000；
ClickHouse的JDBC客戶端是通過HTTP的方式與ClickHouse進行交互的，我們可以判斷場景的可以基於HTTP協議做負載均衡，路由的中間件是可以滿足需求的，這樣我們的選擇其實就有很多了。基於傳統運維常見中間件的如：LVS,Nginx，HAProxy都有相關的能力，這裏我們選用了Nginx。
我們基於它實現2個目的：（1）負載均衡能力（2）採集請求響應日誌。
大家可能奇怪第2個目的，ClickHouse本身有自己的查詢響應日誌，爲啥還要單獨採集。原因很簡單，我們把ClickHouse本身的日誌定位爲做具體問題，排查與分析的日誌，日誌分散在了集羣內部，並且分佈式的查詢轉換爲本地SQL後作爲集羣的系統行監測，我們認爲並不合適。我們通過Nginx日誌分析線上業務的請求情況，並進行可視化展現包括業務使用情況，慢查詢，併發能力等等，如果確實有需要追溯的場景時候，纔會使用到ClickHouse的自身日誌。
同時我們發現社區目前也提供了CHProxy作爲負載均衡和HTTP代理，從我們角度更願意選擇一個簡單，熟悉的。
需要注意的是，我們只針對提供查詢入口的實例配置分佈式表，然後通過Nginx進行代理。由Nginx將請求路由到代理的ClickHouse實例，這樣既將請求分攤開，又避免了單點故障，同時實現了負載均衡和高可用。並且我們在生產環境中也根據不同的業務配置路由入口，實現訪問的業務和負載隔離。
Nginx轉發後的節點（根據負載配置多個），使用 Distribute 表引擎作爲集羣的統一訪問入口 ，當客戶端查詢分佈式表時，ClickHouse會將查詢分發到集羣中各個節點上執行，並將各個節點的返回結果在分佈式表所在節點上進行匯聚，將匯聚結果作爲最終結果返回給客戶端。
跨中心訪問
在我們的業務中，需要實現跨數據中心的分析，可以利用ClickHouse的靈活配置化分佈式特性，將多數據中心的所有集羣的分片都添加到一個ClickHouse實例中，並在該ClickHouse實例上創建分佈式表，作爲客戶端查詢的統一入口。如下圖所示。
當客戶端查詢該分佈式表時，ClickHouse會將查詢分發到各個數據中心的所有分片上，並將各個分片的返回結果在分佈式表所在配置的節點上進行匯聚，匯聚結果作爲最終結果返回給客戶端，需要注意的是如果數據量巨大會給匯聚節點造成巨大的壓力，所以要平衡好數據量與服務器硬件資源之間的關係，纔可以保證系統的穩定性，從業務的安全來說，也只有對外的入口節點知道整個集羣的信息。
最佳參數實踐
在實際項目中，無論是寫入、查詢以及保證集羣穩定運行，需要配置一些參數來維護集羣的狀態，下屬表格中的參數是我們根據依據線上業務總結出來的最佳實踐參數。如果大家基於ClickHouse的生產使用，我們希望使用者理解其中每一個參數的含義，和配置的目的，社區的交流過程發現很多同行中經常遇到一些問題，實際都可以從表格中得到答案。
請注意， 其中很多參數配置是對集羣的穩定性有着決定性的作用 。在理解的基礎上，大家才能結合自己的硬件和業務設置自己的最佳參數實踐。
集羣監控
ClickHouse集羣監控通常使用ClickHouse Exporter + Prometheus +Grafana方式， Exporter負責信息採集，時序數據庫Prometheus存儲相關日誌，並用Grafana進行展現， Grafana基於ClickHouse的監控主題可以查詢社區貢獻的插件。
我們定義監控有2個維度：
（1）集羣信息監控
這裏主要是ClickHouse服務的指標，我們除了通過Exporter採集的數據進行展現外，大家可以選擇合適的Grafana的主題同時自己也可以擴展通過ClickHouse直接訪問系統的配置信息進行展示。
（2） 業務信息監控
這裏我更想介紹的是業務信息的監控，詳情見【業務查詢】。我們通過Nginx額外收集所有訪問日誌，這些日誌我們也同樣存儲到了ClickHouse，基於這個我們進行了併發、響應時間、長尾查詢相關的統計分析。
同時也針對業務表，進行配置了相關統計任務，統計信息存儲與ClickHouse的統計表。
基於Grafana我們將這些業務信息進行了可視化展現。
這裏主要是ClickHouse服務的指標，我們除了通過Exporter採集的數據進行展現外，大家可以選擇合適的Grafana的主題同時自己也可以擴展通過ClickHouse直接訪問系統的配置信息進行展示，如圖所示，爲我們的一個監控頁面，展示着集羣的數據量變化以及其他業務信息。
版本升級
在數據模型版本兼容的情況下，可以使用如下方式升級版本
總體流程：
- 停止當前進程
- 然後卸載已安裝的ClickHouse相關安裝包
- 備份當前集羣的配置文件config.xml、metrika.xml、users.xml
- 安裝新的安裝包
- 使用備份的配置文件覆蓋自動生成的文件
注意：
ClickHouse正常部署完成有三個配置文件，分別是：
config.xml （基本配置）
metrika.xml （集羣配置）
users.xml （用戶以及限額相關配置）
卸載原版本後會將users.xml刪除，並且將config.xml重命名爲config.rpmsave，所以users.xml要注意備份，可以先將users.xml重命名，這樣就不會被刪除。
升級過程：
（1）停止進程 ，查看已安裝的ClickHouse：rpm -qa | grep clickhouse
clickhouse-client-19.15.3.6-1.el7.x86_64
clickhouse-server-common-19.15.3.6-1.el7.x86_64
clickhouse-server-19.15.3.6-1.el7.x86_64
clickhouse-common-static-19.15.3.6-1.el7.x86_64
（2）卸載以上安裝包
注意按照順序卸載：
rpm -e clickhouse-client-19.15.3.6-1.el7.x86_64
rpm -e clickhouse-server-19.15.3.6-1.el7.x86_64
rpm -e clickhouse-common-static-19.15.3.6-1.el7.x86_64
rpm-e clickhouse-server-common-19.15.3.6-1.el7.x86_64
卸載完成後提示：
warning:/etc/clickhouse-server/config.xml saved as/etc/clickhouse-server/config.xml.rpmsave
此時/etc/clickhouse-server/下只剩兩個配置文件，並且config.xml被重命名爲config.rpmsave，users.xml被刪除。（若users.xml有更改要，卸載前要注意備份）
（3）安裝新版本
rpm -ivh *
此時/etc/clickhouse-server/下重新生成了新的config.xml與users.xml
使用原來的config.xml替換新生成的config.xml
rm -rf config.xml
mv config.xml.rpmsaveconfig.xml
使用用原來的users.xml替換新生成的users.xml
rm -rf users.xml
mv users.xml.bakusers.xml
（4）啓動ClickHouse
serviceclickhouse-server start
附常用引擎
MergeTree
MergeTree是ClickHouse中最強大的表引擎。在大量數據寫入時數據，數據高效的以批次的形式寫入，寫入完成後在後臺會按照一定的規則就行數據合併，並且MergeTree引擎家族還有很多擴展引擎*MergeTree，注意，Merge引擎不屬於*MergeTree系列。
建表：
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
INDEX index_name1 expr1 TYPE type1(...) GRANULARITY value1,
INDEX index_name2 expr2 TYPE type2(...) GRANULARITY value2
) ENGINE = MergeTree()
[PARTITION BY expr]
[ORDER BY expr]
[PRIMARY KEY expr]
[SAMPLE BY expr]
[SETTINGS name=value, ...]
- ENGINE—引擎名和參數。ENGINE = MergeTree(). MergeTree 引擎沒有參數
- PARTITION BY—分區鍵
- ORDER BY—表的排序鍵
- PRIMARY KEY—主鍵【默認情況下主鍵跟排序鍵（由
ORDER BY子句指定）相同】 - SAMPLE BY—用於抽樣的表達式
- SETTINGS—影響 MergeTree 性能的額外參數：
index_granularity—索引粒度。即索引中相鄰『標記』間的數據行數。默認值，8192。
index_granularity_bytes—索引粒度，以字節爲單位，默認值: 10Mb。
enable_mixed_granularity_parts—啓用或禁用通過index_granularity_bytes控制索引粒度的大小。
use_minimalistic_part_header_in_zookeeper—數據片段頭在ZooKeeper中的存儲方式。如果設置了use_minimalistic_part_header_in_zookeeper=1 ，ZooKeeper會存儲更少的數據。
min_merge_bytes_to_use_direct_io—使用直接I/O來操作磁盤的合併操作時要求的最小數據量。
merge_with_ttl_timeout—TTL合併頻率的最小間隔時間。默認值: 86400 (1天)。
write_final_mark—啓用或禁用在數據片段尾部寫入最終索引標記。默認值:1（不建議更改）。
storage_policy—存儲策略。
ReplacingMergeTree
該引擎和MergeTree的不同之處在於它會刪除具有相同主鍵的重複項。數據的去重只會在合併的過程中出現。合併會在未知的時間在後臺進行，所以你無法預先作出計劃。有一些數據可能仍未被處理。因此，ReplacingMergeTree適用於在後臺清除重複的數據以節省空間，但是它不保證沒有重複的數據出現。同時ReplacingMergeTree在一定程度上可以彌補ClickHouse不能對數據做更新的操作。
建表：
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
) ENGINE = ReplacingMergeTree([ver])
[PARTITION BY expr]
[ORDER BY expr]
[PRIMARY KEY expr]
[SAMPLE BY expr]
[SETTINGS name=value, ...]
- 合併的時候，ReplacingMergeTree 從所有具有相同主鍵的行中選擇一行留下：
如果ver 列未指定，選擇最後一條。
如果ver 列已指定，選擇 ver 值最大的版本。
SummingMergeTree
該引擎繼承自MergeTree。區別在於，當合並 SummingMergeTree 表的數據片段時，ClickHouse 會把所有具有相同主鍵的行合併爲一行，該行包含了被合併的行中具有數值數據類型的列的彙總值。如果主鍵的組合方式使得單個鍵值對應於大量的行，則可以顯著的減少存儲空間並加快數據查詢的速度。
建表：
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
) ENGINE = SummingMergeTree([columns])
[PARTITION BY expr]
[ORDER BY expr]
[SAMPLE BY expr]
[SETTINGS name=value, ...]
- columns - 包含了將要被彙總的列的列名的元組。可選參數。
如果沒有指定 columns，ClickHouse 會把所有不在主鍵中的數值類型的列都進行彙總。
Replicated*MergeTree
- ReplicatedMergeTree
- ReplicatedSummingMergeTree
- ReplicatedReplacingMergeTree
- ReplicatedAggregatingMergeTree
- ReplicatedCollapsingMergeTree
- ReplicatedVersionedCollapsingMergeTree
- ReplicatedGraphiteMergeTree
副本是表級別的，不是整個服務器級的。所以，服務器裏可以同時有複製表和非複製表。副本不依賴分片。每個分片有它自己的獨立副本。要使用副本，需在配置文件中設置 ZooKeeper 集羣的地址。需要 ZooKeeper 3.4.5 或更高版本。
例如：
<zookeeper>
<node index="1">
<host>example1</host>
<port>2181</port>
</node>
<node index="2">
<host>example2</host>
<port>2181</port>
</node>
<node index="3">
<host>example3</host>
<port>2181</port>
</node>
</zookeeper>
Distributed
以上引擎都是數據存儲引擎，但是該引擎-分佈式引擎本身不存儲數據，但可以在多個服務器上進行分佈式查詢。讀是自動並行的。讀取時，遠程服務器表的索引會被使用。
建表：
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
) ENGINE = Distributed(cluster, db, table_name, [policy_name])
分佈式引擎參數：服務器配置文件中的集羣名，遠程數據庫名，遠程表名，數據分佈策略。
致謝
在ClickHouse的學習、評測、應用及對集羣的維護過程中，得到了來自同行以及ClickHouse中文社區，還有ClickHouse研發團隊的巨大幫助，尤其感謝新浪高鵬的幫助，爲我們解決使用過程中的難題提供了思路，同時還爲我們的集羣架構提出了很多非常有建設性的指導建議。
本文轉載自公衆號百分點（ID：baifendian_com）。
原文鏈接：