共计 2549 个字符，预计需要花费 7 分钟才能阅读完成。
前言：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 可能以较低的老本实现大量数据查问和剖析需要，并且保持稳定。
