前言：Clickhouse数据库作为OLAP畛域内的一匹黑马，目前在泛滥大厂曾经宽泛的被应用。MobTech在2020年开始尝试应用Clickhouse，并且具备肯定的数据规模，目前线上Clickhouse集群数据规模为100亿左右。
一、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种引擎。以下为每种表引擎的简略介绍：
- ReplacingMergeTree：该引擎会在后盾数据合并时移除具备雷同排序键的记录；
- SummingMergeTree：在合并数据时，会把具备雷同主键的记录合并为一条记录。并依据主键进行数据聚合；
3.AggregatingMergeTree：在合并数据时，把具备雷同主键的记录依据指定的聚合函数进行聚合；
4.CollapsingMergeTree：在合并数据时，把具备雷同主键的记录进行折叠。折叠规定依据设定的sign字段，该字段值为1时保留，-1时删除；
5.VersionCollapsingMergeTree: 在合并数据时，把具备雷同主键的记录合并，合并规定是依据指定的version字段。
这些表引擎在解决数据聚合和合并时，都只在同一个分区内。在应用MergeTree表引擎有一点须要留神，Clickhouse的主键并不惟一，意味着数据可能反复。另外MergeTree表引擎数据分区，每个分区都是一个独自的物理文件目录。在查问时指定分区，要比不指定分区查问快数倍。
ReplicatedMergeTree表引擎能够设定数据正本存储。在线上应用时，咱们是要求必须应用 ReplicatedMergeTree引擎，避免单点问题。
四、Clickhouse在MobTech的利用与实际
业务需要场景：
每天大数据会离线跑出一批数据，每天数据量最多达到2亿，业务须要可能实时查问这些数据明细，并进行相干数据统计，每天新导入的数据是一个新的分区。因为大数据工作会呈现提早的状况，在这样的状况下须要可能查问前一天的数据。针对这样的状况，咱们在每次查问数据前会查出该表最新的分区，而后在具体查问SQL中指定最新分区进行查问。最开始咱们抉择了Elasticsearch作为存储系统，因为大数据工作在导入数据时会导致Elasticsearch大量磁盘读写，甚至导致Elasticsearch宕机状况呈现。
在这样的状况下，咱们急须要一种新的数据库来撑持业务。在理解到Clickhouse的个性和综合业务相干状况，咱们最终抉择了Clickhouse。通过比照各种表引擎后，抉择了ReplicatedMergeTree引擎，将罕用的查问字段作为主键索引。另外因为业务须要每天还会有大量的在线数据入库，应用Kafka表引擎接管在线实时数据。通过物化视图的形式，将Kafka表数据写入到指标表。Clickhouse既可能撑持离线数据的导入，也反对实时数据写入，并且具备良好的查问性能。
实际总结：
目前线上Clickhouse单表最大记录数为20亿左右，只应用了2台8核16G的机器就实现了TP99 1s内查问响应。目前线上应用的是单分片加数据正本的模式，可能充分利用Clickhouse单机弱小的能力，又能保障线上数据安全。Clickhouse也有一些毛病，比方：数据更新比拟麻烦，大规模集群没有较好的管理工具等问题存在。总的来说，Clickhouse可能以较低的老本实现大量数据查问和剖析需要，并且保持稳定。