邀测进行中｜阿里云ClickHouse企业版技术原理大揭秘

ClickHouse介绍

ClickHouse是一个全球流行的开源高性能、可扩展列式数据库技术，核心应用于在线分析处理（OLAP）业务，在DB-Engine全球数据库流行度排榜排名前列，逐年关注度增长迅猛。ClickHouse分析性能优异，在典型分析场景下，支持数十亿级数据行规模，90%查询在1秒内完成。这使得ClickHouse成为企业处理大规模数据，构建实时数仓的理想选择。微软、ebay、Uber等国内外大厂都在使用ClickHouse构建数据分析平台。

ClickHouse企业版介绍

阿里云在2020年发布了基于开源社区版本的云数据库ClickHouse社区兼容版，是全球领先的大规模提供全托管ClickHouse服务的云厂商，成熟稳定服务了包含互联网、游戏、电商、金融保险、汽车制造、媒体广告在内的数千家客户。2021年9月20日， ClickHouse项目创始人 Alexey 在 GitHub 宣布他们正式从 Yandex 独立，并成立一个公司：ClickHouse, Inc。2023年阿里云与ClickHouse, Inc达成独家的商业合作，联合研发阿里云数据库ClickHouse企业版（以下简称ClickHouse企业版），并于2023年8月末开启邀测。

今年3月，阿里云与ClickHouse正式签订战略合作协议

ClickHouse企业版对比社区版是里程碑的升级，从传统存算一体的架构全面升级为云原生架构，支持云原生按需弹性 Serverless能力，解决了长期困扰用户的集群扩展效率和平滑性问题。同时升级支持lightweight update&delete，数据更新实时可见，且执行成本更低，效率更高。本文将详细揭秘ClickHouse企业版的技术实现原理。

ClickHouse企业版云原生架构

ClickHouse企业版采用完全不同与开源社区版本的云原生新架构，针对云环境做了全面适配。新架构基于存储和计算分离的架构基础，采用对象存储数据实现Share Storage共享存储，所有ClickHouse Server节点都可以访问相同的全局物理数据，单个Server节点实际上是单个没有限制分片的Replica节点，节点之间访问同一份数据副本。

‍‍

云数据库ClickHouse企业版产品架构图

ClickHouse企业版引擎升级

MergeTree系列的表引擎是ClickHouse中的主要表引擎。它们负责存储插入的数据，在后台进行数据合并，根据特定的引擎进行数据转换等操作。企业版新推出 SharedMergeTree 引擎加入到MergeTree引擎大家庭，而企业版能够支持云原生架构，也核心依赖SharedMergeTree引擎。SharedMergeTree引擎是商业化引擎，仅在企业版提供，在开源社区版不支持。企业版内核相较于开源社区版的核心能力差异如下所示：

开源ReplicatedMergeTree引擎

大多数MergeTree家族中的表都支持自动的数据复制，并通过ReplicatedMergeTree 表引擎的复制机制实现。在社区版Share-nothing架构的ClickHouse集群中，通过ReplicatedMergeTree进行复制以实现数据高可用，并通过分片实现集群横向扩展。阿里云ClickHouse社区兼容版也正是基于这一内核特性实现的高可用和扩展。而 ClickHouse企业版采用了一种新方法，基于SharedMergeTree构建了云原生数据库服务。

云原生SharedMergeTree引擎

SharedMergeTree表引擎是ClickHouse内核ReplicatedMergeTree表引擎的更高效的替代品，专为云原生数据处理而设计和优化。我们将深入了解这个新表引擎，解释其优势，并通过基准测试展示其效率。同时当前正在引入轻量级更新Lightweight Update，与SharedMergeTree形成协同效应。

通过①垂直升配操作和②垂直缩容操作，我们可以更改节点的规格（CPU和内存）。而通过③水平扩展，我们可以增加计算节点的数量。而无需进行任何物理Resharding或数据的Rebalancing，我们可以自由地添加或删除节点。这种无数据移动和搬迁支持水平集群扩展方法，就需要ClickHouse企业版能够提供支持节点访问相同共享数据的表引擎。

ReplicatedMergeTree表引擎并不适用于ClickHouse企业版的预期架构，因为其复制机制旨在在少量的节点上创建数据的物理副本。而ClickHouse企业版需要一个支持在对象存储之上运行大量计算服务节点的表引擎。

显式的数据复制

首先我们解释一下ReplicatedMergeTree表引擎的复制机制。该引擎使用ClickHouse Keeper（也称为“Keeper”）作为协调系统，通过复制日志方式进行数据复制。Keeper充当复制过程特定元数据和表结构的集中式存储，以及分布式操作的一致性协调系统。Keeper确保为Part顺序地分配连续的块编号，将merge和mutation操作分配给特定的replica。

