企业官网建设流程全解析

做外贸的网站有那些,可以做英语阅读理解的网站,中国制造网官网首页,三水建设网站本文字数#xff1a;15334#xff1b;估计阅读时间#xff1a;39 分钟 作者#xff1a;Tom Schreiber Lionel Palacin 本文在公众号【ClickHouseInc】首发 TL;DR 价格表无法反映真实成本。 计算模型才能说明问题。 本文将解释五大主流云数据仓库如何真正地将你的查询…本文字数15334估计阅读时间39 分钟作者Tom Schreiber Lionel Palacin本文在公众号【ClickHouseInc】首发TL;DR价格表无法反映真实成本。计算模型才能说明问题。本文将解释五大主流云数据仓库如何真正地将你的查询转化为花费让你能够在同一标准下进行对比。如果你负责构建、优化或为分析型工作负载付费这将帮助你洞察计算成本的真实结构。计算计费为何如此令人困惑你手头有一个数据集和一组分析查询而现在市场上的云数据仓库选择比以往更多。但在回答那个显而易见的问题之前哪一家在每一美元上的性能表现最优你需要先弄清一个更基础的问题这些系统到底是如何计算并向你收费的乍看之下这似乎很简单——毕竟每家供应商都有公开的价格表。然而在实际操作中这些价格表几乎无法提供有用信息原因包括每个平台使用不同的方式来衡量计算资源如“credits信用点”、“DBUs”、“compute units计算单元”、“slot-seconds插槽秒”、“RPUs”等等这些单位背后所代表的是完全不同的执行模型随着数据规模的增长各系统的查询运行时间扩展方式也不尽相同同一条查询在不同的查询引擎上可能会消耗截然不同的计算资源因此即使你将所有价格表摆在面前仍无法简单回答“哪家更便宜”除非你真正理解这些计费单位的实际含义。本文就是帮助你迈出理解之路的第一步我们将清晰明了地解析五大主流云数据仓库在资源分配、扩展及计费机制上的差异。阅读完后你将清楚了解在以下平台中CPU 周期是如何变成花费的SnowflakeDatabricksSQL ServerlessClickHouse CloudGoogle BigQueryAmazon Redshift Serverless那存储成本呢本文聚焦于计算成本因为这正是各系统之间差异最显著的部分。相比之下存储成本要简单许多而且往往相较计算开销可以忽略不计因为大多数系统使用价格相近的云对象存储来保存数据。但需要说明的是我们的 Bench2Cost 框架见下一节确实对每个系统的存储成本都进行了全面计算。之所以在本文中不重点展示是因为它们对整体对比结果影响不大。在正式开始之前我们是如何用 Bench2Cost 计算成本的本文是我们基于 ClickBench 构建的更广泛成本对比分析的基础。如果你只是想了解各系统的计算模型和计费机制可以跳过本节以及每个系统末尾的小节“Bench2Cost 是如何计算……成本的”。这些内容主要用于解释我们如何将基准测试结果转换为实际美元成本供配套的成本对比分析使用。为了让基准测试结果在计费模型截然不同的系统间具备可比性我们设计了一个框架为 ClickBench或其他任何基准测试加上实际价格标签这就是 Bench2Cost。本研究中的所有数据都是完全可复现的Bench2Cost 的代码仓库包含了我们所使用的全部脚本、定价模型和生成的数据集。总体而言Bench2Cost 主要完成三项工作接收已有的 ClickBench 原始运行时数据查找目标系统的计算定价模型生成一个增强版 JSON 文件其中记录了每条查询的运行时计算成本另外Bench2Cost 也会计算存储成本。在本文稍后介绍每个系统的部分中我们会在结尾提供一个小节详细说明我们是如何将 Bench2Cost 应用于该系统的例如使用了哪份基准测试文件、匹配了哪些定价数据等。有了这些基础我们就能对 Snowflake、Databricks、ClickHouse Cloud、BigQuery 和 Redshift Serverless 的基准测试成本进行清晰对比。现在基础已打好我们将依次介绍各系统如何分配和计费计算资源。SnowflakeSnowflake 计算计费概要Snowflake 使用固定规格类似 T 恤尺寸的数据仓库每种规格在运行期间按小时消耗固定数量的 credit。以下数值基于标准的第一代 Gen 1 数据仓库价格数据截至 2025 年 11 月计费单位按小时计费单位为 creditSnowflake 的计算计费单位典型数据仓库规格X-Small → 每小时 1 creditSmall → 每小时 2 creditsMedium → 每小时 4 credits每个 credit 的价格部署在 AWS 美国东部标准版$2.00 / credit / hour企业版$3.00 / credit / hour关键业务版$4.00 / credit / hour计算模型预配置数据仓库Provisioned WarehousesSnowflake 是“预配置集群”计算模型的典型代表你选择数据仓库的规格并为其运行时间付费而不是按每条查询单独计费。在底层Snowflake 的数据仓库由固定规模的集群组成运行其自研的查询引擎相关论文The Snowflake Elastic Data Warehousehttps://www.cs.cmu.edu/~15721-f24/papers/Snowflake.pdf。每个数据仓库都有一个类似 T 恤尺码的规格如 XS、S、M 等这个规格决定了系统为你分配多少个计算节点见下图每小时将消耗多少个 credit举例如下XS → 1 个节点 → 每小时消耗 1 creditS → 2 个节点 → 每小时消耗 2 creditsM → 4 个节点 → 每小时消耗 4 credits注Snowflake 并未公开其硬件配置但业内普遍认为每个节点大致等同于 8 个 vCPU、16 GiB 内存和约 200 GB 本地磁盘缓存。关于 Snowflake 的数据仓库代际与交互式仓库的说明本指南中使用的均为第一代标准版 Gen 1 数据仓库这是除非用户另行选择 Gen 2否则的默认选项。第二代 Gen 2 数据仓库基于更新的硬件运行在相同规格下每小时 credit 消耗比 Gen 1 高出约 25–35%。Snowflake 的交互式数据仓库截至 2025 年 11 月仍处于预览阶段针对低延迟、高并发的使用场景进行了优化。它们的每小时费用低于标准仓库例如 XS 规格为每小时 0.6 credit而标准为 1 credit但对 SELECT 查询设置了 5 秒的超时限制并强制执行最低 1 小时的计费周期每次唤醒都会按一小时计费。扩展方式纵向扩展与多集群模式Snowflake 支持两种扩展方式每种方式都会影响你的计算成本纵向扩展手动调整规格你可以手动将数据仓库规格从小升级为大例如 S → M → L。规格越大集群节点越多 → 并行处理能力越强 → 查询速度更快但同时每小时消耗的 credits 也会线性增加。横向扩展多集群自动当系统检测到并发查询数量激增时Snowflake 可以自动增加多个与原始规格相同的额外集群。这些集群不会提升单条查询的速度但会增加整体处理能力防止查询排队等待。系统采用 Standard/Economy 策略决定何时启动或关闭这些额外集群。每个处于运行状态的附加集群都将按与主集群相同的费率计费。查询加速服务QASSnowflake 提供一项企业级可选功能——查询加速服务Query Acceleration ServiceQAShttps://docs.snowflake.com/en/user-guide/query-acceleration-service。启用该服务后系统可自动调用额外的无服务器计算资源用于加速查询中突发或大规模扫描的部分逻辑。需要注意的是这会带来额外的计费项https://docs.snowflake.com/en/user-guide/query-acceleration-service#query-acceleration-service-cost。计算定价官方定价信息更新于 2025 年 11 月 → https://www.snowflake.com/en/pricing-optionsSnowflake 的定价与所选版本Standard、Enterprise、Business Critical及所在云平台和区域有关。例如在 AWS 的美国东部区域Standard 版 → $2.00 / credit / 小时Enterprise 版 → $3.00 / credit / 小时Business Critical 版 → $4.00 / credit / 小时计费粒度按 2025 年 11 月的计费规则详见官方文档 How credits are chargedhttps://docs.snowflake.com/en/user-guide/warehouses-considerations#how-are-credits-charged-for-warehousesSnowflake 采用按秒计费模式但每次启动数据仓库后最少按 1 分钟计费。系统支持自动暂停AUTO-SUSPEND与自动恢复AUTO-RESUME功能数据仓库在空闲时会自动暂停在收到查询请求时自动启动。只要仓库处于运行状态系统就开始计费与实际 CPU 使用率无关。恢复过程通常较快一般只需 1 至 2 秒不过在某些情况下也可能因为仓库规格或资源调度导致延迟。交互式数据仓库虽也按秒计费但强制实行 1 小时的最低计费周期每次唤醒都会触发一个新的计费时段。Bench2Cost 如何计算 Snowflake 成本在 Bench2Cost 中我们基于上述定价结构来估算 Snowflake 的计算成本。需要注意的是Databricks 也采用类似的预配置集群计算模型不过它使用的是 DBUs 而非 credits。定价计算逻辑:为了将 Snowflake 在 ClickBench 中的运行时间换算成美元我们构建了一个名为 “Bench2Cost” 的处理流程。该流程将已有的原始基准测试时间、计算仓库配置以及 Snowflake 的定价信息整合为一个统一的成本数据集。Snowflake 的 ClickBench 测试结果例如 4xl.json记录的是在固定计算仓库规格下测得的运行时间本例中为 4X-Large128 credit/小时的计算仓库。此外我们还将 Snowflake 官方的定价数据包括计算仓库的规格级别、每小时 credit 消耗以及在不同版本和地区中的 credit 单价编码为 standard_warehouse.json 文件。一个名为 enrich.sh 的脚本会将这些输入进行整合处理识别基准测试中使用的计算仓库规格例如 4X-Large将每条查询的运行时间乘以 credit 消耗速率与 credit 单价加入 Snowflake 的存储计费信息输出一个增强后的结果文件4xl_enriched.json包含以下内容每条查询的运行时间每条查询的计算成本每月的总存储成本这份增强后的数据集会在我们后续的综合对比文章中使用用于评估五种系统的基准测试成本。Databricks 采用类似的预配置集群模式不过其计算费用单位不是 credit而是 DBU。DatabricksSQL ServerlessDatabricks 计算计费概要每种 SQL 数据仓库规格都有固定的 DBU 消耗速率按小时计费。价格数据截至 2025 年 11 月计费单位按小时计费单位为 DBUDBU Databricks Unit是 Databricks 的抽象计算计费单位典型数据仓库规格2X-Small → 4 DBUs / 小时Small → 12 DBUs / 小时Medium → 24 DBUs / 小时DBU 单价AWS美国东部Premium$0.70 / DBU / 小时Enterprise$0.70 / DBU / 小时注截至 2025 年 11 月Premium 与 Enterprise 的 DBU 单价完全相同并非笔误。计算模型固定规格的数据仓库与 Snowflake 相似Databricks SQL Serverless 采用预配置集群模式你选择数据仓库规格后系统会启动一个固定规格的集群参考论文Photon: A Fast Query Engine for Lakehouse Systemshttps://people.eecs.berkeley.edu/~matei/papers/2022/sigmod_photon.pdf该集群会保持运行直到被你关闭或在空闲状态下自动停止。每一种规格如 2X-Small、Small、Medium 等都对应一个固定的集群配置包括一个 driver 节点若干个 executor 节点主要成本来源仓库规格决定系统会分配多少个 executor集群每小时消耗多少 DBUs例如2X-Small → 约 1 个 executor → 消耗 4 DBUs / 小时Small → 约 3 个 executor → 消耗 12 DBUs / 小时Medium → 约 6 个 executor → 消耗 24 DBUs / 小时Databricks 屏蔽了节点数量与具体硬件配置因此图示仅用于说明概念并非精确结构。为了简化展示我们未包含 driver 节点。规格越大executor 数量越多并行能力越强查询也会更快。但计费完全按照 DBUs / 小时线性增长与实际 CPU 占用无关。扩展方式纵向扩展与多集群扩展Databricks 提供两种扩展方式且都会直接影响成本纵向扩展手动调整规格你可以选择更大的数据仓库规格例如从 2X-Small 调整到 Small 或 Medium。更高规格意味着更多 executor因此查询更快但每小时的 DBU 消耗也相应提高。横向扩展多集群自动在 UI 中你可以为某一规格设置最小与最大集群数。当系统检测到并发量上升时会自动启动更多与原规格一致的集群以处理积压查询。这些额外集群不会加速单个查询但可以提升整体吞吐量避免排队。每个活动中的集群都会独立计费。例如若有三个 Small 集群同时运行则计费为 3 × 12 DBUs / 小时。计算定价官方价格2025 年 11 月发布 → https://www.databricks.com/product/pricing/databricks-sqlDatabricks 中 DBU 换算为美元的成本取决于以下因素所选版本 / 服务等级Standard、Premium、Enterprise所部署的云平台与区域AWS、Azure、GCP以 AWS 美国东部地区为例的常见定价Premium → 约 $0.70 / DBU / 小时Enterprise → 约 $0.70 / DBU / 小时注截至 2025 年 11 月Premium 与 Enterprise 的 DBU 单价完全一致此为官方定价并非笔误。计费粒度参考计费行为2025 年 11 月 → Databricks 官方文档How does Databricks pricing work?https://www.databricks.com/product/databricks-pricingDatabricks 采用秒级粒度进行 DBU 计费——只要数据仓库处于运行状态便开始计费。SQL 数据仓库支持自动停止功能可在空闲达到设定时长后自动关闭。当新的查询请求到达时系统会自动唤醒auto-start仓库。只要仓库未完全停止系统将持续计费无论查询实际消耗多少 CPU。启动过程通常非常快速一般耗时在 2 到 6 秒之间。Bench2Cost 如何计算 Databricks 成本定价计算方式:为了将 Databricks 的 ClickBench 运行时间换算成美元我们复用了同一套 Bench2Cost 流程。这一次我们将原始基准测试时间与 Databricks 提供的计算仓库规格到 DBU/小时的映射关系以及 DBU 到美元的定价数据结合起来。例如一个 Databricks 的 ClickBench 文件clickbench_4X-Large.json记录了在固定 SQL 计算仓库规格下测得的运行时间此处使用的是 4X-Large 规格的计算仓库528 DBU/小时。另外我们还将 Databricks 官方提供的定价表包括集群规格、每小时 DBU 消耗以及针对不同云服务商、地区和服务等级的 DBU 单价编码为 sql_serverless_compute.json 文件。增强脚本enrich.sh会将上述数据进行整合并执行以下步骤自动识别基准测试所用的计算仓库规格4X-Large将每条查询的运行时间乘以 DBU 消耗速率和 DBU 单价添加 Databricks 的存储费用信息生成一个增强后的结果文件clickbench_4X-Large_enriched.json其中包含每条查询的运行时间每条查询的计算成本总体存储成本这份增强后的数据集将用于我们后续的综合对比文章帮助评估五个系统在基准测试中的真实成本表现。ClickHouse Cloud 同样采用预配置计算资源的模式不过它支持完全灵活的节点规格并采用标准化的计费单位。ClickHouse CloudClickHouse Cloud 计算计费概要集群的服务规格决定了其每小时所消耗的计算单元数量。价格数据截至 2025 年 11 月计费单位每小时按计算单元计费1 个计算单元 8 GiB 内存 2 个 vCPU典型服务规格示例2 节点服务每节点 8 GiB 内存 → 每小时共消耗 2 个计算单元3 节点服务每节点 16 GiB 内存 → 每小时共消耗 6 个计算单元4 节点服务每节点 32 GiB 内存 → 每小时共消耗 16 个计算单元计算单元单价部署于 AWS 美国东部Basic$0.22 / 单元 / 小时Scale$0.30 / 单元 / 小时Enterprise$0.39 / 单元 / 小时计算模型灵活服务 统一计算单元模式ClickHouse Cloud 基于 ClickHouse 引擎构建参考论文ClickHouse - Lightning Fast Analytics for Everyonehttps://www.vldb.org/pvldb/vol17/p3731-schulze.pdf采用预配置计算模式但与传统的固定仓库规格不同其节点大小完全灵活可调。一个服务的配置由两个维度决定计算节点的数量横向扩展你可以根据需求选择任意数量的节点例如 1 个、2 个、3 个甚至几十、上百个节点。节点数量决定了系统同时处理多条查询的能力查询间并发以及单条查询使用的计算资源规模查询内并行。单个节点的配置规格纵向扩展每个节点的内存与 vCPU 组合均可灵活选择从最小的 8 GiB / 2 vCPU到最大的 356 GiB / 89 vCPU支持多种中间配置。为了对所有可能的节点配置统一计费ClickHouse 定义了标准化计算单元1 个计算单元 8 GiB 内存 2 个 vCPU所有节点配置都是该单位的倍数。ClickHouse Cloud 会将每个服务的总计费量计算为总计算单元 节点数 × 每节点所含的计算单元数量只要服务处于运行状态就按上述总计算单元每小时计费。示例2 节点服务每节点 8 GiB 内存 2 vCPU→ 每节点 1 个计算单元共 2 个计算单元 / 小时3 节点服务每节点 16 GiB 内存 4 vCPU→ 每节点 2 个计算单元共 6 个计算单元 / 小时4 节点服务每节点 32 GiB 内存 8 vCPU→ 每节点 4 个计算单元共 16 个计算单元 / 小时与 Snowflake 和 Databricks 的固定“尺码”模型不同ClickHouse Cloud 的节点大小完全可按需配置打破了传统 T 恤尺寸式规格限制。扩展方式自动纵向扩展 手动横向扩展ClickHouse Cloud 支持两种扩展机制两者都会直接影响服务每小时消耗的计算单元数量1. 纵向扩展自动调整节点规格在 ClickHouse Cloud 中系统可根据实际的 CPU 与内存压力在用户设定的最小和最大范围之间自动调整节点规格即 RAM 和 vCPU 配置。这与 Snowflake 和 Databricks 等平台形成对比——后者的纵向扩展只能手动执行用户必须自行选择更大或更小的集群规格。2. 横向扩展手动调整节点数量与 Snowflake 或 Databricks 不同这些平台的集群大小存在上限横向扩展通常只是增加集群数量以提升并发处理能力单条查询仍只能在单个集群中运行。而 ClickHouse Cloud 的横向扩展没有固定限制通过添加更多节点既可以提升系统同时处理多条查询的能力查询间扩展也能显著增强单条查询在多个节点间的分布式执行能力查询内扩展。这意味着ClickHouse Cloud 的横向扩展不仅提升整体吞吐量也有助于加快个别查询的执行速度。目前节点数量的调整需手动完成但自动横向扩展功能正在积极研发中。此外ClickHouse Cloud 还支持 Warehouses即计算资源间的隔离机制。你可以为不同的工作负载分配独立计算资源同时共享相同的数据存储。计算定价官方价格更新于 2025 年 11 月 → https://clickhouse.com/pricing定价依赖于服务等级Basic、Scale、Enterprise及所在云平台和区域。以 AWS 美国东部为例Basic约 $0.22 / 计算单元 / 小时Scale约 $0.30 / 计算单元 / 小时Enterprise约 $0.39 / 计算单元 / 小时计费粒度2025 年 11 月版本 → 参考 ClickHouse Cloud 文档How is compute metered?https://clickhouse.com/docs/cloud/manage/billing/overview#how-is-compute-meteredClickHouse Cloud 按标准化计算单元进行计费粒度为分钟级。服务支持空闲超时设置在设定时间内无活动查询时系统会自动关闭计算资源。当新的查询到来时服务会自动重启并重新开始计费自动唤醒。只要服务处于活动状态即使没有任何查询正在执行仍会持续计费。从空闲状态恢复通常需要 20 至 30 秒。Bench2Cost 如何计算 ClickHouse Cloud 成本成本计算方式和 Snowflake、Databricks 一样ClickHouse Cloud 同样通过 Bench2Cost 流程进行成本计算。对于计算资源部分我们从一个已有的 ClickBench 测试结果文件入手例如 aws.3.64.json记录了在 3 节点、64 GiB 规格服务下的测试结果。与此同时我们将 ClickHouse Cloud 各个服务等级Basic、Scale、Enterprise对应的计算单元每小时价格和每 TB-月的存储费用整理并编码为标准化的定价文件。Bench2Cost 的脚本enrich.sh会执行以下处理步骤读取服务配置例如 3 个节点每个节点 2 个计算单元据此计算出该服务的总计算单元使用率单位每小时将每条查询的运行时间乘以资源消耗速率和该等级下的单价得到每条查询的计算成本基于数据集大小和 TB-月的价格计算出每月的存储费用最终输出一个增强版本的 JSON 文件aws.3.64_enriched.json其中针对每个服务等级包含以下内容每条查询的运行时间每条查询的计算成本每月总存储费用。这份增强后的文件将在我们后续的 配套文章(https://clickhouse.com/blog/cloud-data-warehouses-cost-performance-comparison) 中使用用于将 ClickHouse Cloud 与其他系统在每项基准测试中的成本进行对比分析。相比之下BigQuery 采用了完全不同的模式用户无需指定或配置任何集群规格。BigQueryBigQuery 计算计费概要在 BigQuery 中你可以选择两种模式之一进行计费按查询扫描的数据量按需模式计费或按查询实际占用的计算 slot 时间容量预留模式计费。价格数据截至 2025 年 11 月计费单位按需模式以扫描的数据字节数计费容量模式以 slot 小时计费slot 是 GCP 中的逻辑计算资源单位举例说明查询扫描了 2 TiB 数据 → 按 2 TiB 计费一个项目使用了 500 个 slot 并运行了 1 小时 → 按 500 slot 小时计费单位价格GCP美国东部按需模式$6.25 / TiB 扫描容量模式Standard$0.04 / slot / 小时容量模式Enterprise$0.06 / slot / 小时容量模式Enterprise Plus$0.10 / slot / 小时计算模型基于无服务器共享计算架构的 Slot 模式前文介绍的 Snowflake、Databricks 和 ClickHouse Cloud 都属于“预配置集群”计算模式你需要预留固定规模的计算资源并按运行时间计费。BigQuery 则采用完全不同的架构。它使用的是无服务器共享计算模型。你无需配置任何集群或仓库查询会在 Google 提前部署好的共享计算池中运行。你只需为每条查询实际消耗的资源付费而无需考虑集群规模或在线时长。下面是对 BigQuery 计算模型的简要说明包括其运行方式、扩展逻辑与计费机制。BigQuery 的查询执行基于其自研引擎参考论文Dremel: Interactive Analysis of Web-Scale Datasets运行在一个共享的无服务器计算池中。每条查询的执行过程如下1. 系统为查询分配 slot —— 即逻辑计算单元大致等价于并行执行的线程数。2. 这些 slot 被调度至多个节点中执行节点来自无服务器架构中的共享资源池。slot 的数量由查询计划动态决定在数据扫描和过滤阶段若涉及大量分区或列块可高度并行使用大量 slot聚合阶段因受分组数量和数据分布影响通常使用较少 slot最终合并阶段只需少量 slot 即可完成结果整合。换言之BigQuery 会为每个执行阶段分配最合适的并行资源并在不同阶段之间动态调整 slot 数量。计费按每条查询实际使用的 slot 时间总和计算。示例说明假设有一个总运行时间为 20 秒的查询包含三个串行阶段阶段 1扫描持续时间12 秒使用 1,000 个 slot计费为 12,000 slot 秒阶段 2聚合持续时间6 秒使用 600 个 slot计费为 3,600 slot 秒阶段 3最终合并持续时间2 秒使用 4 个 slot计费为 8 slot 秒总计15,608 slot 秒尽管用户看到的查询只运行了 20 秒实际计费则反映出在不同阶段并行消耗的总计算资源。动态扩展slot 分配自动伸缩BigQuery 会根据每个阶段可利用的并行度自动调整 slot 的数量实现灵活扩展。Slot 使用限制如果你采用“容量预留”模式可为项目购买固定数量的 slotBigQuery 最多只会使用这些 slot需手动扩展才可提高上限。若使用“按需计费”模式系统可为项目提供最多 2,000 个并发 slot用于所有查询共享。计算定价官方定价2025 年 11 月 → https://cloud.google.com/bigquery/pricingslot 模式的价格取决于版本Standard、Enterprise、Enterprise Plus以及承诺方式按需或 1/3 年 CUD 预付承诺Standard$0.04 / slot / 小时Enterprise$0.06 / slot / 小时Enterprise Plus$0.10 / slot / 小时使用预付承诺后价格可降至约 $0.032–0.09 / slot / 小时视版本和承诺周期而定。BigQuery 还提供另一种也是默认的计费方式按查询扫描数据量计费按需模式。在此模式下你无需关心 slot 数量或使用时长系统仅依据每条查询扫描的数据量计费每个账户每月前 1 TiB 免费超出后按 $6.25 / TiB 收费计费仅依据最终扫描的逻辑字节数经过过滤、聚簇、剪枝等优化后slot 的分配和扩展完全由系统内部处理不影响计费。计费粒度容量模式slot按秒计费单次计费最少 1 分钟。按需模式字节无时间相关计费仅按扫描字节计费首 1 TiB 免费。由于 BigQuery 构建在共享计算池上不存在集群或服务“空闲/挂起”的概念系统无需预热可随时即时执行查询。Bench2Cost 如何计算 BigQuery 成本BigQuery 的成本计算更为复杂因为它支持两种计费模式基于容量的 slot 模式与按需扫描模式且查询引擎同时提供每条查询的 slot 秒数与扫描字节数。为了支持 BigQuery我们对基准测试工具链进行了三个方面的扩展1. 扩展 ClickBench 运行器以采集 BigQuery 的计费指标我们新增了 BigQuery 专用的运行脚本run_bq_bench.sh通过 BigQuery CLI 包裹每条查询的执行过程提取出查询的实际运行时间wall-clock runtime系统计费的 slot 秒数jobQueryStatistics.totalSlotMs查询扫描的数据字节数jobQueryStatistics.totalBytesProcessed这要求我们重新运行整套 ClickBench 测试以确保每条查询都包含完整的计费信息。2. 对接 BigQuery 的双重定价模型我们编写了定价配置文件 serverless.json其中包含基于容量slot的按秒计价模型按版本和地区区分按需扫描模式的定价存储定价包括逻辑存储与物理存储以及活跃层与长期层该结构与其他平台的定价描述保持一致。3. 注入成本信息至基准测试结果一个专用脚本enrich.sh负责将以下输入原始查询结果result.json定价配置serverless.json结合起来计算并输出一个增强版结果文件result_enriched.json其中包含按容量模式计算的成本按需模式下的成本估算的月度存储费用Redshift ServerlessRedshift Serverless 计算定价概要用户可为工作组设置最小和最大 RPUsRedshift Processing Units范围Redshift 会使用机器学习驱动的预测扩展在该范围内自动调整计算资源。定价数据截至 2025 年 11 月计费单位RPU 小时1 RPU 16 GB 内存 2 vCPU使用示例查询使用 4 个 RPU 运行 60 秒 → 计费 240 RPU 秒高峰期扩展至 24 个 RPU → 仅对活跃 RPU 秒计费RPU 单价AWS美国东部$0.36 / RPU / 小时计算模型无服务器 RPU 分配Redshift Serverless 与 BigQuery 类似采用无服务器共享计算架构查询在 AWS 提前部署的计算池中运行。 不同之处在于Redshift 不使用 slot而是通过 RPURedshift Processing Unit来分配计算资源每个 RPU 是固定的 CPU 和内存组合。系统会根据工作负载的实时变化自动调整所需的 RPU 数量。Redshift 的一大亮点在于其预测式扩展能力RAIS借助机器学习模型系统可根据查询结构、数据量、并发度与历史运行记录提前为重型查询预分配所需计算资源从而实现提前扩展。你只需为查询运行时所使用的 RPU 时间付费。示意图展示了 Redshift 如何在你配置的 RPU 范围内进行动态扩展。例如若系统预测一条查询需要 16 个 RPU并运行 60 秒则实际计费为16 × 60 960 RPU 秒扩展机制机器学习驱动的预测分配Redshift Serverless 的扩展是在你设定的范围内自动进行的包含两个关键参数基础容量工作组始终保留的最小 RPU 数量默认 128可设为 4–512部分地区支持上限 1024最大容量系统在负载高峰期可以扩展至的最大 RPU 数量扩展特性如下自动化无需用户手动调整节点或集群预测性使用 ML 模型提前分配资源响应潜在重载查询成本可控始终受配置范围限制避免资源浪费当负载减少时系统会自动释放空闲 RPU并在无查询运行时降至 0。若保持空闲过久再次运行查询时将触发冷启动详见后文计费粒度说明。Redshift 与 BigQuery 的扩展方式对比BigQuery在查询执行过程中动态分配并调整 slot 数量Redshift在查询开始前一次性分配完整的 RPU 数量。简言之BigQuery 是“边执行边扩展”Redshift 则是“先分配再执行”。一旦确定了 RPU 数量整个查询将在固定资源规模下运行。计算定价官方定价更新于 2025 年 11 月 → https://aws.amazon.com/redshift/pricing/在 AWS 美国东部弗吉尼亚北部地区Redshift Serverless 的按需计费价格为 $0.375 / RPU / 小时。计费粒度参考 AWS 文档Amazon Redshift Serverless compute pricing details2025 年 11 月https://aws.amazon.com/cn/redshift/pricing/Redshift Serverless 以秒为单位计费但每次最低收取 60 秒费用。计算容量由系统自动管理。当没有查询运行时Redshift 会立即缩容至 0无需用户手动设置空闲超时服务会在后台自动挂起待有新查询到来时再恢复。如果服务仍处于活跃状态即热池未被释放通常可以快速恢复。但若空闲时间较长AWS 可能会释放底层资源从而触发冷启动这可能带来几十秒的延迟。虽然这一行为没有在官方文档中明确说明但实际情况中确实存在。Bench2Cost 如何计算 Redshift Serverless 成本成本计算方式:Redshift Serverless 的成本计算方式基本遵循与其他引擎相同的 Bench2Cost 流程但有一个关键差异Redshift 并不按挂钟时间wall-clock runtime计费而是根据 RPU 时间RPU-time来计费。具体而言RPU-time 挂钟运行时间 × 实际使用的 RPU 数量而原始的 ClickBench 输出中只包含挂钟时间并不包含 RPU 时间。为此我们对 ClickBench 的运行器进行了扩展使其能够通过 Redshift 的系统表和 AWS API 获取每条查询所产生的计费 RPU 秒数。这部分功能由脚本 get_metrics.sh 实现。在此基础上Bench2Cost 流程的执行步骤如下使用扩展后的运行器重新执行 ClickBench 测试生成包含每条查询挂钟时间与 RPU 时间的 Redshift 专用结果文件例如 serverless_100m.json加载 Redshift 的定价模型Bench2Cost 使用定价描述文件serverless.json其中记录了 RPU 的单价和存储费用将测试结果与成本信息结合enrich.sh 脚本将基准数据与定价模型结合生成一个包含每条查询计算成本和存储成本的增强 JSON 文件例如 enriched_100m.json。最终输出结果包括以下内容每条查询的挂钟运行时间计费的 RPU 时间以美元计的计算成本以美元计的存储成本通过上述处理Redshift 的数据便可以与其他系统进行统一对比用于每条查询的成本分析。至此我们已经完整介绍了五大主流云数据仓库在计算资源计费上的具体方式。接下来我们将进一步探讨这些模型对于云数据仓库经济性的启示。云数据仓库的经济学意义我们刚刚全面分析了五大主流云数仓平台是如何真正计费的。最核心的结论其实很简单决定成本的不是查询运行时间而是背后的计费模型。虽然 Snowflake、Databricks 和 ClickHouse Cloud 都采用“预配置计算容量”模式但 ClickHouse 是一个特别的存在且这种“特别”带来了巨大优势Snowflake 和 Databricks 的计费单位较为抽象、难以理解ClickHouse 的计费单位则直接基于硬件资源 —— 每个计算单元对应 8 GiB 内存和 2 个 vCPU极具透明性。它也是目前唯一同时支持“无限横向扩展”与“自动纵向扩展”的平台。换句话说单条查询可以动态调度所有节点上的 CPU 与内存资源充分利用整个集群。而 BigQuery 和 Redshift Serverless 则采取相反策略完全基于“无服务器共享计算”。你不需要预先配置任何集群大小系统根据每条查询的资源需求动态分配资源并据此计费。每个平台对“你在为什么买单”的定义都不一样因此只看价格表几乎毫无意义。正因如此我们设计了 Bench2Cost —— 一个中立、结构化的方式帮助将基准测试的运行时间转化为可比的每查询成本指标。本文为你构建了理解云数仓成本的分析模型。而我们接下来的配套文章将直击核心问题哪个平台在分析型查询方面的性价比最高提前透露一下在大规模分析型工作负载中ClickHouse Cloud 的性价比比所有其他平台高出一个数量级。征稿启示面向社区长期正文文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出图文并茂。质量合格的文章将会发布在本公众号优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至Tracy.Wangclickhouse.com