Warehouses：解密 ClickHouse Cloud 的计算资源分离

本文字数：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 提供了很大的灵活性，但当前实现仍然存在一些限制，我们计划在未来版本中优化：

1. 主服务必须保持在线 -  计算仓库中的第一个服务必须始终处于活动状态，不能被停止或置为空闲。如果至少存在一个辅助服务，则无法停止或使主服务进入空闲状态。只有当所有辅助服务被移除后，主服务才能再次停止或进入空闲模式。

2. 读写服务间的后台合并影响 - 如前所述，所有读写服务都会执行后台合并操作。因此，可能会出现 INSERT 查询在 Service 1 执行，但数据合并操作却由 Service 2 处理的情况。换句话说，一个读写服务的工作负载可能会影响另一个读写服务的性能。需要注意的是，只读服务不会执行后台合并，因此不会因该操作消耗资源。建议使用单个读写服务来处理数据写入和转换，并使用只读服务处理查询等其他需求。

3. 后台合并可能阻止服务进入空闲状态 - 在启用空闲模式的情况下，一个读写服务的 INSERT 操作可能会阻止另一个读写服务进入空闲状态。这是因为第二个服务可能会执行第一个服务的后台合并任务，从而无法立即进入休眠。只有当后台合并操作完成后，该服务才会进入空闲模式。相比之下，只读服务不会受到影响，并且可以立即进入空闲状态。

4. 数据库管理查询可能受阻 -  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