在这里，我们简要介绍SharedMergeTree如何支持ClickHouse企业版自动进行集群扩展。提醒一下：ClickHouse企业版计算节点是具有访问共享存储的计算单元，其规格和数量可以更改。基于此机制，SharedMergeTree完全将业务数据和元数据的存储与计算节点分离，并使用Keeper的接口去读取、写入和修改共享元数据。每个计算节点都有一个存储元数据的本地缓存，并通过订阅机制自动获取数据更改的通知。下图描述了如何使用SharedMergeTree将新服务器添加到集群中：

3. ③新添加的Server-3几乎可以立即参与数据处理，因为它通过从Keeper中只获取必要的元数据信息，找到有哪些数据以及在共享存储中的什么位置。

③ Server-1还将关于该部分的信息存储在其本地缓存和Keeper中（例如，哪些文件属于该Part，以及与文件对应的块位于共享存储中的位置）。

从集群中移除节点也是一个简单且快速的操作。为了优雅地移除，相关节点只需从 Keeper中注销，以便处理进行中的分布式查询时不会出现缺少服务器的警告。

在本节中，我们将展示SharedMergeTree的无缝写入性能扩展能力。

下图可视化了在具有3个副本节点的集群上进行基准测试，期间活动Parts的数量，成功加载数据所花费的秒数（见Ingest finished标记），以及在将Parts合并到少于3000 和 300 个活动Parts时所花费的秒数：我们可以看到两种表引擎的性能在这里非常相似。

WITH
'default' AS db_name,
'wikistat' AS table_name,
(
SELECT uuid
FROM system.tables
WHERE (database = db_name) AND (name = table_name)
) AS table_id
SELECT
formatReadableQuantity(countIf(event_type = 'NewPart')) AS parts,
formatReadableQuantity(avgIf(rows, event_type = 'NewPart')) AS rows_avg,
formatReadableSize(avgIf(size_in_bytes, event_type = 'NewPart')) AS size_in_bytes_avg,
formatReadableQuantity(sumIf(rows, event_type = 'NewPart')) AS rows_total
FROM clusterAllReplicas(default, system.part_log)
WHERE table_uuid = table_id;
┌─parts──────────┬─rows_avg─────┬─size_in_bytes_avg─┬─rows_total────┐
│ 23.70 thousand │ 1.11 million │ 9.86 MiB │ 26.23 billion │
└────────────────┴──────────────┴───────────────────┴───────────────┘

WITH
'default' AS db_name,
'wikistat' AS table_name,
(
SELECT uuid
FROM system.tables
WHERE (database = db_name) AND (name = table_name)
) AS table_id
SELECT
DENSE_RANK() OVER (ORDER BY hostName() ASC) AS node_id,
formatReadableQuantity(countIf(event_type = 'NewPart')) AS parts,
formatReadableQuantity(sumIf(rows, event_type = 'NewPart')) AS rows_total
FROM clusterAllReplicas(default, system.part_log)
WHERE table_uuid = table_id
GROUP BY hostName()
WITH TOTALS
ORDER BY node_id ASC;
┌─node_id─┬─parts─────────┬─rows_total───┐
│ 1 │ 2.44 thousand │ 2.69 billion │
│ 2 │ 2.49 thousand │ 2.75 billion │
│ 3 │ 2.34 thousand │ 2.59 billion │
│ 4 │ 2.41 thousand │ 2.66 billion │
│ 5 │ 2.30 thousand │ 2.55 billion │
│ 6 │ 2.31 thousand │ 2.55 billion │
│ 7 │ 2.42 thousand │ 2.68 billion │
│ 8 │ 2.28 thousand │ 2.52 billion │
│ 9 │ 2.30 thousand │ 2.54 billion │
│ 10 │ 2.42 thousand │ 2.68 billion │
└─────────┴───────────────┴──────────────┘
Totals:
┌─node_id─┬─parts──────────┬─rows_total────┐
│ 1 │ 23.71 thousand │ 26.23 billion │
└─────────┴────────────────┴───────────────┘

但是SharedMergeTree引擎在数据加载过程中更有效地合并了这些部分：

SharedMergeTree是云原生服务的一个重要基础组成。它使我们能够在以前无法或过于复杂实现的情况下构建新的功能和改进现有功能。许多功能从SharedMergeTree的架构下受益，使ClickHouse企业版性能更强、更易用和高持久性。其中一个特性就是“Lightweight Update” ：一种可以在使用更少资源的情况下立即使 ALTER Update 查询的结果实时可见的优化。