黄石市网站建设_网站建设公司_React_seo优化

本文字数：7483；估计阅读时间：19 分钟

作者：Tom Schreiber & Lionel Palacin

本文在公众号【ClickHouseInc】首发

简要结论

我们对 Snowflake、Databricks、ClickHouse Cloud、BigQuery 和 Redshift 进行了基准测试，覆盖数据规模为 10 亿、100 亿和 1000 亿行，并严格依据各平台的实际计费方式进行成本测算。

在大规模分析型工作负载场景下，ClickHouse Cloud 的性价比远超其他系统，高出至少一个数量级。

如何衡量云数仓的成本与性能

假设你手上有一个数据集和一组分析查询，而你可以选择多个云数据仓库来运行它们。那么问题来了：

哪个平台在分析型查询中能带来最高的每美元性能回报？

查看定价页面并不能直接得出答案。

这是因为各厂商在计量计算资源、定价方式以及“计算能力”的定义上存在显著差异，导致这些价格在表面上根本无法横向比较。

因此，我们设计了统一的测试流程，在以下五大主流云数据仓库中运行同一组来源于真实业务场景的分析型查询：

• Snowflake

• Databricks

• ClickHouse Cloud

• BigQuery

• Redshift

测试分别在三种数据规模下进行：10 亿行、100 亿行和 1000 亿行，以观察随着数据规模增长，系统在性能和成本上的变化趋势。

如果你只想知道结论，这里直接说出关键点：不同系统在成本与性能上的变化并不呈线性关系。

ClickHouse Cloud 在所有测试规模下的性价比表现均远超其他系统，具有数量级上的领先优势。

如果你对具体细节、图表数据和测试方法感兴趣，欢迎继续阅读下文。

测试流程可完全复现：

本文所有测试数据均通过 Bench2Cost 得出，这是我们开源的可复现基准测试框架。Bench2Cost 会将各平台的实际计费模型应用于原始执行时间数据，从而确保对比结果真实、准确且可验证。

本次不聚焦存储成本：

Bench2Cost 同样支持计算存储成本，不过我们在本文中没有重点展示相关数据。主要原因是：各厂商的存储价格结构相对简单，且在分析型查询中，计算资源的成本远高于存储，因此可以忽略不计。

值得一提的存储表现：

尽管我们没有专门展开，但如果你查阅图表所链接的结果 JSON 文件，就会发现 ClickHouse Cloud 在存储体积和存储成本方面也全面领先其他系统，甚至在多个维度上呈现数量级优势。不过这不属于本文的对比范围。

交互式基准测试浏览器

静态图表有助于展示整体趋势，但它们只能呈现数据集的冰山一角。

因此，我们专门构建了一个全新的交互式基准测试浏览器，并直接嵌入到了本篇博客中。

你可以自由选择不同的厂商、服务类型、集群规格和数据规模，自定义查看运行时长、计算成本或成本-性能的排名，还能深入查阅本次评测的完整原始结果。

如果你想了解我们是如何生成这些数据的，所有细节都已在文章结尾的附录中做了详细说明。

接下来，我们将按数据规模逐一解析各系统的表现，首先从 10 亿行开始。

（如附录所述，我们采用标准的 ClickBench 分析型工作负载进行测试，该工作负载包含 43 条查询。）

10 亿行：性能起点

虽然我们将 10 亿行作为评测的起始规模，但对于当前主流的数据平台而言，真正有压力的场景往往出现在 100 亿、1000 亿甚至更大规模的数据集上。

如今的分析型查询系统普遍处理规模庞大的数据。例如，特斯拉曾在压力测试中向 ClickHouse 导入超过一千万亿行数据，而我们的 Python 客户端遥测数据集 ClickPy 也已突破两万亿行。

下方的散点图展示了每个系统在处理 10 亿行 ClickBench 查询任务时的总运行时间（横坐标）和总计算成本（纵坐标）。

（为了提升可读性，我们省略了坐标轴标签，但所有数据点的位置是精确的。如需查看完整坐标轴，可通过上方的交互式浏览器查看。）

（图中涵盖了每个系统的全套测试配置，具体细节请参阅附录。）

在 10 亿行规模下，图表显示出三种典型的系统表现类型，分别分布在三个清晰的象限中。

交叉对比成本效率：统一成本-性能评分

为了更直观地比较不同系统的成本效率，我们将运行时间与计算成本整合为一个统一的“成本-性能得分”（具体定义见文末方法论部分）：

结果一目了然：

