Warehouses：解密 ClickHouse Cloud 的计算资源分离-优快云博客

本文链接：https://blog.youkuaiyun.com/ClickHouseDB/article/details/145801744

本文字数：6753；估计阅读时间：17 分钟

作者： Dmitry Pavlov

本文在公众号【ClickHouseInc】首发

在现代云数据库服务中，计算资源分离 (compute-compute separation) 是一种强大的技术，它通过为特定的工作负载、用户或业务功能提供独立的计算资源，优化数据库性能和资源管理。不同于传统的资源共享模式，这种方法可以为不同类型的数据库操作（如读和写）提供专属计算实例，降低操作之间的干扰。对于负载波动较大的环境，这种方式尤其重要，因为它能够确保查询速度和可靠性不受影响。

在本文中，我们将介绍 ClickHouse Cloud 中的计算资源分离技术，解释其重要性，并重点说明它能为用户带来哪些具体优势。

什么是计算资源分离？

计算资源分离指的是数据库系统为不同的用户、工作负载或操作类型分配独立的计算资源，避免它们相互干扰。这样可以确保查询的性能和稳定性不受其他任务影响。虽然配额和限制也可以在一定程度上达到类似效果，但它们的灵活性和保障性远不及计算资源分离。

简而言之，用户可以创建多个独立的计算池，它们可以读取和写入相同的数据，但分别用于不同的任务。

计算资源分离的优势

这种模式在以下场景中尤为实用：

1. 读写分离

在某些场景下，写入操作对执行时间非常敏感，因此数据库中的其他查询不应影响 INSERT 和 UPDATE 的执行。如果用户直接提交查询，或者使用 BI 工具执行临时查询 (ad-hoc queries)，可能会导致资源消耗过大，影响整体性能。

计算资源分离允许我们为 INSERT 操作等关键任务分配专属计算资源，确保其性能不受其他查询影响。在某些情况下，读取操作可能比写入更重要，此时也可以使用相同的方法为其分配独立计算资源。

2. 为不同团队和业务需求提供专属计算资源

大型企业往往有多个团队或部门共享同一个数据库或数据仓库。不同团队可能有不同的查询性能需求，并且更倾向于独享计算资源，以保证查询性能的一致性。

此外，许多团队希望能够独立管理数据库成本，以便进行责任划分和预算控制。

在这种情况下，计算资源分离带来了多重优势：

隔离不同团队的查询任务，避免相互影响。
灵活调整计算资源，每个团队可以根据需求选择合适的计算规模和成本。
独立计费，使查询成本一目了然，尤其适用于启用了空闲计算管理的场景。

3. 为不同工作负载提供灵活的高可用性级别

不同的工作负载对高可用性的需求各不相同。有些任务至关重要，而另一些则可以接受较低的可用性，以减少成本。例如：

终端用户产品的图表和可视化需要最高级别的可用性，因此应部署在三个可用区 (Availability Zones) 中。这类查询通常较为简单，对 CPU 和内存的需求较低。
ETL/ELT 查询既重要又计算密集，但失败后可以自动重试。因此，仅在两个可用区部署两个节点即可满足需求。
大规模临时查询 (ad-hoc queries)需要大量内存，并且通常由分析师手动执行。由于分析师通常只在每周 5 天、每天 8 小时的工作时间内使用这些查询，因此在非工作时间可以释放计算资源。此外，如果某个节点短暂故障，他们也能接受偶尔的查询失败。在这种情况下，仅在一个可用区部署单节点即可满足需求。

借助计算资源分离 (compute-compute separation)，每个工作负载都能获得专属计算资源，并满足其特定的高可用性需求。此外，这种架构还能实现不同团队之间的成本分摊，确保数据库资源的合理分配。

Warehouses 简介

在 ClickHouse Cloud 中，每个数据库实例由以下组件构成：

一组 ClickHouse 计算节点（或副本） - 具体数量取决于高可用性配置，一个实例可能包含一个或多个节点。
数据库访问端点 - 用户可以通过 ClickHouse Cloud 控制台创建一个或多个端点，并使用相应的 URL 进行连接，例如：https://dv2fzne24g.us-east-1.aws.clickhouse.cloud:8443。
对象存储文件夹 - 用于存储数据库中的所有数据及部分元数据。
Keeper 实例 - 负责分布式协调，通常由三个节点组成：

我们现在引入 Warehouse 概念。Warehouse 是一组共享数据（包括表、视图、函数等）的计算服务。每个 Warehouse 包含一个主服务（最先创建的服务）以及一个或多个次要服务。例如，以下是一个包含两个计算服务的 Warehouse 结构示意图：

每个 Warehouse 内的服务都具有独立配置：

