百分點大數據技術團隊：ClickHouse國家級項目最佳實踐

編者按

ClickHouse自從2016年開源以來，在數據分析（OLAP）領域火熱，各個大廠紛紛跟進大規模使用,百分點在某國家級項目中的完成了多數據中心的ClickHouse集羣建設，目前存儲總量超10PB，日增數據100TB左右，預計流量今年會擴大3倍。本文是結合百分點在前期設計中的經驗對ClickHouse作的整理，其中百分點最佳實踐部分是基於咱們的業務場景以及數據規模，通過大量的測試及總結後獲得的結論，而且充分保證了整個系統往後的穩定運行，極具參考意義。

做者：百分點鄒立民 趙羣

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）

簡單理解就是相同的數據備份，在CK中經過複製集，咱們實現保障了數據可靠性外，也經過多副本的方式，增長了CK查詢的併發能力。這裏通常有2種方式：一、基於ZooKeeper的表複製方式；二、基於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 分片和副本關係示例

如【圖一、圖2】，ClickHouse分佈式集羣有4個節點，2個Shard，副本數爲2。其中節點example1,example2屬於同一Shard，互爲副本，他們的數據一致。example3,example4屬於同一Shard。查詢時，分佈從2個Shard中隨機取一個節點進行訪問。其中任何單節點異常時，寫入和查詢都能保障數據完整性，高可用，業務無感知。

ClickHouse的分佈式也是一個有意思的設計方式，多個節點部署完成後，節點與節點之間並無聯繫。經過ClickHouse集羣的配置文件來實現，即節點與節點之間經過配置文件來造成成集羣，配置中包含集羣的節點信息，複製節點，分片節點，同構成一個Cluster。

這樣就造成了一個有意思的現象。咱們能夠抽象爲："集羣定義節點，和節點關係，節點不知道集羣"。這樣一個引用關係，表現爲ClickHouse的分佈式在使用上就很靈活。

舉個例子，一個集羣裏有30節點，我能夠挑選其中2個配置整個集羣的分佈式關係，這樣你會發現每一個節點都是獨立的，並不知道整個集羣的全貌，集羣的調整我只要關注2個節點的配置就行。包括基於之上的，數據安全，外部訪問控制等等。

如上，從高可用的角度，咱們默認都是採用分佈式集羣方式，數據作分片，保證數據寫入不中斷。數據副本提供可靠性，同時提高併發查詢能力。

集羣配置

有四個節點，example一、example二、example三、example4，能夠在config.xml中配置，配置文件中搜索remote_servers，在remote_servers內便可配置字集羣，也能夠提出來配置到擴展文件中。incl屬性表示可從外部文件中獲取節點名爲clickhouse_remote_servers的配置內容。

一般，咱們採用擴展文件的方式來配置集羣，首先，在config.xml文件中添加外部擴展配置文件metrika.xml的配置信息，在config.xml文件中加入如下內容容許使用擴展文件metrika.xml來配置信息。

而後，在/etc/clickhouse-server下新建metrika.xml文件，而且插入如下內容。

說明：

1) clickhouse_remote_servers與config.xml中的incl屬性值對應

2) cluster_with_replica是集羣名，能夠自定義。

3) shard即爲數據分片

4) internal_replication =true 這個參數和數據的寫入，自動複製相關。從生產環境角度考慮，咱們都是複製表，經過本地表寫入，這裏配置true就好。不推薦也不須要考慮其餘狀況。

5) macros是使用複製引擎時指定的zookeeper路徑中佔位符替換的信息。（注意這裏的配置在建立Distribute表時會用到，見【6.3 表的建立】，注意這裏不一樣的shard和replica須要區分開來，一般集羣中的每一個節點都不同的。

6) zookeeper-servers來同步數據，指定當前集羣的zookeeper信息便可。

7) clickhouse_compression數據的壓縮。

• 表的建立

咱們這裏以有副本模式的數據寫入爲例，首先在每個節點建立本地表，能夠到每一個實例上運行一次建表語句。

（1） 建立本地表：

1) /clickhouse/tables/{shard}/test：表明的是這張表在ZooKeeper上的路徑。即配置在相同shard裏面的不一樣replica的機器須要配置相同的路徑，不一樣shard的路徑不一樣。

2) {replica}：分片的名稱，能夠理解是機器名,即須要每臺機器都不一樣。

3) 集羣的配置,{shard}{replica}配置在配置文件metrika.xml中。

此時，將internal_replication設置爲true，這種配置下，寫入不須要經過分佈式表，而是將數據直接寫入到每一個shard內任意的一個本地表中，如圖所示。