• ClickHouse Cloud 在整体成本-性能表现中遥遥领先。它的运行时 × 成本值最低，成为其他系统对比的基准。

• BigQuery（容量模式）位列第二，但在相同数据规模下，其得分大约比 ClickHouse 差两倍。

• 其余大多数配置在运行时与成本叠加后表现迅速滑落：从 ClickHouse 的 3–4 倍差距，到 Snowflake 和 Databricks 大规格实例高达数十倍的落后。

但真正的分水岭出现在数据量扩大之后。

10 亿行在当今数据体量标准下只是个起点。当我们把测试规模提升到 100 亿、甚至 1000 亿行时，系统之间的性能与成本差异迅速放大，许多平台开始远离“高性能、低成本”的理想区间。

100 亿行：性能差距初现

下方的散点图展示了各系统在处理 100 亿行 ClickBench 查询时的总运行时间（横坐标）与计算成本（纵坐标）：

（为提升图表可读性，我们省略了坐标轴的刻度标签，但数据点的位置依旧精准。你可以通过上方交互式测试浏览器查看完整的数值坐标轴。）

（图中涵盖了每款引擎的所有测试规格，详见文末附录。）

当数据扩展至 100 亿行时，首次出现系统间明显的性能分层。运行时间拉长、成本上升，多个系统开始逐步偏离“高效、低价”的核心区域。

而从统一成本-性能评分角度看，这种差异更加直观：

• 在这一规模下，ClickHouse Cloud 依旧稳居榜首，远远领先其他系统。

• 次一级的系统已经被拉开了明显差距，其成本-性能比普遍比 ClickHouse 差 7 至 13 倍不等（如 Snowflake 4X-L 规格、Databricks Large、Databricks 4X-Large 等）。

• BigQuery Enterprise 表现更弱，成本-性能比落后约 14 倍。

• 至于其余配置，则彻底跌入“长尾区”——这些系统的效率比 ClickHouse Cloud 差几十倍乃至上百倍，包括 Redshift Serverless（128 RPU）、Snowflake L、BigQuery On-Demand、Snowflake X-Small 以及 Databricks 2X-Small 等规格。

综上，在 100 亿行这一更贴近真实场景的规模下，各平台的成本效益差距开始显现，而 ClickHouse Cloud 仍以压倒性优势脱颖而出，其性价比远超其他系统，达到数量级上的领先水平。

1000 亿行：真正的压力大关

下方散点图展示了五个系统在处理 1000 亿行 ClickBench 工作负载时的总运行时间（横轴）与总计算成本（纵轴）。

（和前文一样，我们为了保持图表清晰隐藏了刻度标签，但数据点的位置完全准确。完整坐标可在上方的交互式基准浏览器中查看。）

（图中的配置涵盖各系统的所有测试规格；由于坐标轴为对数刻度，横向与纵向差距都比肉眼看到的要大得多，详情可参考附录。）

当数据量提升到 1000 亿行时，各系统之间的差异变得极其明显。只有 ClickHouse Cloud 仍稳稳处在“高性能、低成本”区域。

其他系统则全部被迫挤入“低性能、高成本”区：运行时间从数分钟一路攀升到数小时，计算成本也提高了一个数量级。

（Snowflake 和 Databricks 的最小规格未显示在图表中，因为它们在 1000 亿行测试下需要运行数天，无法纳入同一尺度进行对比。）

成本-性能得分进一步放大了这种差异：

当规模扩展到 1000 亿行后，各系统的成本-性能差距急剧拉开：

• ClickHouse Cloud 继续以显著优势保持第一；

• 紧随其后的 Databricks（4X-Large）已经落后 23 倍；

• Snowflake（4X-L）落后 32 倍；

• BigQuery Enterprise、Redshift Serverless（128 RPU）、Databricks（Large）以及 Snowflake（L）落后数百倍；

• BigQuery On-Demand 更是跌至谷底，落后达 1350 倍。

我们选择在 1000 亿行处结束测试，并不是因为 ClickHouse Cloud 遇到了瓶颈——事实恰恰相反，而是因为如果继续将同样的基准扩展到 1 万亿行及更高规模，对其余系统而言成本将高得难以接受，且运行时间会长达多日。

在 1000 亿行规模下，一些仓库运行一次 ClickBench 的计算费用已经高达 100 至 1700 美元，而较小规格实例甚至需要运行数天。

谁能在每美元上带来最多的分析性能？

我们从这个简单的问题开始，如今可以用数据给出明确答案：

在大规模分析型工作负载下，哪个系统的性价比最高？

