百分点大数据技术团队：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研发团队的巨大帮助，尤为感谢新浪高鹏的帮助，为咱们解决使用过程当中的难题提供了思路，同时还为咱们的集群架构提出了不少很是有建设性的指导建议。