ClickHouse 推出按需计算：为单个查询扩容

我们为什么要构建它？

在构建 ClickHouse Cloud 时，我们的主要目标之一是让用户能够在经济高效、可扩展的存储之上使用 ClickHouse 的强大能力。SharedMergeTree为我们带来了原生的计算与存储分离，使服务能够独立扩展它们。

随后我们添加了自动扩缩容，使计算可以随需求增长和缩减。但基于指标的自动扩缩容是被动的：服务需要先观察到需求，然后才能扩展。对于大多数工作负载来说，这正是你想要的。但对于一个你已经知道会需要更多资源的计算密集型查询呢？既然你可以从一开始就申请所需的计算资源，为什么还要等待自动扩缩容呢？

这说起来容易做起来难。额外的计算通常需要先完成配置并上线，查询才能使用它。这让你面临三个不完美的选择：为峰值需求过度配置、等待自动扩缩容，或者让繁重查询与关键工作负载相互竞争。

这就是我们构建 ClickHouse On-Demand Compute 的动机。与其扩展整个服务，不如扩展查询本身。符合条件的查询可以从 ClickHouse 管理的资源池中请求额外的工作节点，从而减少主服务上的资源竞争，而无需永久增加其规模。

这使得 On-Demand Compute 适用于多种工作负载模式：

• 临时查询。在额外的工作节点上运行探索性或一次性查询。
• 工作负载卸载。将选定的读取工作负载转移到额外的工作节点上，减少与关键工作负载的竞争。
• 数据湖工作负载。在额外的工作节点上对受支持的 Apache Iceberg 和 Delta Lake 数据运行符合条件的查询。

它是如何工作的？

使用 On-Demand Compute 就像向查询中添加几个设置一样简单：

1SELECT2    l_returnflag,3    l_linestatus,4sum(l_quantity) AS sum_qty,5avg(l_extendedprice) AS avg_price6FROM lineitem7GROUPBY l_returnflag, l_linestatus8SETTINGS9    make_distributed_plan =1,10    distributed_plan_workers_num =3,11    enable_parallel_replicas =0;

On-Demand Compute 可与以下项配合使用：

• SharedMergeTree
• Iceberg
• Delta

工作节点与租约

当上述查询运行时，On-Demand Compute 会从资源池中请求三个工作节点。每个工作节点至少被租用 60 秒，如果查询运行时间更长，租约会自动续期。

查询完成后，工作节点仍处于租用状态但处于非活动状态。

这就是有趣的地方：如果你在租约仍然有效时发送一个新查询，这些工作节点会被立即复用立即，没有冷启动，也没有发现延迟。当租约到期时，工作节点会被释放并终止。这使得 ClickHouse 更快，因为下一个查询可以立即开始，而无需等待新的工作节点上线。

有一个重要的行为需要牢记：并发查询共享工作节点，而不是各自获得独立的工作节点集合。例如，如果两个并发查询各请求三个工作节点，它们将共享同样的三个工作节点。如果第三个并发查询请求五个工作节点，它将使用那三个工作节点再加上两个额外的工作节点。这意味着资源池会扩展到与最大的工作节点请求相匹配，而不是将每个查询的请求相加。

如果工作节点池资源不足怎么办？

在私有预览期间，当我们微调其自动扩缩容时，你有时可能会请求比资源池所能提供的更多工作节点。如果发生这种情况，你的查询仍将使用当前可用的工作节点运行。例如，如果你请求五个工作节点但只有三个可用，查询将在那三个上运行。

On-Demand Compute 实战

设置

让我们看看如何使用 On-Demand Compute 来支撑你的工作负载。

在此场景中，我们将使用 SharedMergeTree 作为存储，并使用 TPC-H SF10 数据集。

我们将使用两个具有以下配置的集群：

On-Demand Compute 集群：

• 1 个节点
• 静态规模为 32 GB/8 CPU
• 最多可使用 15 个工作节点（32 GB/8 CPU）

自动扩缩容集群：

• 5 个节点
• 最小节点规模为 32 GB/8 CPU
• 最大节点规模为 64 GB/16 CPU

实验相当简单：我们将在每个集群上以不同的并发级别多次运行基准测试。对于 On-Demand Compute 集群，我们将随着查询并发的增加而增加工作节点数量：

这将测试 ClickHouse 使用超出预期计算资源的能力。

结果

CPU 使用率

我们先来看看两个集群的 CPU 使用率。下面的第一张图比较了 On-Demand Compute 与有状态自动扩缩容集群之间的 CPU 使用率。在并发级别为 1 和 3 时，两者使用的 CPU 大致相同。

在第二次迭代接近尾声时，自动扩缩容集群开始扩展。它采用“先建后断”的方式，在移除旧容量之前先将新容量上线。这解释了在使用量稳定在约 80 个 CPU 核心之前出现的急剧上升。

与自动扩缩容集群相比，On-Demand Compute（黄色）表现出不同的行为。出现低谷是因为 ClickHouse 工作节点在其租约期间被分配。当租约在两次运行之间的暂停期间到期时，这些工作节点会被释放，从而在工作负载空闲时降低 CPU 使用率。这意味着你可以在查询需要时按需使用计算资源，而不是在突发之间保持额外容量运行。

自动扩缩容也需要时间。基准测试结束数小时后，自动扩缩容器仍在建议 80 个 CPU 核心，尽管突发已经结束。集群扩展得很快，但会将额外容量保留更长时间。

查询性能

第二张图比较了基准测试性能。对于这个特定的工作负载，On-Demand Compute 更快。

新的分布式查询计划和基于成本的优化器（CBO）在很大程度上解释了这种差异。两者在有状态集群上都尚未启用。它们共同选择了更高效的执行计划，并将工作分配到可用的工作节点上。

随着并发增加，新分布式查询执行框架的性能优势会缩小。在 25 个并发查询、15 个工作节点的情况下，它提供了与有状态集群单节点执行相似的性能，同时使用的计算资源减少了 50%。

同样重要的是要注意，这些结果因基准测试而异。通常，复杂的 JOIN、GROUP BY 和 ORDER BY 查询在新分布式计划下表现更好，但主要执行简单读取和分析的短时运行查询在有状态集群上可能表现更好。

接下来是什么？

这是 On-Demand Compute 的第一个版本。我们知道该功能的第一个迭代范围有限，但我们希望尽快将其交到您手中，以便您可以进行实验、开始基于它构建，并告诉我们我们应该改进或优先处理哪些方面！

立即注册私人预览，我们将在 2026 年 9 月 24 日的网络研讨会后开始推出该功能：注册 此处。如果您想了解有关该功能的更多信息，请查看文档：On-Demand Compute 文档。