随着规模从 10 亿、扩大到 100 亿，再到 1000 亿行，趋势愈发清晰：所有主流云数据仓库都会逐渐滑向“速度慢、成本高”的象限。

只有一个例外。

无论在哪种规模下，包括 1000 亿行这一真正考验系统能力的压力点，ClickHouse Cloud 始终稳居“高性能、低成本”区域，而其他系统要么变慢，要么变贵，或两者兼有。

在大规模分析场景中，ClickHouse Cloud 所提供的价值比任何其他系统都高出一个数量级。

更值得注意的是，Snowflake 和 Databricks 在测试中已经使用了各自提供的最高规格节点，已触及上限。

ClickHouse Cloud 则没有这样的天花板。

我们在 20 个计算节点时停止测试，并不是因为 ClickHouse Cloud 达到了极限，而是因为当时结论已经毫无悬念。

如果你想了解整个基准测试是如何运行的，完整的测试流程与方法论都可以在文末附录中找到。

附录：基准测试方法说明

本节详细介绍了我们如何进行跨五大云数据仓库的基准测试，并统一不同平台间的价格计算方式。

测试方案说明

本次测试基于 ClickBench，选用的是来自真实生产环境的匿名数据集和 43 条典型分析查询（如 clickstream、日志、仪表盘等），而非人工构造的数据。

但需要说明的是，ClickBench 的标准数据集仅为约 1 亿行，远低于当今主流数据平台所处理的规模。如今常见的数据集往往在十亿、万亿甚至千万亿行级别。特斯拉曾在压力测试中向 ClickHouse 导入超千万亿行数据，而我们的 Python 客户端遥测系统 ClickPy，其数据量也已突破两万亿行。

为更全面评估数据扩展对性能与成本的影响，我们将 ClickBench 数据集扩展到 10 亿、100 亿与 1000 亿行，并在每个规模下重复运行完整的 43 条查询。

为了确保测试公平且可复现，我们严格遵循 ClickBench 的标准流程：不进行参数调优、不针对特定系统做任何优化，也不调整计算资源的上下限。这意味着测试结果能够如实反映系统在“开箱即用”情况下的性能，而不会受到人为微调或特定优化技巧的干扰（例如通过物化视图预先聚合数据等）。

针对不同平台之间计费方式不一致的问题，我们使用了 Bench2Cost 框架（见配套文章）。该框架基于每条查询的原始运行时，结合各厂商实际的计费模型，统一计算出每个查询在每个平台上的运行时长、计算费用、存储费用及相关系统元数据，构建出可比性强的数据集。

配置选择原则

尽管交互式基准浏览器支持任意配置对比，为了保证正文清晰简洁，我们统一采用以下对比策略：

• Snowflake 与 Databricks：各自选取三个规格，覆盖最小配置、中档规格以及最大企业级实例，确保囊括其主要使用场景。（关于 Snowflake 的额外细节，如 Gen 2 仓库、QAS 与新版本规格，请参见附注。）

• ClickHouse Cloud：由于其不采用固定的仓库规格划分，因此没有“小 / 中 / 大”之类的标准分级。我们在每种数据规模下，统一使用同一个企业级配置进行测试。

• BigQuery：作为完全无服务器的产品，BigQuery 本身不区分集群规格，但提供两种计费模式。我们在默认配置（2000 slot）下执行一次查询，并分别以 Enterprise（按 slot 使用量计费）与 On-demand（按扫描数据量计费）方式核算价格，因此图表中出现两组 BigQuery 数据。

• Redshift Serverless：Redshift 也不区分仓库规格，仅采用单一默认配置，我们使用其 128 RPU 的标准基线进行测试。

所有平台的价格信息均采自相同的云服务商与区域（AWS us-east），确保对比基础一致；BigQuery 为例外，采用的是 GCP us-east 区域。

在厂商提供多个定价版本（如 Enterprise 与 Basic）时，我们统一使用 Enterprise 版本进行对比，以保证一致性。不过不同定价等级之间的成本-性能趋势整体一致，你可通过交互式浏览器进一步验证其他等级的表现。

通过上述设计，我们确保了不同数据规模（10 亿、100 亿、1000 亿行）下的对比既公平又具备可解释性和一致性。

关于 Snowflake Gen2、QAS、新规格仓库以及 Interactive Warehouses 的补充说明

在本次基准测试中，我们统一采用了 Snowflake 的 Gen 1 仓库作为测试基础，这也是目前多数区域的默认配置。