端点 (Endpoint) - 允许用户为不同的工作负载、BI 工具和 ETL/ELT 系统分配特定的计算节点，以优化资源使用。
计算节点 (Compute nodes) - 确保各个工作负载互不干扰，使其运行更加稳定。这也意味着你可以独立调整每个服务的计算资源，例如：
- 配置不同的计算节点数量。
- 选择合适的节点规格（以 GiB 计算的 RAM），更大的实例还提供更多的 vCPU 资源。
- 启用空闲模式 (idling)，在资源未使用时自动释放计算实例。
- 企业版 (Enterprise tier) 客户还可以灵活调整 CPU/RAM 配比！例如，一些工作负载主要依赖 CPU 进行数据压缩/解压缩，而另一些则需要更大的内存来执行复杂查询。借助计算资源隔离，这些不同的工作负载可以被独立处理，提高整体性能。
网络访问权限 (Network access settings) - 允许用户限制特定应用程序或用户对某些服务的访问权限，确保数据安全性。

Warehouse 内的所有服务共享以下资源：

数据 (Data) - 所有服务访问相同的数据。因此，在不同的服务上执行 SELECT 查询时，返回的结果是一致的。
Keeper 实例 (Keeper instances) - 由于 Keeper 负责管理数据的协调和复制，所有使用相同数据的服务共享一个 Keeper 集群，以确保数据一致性。
备份 (Backups) - 为避免重复备份相同的数据，我们仅对 **主服务**（Warehouse 中最早创建的服务）执行数据备份。
目前，Warehouse 内的所有服务必须满足以下一致性要求：
- 云服务提供商（AWS、GCP 或 Azure）
- 所在区域 (Region)
- ClickHouse 数据库版本

当某个 Warehouse 包含两个或更多服务时，UI 会自动将这些服务归为一组进行展示。例如，以下是两个 Warehouse 及其服务列表

DWH_pre_prod 共有 4 个服务
DWH_for_tests_us_east_1 仅包含 1 个服务：

内部架构

为了实现计算与计算的分离 (compute-compute separation)，我们主要解决了两个核心问题：

1. 如何在不同计算组之间同步数据。

2. 如何确保查询工作负载严格遵循服务边界，避免使用同一 Warehouse 内其他服务的计算资源。

在 ClickHouse Cloud 中，我们通过两个关键的架构设计实现了高效的数据同步：

1. 存储与计算分离

我们采用存储与计算分离 (separation of storage and compute) 架构，使所有计算服务共享云存储（如 S3）中的同一数据。这种方式确保了不同服务间的数据同步快速、高效。此外，在表结构和元数据同步方面，我们使用 SharedMergeTree 表引擎，在共享 Keeper 集群中实现轻量级的元数据同步。

2. 副本组 (Replica Groups)

在复制数据库 (Replicated database) 体系下，我们引入副本组 (replica-group) 概念，以确保：在分布式查询或并行副本运行时，负载仅限于当前副本组内部，而不会影响其他服务。资源分配严格限定在特定服务范围内，防止不同服务之间出现计算资源争用问题，从而提升隔离性和整体效率。

在上述技术架构的基础上，我们进一步优化了计算分离机制，包括：

独立监控 Warehouse 内的各个服务，支持独立的空闲模式 (idling) 和自动扩展 (auto scaling)，提升资源利用率。
对 Warehouse 内的服务强制执行网络和存储隔离，确保不同服务的计算资源和数据访问权限严格受控，提高安全性。
在 Warehouse 内的所有服务之间强制执行数据库同步，保证数据一致性，避免数据版本差异导致的查询问题。
在只读服务中禁用数据合并 (merge) 和插入 (insert) 操作，防止后台任务（如数据变更操作）影响查询性能。（详见“后台操作”部分）

借助这些优化，我们能够更高效地实现计算与计算的分离，为 ClickHouse Cloud 用户提供更稳定、可控的计算资源管理能力。

数据库凭据

在同一个 Warehouse 内，所有服务共享相同的表，因此它们也共享访问权限 (grants) 以及用户和角色。这意味着，在 Service 1 中创建的用户，也可以访问 Service 2，并拥有相同的权限（例如表、视图等的访问权限），反之亦然。

尽管每个服务都有不同的连接端点 (endpoint)，但所有服务的用户凭据（用户名和密码）是相同的。因此，在单个 Warehouse 内，所有服务共用一套用户体系。

网络访问控制

在某些情况下，可能需要对不同服务的访问权限进行限制，防止某些应用程序或临时用户访问特定服务。

你可以通过网络访问控制来实现这一点，其配置方式与 ClickHouse Cloud 现有的服务访问管理机制类似。要应用这些限制，可以在 ClickHouse Cloud 控制台的服务(Service) 选项卡下，进入设置 (Settings) 进行调整。

你可以为每个服务单独配置 IP 访问规则，从而精准控制哪些应用程序和用户可以访问特定的服务。

