来和我一起挑战吧：ClickHouse vs. Databricks & Snowflake丨第 1 部分-优快云博客

本文字数：4461；估计阅读时间：12 分钟

作者：Al Brown and Tom Schreiber

来和我一起挑战吧：ClickHouse vs. Databricks & Snowflake丨第 1 部分

摘要（TL;DR）

我们选择了一个公开的基准测试，它用来检验在 Databricks 和 Snowflake 上执行大量 join 的 SQL 查询，然后在 ClickHouse Cloud 上跑了同样的查询对比。

在 7.21 亿行到 72 亿行的各个规模下，ClickHouse 都展现出更快、性价比更高的优势。

“ClickHouse 不能做 join”？那我们就来验证一下

先说清楚：这个基准并不是我们自己设计的。

这套以咖啡店为主题的基准测试由其他人提出，旨在比较 Databricks 和 Snowflake 在不同计算规模下执行大量 join 查询时的性能和成本。作者也把完整的数据集和查询脚本都公开了。

出于好奇，我们直接采用相同的基准，把数据加载进 ClickHouse Cloud，使用接近的实例规模，并跑了原始的 17 条查询。大部分查询都包含 join，我们也没有做任何重写（只有查询 6、10、15 做了少量语法调整以兼容 ClickHouse SQL 方言）。

查询本身没有做任何调优，ClickHouse 侧也没有任何表结构、索引或参数的修改。

下次有人再说“ClickHouse 不能做 join”，就把这篇文章甩给他们看。

