前言：Clickhouse数据库作为OLAP领域内的一匹黑马，目前在众多大厂已经广泛的被使用。MobTech在2020年开始尝试使用Clickhouse，并且具有一定的数据规模，目前线上Clickhouse集群数据规模为百亿左右。

 

Clickhouse是什么？

 

Clickhouse(https://Clickhouse.tech/)是俄罗斯最大的搜索引擎厂商Yandex开发的一款OLAP数据库，是一款面向列式存储的近实时数据库系统。它的特点就是快，适用场景如下：

1.数据量比较大，亿级别以上；

2.数据不需要更新；

3.没有事务要求；

4.查询并发要求不高。

 

Clickhouse为什么这么快？主要是以下两个原因：

1.对于OLAP数据库，每次查询并不需要访问所有的列。使用列存储能够极大减少IO，提升数据查询速度。另外使用列式存储也便于进行压缩，减少数据体积；

2.Clickhouse 执行引擎使用CPU向量执行模型，能够极大提高计算速度。

 

 Clickhouse与其他OLAP系统的优劣势对比？

 

目前在OLAP领域内使用比较多的系统主要有：Presto、Druid、Kylin、Doris和Clickhouse等其他。整个OLAP系统主要分为两大类型：预聚合和实时聚合，这两种类型都有各自的优缺点。

 

预聚合数据库特点：

1.查询速度比较快，由于已经预聚合部分数据，整体的数据集会相对减少；

2.数据经过预聚合会导致明细数据丢失，这也是一大问题；

3.数据需要预先聚合，查询灵活性比较低，也会导致维度膨胀整体数据量偏大。

 

实时聚合数据库特点：

1.存储所有明细数据，查询响应时间会稍微偏大；

2.不需要预聚合，查询灵活度比较高。

 

上述数据库Druid，Kylin属于预聚合类型，而Presto，Doris，Clickhouse属于实时聚合类型。MobTech主流使用的OLAP系统为Presto，下面介绍下Presto的特点：

 

Presto是一个计算和存储分离的OLAP系统，支持标准SQL查询，完全基于内存运行，动态编译执行计划。Presto查询引擎是主从架构，由一个协调节点，一个发现节点，多个工作节点组成。通常情况下，发现节点和协调节点运行在同一个进程内，协调节点负责SQL解析，生成执行计划，分发任务到工作节点，工作节点负责实际的查询任务执行。

 

MobTech在使用Presto过程中存在不少问题，如：

1.无法控制资源使用量，导致不同业务线之间资源抢占比较严重；

2.查询速度比较慢；

3.Presto是纯内存计算，对资源消耗比较大。

Clickhouse核心之MergeTree表引擎

 

MergeTree系列表引擎，是Clickhouse最核心的表引擎。存储的数据顺序按主键排序，可以使用数据分区，支持数据副本特性和数据抽样。官方提供了包括MergeTree、ReplacingMergeTree、SummingMergeTree、AggregatingMergeTree、CollapsingMergeTree、VersionCollapsingMergeTree、GraphiteMergeTree等7种引擎。以下为每种表引擎的简单介绍：

 

1. ReplacingMergeTree：该引擎会在后台数据合并时移除具有相同排序键的记录；

2. SummingMergeTree：在合并数据时，会把具有相同主键的记录合并为一条记录。并根据主键进行数据聚合；

3.AggregatingMergeTree：在合并数据时，把具有相同主键的记录根据指定的聚合函数进行聚合；

4.CollapsingMergeTree：在合并数据时，把具有相同主键的记录进行折叠。折叠规则根据设定的sign字段，该字段值为1时保留，-1时删除；

5.VersionCollapsingMergeTree: 在合并数据时，把具有相同主键的记录合并，合并规则是根据指定的version字段。

 

这些表引擎在处理数据聚合和合并时，都只在同一个分区内。在使用MergeTree表引擎有一点需要注意，Clickhouse的主键并不唯一，意味着数据可能重复。另外MergeTree表引擎数据分区，每个分区都是一个单独的物理文件目录。在查询时指定分区，要比不指定分区查询快数倍。

 

ReplicatedMergeTree表引擎可以设定数据副本存储。在线上使用时，我们是要求必须使用 ReplicatedMergeTree引擎，防止单点问题。

 

 Clickhouse在MobTech的应用与实践

 

业务需求场景：

每天大数据会离线跑出一批数据，每天数据量最多达到数亿，业务需要能够实时查询这些数据明细，并进行相关数据统计，每天新导入的数据是一个新的分区。由于大数据任务会出现延迟的情况，在这样的情况下需要能够查询前一天的数据。针对这样的情况，我们在每次查询数据前会查出该表最新的分区，然后在具体查询SQL中指定最新分区进行查询。最开始我们选择了Elasticsearch作为存储系统，由于大数据任务在导入数据时会导致Elasticsearch大量磁盘读写，甚至导致Elasticsearch宕机情况出现。

 

在这样的情况下，我们急需要一种新的数据库来支撑业务。在了解到Clickhouse的特性和综合业务相关情况，我们最终选择了Clickhouse。经过对比各种表引擎后，选择了ReplicatedMergeTree引擎，将常用的查询字段作为主键索引。另外由于业务需要每天还会有少量的在线数据入库，使用Kafka表引擎接收在线实时数据。通过物化视图的方式，将Kafka表数据写入到目标表。Clickhouse既能够支撑离线数据的导入，也支持实时数据写入，并且具有良好的查询性能。

 

实践总结：

目前线上Clickhouse单表最大记录数为几十亿左右，只使用了2台8核16G的机器就完成了TP99 1s内查询响应。目前线上使用的是单分片加数据副本的模式，能够充分利用Clickhouse单机强大的能力，又能保障线上数据安全。Clickhouse也有一些缺点，比如：数据更新比较麻烦，大规模集群没有较好的管理工具等问题存在。总的来说，Clickhouse能够以较低的成本完成大量数据查询和分析需求，并且保持稳定。