只读 vs 读写

在某些场景下，你可能希望限制某些服务的写入权限，仅允许一部分服务进行写入操作。 ClickHouse Cloud 允许你创建只读 (read-only) 服务，从而防止写入操作影响关键查询的性能。

在一个 Warehouse 内，默认规则如下：第一个创建的服务必须为读写 (read-write, RW) 服务。后续创建的服务可以设置为只读 (read-only)，这样它们就不会影响数据库的写入性能。

后台操作

ClickHouse 在后台执行多个资源密集型任务，例如：在数据插入后，数据库会执行数据分片合并 (merging parts)，优化查询性能。这些合并操作在后台进行，可能会消耗大量 CPU 和内存。

为了确保计算-计算完全隔离，只有可读写 (RW) 服务才能执行后台操作。这样，当你专门为关键查询任务配置了一个只读服务时，可以确保它的查询性能不会受到后台任务的影响。

然而，如果一个 Warehouse 内有多个可读写服务，那么：任何 RW 服务都可能执行 INSERT 触发的后台合并操作。合并操作并不直接绑定到触发它的查询，这意味着，在极少数情况下，高负载的写入操作仍可能影响不同 RW 服务的性能。

为了优化这一机制，我们计划在未来引入后台任务分配控制，允许用户指定哪些 RW 服务可以执行后台操作。根据触发查询的来源，将后台合并任务分配到特定的 RW 服务，从而减少不同写入任务之间的相互影响。

计算仓库的限制

尽管计算仓库为 ClickHouse Cloud 提供了很大的灵活性，但当前实现仍然存在一些限制，我们计划在未来版本中优化：

主服务必须保持在线 - 计算仓库中的第一个服务必须始终处于活动状态，不能被停止或置为空闲。如果至少存在一个辅助服务，则无法停止或使主服务进入空闲状态。只有当所有辅助服务被移除后，主服务才能再次停止或进入空闲模式。
读写服务间的后台合并影响 - 如前所述，所有读写服务都会执行后台合并操作。因此，可能会出现 INSERT 查询在 Service 1 执行，但数据合并操作却由 Service 2 处理的情况。换句话说，一个读写服务的工作负载可能会影响另一个读写服务的性能。需要注意的是，只读服务不会执行后台合并，因此不会因该操作消耗资源。建议使用单个读写服务来处理数据写入和转换，并使用只读服务处理查询等其他需求。
后台合并可能阻止服务进入空闲状态 - 在启用空闲模式的情况下，一个读写服务的 INSERT 操作可能会阻止另一个读写服务进入空闲状态。这是因为第二个服务可能会执行第一个服务的后台合并任务，从而无法立即进入休眠。只有当后台合并操作完成后，该服务才会进入空闲模式。相比之下，只读服务不会受到影响，并且可以立即进入空闲状态。
数据库管理查询可能受阻 - CREATE / RENAME / DROP DATABASE 查询可能会因为某些服务处于空闲或停止状态而被阻塞，导致这些查询无法执行。要绕过此问题，可以在会话或查询级别使用 distributed_ddl_task_timeout=0 运行数据库管理查询。例如：

create database db_test_ddl_single_query_setting
settings distributed_ddl_task_timeout=0

客户反馈

在正式发布 Warehouse 之前，我们针对部分客户开展了私有预览计划，让他们在真实的生产环境中进行测试。以下是用户的部分反馈：

"我们设置了一个较小的专用主集群，仅用于写入，并与主要的读集群隔离。同时，我们还有一个按需使用的集群，在空闲时会自动休眠。这种设计非常棒，用户可以在其中运行任何低效查询，而不会影响生产环境。"

—— Beehiiv.com

"目前使用体验非常棒！本周主服务负载较高，我们成功将流量引导至次级服务，以确保面向客户的查询速度不受影响。"

—— CommonRoom.io

"只是想说声谢谢！我们现在在生产环境中运行 compute-compute 分离，同时启用了 query_cache、allow_experimental_analyzer 和 allow_experimental_parallel_reading_from_replicas。这个新架构让我们进入了一个梦幻般的世界。"

—— Vantage.sh

"计算-计算分离带来了极大的满足感。从实验结果来看，我们的常规计算任务现在只需 30 秒，相比于在 BigQuery 上需要 30 分钟，这是因为我们现在能够完全分离不同的工作负载。"

—— ABTasty.com

"以前需要 8 小时才能完成的任务，现在只需要 30 分钟或更短时间。对其他服务几乎没有任何影响，绝对是一个 A+ 级别的特性！"

—— Cypress.io

立即体验

本文介绍了 compute-compute 分离如何帮助 ClickHouse Cloud 客户实现更好的租户隔离，并优化整体资源利用率和成本。

征稿启示

面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com