ClickHouse目錄下多為測(cè)試版更新，更新速度快；clickhouse-altinity-stable目錄為穩(wěn)定版發(fā)布目錄。
（2）部署包說(shuō)明
ClickHouse安裝部署需要四個(gè)安裝包：
clickhouse-client.rpm
clickhouse-common-static.rpm
clickhouse-server.rpm
clickhouse-server-common4.rpm
（3）部署方式
下載安裝包時(shí)要對(duì)應(yīng)版本下載四個(gè)安裝包，將四個(gè)安裝包拷貝到統(tǒng)一目錄下，執(zhí)行rpm -ivh * 即可完成安裝。
安裝完成后的主要目錄以及文件說(shuō)明：
/etc/clickhouse-server：配置文件目錄，包括：config.xml和users.xml
/etc/clickhouse-client：客戶端配置文件目錄
/var/lib/clickhouse：默認(rèn)數(shù)據(jù)目錄
/var/log/clickhouse-server：默認(rèn)日志目錄
/etc/init.d/clickhouse-server：?jiǎn)?dòng)shell腳本
/etc/security/limits.d/clickhouse.conf：最大文件打開(kāi)數(shù)的配置
/etc/cron.d/clickhouse-server：定時(shí)任務(wù)配置，默認(rèn)沒(méi)有任務(wù)
/usr/bin/clickhouse-client：clickhouse客戶端
如上圖，是我們的線上服務(wù)器情況，ClickHouse查詢使用并行處理機(jī)制，對(duì)CPU和內(nèi)存的要求還是比較高的。不建議單臺(tái)機(jī)器上部署多個(gè)節(jié)點(diǎn)，同時(shí)也要求ClickHouse節(jié)點(diǎn)與集群中ZooKeeper節(jié)點(diǎn)分開(kāi)。防止高負(fù)載下相互影響。
由于當(dāng)時(shí)使用的ClickHouse版本不支持多數(shù)據(jù)盤(pán)，所以選擇一個(gè)合適的Raid方式也是很多人關(guān)心的問(wèn)題，這里我們直接建議Raid5，注意配置熱備盤(pán)，這樣無(wú)論從磁盤(pán)IO，數(shù)據(jù)可靠性，數(shù)據(jù)恢復(fù)，及運(yùn)維復(fù)雜度來(lái)說(shuō)都提供了很好的保障。這里也給出了Raid5情況下的磁盤(pán)恢復(fù)的影響，供大家參考。
此外， 19.15 版本開(kāi)始，ClickHouse 開(kāi)始實(shí)現(xiàn)多卷存儲(chǔ)的功能。它具有多種用途，其中最重要的用途是將熱數(shù)據(jù)和冷數(shù)據(jù)存儲(chǔ)在不同類型的存儲(chǔ)中。這種配置被稱為分層存儲(chǔ)，如何很好的利用多卷存儲(chǔ)能力，實(shí)現(xiàn)結(jié)合業(yè)務(wù)實(shí)現(xiàn)分層存儲(chǔ)，也期待大家能分享自己的經(jīng)驗(yàn)。
圖1 分布式集群示例
圖2 分片和副本關(guān)系示例
如【圖1、圖2】，ClickHouse分布式集群有4個(gè)節(jié)點(diǎn)，2個(gè)Shard，副本數(shù)為2。其中節(jié)點(diǎn)example1,example2屬于同一Shard,互為副本，他們的數(shù)據(jù)一致。example3,example4屬于同一Shard。查詢時(shí)，分布從2個(gè)Shard中隨機(jī)取一個(gè)節(jié)點(diǎn)進(jìn)行訪問(wèn)。其中任何單節(jié)點(diǎn)異常時(shí)，寫(xiě)入和查詢都能保障數(shù)據(jù)完整性，高可用，業(yè)務(wù)無(wú)感知。
ClickHouse的分布式也是一個(gè)有意思的設(shè)計(jì)方式，多個(gè)節(jié)點(diǎn)部署完成后，節(jié)點(diǎn)與節(jié)點(diǎn)之間并沒(méi)有聯(lián)系。通過(guò)ClickHouse集群的配置文件來(lái)實(shí)現(xiàn)，即節(jié)點(diǎn)與節(jié)點(diǎn)之間通過(guò)配置文件來(lái)形成成集群，配置中包含集群的節(jié)點(diǎn)信息，復(fù)制節(jié)點(diǎn)，分片節(jié)點(diǎn)，同構(gòu)成一個(gè)Cluster。
這樣就形成了一個(gè)有意思的現(xiàn)象。我們可以抽象為：“集群定義節(jié)點(diǎn)，和節(jié)點(diǎn)關(guān)系，節(jié)點(diǎn)不知道集群”。這樣一個(gè)引用關(guān)系，表現(xiàn)為ClickHouse的分布式在使用上就很靈活。
舉個(gè)例子，一個(gè)集群里有30節(jié)點(diǎn)，我可以挑選其中2個(gè)配置整個(gè)集群的分布式關(guān)系，這樣你會(huì)發(fā)現(xiàn)每個(gè)節(jié)點(diǎn)都是獨(dú)立的，并不知道整個(gè)集群的全貌，集群的調(diào)整我只要關(guān)注2個(gè)節(jié)點(diǎn)的配置就行。包括基于之上的，數(shù)據(jù)安全，外部訪問(wèn)控制等等。
如上，從高可用的角度，我們默認(rèn)都是采用分布式集群方式，數(shù)據(jù)做分片，保證數(shù)據(jù)寫(xiě)入不中斷。數(shù)據(jù)副本提供可靠性，同時(shí)提升并發(fā)查詢能力。
有四個(gè)節(jié)點(diǎn)，example1、example2、example3、example4，可以在config.xml中配置，配置文件中搜索remote_servers，在remote_servers內(nèi)即可配置字集群，也可以提出來(lái)配置到擴(kuò)展文件中。incl屬性表示可從外部文件中獲取節(jié)點(diǎn)名為clickhouse_remote_servers的配置內(nèi)容。
通常，我們采用擴(kuò)展文件的方式來(lái)配置集群，首先，在config.xml文件中添加外部擴(kuò)展配置文件metrika.xml的配置信息，在config.xml文件中加入以下內(nèi)容允許使用擴(kuò)展文件metrika.xml來(lái)配置信息。
<!-- 依賴外部metrika.xm依賴外部metrika.xml --><include_from>/etc/clickhouse-server/metrika.xml</include_from>
然后，在/etc/clickhouse-server下新建metrika.xml文件，并且插入以下內(nèi)容。
說(shuō)明：
我們這里以有副本模式的數(shù)據(jù)寫(xiě)入為例，首先在每一個(gè)節(jié)點(diǎn)創(chuàng)建本地表，可以到每個(gè)實(shí)例上運(yùn)行一次建表語(yǔ)句。
（1） 創(chuàng)建本地表
此時(shí)，將internal_replication設(shè)置為true，這種配置下，寫(xiě)入不需要通過(guò)分布式表，而是將數(shù)據(jù)直接寫(xiě)入到每個(gè)Shard內(nèi)任意的一個(gè)本地表中，如圖所示。
（2）創(chuàng)建分布式表
我們只借助于分布式表提供分布式查詢能力，與數(shù)據(jù)寫(xiě)入無(wú)關(guān)，類似創(chuàng)建DB的View命令，所以這里只需要在提供查詢?nèi)肟诘臋C(jī)器上創(chuàng)建，并不一定在所有機(jī)器上創(chuàng)建。
（3）借助集群的指令
oncluster {cluster_name} 這個(gè)指令使得操作能在集群范圍內(nèi)的節(jié)點(diǎn)上都生效。這里使用類似create table xxx oncluster [cluster_name](xxx) ENGINE = ReplicatedMergeTree()。
在任意一個(gè)節(jié)點(diǎn)上運(yùn)行，ClickHouse會(huì)根據(jù)集群里面配置的分片信息在每一個(gè)節(jié)點(diǎn)上將表格創(chuàng)建好。有些日常批量維護(hù)的命令可以通過(guò)類似方式執(zhí)行。
如果需要通過(guò)此方式進(jìn)行維護(hù)，需要注意維護(hù)一個(gè)專門(mén)用戶發(fā)送集群指令的節(jié)點(diǎn)列表。
實(shí)際生產(chǎn)運(yùn)維中，我們并不推薦集群指令的方式，建議通過(guò)運(yùn)維的方式，從管理規(guī)范上，準(zhǔn)備日常維護(hù)的批量腳本，配置文件的分發(fā)和命令的執(zhí)行，從操作機(jī)上，使用腳本批量遠(yuǎn)程登陸執(zhí)行。
禁止分布式寫(xiě)入，采用本地表寫(xiě)入。
社區(qū)很多伙伴在分享時(shí)，也都提到了禁止使用分布式表寫(xiě)入，我們也一樣。
禁止使用的原因是需要設(shè)計(jì)及減少Part的生成頻率，這對(duì)整個(gè)集群的穩(wěn)定性和整體性能有著決定的作用，這個(gè)在之前我司的分享中曾經(jīng)介紹過(guò)，我們控制批次的上線和批次的時(shí)間窗口，保障寫(xiě)入操作對(duì)每個(gè)節(jié)點(diǎn)的穩(wěn)定壓力。
這里也分享下我們?cè)谧鲈u(píng)估寫(xiě)入穩(wěn)定性測(cè)試的結(jié)果，作為大家可借鑒的評(píng)估思路，其本質(zhì)是平衡好合并速度和Part數(shù)量的關(guān)系，一定是需要相對(duì)均衡的。
（1）寫(xiě)本地表
數(shù)據(jù)寫(xiě)入時(shí)，可以由客戶端控制數(shù)據(jù)分布，直接寫(xiě)入集群中ClickHouse實(shí)例的本地表，也可以通過(guò)LB組件（如LVS，Nginx）進(jìn)行控制。
（2）寫(xiě)分布式表
數(shù)據(jù)寫(xiě)入時(shí)，先寫(xiě)入集群中的分布式表下的節(jié)點(diǎn)臨時(shí)目錄，再由分布式表將Insert語(yǔ)句分發(fā)到集群各個(gè)節(jié)點(diǎn)上執(zhí)行，分布式表不存儲(chǔ)實(shí)際數(shù)據(jù)。
ClickHouse在分布式寫(xiě)入時(shí)，會(huì)根據(jù)節(jié)點(diǎn)數(shù)量在接收請(qǐng)求的節(jié)點(diǎn)的下創(chuàng)建集群節(jié)點(diǎn)的臨時(shí)目錄，數(shù)據(jù)（Insert語(yǔ)句）會(huì)優(yōu)先提交的本地目錄下，之后同步數(shù)據(jù)到對(duì)應(yīng)的節(jié)點(diǎn)。此過(guò)程好處是提交后，數(shù)據(jù)不會(huì)丟失。我們模擬同步過(guò)程中節(jié)點(diǎn)異常，重啟后數(shù)據(jù)也會(huì)自動(dòng)恢復(fù)，如果你的數(shù)據(jù)量及集群壓力并不大，分布式也可以認(rèn)為是一種簡(jiǎn)單的實(shí)現(xiàn)方式。
（3）寫(xiě)入副本同步
在集群配置中，Shard標(biāo)簽里面配置的replica互為副本，將internal_replication設(shè)置成true，此時(shí)寫(xiě)入同一個(gè)Shard內(nèi)的任意一個(gè)節(jié)點(diǎn)的本地表，ZooKeeper會(huì)自動(dòng)異步的將數(shù)據(jù)同步到互為副本的另一個(gè)節(jié)點(diǎn)。
業(yè)務(wù)查詢?nèi)肟谝Ｕ喜樵兏呖捎茫枰峁┴?fù)載均衡和路由的能力。一些大廠都會(huì)有自己的LB基礎(chǔ)設(shè)施。其實(shí)大家可以能夠觀察ClickHouse提供兩個(gè)網(wǎng)絡(luò)端口分別是：
HTTP默認(rèn)8123；
TCP默認(rèn)9000；
ClickHouse的JDBC客戶端是通過(guò)HTTP的方式與ClickHouse進(jìn)行交互的，我們可以判斷場(chǎng)景的可以基于HTTP協(xié)議做負(fù)載均衡，路由的中間件是可以滿足需求的，這樣我們的選擇其實(shí)就有很多了?；趥鹘y(tǒng)運(yùn)維常見(jiàn)中間件的如：LVS,Nginx，HAProxy都有相關(guān)的能力，這里我們選用了Nginx。
我們基于它實(shí)現(xiàn)2個(gè)目的：（1）負(fù)載均衡能力（2）采集請(qǐng)求響應(yīng)日志。
大家可能奇怪第2個(gè)目的，ClickHouse本身有自己的查詢響應(yīng)日志，為啥還要單獨(dú)采集。原因很簡(jiǎn)單，我們把ClickHouse本身的日志定位為做具體問(wèn)題，排查與分析的日志，日志分散在了集群內(nèi)部，并且分布式的查詢轉(zhuǎn)換為本地SQL后作為集群的系統(tǒng)行監(jiān)測(cè)，我們認(rèn)為并不合適。我們通過(guò)Nginx日志分析線上業(yè)務(wù)的請(qǐng)求情況，并進(jìn)行可視化展現(xiàn)包括業(yè)務(wù)使用情況，慢查詢，并發(fā)能力等等，如果確實(shí)有需要追溯的場(chǎng)景時(shí)候，才會(huì)使用到ClickHouse的自身日志。
同時(shí)我們發(fā)現(xiàn)社區(qū)目前也提供了CHProxy作為負(fù)載均衡和HTTP代理，從我們角度更愿意選擇一個(gè)簡(jiǎn)單，熟悉的。
需要注意的是，我們只針對(duì)提供查詢?nèi)肟诘膶?shí)例配置分布式表，然后通過(guò)Nginx進(jìn)行代理。由Nginx將請(qǐng)求路由到代理的ClickHouse實(shí)例，這樣既將請(qǐng)求分?jǐn)傞_(kāi)，又避免了單點(diǎn)故障，同時(shí)實(shí)現(xiàn)了負(fù)載均衡和高可用。并且我們?cè)谏a(chǎn)環(huán)境中也根據(jù)不同的業(yè)務(wù)配置路由入口，實(shí)現(xiàn)訪問(wèn)的業(yè)務(wù)和負(fù)載隔離。
Nginx轉(zhuǎn)發(fā)后的節(jié)點(diǎn)（根據(jù)負(fù)載配置多個(gè)），使用Distribute表引擎作為集群的統(tǒng)一訪問(wèn)入口，當(dāng)客戶端查詢分布式表時(shí)，ClickHouse會(huì)將查詢分發(fā)到集群中各個(gè)節(jié)點(diǎn)上執(zhí)行，并將各個(gè)節(jié)點(diǎn)的返回結(jié)果在分布式表所在節(jié)點(diǎn)上進(jìn)行匯聚，將匯聚結(jié)果作為最終結(jié)果返回給客戶端。
在我們的業(yè)務(wù)中，需要實(shí)現(xiàn)跨數(shù)據(jù)中心的分析，可以利用ClickHouse的靈活配置化分布式特性，將多數(shù)據(jù)中心的所有集群的分片都添加到一個(gè)ClickHouse實(shí)例中，并在該ClickHouse實(shí)例上創(chuàng)建分布式表，作為客戶端查詢的統(tǒng)一入口。如下圖所示。
當(dāng)客戶端查詢?cè)摲植际奖頃r(shí)，ClickHouse會(huì)將查詢分發(fā)到各個(gè)數(shù)據(jù)中心的所有分片上，并將各個(gè)分片的返回結(jié)果在分布式表所在配置的節(jié)點(diǎn)上進(jìn)行匯聚，匯聚結(jié)果作為最終結(jié)果返回給客戶端，需要注意的是如果數(shù)據(jù)量巨大會(huì)給匯聚節(jié)點(diǎn)造成巨大的壓力，所以要平衡好數(shù)據(jù)量與服務(wù)器硬件資源之間的關(guān)系，才可以保證系統(tǒng)的穩(wěn)定性，從業(yè)務(wù)的安全來(lái)說(shuō)，也只有對(duì)外的入口節(jié)點(diǎn)知道整個(gè)集群的信息。
在實(shí)際項(xiàng)目中，無(wú)論是寫(xiě)入、查詢以及保證集群穩(wěn)定運(yùn)行，需要配置一些參數(shù)來(lái)維護(hù)集群的狀態(tài)，下屬表格中的參數(shù)是我們根據(jù)依據(jù)線上業(yè)務(wù)總結(jié)出來(lái)的最佳實(shí)踐參數(shù)。如果大家基于ClickHouse的生產(chǎn)使用，我們希望使用者理解其中每一個(gè)參數(shù)的含義，和配置的目的，社區(qū)的交流過(guò)程發(fā)現(xiàn)很多同行中經(jīng)常遇到一些問(wèn)題，實(shí)際都可以從表格中得到答案。
請(qǐng)注意，其中很多參數(shù)配置是對(duì)集群的穩(wěn)定性有著決定性的作用。在理解的基礎(chǔ)上，大家才能結(jié)合自己的硬件和業(yè)務(wù)設(shè)置自己的最佳參數(shù)實(shí)踐。
ClickHouse集群監(jiān)控通常使用ClickHouse Exporter + Prometheus +Grafana方式， Exporter負(fù)責(zé)信息采集，時(shí)序數(shù)據(jù)庫(kù)Prometheus存儲(chǔ)相關(guān)日志，并用Grafana進(jìn)行展現(xiàn)， Grafana基于ClickHouse的監(jiān)控主題可以查詢社區(qū)貢獻(xiàn)的插件。
我們定義監(jiān)控有2個(gè)維度：
（1）集群信息監(jiān)控
這里主要是ClickHouse服務(wù)的指標(biāo)，我們除了通過(guò)Exporter采集的數(shù)據(jù)進(jìn)行展現(xiàn)外，大家可以選擇合適的Grafana的主題同時(shí)自己也可以擴(kuò)展通過(guò)ClickHouse直接訪問(wèn)系統(tǒng)的配置信息進(jìn)行展示。
（2） 業(yè)務(wù)信息監(jiān)控
這里我更想介紹的是業(yè)務(wù)信息的監(jiān)控，詳情見(jiàn)【業(yè)務(wù)查詢】。我們通過(guò)Nginx額外收集所有訪問(wèn)日志，這些日志我們也同樣存儲(chǔ)到了ClickHouse，基于這個(gè)我們進(jìn)行了并發(fā)、響應(yīng)時(shí)間、長(zhǎng)尾查詢相關(guān)的統(tǒng)計(jì)分析。
同時(shí)也針對(duì)業(yè)務(wù)表，進(jìn)行配置了相關(guān)統(tǒng)計(jì)任務(wù)，統(tǒng)計(jì)信息存儲(chǔ)與ClickHouse的統(tǒng)計(jì)表。
基于Grafana我們將這些業(yè)務(wù)信息進(jìn)行了可視化展現(xiàn)。
這里主要是ClickHouse服務(wù)的指標(biāo)，我們除了通過(guò)Exporter采集的數(shù)據(jù)進(jìn)行展現(xiàn)外，大家可以選擇合適的Grafana的主題同時(shí)自己也可以擴(kuò)展通過(guò)ClickHouse直接訪問(wèn)系統(tǒng)的配置信息進(jìn)行展示，如圖所示，為我們的一個(gè)監(jiān)控頁(yè)面，展示著集群的數(shù)據(jù)量變化以及其他業(yè)務(wù)信息。
? 版本升級(jí)
在數(shù)據(jù)模型版本兼容的情況下，可以使用如下方式升級(jí)版本
總體流程：
注意：
ClickHouse正常部署完成有三個(gè)配置文件，分別是：
config.xml （基本配置）
metrika.xml （集群配置）
users.xml （用戶以及限額相關(guān)配置）
卸載原版本后會(huì)將users.xml刪除，并且將config.xml重命名為config.rpmsave，所以u(píng)sers.xml要注意備份，可以先將users.xml重命名，這樣就不會(huì)被刪除。
升級(jí)過(guò)程：
（1）停止進(jìn)程，查看已安裝的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
此時(shí)/etc/clickhouse-server/下只剩兩個(gè)配置文件，并且config.xml被重命名為config.rpmsave，users.xml被刪除。（若users.xml有更改要，卸載前要注意備份）
（3）安裝新版本
rpm -ivh *
此時(shí)/etc/clickhouse-server/下重新生成了新的config.xml與users.xml
使用原來(lái)的config.xml替換新生成的config.xml
rm -rf config.xml
mv config.xml.rpmsaveconfig.xml
使用用原來(lái)的users.xml替換新生成的users.xml
rm -rf users.xml
mv users.xml.bakusers.xml
（4）啟動(dòng)ClickHouse
serviceclickhouse-server start
MergeTree是ClickHouse中最強(qiáng)大的表引擎。在大量數(shù)據(jù)寫(xiě)入時(shí)數(shù)據(jù)，數(shù)據(jù)高效的以批次的形式寫(xiě)入，寫(xiě)入完成后在后臺(tái)會(huì)按照一定的規(guī)則就行數(shù)據(jù)合并，并且MergeTree引擎家族還有很多擴(kuò)展引擎*MergeTree，注意，Merge引擎不屬于*MergeTree系列。
建表：
index_granularity—索引粒度。即索引中相鄰『標(biāo)記』間的數(shù)據(jù)行數(shù)。默認(rèn)值，8192。
index_granularity_bytes—索引粒度，以字節(jié)為單位，默認(rèn)值: 10Mb。
enable_mixed_granularity_parts—啟用或禁用通過(guò)index_granularity_bytes控制索引粒度的大小。
use_minimalistic_part_header_in_zookeeper—數(shù)據(jù)片段頭在ZooKeeper中的存儲(chǔ)方式。如果設(shè)置了use_minimalistic_part_header_in_zookeeper=1 ，ZooKeeper會(huì)存儲(chǔ)更少的數(shù)據(jù)。
min_merge_bytes_to_use_direct_io—使用直接I/O來(lái)操作磁盤(pán)的合并操作時(shí)要求的最小數(shù)據(jù)量。
merge_with_ttl_timeout—TTL合并頻率的最小間隔時(shí)間。默認(rèn)值: 86400 (1天)。
write_final_mark—啟用或禁用在數(shù)據(jù)片段尾部寫(xiě)入最終索引標(biāo)記。默認(rèn)值:1（不建議更改）。
storage_policy—存儲(chǔ)策略。
該引擎和MergeTree的不同之處在于它會(huì)刪除具有相同主鍵的重復(fù)項(xiàng)。數(shù)據(jù)的去重只會(huì)在合并的過(guò)程中出現(xiàn)。合并會(huì)在未知的時(shí)間在后臺(tái)進(jìn)行，所以你無(wú)法預(yù)先作出計(jì)劃。有一些數(shù)據(jù)可能仍未被處理。因此，ReplacingMergeTree適用于在后臺(tái)清除重復(fù)的數(shù)據(jù)以節(jié)省空間，但是它不保證沒(méi)有重復(fù)的數(shù)據(jù)出現(xiàn)。同時(shí)ReplacingMergeTree在一定程度上可以彌補(bǔ)ClickHouse不能對(duì)數(shù)據(jù)做更新的操作。
建表：
如果ver 列未指定，選擇最后一條。
如果ver 列已指定，選擇 ver 值最大的版本。
該引擎繼承自MergeTree。區(qū)別在于，當(dāng)合并 SummingMergeTree 表的數(shù)據(jù)片段時(shí)，ClickHouse 會(huì)把所有具有相同主鍵的行合并為一行，該行包含了被合并的行中具有數(shù)值數(shù)據(jù)類型的列的匯總值。如果主鍵的組合方式使得單個(gè)鍵值對(duì)應(yīng)于大量的行，則可以顯著的減少存儲(chǔ)空間并加快數(shù)據(jù)查詢的速度。
建表：
如果沒(méi)有指定 `columns`，ClickHouse 會(huì)把所有不在主鍵中的數(shù)值類型的列都進(jìn)行匯總。
副本是表級(jí)別的，不是整個(gè)服務(wù)器級(jí)的。所以，服務(wù)器里可以同時(shí)有復(fù)制表和非復(fù)制表。副本不依賴分片。每個(gè)分片有它自己的獨(dú)立副本。要使用副本，需在配置文件中設(shè)置 ZooKeeper 集群的地址。需要 ZooKeeper 3.4.5 或更高版本。
例如：
以上引擎都是數(shù)據(jù)存儲(chǔ)引擎，但是該引擎-分布式引擎本身不存儲(chǔ)數(shù)據(jù)，但可以在多個(gè)服務(wù)器上進(jìn)行分布式查詢。讀是自動(dòng)并行的。讀取時(shí)，遠(yuǎn)程服務(wù)器表的索引會(huì)被使用。
建表：
分布式引擎參數(shù)：服務(wù)器配置文件中的集群名，遠(yuǎn)程數(shù)據(jù)庫(kù)名，遠(yuǎn)程表名，數(shù)據(jù)分布策略。
致 謝
在ClickHouse的學(xué)習(xí)、評(píng)測(cè)、應(yīng)用及對(duì)集群的維護(hù)過(guò)程中，得到了來(lái)自同行以及ClickHouse中文社區(qū)，還有ClickHouse研發(fā)團(tuán)隊(duì)的巨大幫助，尤其感謝新浪高鵬的幫助，為我們解決使用過(guò)程中的難題提供了思路，同時(shí)還為我們的集群架構(gòu)提出了很多非常有建設(shè)性的指導(dǎo)建議。
【本文作者：鄒立民 趙群 】
全球頂尖科學(xué)家陳松蹊院士出任百分點(diǎn)數(shù)據(jù)科學(xué)研究院名譽(yù)院長(zhǎng)
百分點(diǎn)數(shù)據(jù)科學(xué)實(shí)驗(yàn)室：基于數(shù)據(jù)驅(qū)動(dòng)的銷量預(yù)測(cè)模型建構(gòu)
百分點(diǎn)認(rèn)知智能實(shí)驗(yàn)室：如何打造工業(yè)級(jí)的機(jī)器翻譯
百分點(diǎn)大數(shù)據(jù)技術(shù)團(tuán)隊(duì)：輿情平臺(tái)架構(gòu)實(shí)踐與演進(jìn)
百分點(diǎn)大數(shù)據(jù)技術(shù)團(tuán)隊(duì)：政務(wù)數(shù)據(jù)安全管理實(shí)踐百分點(diǎn)大數(shù)據(jù)技術(shù)團(tuán)隊(duì)：萬(wàn)億級(jí)大數(shù)據(jù)監(jiān)控平臺(tái)建設(shè)實(shí)踐百分點(diǎn)大數(shù)據(jù)技術(shù)團(tuán)隊(duì)：數(shù)據(jù)治理“PAI”實(shí)施方法論劉譯璟：未來(lái)3-5年，數(shù)據(jù)智能技術(shù)應(yīng)用五大趨勢(shì)