ClickHouse - 核心原理、特点、以及架构详解

作者：hangge | 2024-11-13 08:39

1，什么是 ClickHouse？

（1）ClickHouse 的全称是 Click Stream + Data WareHouse，可以将其翻译为“点击流数据仓库”。

（2）ClickHouse 是俄罗斯的 Yandex 公司于 2016 年开源的一个列式数据库，专为 OLAP 而设计。这个列式储存数据库的性能大幅超越了很多商业 MPP 数据库软件。

（3）ClickHouse 是一个用于联机分析的列式数据库管理系统，它可以提供海量实时数据的快速写入，以及快速实时查询，目前主要应用于实时数据仓库领域。

2，ClickHouse 的核心特性

真正的列式数据库管理系统：ClickHouse 基于列式存储，可以显著提高查询效率。ClickHouse 不仅是一个数据库，还是一个数据库管理系统。因为它允许在运行时创建表和数据库、加载数据和运行查询，而无须重新配置或重启服务。
数据压缩：ClickHouse 支持按列设置数据压缩格式，进一步提升了查询性能。
数据的磁盘存储：部分列式数据库只能存储在内存中，但是 ClickHouse 是基于传统磁盘存储的，存储成本更低。
多核并行处理，多服务器分布式处理：ClickHouse 会使用服务器上一切可用的资源，从而以最自然的方式并行处理大型查询。
支持 SQL：包括 GROUP BY、ORDER BY、IN、JOIN 及非相关子查询。ClickHouse 支持基于 SQL 的声明式查询语言，它在许多情况下与标准 SQL 是一样的。
向量引擎：为了高效地使用 CPU，数据不仅被按列存储，还被按向量进行处理，这样可以更加高效地使用 CPU。
实时数据更新：ClickHouse 支持在表中定义主键。为了使查询能够快速在主键中进行按范围查找，数据总是以增量的方式有序地存储在 MergeTree 中。因此，数据可以持续不断地高效写入表中，并且在写入的过程中不会存在任何加锁的行为。
支持索引：按照主键对数据进行排序，这样可以帮助 ClickHouse 在几十毫秒内完成对数据按特定值或范围进行查找。
适合在线查询：可以在没有对数据做任何预处理的情况下，以极低的延迟进行查询并将结果返回给用户。
支持近似计算：ClickHouse 提供了多种在允许牺牲数据精度的情况下对查询进行加速的算法。
支持数据复制和数据完整性：ClickHouse 使用了异步的多主复制技术。当数据被写入任何一个可用副本后，系统会在后台将数据分发给其他副本，以保证在不同副本上保持相同的数据。在大多数情况下 ClickHouse 能够在故障后自动恢复，在一些少数的复杂情况下需要手动恢复。
支持角色访问控制：ClickHouse 使用 SQL 查询实现用户账户管理，并允许角色的访问控制，类似于标准 SQL 和流行的关系数据库管理系统。

3，ClickHouse 的缺点

没有完整的事务支持：这一点其实可以理解，毕竟 ClickHouse 是 OLAP 引擎，不是 OLTP 引擎。
不支持高并发：官方建议 QPS 最大为 100，可以通过修改配置文件增加连接数（服务器足够好的情况下）。ClickHouse 快是因为采用了并行处理机制——即使一个查询也会用服务器一半的 CPU 去执行，所以 ClickHouse 不能被应用于高并发使用场景。
不擅长根据主键按行粒度查询：ClickHouse 支持根据主键按行粒度查询，只是不太擅长，性能不高。因为 ClickHouse 是稀疏索引，所以不应该把 ClickHouse 作为 Key-Value 类型的数据库使用。
不擅长按行修改和删除数据。
不支持二级索引：所以 ClickHouse 在海量数据分析场景中，存在多维度查询能力不足的短板。
有限的 SQL 支持：不支持窗口函数和相关子查询，但将来可以支持。
不支持窗口功能，JOIN 操作的实现与众不同。
运维复杂：ClickHouse 集群需要依赖第三方系统来运行副本机制，需要在配置文件中维护所有服务器的信息，在扩缩容时需要创建新表重新导数据。如果数据量增大，数据表数增多，则 Zookeeper 就会出现性能瓶颈，甚至会出现元数据不一致的问题。

4，架构分析

（1）ClickHouse 采用典型的分组式的分布式架构，如下图所示：

（2）说明如下：

ZooKeeper：在 ClickHouse 集群中，节点之间通过 ZooKeeper 服务进行分布式协调。
Shard：集群内可以划分为多个分片（Shard 0、 Shard 1、Shard 2 等），通过 Shard 的线性扩展能力，可以支持海量数据的分布式存储计算。
Node：在每个分片内包含一定数量的节点，同一个分片内的节点互为副本，保障数据的可靠性。ClickHouse 中的副本数量可以按需修改，并且不同分片内的副本数可以不同。

附：对比 Druid、ClickHouse 和 Doris

Druid、ClickHouse 和 Doris 都适合应用于实时 OLAP 数据分析领域，不过它们各有特色，在技术选型时需要结合具体业务需求进行考虑。这 3 个实时 OLAP 引擎的对比如下。

Druid：主要针对时间序列数据提供低延时的数据写入及快速交互式 SQL 查询，适合被应用在海量实时数据的交互式分析场景中。其可以基于时间维度对实时产生的明细数据自动实时聚合，提高查询效率。它有一个比较明显的缺点——对 SQL 支持有限。在 Druid 0.18 版本之前它是不支持 JOIN 操作的，从 0.18 版本开始它有限支持 JOIN 操作，目前主要支持 INNER JOIN、LEFT JOIN 和 CROSS JOIN。
ClickHouse：可以提供海量实时数据的快速写入，以及基于 SQL 的快速实时查询，适合应用在海量实时数据的交互式分析场景中。其支持非标准 SQL，有限支持 JOIN 操作，目前在实时数据仓库领域应用得比较广泛。
Doris：可以通过 SQL 实现实时数据分析，适合应用在海量实时数据的交互式分析场景中。其对 SQL 支持比较好，支持 JOIN 操作。Doris 和 ClickHouse 是比较类似的，但是 Doris 目前的成熟度暂时还不如 ClickHouse。

说明：

查询性能：这 3 个组件的查询性能都比较高。
高并发：Druid 和 Doris 可以支持高并发，ClickHouse 的并发能力有限。
实时数据摄入：因为都属于实时 OLAP 引擎，所以它们都支持实时数据摄入。
实时数据更新：Druid 是不支持实时更新的，只能通过后台批处理任务实现覆盖更新。ClickHouse 支持实时更新，只是功能比较弱。Doris 可以正常支持实时更新。
支持 JOIN 操作：在基于 SQL 实现统计分析时，是否支持 JOIN 操作是一个比较重要的指标。Druid 和 ClickHouse 都支持 JOIN 操作，但是支持度有限。Doris 可以正常支持 JOIN 操作。
SQL 支持程度：Druid 对 SQL 的支持度是有限的，ClickHouse 支持非标准 SQL，Doris 支持标准 SQL（相对较好）。
成熟程度：Druid 和 ClickHouse 的成熟程度比较高，Doris 目前正处于快速发展阶段。
运维复杂度：ClickHouse 运维比较复杂，Druid 运维难度中等，Doris 运维最简单。

大数据