本文字数：5249；估计阅读时间：14分钟
作者：Tom Schreiber, Mark Needham, Alexander Gololobov, Andriy Yakovlev and Robert Schulze
TL;DR
在 TPC-H SF100 标准下，单个 59 核 ClickHouse Cloud 节点在实际运行时间方面，与 Snowflake、Databricks、BigQuery 和 Redshift 相比极具竞争力，同时在性价比方面位居榜首。在 SF10 标准下，它运行所有 22 个查询的成本不到一美分。
ClickHouse Cloud 加入 TPC-H 对比测试
我们在 ClickHouse Cloud、Snowflake、Databricks、BigQuery 和 Redshift 上运行了完整的 TPC-H 工作负载。
在 SF100 标准下，这意味着处理 100 GB 数据、8.66 亿行，并执行 22 个包含大量连接的分析查询。
结果显示：ClickHouse Cloud 在实际运行时间方面表现出强劲竞争力，并在性价比方面位居榜首。
在 SF10 标准下，完成整个工作负载仅需 2.9 秒，计算成本为 0.009 美元。
不到一美分。
本文将展示基准测试结果。有关这些结果背后长达两年之久的连接（Join）工程工作，请参阅配套文章。
基准测试设置
所有基准测试脚本、查询和结果文件均已发布在公共 GitHub 仓库中，以便结果能够被复现和审查。
数据集与运行时间测量
主要对比测试采用 TPC-H SF100 标准：对 8.66 亿行数据执行 22 个查询。
在运行时间测量方面，我们区分冷启动运行（Cold Run）和热启动运行（Hot Run）：
冷启动运行（Cold Runs）：我们并未系统地比较冷启动性能。云数据仓库表现出不同的缓存行为，且大多数不允许用户可靠地重置操作系统级别的页面缓存或按需重启计算资源。由于冷启动条件无法标准化，因此冷启动结果既不公平也难以复现。
热启动运行（Hot Runs）：每个查询在禁用结果缓存的情况下运行三次。图表中采用的是最快的热启动运行结果。由于禁用了结果缓存，此基准测试旨在衡量查询执行本身的性能，而非返回之前已缓存的结果。
对比系统
对于ClickHouse Cloud，我们采用了一套固定配置：一个配备 59 核的 AWS 单计算节点。而对于其他系统，我们选择了实用的数据仓库或无服务器（Serverless）容量配置，并将在后续讨论与其最接近的硬件对比。
• Snowflake ：Small、Medium、Large 和 4X-Large Gen2 warehouses
• Databricks (SQL Serverless) ：Small、Medium、Large 和 4X-Large warehouses
• BigQuery ：2,000 slots
• Redshift Serverless ：128 RPUs
成本计算
对于成本计算，我们沿用了此前在关于云数据仓库计费和成本性能的文章中介绍的方法。我们将各个供应商的公开计费模型应用于实测的查询运行时间，并假设所有系统都能实现精确的按秒计算计费。我们还在可比较的美国东部地区采用企业级定价：对于支持的系统，使用 AWSus-east；对于 BigQuery，则使用 GCPus-east。
基于上述配置，我们首先来看原始热运行时间 (raw hot runtime)。
TPC-H SF100：原始热运行时间 (raw hot runtime)
TPC-H SF100 包含100 GB 数据、8.66 亿行，以及22 个连接密集型分析查询。
在下图中，每个条形图汇总了 22 个 TPC-H 查询中各查询三次运行的最快结果。数值越低表示性能越好。
ClickHouse Cloud在 19.8 秒内完成了工作负载。
Snowflake则在 Small warehouse 上耗时 32.7 秒，在 Medium 上耗时 22.9 秒，在 Large 上耗时 15.9 秒，在 4X-Large 上耗时 14.7 秒。
Databricks在其不同规模的 SQL 仓库 (SQL warehouse) 上表现如下：Small 仓库耗时 37.3 秒，Medium 仓库耗时 40.0 秒，Large 仓库耗时 28.9 秒，4X-Large 仓库耗时 26.4 秒。
BigQuery在使用 2,000 个 slots 的情况下，耗时 26.2 秒 完成。
Redshift Serverless在使用 128 个 RPU (Redshift Processing Unit) 的情况下，耗时 30.7 秒 完成。
需要注意的是，各系统所使用的计算资源配置并不完全相同。ClickHouse Cloud 使用了一个配备 59 个核心和 236 GiB 内存的 Graviton3 计算节点。
针对 Snowflake 和 Databricks，我们测试了多种 SQL 仓库 (SQL warehouse) 规模，旨在展示运行时长随计算资源扩展的变化情况。与 ClickHouse Cloud 的 59 核节点最接近的硬件参考配置是 Snowflake Large Gen2（据了解采用 64 个 AWS Graviton3 核心和 128 GB 内存），以及 Databricks Large（根据文档中记载的经典计算平面 (compute-plane) 规格，对应 64 个 Intel Xeon E5-2686 v4 核心和 488 GiB 内存）。尽管我们在本次基准测试中使用了 Databricks SQL Serverless，但其公布的 SQL 仓库规格仍提供了一个有价值的参考依据。
此外，还需注意，采用无服务器容量模型 (serverless capacity model) 的系统能够自动将查询工作分散到大规模的预配置计算池中：在此次基准测试中，BigQuery 使用了高达 2,000 个 slots，而 Redshift Serverless 则使用了 128 个 RPU。
凭借单个 59 核计算节点，ClickHouse Cloud 在 TPC-H SF100 的裸机运行时间方面表现出强大的竞争力，足以与主流云数据仓库抗衡，这其中包括配置相近的 64 核 Snowflake 和 Databricks 数据仓库，以及那些能在远超 59 核的大型预置计算池中自动扩展的无服务器引擎。
运行时间仅是考量之一
如上所述，直接比较各系统在运行 TPC-H SF100 工作负载时所使用的计算资源量是困难的。
但我们可以直接比较运行此工作负载的成本。
下面的图表沿用了相同的运行时间条形图，并叠加了各厂商基于其公开计费模型所计算的实际运行计算成本。
ClickHouse Cloud以 19.8 秒完成工作负载，计算成本为 $0.063。
SnowflakeLarge 用时更短，为 15.9 秒，但成本高达 $0.143。Snowflake 4X-Large 再次提速，用时 14.7 秒，但成本则飙升至 $2.121。Databricks的成本范围则在 $0.087 至 $2.714 之间。BigQuery用时 26.2 秒，成本为 $0.163，而Redshift Serverless则用时 30.7 秒，成本为 $0.436。
下一节将运行时间与成本整合，生成单一的成本-性能得分。
TPC-H SF100：成本-性能排名
前面的图表并列展示了运行时间和成本。现在，我们将这两项指标整合为一个简单的成本-性能得分：
成本-性能得分 = 计算成本 × 运行时间
得分越低越好。
这有助于我们解答真正的云基准测试问题：
谁能以每美元成本提供最佳的 Join (连接) 性能？
运行速度快的系统得分更高，成本低的系统得分更高。运行缓慢或价格昂贵的系统会迅速落后。如果一个系统既慢又贵，那么这两种负面影响还会叠加。
ClickHouse Cloud荣登榜首。
紧随其后的是SnowflakeLarge 和 Snowflake Medium 配置，两者的表现均比 ClickHouse Cloud 差约 2 倍。DatabricksSmall 以及拥有 2,000 个槽位 (slots) 的BigQuery则差 3 倍。DatabricksLarge 和 Medium 分别以 5 倍和 6 倍的差距位列其后。
在排名靠后的配置中，Redshift Serverless的表现差 11 倍，Snowflake 4X-Large 差 25 倍，Databricks 4X-Large 差 57 倍，而 BigQuery 按需 (On-demand) 更是差了 67 倍。
ClickHouse Cloud 在 TPC-H SF100 基准测试中实现了最佳的成本-性能：综合得分最低，最接近的测试配置也比其表现差约 2 倍。
TPC-H SF100：按查询运行时间细分
为了全面起见，这里列出了按查询的运行时间细分。每个条形图展示了 22 个 TPC-H 查询中，每个查询三次运行中的最快结果。
聚合结果并非由某个单一异常值 (outlier) 导致。ClickHouse Cloud 在整个查询集上都表现出持续的竞争力。
规模缩减：TPC-H 运行成本低于一美分
SF100 是本文的主要基准测试。但将规模缩减至 SF10，却带来了点睛之笔。
在 SF10 场景下，该工作负载包含8600 万行 (86M rows)数据，涉及与 SF100 相同的22 个 Join (连接) 密集型 TPC-H 查询。
在相同的 ClickHouse Cloud 配置下，使用一个 59 核的计算节点 (compute node)，整个“热”工作负载 (hot workload) 在 2.9 秒 内完成运行，计算成本仅为 0.009 美元。
下图将运行时间与成本结合，形成一个单一的性价比得分，旨在回答“谁能以每美元实现最佳连接（join）性能？”的问题。
在此规模下，ClickHouse Cloud在这两个维度上均表现出色：它是测试中最快的配置，同时运行成本也最低。Snowflake在性价比方面位居次席，但性能表现仍旧差了 8 倍。BigQuery差了 12 倍，RedshiftServerless差了 27 倍，而更大规模的 Snowflake 和Databricks配置则远远落后。
在 SF10 规模下，ClickHouse Cloud 仅用 2.9 秒就能运行所有 22 个 TPC-H 查询，成本不到一美分，并且以显著优势提供了最佳性价比。
规模扩展：SF1000 及更高
SF100 的测试结果展示了 ClickHouse 的当前实力：凭借单个 59 核计算节点，ClickHouse Cloud 在运行时间和性价比方面均能与主流云数据仓库抗衡，包括那些采用更大规模或更弹性计算配置的系统。
但 SF100 并非故事的终结。
对于更庞大的规模因子，例如TPC-H SF1000 及更高，连接执行需要在多个节点间进行适当的扩展。这正是工程团队接下来的重点工作，他们将在 ClickHouse Cloud 中为大型分布式连接引入多阶段分布式查询执行 (multi-stage distributed query execution)。
这是下一篇章的内容。而当前这些成就，则得益于过去两年在连接（join）工程上的持续投入。
我们如何实现这一飞跃
上述成果是 ClickHouse 团队两年专注于连接（join）工程的结晶。
在这项工作启动一年后，相同的 TPC-H SF100 连接密集型工作负载已经比 22.4 版本快 4.4 倍。又过了一年，如今整体性能提升了 26 倍，仅去年一年，在默认设置下就带来了额外的6 倍性能提升。
这一系列进步源于整个技术栈的优化，具体包括：更快的哈希连接 (hash joins)、更优的查询规划 (planning)、关联子查询 (correlated subquery) 支持、惰性列复制 (lazy column replication)、运行时过滤器 (runtime filters) 以及基于统计信息的连接重排序 (statistics-based join reordering)。
配套文章详细阐述了这些数据背后的工程故事：ClickHouse 如何从“速度快，但不擅长连接操作”转变为默认即具备高性能连接能力的系统。
经过两年专注于连接查询的工程优化，ClickHouse 在 TPC-H SF100 以连接查询为主的工作负载下性能提升了 26 倍，这正是取得这些基准测试结果的关键。
ClickHouse 是面向 AI 时代打造的高性能实时分析数据库，能够以极致性能处理海量数据分析任务。凭借高并发、低延迟和云原生架构，ClickHouse 广泛应用于可观测性、数据仓库、实时分析及 AI 数据基础设施等场景。我们致力于帮助企业在公有云平台上构建安全、弹性且高性价比的实时分析与 AI 数据平台，加速释放数据价值，推动智能化创新与数字化转型。目前，Trip.com、DiDi、Meta、Sony、Netflix、Deutsche Bank、Sierra、Cloudflare 等全球领先企业均在使用 ClickHouse 支撑其关键业务和数据分析平台。