Gen 2 仓库在相同规格下每小时的 credit 消耗高出约 25–35％，并且不同云平台与区域的支持情况并不一致。为了让不同环境的结果具备可比性，我们选择保持在 Gen 1 上进行测试。

此外，我们没有启用 Snowflake 的 Query Acceleration Service（QAS）。

QAS 会在原有仓库基础上增加无服务器的弹性算力，用于加速高峰期或扫描量较大的查询片段。但由于它会引入额外的计费维度，如果纳入测试会影响基线的清晰度，因此我们在本次比较中不使用 QAS。

Snowflake 近来也推出了大于 4X-Large 的规格，包括 5X-Large 与 6X-Large。虽然这些新规格已在 2024 年扩展至多个云平台，但 4X-Large 仍是最常用的上层容量，因此我们选择它作为最大比较规格。

Snowflake 的 Interactive Warehouses（预览版）主要面向低延迟、高并发场景，按小时计费比标准仓库更低（例如 XS 从 1 credit/hour 降为 0.6），但会对 SELECT 查询设置 5 秒超时，并采用 1 小时的最小计费周期——每次恢复都会产生完整的最低计费。

由于 Snowflake 的性能影响因素很多（Gen 1 与 Gen 2、QAS、5XL/6XL、新交互式仓库等），我们没有将这些变量混入初始基准，让比较保持简洁。后续我们会推出专门针对 Snowflake 的深入评测。

关于热启动与冷启动运行时间

按照 ClickBench 的规范，我们报告的是 hot 运行时间，即三次执行中的最佳结果，并禁用了所有查询缓存。

我们没有包含 cold-start 测试，因为各云厂商的数据缓存机制差异极大，而且大多数平台无法要求重置 OS 缓存或重启计算节点。冷启动条件无法标准化，因此无法保证公平性与可复现性。

关于原生存储格式

本次测试中，每个系统都基于自己的原生存储格式运行：

ClickHouse Cloud 使用 MergeTree，Databricks 使用 Delta Lake，Snowflake 使用其私有微分区格式，而 BigQuery 采用 Capacitor 列式存储。

这样才能确保测量结果反映系统在其最佳设计环境下的真实表现。

部分系统（包括 Snowflake 和 ClickHouse Cloud）也能直接查询 Delta Lake、Apache Iceberg、Apache Hudi 等开放表格式，但本研究只关注原生性能。我们也会在后续推出专门对比开放表格式表现的基准测试。

关于计费粒度

为了让五个系统的比较更加一致，我们做了一项简化假设：

将所有系统都视为以“精确到秒”方式计费。

但实际情况更复杂，例如：

• Snowflake、Databricks 与 ClickHouse Cloud 只有在空闲超时后才停止计费，并且每次运行至少会产生 1 分钟的最低收费；

• BigQuery 与 Redshift Serverless 虽按秒计费，但仍有最小计费周期（如 BigQuery 对 slot 的 1 分钟最小计费、Redshift 对 RPU 的 1 分钟最小计费）。

关于范围与功能差异

本次分析只回答一个核心问题：

在数据规模不断增长的情况下，执行一套分析型工作负载要花多少钱？

因此本文只比较 43 条查询的计算成本，不涉及平台级别的功能（如治理、生态集成、ML 工具、lakehouse 能力、调度&资源管理等）。这些能力会影响厂商的定价策略，但不属于本次研究范围。

如何定义“整体成本-性能排名”

为了比较计费模式完全不同的系统，我们采用了一个简单且与规模无关的统一指标：

成本-性能得分 = 运行时间 × 成本

（越小越好）

这个指标很好地体现了性能排序逻辑：

• 越快的系统得分越好

• 越便宜的系统得分越好

• 一旦系统变慢或变贵，得分就会迅速膨胀

• 成本和时间会相互放大低效

它直接回答了我们最关心的问题：

让这个系统跑完整个工作负载，到底要花多少钱？

我们将所有结果标准化，使最优系统作为基准（1×），其他系统按 N 倍差距展示，这样用户可以直观看到差异。

如何阅读散点图

正文中使用的“总运行时间 vs 总计算成本”散点图有两点需要特别说明：

1. 两个坐标轴都是对数刻度，因为在大规模数据下系统间差异往往达到数量级，用 log–log 图能保持清晰度。

2. 图中的四个象限标签（例如“快速且低成本”等）只是视觉辅助，并不基于任何统计划分。

真正有意思的是：随着数据规模增长，各系统在象限之间的移动路线。

征稿启示

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