（2） 建立分佈式表：

咱們只借助於分佈式表提供分佈式查詢能力，與數據寫入無關，相似建立DB的View命令，因此這裏只須要在提供查詢入口的機器上建立，並不必定在全部機器上建立。

（3） 藉助集羣的指令

on cluster {cluster_name} 這個指令使得操做能在集羣範圍內的節點上都生效。這裏使用相似create table xxx on cluster [cluster_name](xxx) 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） 業務信息監控

這裏我更想介紹的是業務信息的監控。見【2.6業務查詢】，咱們經過Nginx額外收集全部訪問日誌，這些日誌咱們也一樣存儲到了ClickHouse，基於這個咱們進行了併發，響應時間，長尾查詢相關的統計分析。

同時也針對業務表，進行配置了相關統計任務，統計信息存儲與ClickHouse的統計表。

基於Grafana咱們將這些業務信息進行了可視化展示。

這裏主要是ClickHouse服務的指標，咱們除了經過Exporter採集的數據進行展示外。你們能夠選擇合適的Grafana的主題同時本身也能夠擴展經過ClickHouse直接訪問系統的配置信息進行展現，如圖所示，爲咱們的一個監控頁面，展現着集羣的數據量變化以及其餘業務信息。

• 版本升級

在數據模型版本兼容的狀況下，但是使用以下方式升級版本，整體流程：

1) 中止當前進程

2) 而後卸載已安裝的clickhouse相關安裝包

3) 備份當前集羣的配置文件config.xml、metrika.xml、users.xml

4) 安裝新的安裝包

5) 使用備份的配置文件覆蓋自動生成的文件

注意：

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.rpmsave config.xml

使用用原來的users.xml替換新生成的users.xml

rm -rf users.xml

mv users.xml.bak users.xml

4) 啓動ClickHouse

service clickhouse-server start

附經常使用引擎

• MergeTree

MergeTree是ClickHouse中最強大的表引擎。在大量數據寫入時數據，數據高效的以批次的形式寫入，寫入完成後在後臺會按照必定的規則就行數據合併，而且MergeTree引擎家族還有不少擴展引擎*MergeTree，注意，Merge引擎不屬於*MergeTree系列。

建表：

· 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不能對數據作更新的操做。

建表：

· 合併的時候，ReplacingMergeTree 從全部具備相同主鍵的行中選擇一行留下：

若是 ver 列未指定，選擇最後一條。

若是 ver 列已指定，選擇 ver 值最大的版本。

• SummingMergeTree

該引擎繼承自 MergeTree。區別在於，當合並 SummingMergeTree 表的數據片斷時，ClickHouse 會把全部具備相同主鍵的行合併爲一行，該行包含了被合併的行中具備數值數據類型的列的彙總值。若是主鍵的組合方式使得單個鍵值對應於大量的行，則能夠顯著的減小存儲空間並加快數據查詢的速度。

建表：

· columns - 包含了將要被彙總的列的列名的元組。可選參數。

若是沒有指定 `columns`，ClickHouse 會把全部不在主鍵中的數值類型的列都進行彙總。

• Replicated*MergeTree

· ReplicatedMergeTree

· ReplicatedSummingMergeTree

· ReplicatedReplacingMergeTree

· ReplicatedAggregatingMergeTree

· ReplicatedCollapsingMergeTree

· ReplicatedVersionedCollapsingMergeTree

· ReplicatedGraphiteMergeTree

副本是表級別的，不是整個服務器級的。因此，服務器裏能夠同時有複製表和非複製表。副本不依賴分片。每一個分片有它本身的獨立副本。要使用副本，需在配置文件中設置 ZooKeeper 集羣的地址。須要 ZooKeeper 3.4.5 或更高版本。

例如：

• Distributed

以上引擎都是數據存儲引擎，可是該引擎-分佈式引擎自己不存儲數據，但能夠在多個服務器上進行分佈式查詢。讀是自動並行的。讀取時，遠程服務器表的索引會被使用。

建表：

分佈式引擎參數：服務器配置文件中的集羣名，遠程數據庫名，遠程表名，數據分佈策略。

致謝

在ClickHouse的學習、評測、應用及對集羣的維護過程當中，獲得了來自同行以及ClickHouse中文社區，還有ClickHouse研發團隊的巨大幫助，尤爲感謝新浪高鵬的幫助，爲咱們解決使用過程當中的難題提供了思路，同時還爲咱們的集羣架構提出了不少很是有建設性的指導建議。