过去半年里，我们大幅优化了 ClickHouse 的 join 性能[https://youtu.be/gd3OyQzB_Fc?si=Fso5oedhSHYYW16L&t=137]，这篇文章就是你第一次见证我们取得的进展。（剧透一下：真的很快，也很便宜，而且这还只是开始。）

接下来我们会一步一步介绍如何运行这套基准，你也可以自己动手试试，并且会详细展示三个数据规模（7.21 亿、14 亿、72 亿行）的完整测试结果。

最后总结一句：ClickHouse 能做 join，而且做得很快。

如何复现

你可以在这个 GitHub 仓库[https://github.com/sdairs/coffeeshop-benchmark/tree/main]里找到所有信息，包括 17 条查询、脚本和说明文档。我们还把完整数据集放进一个公开的 S3 bucket[https://github.com/sdairs/coffeeshop-benchmark/tree/main?tab=readme-ov-file#get-the-data]，所以你可以直接跳过生成数据这一步，马上开始测试。

整个流程都是自动化的：启动 ClickHouse Cloud 服务，通过环境变量设置凭据，然后使用你的集群规格和每计算单元价格执行一个命令即可。

点一下，喝口咖啡，结果就出炉了。

我们每条查询会跑 5 次，并选取最快的一次来反映缓存命中状态下的性能。你可以查看完整结果[https://github.com/sdairs/coffeeshop-benchmark/tree/main/clickhouse-cloud/results]。

一个数据集，多种运行方式：我们的规模化基准方法

为了加快基准测试的效率，我们使用了 ClickHouse Cloud 中的 Warehouses 功能[https://clickhouse.com/blog/introducing-warehouses-compute-compute-separation-in-clickhouse-cloud]，它可以在同一个共享数据集上同时启动多个计算节点服务。

我们只需要一次性导入数据，然后在不同配置下启动多个服务，通过调整节点数、CPU 核心数以及内存，来测试不同的硬件组合和成本结构。

由于同一个 Warehouse 中的所有服务共享相同数据，我们就能在所有配置上同时跑完基准，而无需反复加载数据。

这也让我们得以测试 ClickHouse Cloud 的 Parallel Replicas 功能[https://clickhouse.com/docs/deployment-guides/parallel-replicas]，通过多个计算节点并行执行一条查询，获得更快的响应。

基准结构

这套基准最早在 LinkedIn 上分成两部分发布（第 1 部分[https://www.linkedin.cn/incareer/pulse/databricks-vs-snowflake-sql-performance-test-day-1-721m-bogran-lsboe/]和第 2 部分[https://www.linkedin.cn/incareer/pulse/databricks-vs-snowflake-gen-1-2-sql-performance-test-day-bogran-ddmhe/]），使用模拟的全国咖啡连锁订单数据。主要针对事实表的三个数据规模进行测试：

Scale factor	Total rows in fact table (Sales)
5亿行	7.21 亿行
10亿行	14亿行
50亿行	72亿行

三个规模使用相同的三张表结构：

Sales：订单事实表
Products：产品维度表
Locations：门店/位置维度表

这份基准总共包含 17 条 SQL 查询[https://github.com/JosueBogran/coffeeshopdatageneratorv2/blob/2a99993b6bca94c0bc04fae7c695e86cd152add1/Performance%20Test%20Queries.sql]，其中大多数涉及事实表与一个或两个维度表的 join，所有查询按顺序依次执行。

原始基准的第 1 部分覆盖了较小的 7.21 亿行数据量，第 2 部分则增加了 14 亿和 72 亿行的数据结果。

本篇文章保持原帖的整体结构和风格：相同的查询、相同的图表样式、相同的顺序，只是全部在 ClickHouse Cloud 上重新执行了一遍。针对每个数据规模，我们会报告：

总成本（美元）
总运行时长（秒）
单条查询平均成本（不含 Q10 和 Q16）
单条查询平均耗时（不含 Q10 和 Q16）
单条查询成本（仅 Q10 和 Q16）
单条查询耗时（仅 Q10 和 Q16）

由于查询 10 和查询 16 的耗时远高于其他查询，如果放在同一张图里会压缩其他结果的可读性，因此原始帖子将它们单独列出。

此外，原始基准中还提供了“Clustered”和“Non-clustered”两种版本（其中“Clustered”是指按物理排序并共置数据，以优化大表的查询效率）。为了保证一致性，我们这里仅报告 Clustered 版本的结果。

测试方法与环境

在原始基准测试中，所有结果都属于多次预热后的运行。我们也对每条查询执行 5 次，并报告其中最快的一次，以公平地反映缓存命中后的性能表现。

本文展示的所有结果均基于 ClickHouse Cloud 的 Scale 层，服务部署在 AWS 的 us-east-2 区域。完整测试中还包含 Enterprise 层的成本数据，与 Scale 层相比依然具备明显竞争力。

所有服务均运行 ClickHouse 25.4.1，且默认开启并行副本（Parallel Replicas）。

下面会呈现完整的图表，不再做额外说明，详细背景可参考原始 LinkedIn 帖子，最后我们也会总结出一个清晰的结论。

在下方图表中，ClickHouse Cloud 的测试结果使用这样的标签格式：CH 2n_30c_120g，含义如下：

2n = 计算节点数量
30c = 每节点 CPU 核心数
120g = 每节点内存（GB）

所有服务配置均为每节点 30 核心、120 GB 内存，测试 4 种节点规模：2、4、8 和 16 个节点。

Databricks（例如 DBX_S）和 Snowflake（例如 SF_S_Gen2）的标签含义保持不变，详细解释可见原帖。

结果：500m 规模（7.21 亿行）

该规模以 5 亿条订单为原始数据生成 7.21 亿行记录。

总成本

每根柱状图括号中同时展示 17 条查询的总运行时

总运行时间

每根柱状图括号中同时展示 17 条查询的总成本

单条查询平均成本（不含 Q10 和 Q16）

单条查询平均耗时（不含 Q10 和 Q16）

Q10 和 Q16 查询的平均成本

Q10 和 Q16 查询的平均耗时

结果：1b 规模（14 亿行）

该规模以 10 亿条订单为原始数据生成 14 亿行记录。

总成本

每根柱状图括号中同时展示 17 条查询的总运行时

总运行时间

每根柱状图括号中同时展示 17 条查询的总成本

单条查询平均成本（不含 Q10 和 Q16）

单条查询平均耗时（不含 Q10 和 Q16）

Q10 和 Q16 查询的平均成本

Q10 和 Q16 查询的平均耗时

结果：5b 规模（72 亿行）

该规模以 50 亿条订单为原始数据生成 72 亿行记录。

总成本

每根柱状图括号中同时展示 17 条查询的总运行时

总运行时间

每根柱状图括号中同时展示 17 条查询的总成本

单条查询平均成本（不含 Q10 和 Q16）

单条查询平均耗时（不含 Q10 和 Q16）

Q10 和 Q16 查询的平均成本

Q10 和 Q16 查询的平均耗时

总结与展望

ClickHouse 在 join 场景下的表现非常优秀，跨越所有数据规模都表现出惊人的速度。

本次基准测试包含的 17 条查询，聚焦于贴近真实业务的 join 场景：涉及 2–3 张表，没有做任何调优或重写。我们就是想看看 ClickHouse 在原始状态下的实际水平。

在 500m 规模下，大多数查询都能在 1 秒内跑完，ClickHouse 始终比其他方案快 3～5 倍，并且更省钱。
在 1b 规模下，ClickHouse 仅用半秒就完成对 17 亿行数据的 join、聚合和排序，而其他系统需要 5 到 13 秒，且依旧更贵。
在 5b 规模下，即使最重型的查询也能在几秒钟内完成，而不是几分钟，ClickHouse 依然是又快又省的最佳选择。

我们并没有做任何特别的操作，没有改配置，也没有专门的小技巧，只是干干净净地跑了一遍原始基准。

在接下来的第二部分，我们会演示通过几个我们手里的强力绝招，如何以 ClickHouse 方式把 join 性能真正推到极致。

在过去 6 个月里，我们持续深耕 ClickHouse 的 join 性能，无论是优化查询计划、内存效率，还是执行策略，都做了大幅改进。

而且这远远不够。

接下来，我们要把难度继续拉满：完整的 TPC-H 测试，挑战最多 8 表（8-way）连接。

想看看 ClickHouse 在最严苛 join 场景下的表现吗？敬请期待我们的 TPC-H 测试结果！

征稿启示

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