TL;DR

实时系统在将传入数据从到达至可查询的过程中，其成本和效率差异巨大。在本系列中，我们沿着这条路径来观察它如何影响准备成本、查询成本和查询运行时。

在这里，ClickHouse Cloud 和 BigQuery 在查询运行期间摄入了 1132 亿条报价。在 BigQuery 容量定价下，ClickHouse Cloud 每美元的端到端性能提升了 438 倍，在按需定价下提升了 512 倍。该对比追溯了这些差异的起源。

从新鲜数据到快速答案 #

实时分析必须在新数据到达时持续快速作答。CostBench 直接对此进行测试：查询在持续摄入过程中运行，答案包含新到达的数据。高效地准备这些数据可以降低保持其可查询的成本，并为查询留下更少的工作，从而降低查询成本和运行时。

列式存储让查询可以跳过未使用的字段；排序让下钻查询可以跳过无关的报价；当前预聚合让交互式聚合可以组合已准备好的摘要。下图展示了随着准备工作的跟上或落后，新鲜数据路径如何改变查询工作。

CostBench 衡量 ① 准备成本、② 查询成本和 ③ 运行时，然后将它们合并为一个端到端的每美元性能评分。

本文通过 ClickHouse 与 BigQuery 的对比，追踪这三个影响，从准备传入数据到服务查询。

工作负载与结果 #

在容量定价模式下，ClickHouse Cloud 的端到端每美元性能比 BigQuery 高出 438 倍，在按需定价模式下高出 512 倍，同时数据摄取和查询并行运行。

两个系统均使用了各自推荐的实时摄取路径和原生预处理功能：ClickHouse 使用异步插入；BigQuery 使用 Storage Write API（应用程序编程接口） 的已提交流、聚簇和增量物化视图。CostBench 以每秒 100 万行为目标流式写入 1132 亿条股票市场报价，使用等效的排序或聚簇键，并按股票代码进行每日预聚合。在整个摄取过程中，四个交互式聚合查询每十分钟运行一次；两个针对原始报价的下钻查询每小时运行一次。每个查询覆盖截至当时已摄取的全部历史数据，包括新到达的报价。查询结果缓存已禁用。

CostBench 使用以下公式计算其端到端每美元性能得分：得分 = (① 预处理成本 + ② 归一化查询成本) × ③ 累计查询运行时间。

预处理成本涵盖完整的新数据路径。归一化查询成本对查询所消耗的资源进行定价；累计查询运行时间是各查询持续时间之和。得分越低越好。BigQuery 的容量定价和按需定价是同一测量工作负载的两种替代价格，查询延迟相同。

两个系统使用了相同的源数据集、模式、分析工作负载、节奏模型、查询计划和结果格式。目标端特定的适配器负责数据投递和时序控制。第 1 部分解释了共享方法论；BigQuery 基准测试合约记录了该提供商的实现。

数据集与预处理

完整的 NBBO 数据集包含 113,219,565,734 行窄表数据，每行 12 列。原始表使用 (sym, t)，即股票代码和事件时间戳；每日汇总表使用 (sym, day)，即股票代码和 UTC 日期。汇总表维护了聚合查询所使用的计数、求和以及价格最小值和最大值。

新数据行以每秒 100 万行的速度写入，同时聚合查询和下钻查询按每十分钟和每小时的计划运行。这模拟了持续生成并在到达时即进行预处理的数据。BigQuery 的 max_staleness 选项未设置，因此物化视图查询必须包含更新的基表数据。

推荐技术栈与规格

ClickHouse Cloud 使用了一个 16 CPU、64 GiB 的读取节点。BigQuery 使用了按需无服务器查询计算，动态分配槽位，没有固定预留。这不是两个固定 16 CPU 分配之间的比较。容量定价替代方案以企业版标价对相同的实测槽位消耗进行定价；它并不代表单独的容量运行。

完整路径包括 ClickHouse 的完整双节点高可用摄取服务，以及 BigQuery 的 Storage Write API 摄取加上自动物化视图刷新。BigQuery 的自动重新聚簇不单独收费。容量定价和按需定价的预处理总计在各自的计费模型下保留相同的摄取计量和价格刷新资源。

② 查询成本与 ③ 运行时间

ClickHouse 查询成本等于记录的持续时间乘以其读取侧计算费率。BigQuery Capacity 使用作业槽秒数；On-demand 使用计费字节数。两种 BigQuery 替代方案在 ③ 中使用相同的记录查询持续时间。这些归一化成本描述的是已接受的查询工作量，而非完整的提供商账单。

目标速率与实际速率对比

BigQuery 在大约 31.5 小时内确认了完整的逻辑数据集，平均 999,495 行/秒；ClickHouse 在大约 36.75 小时内完成了数据摄入，平均约 86 万行/秒。摄入摘要将 BigQuery 确认的行数与提供商成功写入计量器分开记录。该计量器包含 113,172,471,254 条成功行；ClickHouse 的写入成本证据包含 113,217,743,918 行，差异为 0.040%。查询对比使用 113,219,565,734 行的参考范围。

每查询延迟图在 1000 亿行处截止。准备成本保留完整的摄入计量器和收集到的刷新用量。累计查询成本和运行时使用截至参考端点的已接受活跃摄入观测值；后续查询观测值被排除。显示的总计经过四舍五入。定价说明中陈述了刷新导出边界和排除项。

ClickHouse Cloud 在所有三个测量组件中均领先：

① 准备成本：$28.69 对比 $243.09 Capacity / $264.59 On-demand。② 归一化查询成本：约 $0.05 对比 $4.75 Capacity / $24.80 On-demand。③ 累计查询运行时：58.29 秒对比任一 BigQuery 定价模型下的 49.36 分钟。

以下图表展示了这些成本和运行时在数据到达过程中如何累积。

下一张图表将评分公式应用于这些组件：ClickHouse 在 Capacity 定价下综合成本低 8.62 倍，在 On-demand 下低 10.07 倍，结合累计查询运行时低 50.8 倍。

ClickHouse Cloud 使用每计算单元（CU）每小时 $0.3903。BigQuery 使用已检入的美国列表价格：Storage Write API 摄入 $0.025/GiB，Enterprise Capacity $0.06/槽小时，On-demand 分析 $6.25/TiB。已接受的摘要保留全精度输入。Capacity 和 On-demand 是相同作业的替代建模成本。

① 完整准备成本

这涵盖完整的流式摄入计量器、无额外费用的自动重新聚簇，以及收集到的 MV 刷新用量。

2 CU × 36.75 小时 × $0.3903/CU-小时 = $28.68705，包括两个 HA 摄入节点。

Write API 计量器记录 9,642.7384687 GiB × $0.025/GiB = $241.06846172，使用成功输入字节数。客户端确认的 Arrow 字节数和提供商计量的输入字节数是不同的度量。

自动重新聚簇已包含在内，不单独收费。未添加付费的手动重组作业。

362 个作业的导出包含 121,166.568 slot-seconds，按 $0.06/slot-hour 计价为 $2.0194428，或 4,137,783,656,448 billed bytes，按 $6.25/TiB 计价为 $23.52057695。准备阶段总计为 $243.08790452 Capacity 和 $264.58903867 On-demand。

② 归一化查询成本

BigQuery 按消耗的 slot-seconds 或 billed bytes 对相同的已接受查询作业计价。ClickHouse 按读取侧费率对记录的持续时间计价。

8 CUs × $0.3903/CU-hour × (10.324s 聚合 + 47.962s 下钻) ÷ 3,600 ≈ $0.05055，使用四舍五入的成本汇总输入。

聚合作业成本为 $4.29558297，下钻作业成本为 $0.45264198，总计 $4.74822495。合并的 79.1370825 slot-hours × $0.06/slot-hour 分配使用记录的作业 slot 消耗量。

聚合作业成本为 $20.94800472，下钻作业成本为 $3.85683775，总计 $24.80484247。合并的计费量为 3.9687748 TiB × $6.25/TiB。这是 Capacity 定价的替代方案，而非附加组件。

准备模型保留完整的成功写入计量器和所有 362 个收集的刷新作业，包括生产者完成后的终端刷新。查询总计不包括后续的摄入后观察和证据收集器作业。数据库存储、免费层、折扣、空闲/最低容量费用、生产者基础设施和网络费用均不包括在内。

③ 累计查询运行时间

ClickHouse：10.324s 聚合 + 47.962s 下钻 = 58.286s。BigQuery：2,751.868s 聚合 + 209.518s 下钻 = 2,961.386s，在任一计价模型下均如此。

① 保留完整摄入准备使用量。② 和 ③ 使用 190 个四查询聚合批次和 33 个双查询下钻批次，按参考范围内的行进度对齐。延迟统计使用单独的 1000 亿行窗口。Capacity 替代方案改变应用于已计量资源的价格；它不改变查询硬件或重新运行工作负载。

ClickHouse：($28.68705 + $0.05055) × 58.286 = 1,674.99975。BigQuery Capacity：($243.08790452 + $4.74822495) × 2,961.386 = 733,938.44411，比值为 438.172×。BigQuery On-demand：($264.58903867 + $24.80484247) × 2,961.386 = 857,006.98809，比值为 511.646×。标题数值四舍五入为 438× 和 512×。

每美元实时性能提升 438×

有兴趣了解 ClickHouse 如何在您的数据上运行吗？几分钟内即可开始使用 ClickHouse Cloud，并获得 $300 免费额度。

所有基准测试代码和结果均可在 CostBench 仓库 中获取。stock-quotes 数据集需要单独的数据许可，因此数据本身无法再分发。

为了解释这一结果，我们按照与数据相同的路径进行说明：先准备，再查询服务。

ClickHouse Cloud 如何准备传入数据 #

该基准测试使用了一个专用的 ClickHouse Cloud 摄取服务，包含两个 2-CPU 节点以实现高可用性，这是在校准期间能够维持目标的最小 HA 配置。共享客户端通过内置于每个节点的异步插入发送行数据。

下图展示了这些相同节点如何在总共四个 CPU 核心上处理 ① 列式存储、② 原始数据排序和 ③ 有序预聚合，以及后台合并。

① 按列存储和 ② 数据排序：当摄取节点刷新其异步插入缓冲区时，它会按 MergeTree 表的 (sym, t) 键（股票代码和事件时间戳）对原始报价进行排序，并写入一个有序数据部分。

③ 数据排序和预聚合：同一节点在内存中对传入块运行增量 MV 查询，计算聚合状态，并按 AggregatingMergeTree 表的 (sym, day) 键对结果排序，然后写入包含摘要的有序部分。

后台合并会整合两个表中的部分。

结果是：原始数据和预聚合从同一个已刷新的插入块一起推进，无需单独的刷新周期。

ClickHouse 写入利用率结果显示，数据摄取与后台维护同时进行。CPU 使用率保持在 4 个可用核心中的约 3.1 个核心，跟踪内存保持在容量范围内，后台合并每秒处理数百万行，每个分区的最大活跃分片数保持在 100 左右。这些诊断信息描述了本次对比中复用的 ClickHouse 源端运行情况。

两个节点均被保留以实现高可用性，因此准备成本包含完整的两节点部署。

现在通过 BigQuery 来跟踪同样的三个准备任务，其中流式摄取、聚簇和物化视图刷新分别推进。

BigQuery 如何准备传入数据 #

该基准测试使用了 BigQuery 的 Storage Write API，配合应用程序创建的已提交流，通过长连接 gRPC 连接发送 Arrow 记录批次。成功的追加操作使行数据可供查询。

如下所示，流式路径处理 ① 列式存储，而 BigQuery 异步管理 ② 聚簇和 ③ 增量物化视图刷新。

① 列式存储：Storage Write API 将行数据写入原生 BigQuery 表。BigQuery 将列式存储与查询计算分开管理；已确认的已提交追加并不保证表的聚簇已完全优化。

② 数据排序：原始表使用 CLUSTER BY sym, t，为符号过滤提供了裁剪存储块的能力。BigQuery 通过自动重新聚簇来维护该布局；它不保证每个追加的批次已经有序。

③ 数据排序与预聚合：一个原生增量物化视图按 (sym, day) 对报价进行分组，维护计数、求和和价格极值，并使用相同的聚簇键。自动刷新通过 refresh_interval_minutes = 1 启用，这是支持的最小间隔。这允许自动刷新频率不超过每分钟一次；它不保证摘要能在一分钟内变为最新。

结果是：BigQuery 可以在聚簇跟上之前使新行可查询，而预聚合则通过单独的刷新周期推进。

相同的摄取问题

频繁的应用程序写入必须转化为高效的存储写入。ClickHouse 在其摄取节点上缓冲 INSERT 请求。BigQuery 通过已提交的 Storage Write API 流接受 Arrow 批次，在测量的路径中不需要 Kafka 代理或文件落地阶段。

BIGQUERY 的流式路径

全量运行配置使用了 40 个已提交流、显式行偏移量、131,000 行的客户端批次，以及 16,000,000 字节的请求限制。一个全局速率控制器将追加启动速度调节至约 100 万行/秒。进度由成功确认定义，而非仅从 Parquet 读取的行数。

CLICKHOUSE 的原生路径

启用 async_insert 的普通 INSERT 请求在每个接收节点上进行缓冲。自适应刷新超时会响应传入流量。排序和预聚合在摄取节点上运行；专用摄取服务与独立调整规模的读取服务共享存储。

两个适配器读取相同的 Parquet 数据集，并在相同的目标速率模型下解码相同的 schema。并行度和客户端批次大小根据每个目标的 API 进行调整；它们并未被强制要求完全相同。

客户端通过异步插入发送 3,000 行的批次。默认缓冲在三个阈值中最先达到者触发刷新：缓冲达到 100 MiB、自适应超时在 50 毫秒到 1 秒之间，或 450 个排队的插入查询。

每个工作线程拥有一个已提交流，并发送序列化的 Arrow 记录批次。这是实时流式投递；行并未作为文件上传以供后续加载作业使用。未使用待处理流批次提交。

3,000 行的 ClickHouse 和 131,000 行的 BigQuery 大小描述的是客户端投递。它们并不指定最终的 MergeTree 部件或 BigQuery 存储块大小。

重试与对账

显式偏移量让 BigQuery 能够在确认丢失后检测到精确重放。客户端契约将已确认的重放计为一次并重新连接。这在实时运行中提供了恰好一次的重试处理，而非可崩溃恢复的源检查点。客户端确认、提供商成功写入行数和表元数据被保留为不同的证据。

增量维护

MV 定义在仅追加源上使用了受支持的 COUNT、MIN、MAX 和 SUM 操作。刷新作业导出包含 362 个成功的自动刷新作业，没有失败作业。刷新槽秒数和计费字节数与仪表板作业分开记录。

布局与分区

原始表被有意设置为不分区，因为 D1 和 D2 在全部已摄入历史数据上按 symbol 过滤，没有时间谓词。按 (sym, t) 进行聚簇可服务于该工作负载。自动重新聚簇由系统管理，不产生单独的计算费用；基准测试中未加入手动重写。

这对新鲜度和准备成本意味着什么 #

预聚合延迟 #

ClickHouse 在插入期间更新汇总；BigQuery 异步刷新它们。下图显示了每个完整刷新周期中观测到的一次滞后最大值：BigQuery 绘制的周期峰值平均为 4.9 分钟，最高达到 6.1 分钟。在此设置中，ClickHouse 的原始数据和汇总同步推进。

这衡量的是汇总维护滞后。BigQuery 在查询时仍会纳入较新的基表行，从而返回当前的 MV 答案。

新鲜度监控每分钟采样一次 refresh_watermark。滞后是从该 watermark 到观测时刻所经过的时间。包含截至首次全行观测的 1,889 个活跃样本；排除了之后的 441 个样本。这是维护 watermark 的度量，而非答案陈旧度。

显示与读数

该图表从每个完整观测到的 refresh-watermark 周期中选取一个实测最大值，共产生 359 个周期峰值。首个和最后一个不完整周期被排除。其均值为 4.861 分钟，最大值为 6.100 分钟，四舍五入为 4.9 和 6.1。完整的活跃原始序列有一个 8.023 分钟的启动峰值，不在该周期峰值显示范围内。读数遵循所显示的曲线。

零线是基准语义基线，而非单独轮询的提供商指标。原始表和增量 MV 消费同一个已刷新的插入块，二者之间没有独立的汇总刷新间隔。它并不声称源到查询的摄入延迟为零。

ClickHouse 将汇总与原始数据同步维护；BigQuery 绘制的刷新周期滞后峰值平均为 4.9 分钟，导致较新的行需在查询时纳入。

这些较新的行会给查询增加工作量。首先，比较准备路径本身的成本。

保持传入数据可查询的成本 #

ClickHouse 在其引擎内处理 ① 列式存储、② 原始数据排序以及 ③ 有序预聚合。BigQuery 将单独计价的流式摄取和 MV 维护结合在一起；自动重新聚簇不产生额外费用。下图比较了两种 BigQuery 定价模型下的完整准备成本。

ClickHouse 的完整摄取服务成本为 $28.69。BigQuery 的 Storage Write API 成本为 $241.07（①）；自动重新聚簇（②）没有单独费用。MV 刷新（③）在 Capacity 定价下增加 $2.02，在 On-demand 下增加 $23.52，因此准备总成本分别为 $243.09 和 $264.59。

ClickHouse 以比 BigQuery Capacity 低 8.5 倍、比 On-demand 低 9.2 倍的成本完成了完整的准备路径。

现在跟随原始数据和汇总数据进入查询服务。

ClickHouse Cloud 如何提供查询服务 #

有序原始数据让下钻查询可以跳过无关行；预聚合让交互式聚合可以组合已准备好的结果，而不是从单条报价重新计算。下图展示了通过 ClickHouse Cloud 读取服务的两条路径：一个具有 16 个 CPU 和 64 GiB 内存的节点。

下钻查询：查询会在事件级 MergeTree 表中裁剪有序原始数据。按 symbol 过滤——它是 (sym, t) 排序键的前导列——可以让读取服务跳过无关报价。

交互式聚合：查询从 AggregatingMergeTree 表中读取当前预聚合，组合来自小得多的每日汇总行集合的已准备计数、求和、最小值和最大值。无需等待独立的刷新。

结果是：下钻查询裁剪有序原始数据；交互式聚合读取在摄取期间保持最新的汇总数据。

BigQuery 遵循相同的两条查询路径，但当聚簇或汇总刷新落后时会产生额外工作。

BigQuery 如何提供查询服务 #

下图展示了两个工作负载在 BigQuery 无服务器计算池中的运行过程。Slot 是动态分配的；本次运行中没有固定 CPU 数量的专用仓库。

下钻查询：查询直接读取聚簇原始表。基于 sym 的过滤可以裁剪掉不相关的数据块，但新到达的数据在重新聚簇优化其布局之前可能仍需要扫描。

交互式聚合：查询针对增量 MV，并将其汇总结果与自上次刷新以来添加到基表中的变更相结合。这种追赶工作使答案保持最新，即使 MV 的 watermark 落后于传入数据。

因此，两条路径都可能遇到未完成的准备工作：下钻查询可能扫描聚簇尚未完成的数据；聚合查询必须包含刷新尚未汇总的行。

CURRENT-ANSWER CONTRACT

在未设置 max_staleness 的情况下，直接查询物化视图会包含基表中尚未体现在 MV 中的变更。刷新 watermark 滞后并不意味着返回的答案是过时的。它意味着部分准备工作仍留在查询路径上。

一分钟的刷新间隔是一个频率上限。自动刷新是尽力而为的，在负载下可能完成得更少。刷新 watermark 滞后和查询延迟是分别度量的；基准测试不会将整个延迟差距都归因于增量处理。

所测量的作业运行在按需、动态分配的 slot 上。Enterprise Capacity 定价对测量的作业 slot-秒 按每 slot-小时 $0.06 计费。它不会在固定预留上重放作业，也不会改变其测量的延迟。

另一种方案对每个作业的计费字节按每 TiB $6.25 计费。字节和 slot-秒 描述的是相同作业在不同定价惯例下的情况；它们的成本永远不会相加。

一次成功提交的追加会使行可查询，而表元数据可能稍后更新。运行器的进度信号使用已确认的行。可查询性、元数据更新、聚簇和汇总刷新仍然是不同的里程碑。

结果：BigQuery 下钻查询可能在聚簇跟上之前扫描新到达的数据；交互式聚合会包含其汇总尚未纳入的较新行。

这对查询性能和成本意味着什么 #

对有序原始数据进行下钻分析 #

两个系统均使用 (sym, t) 键，ClickHouse 在插入时对行进行排序，而 BigQuery 则异步管理聚簇。D1 和 D2 直接研究单只股票不断增长的历史数据：小时级价格汇总以及风险与流动性画像。下图遵循这条原始数据路径，绕过了预聚合 MV。

ClickHouse Cloud 为黄色；BigQuery 为蓝色。

第 1 部分描述了 A1-A4 和 D1-D2。BigQuery SQL 保留了符号过滤、全历史范围、分组、排序和限制。D2 使用总体中心矩和 APPROX_QUANTILES 计算百分位数；该百分位数算法与 ClickHouse 的 quantilesTDigest 不同，需要基于容差进行比较。

查询结果缓存已通过 use_query_cache=False 禁用。底层数据缓存被允许正常运行；查询之间未对其进行刷新。

BigQuery 延迟为已完成作业的 finalExecutionDurationMs 除以 1,000；ClickHouse 使用其记录的 runner 持续时间。中位数、P99 和最大值为池化未平滑的每查询观测值，条件为 0 < raw_rows ≤ 1000 亿。P99 使用线性插值。记录的计时约定保留在累计运行时间中。

每个系统按其自身观测到的摄取进度绘制。聚合趋势使用居中的七次观测滚动中位数；下钻使用五次观测，边缘窗口收缩。不剔除任何离群值。曲线为显示平滑；统计量和累计总量使用原始记录的持续时间。

交互式读数

图表下方的值遵循所选行数处显示的趋线。对数刻度使毫秒和秒可同时读取；线性刻度显示绝对差异。每个图表都有各自的播放和行位置控件。

已接受的累计工作负载

所选内容包含每个系统 190 个四查询聚合批次和 33 个双查询下钻批次：760 + 66 = 826 次执行。ClickHouse 观测值通过 113,219,565,734 行的参考视界与 BigQuery 行进度对齐。初始观测值在存在时予以保留；后续摄取后的观测值被排除。

查询持续时间在对应的摄取计数处以步进和的方式相加，不进行平滑处理，也不将未来执行插值到更早的位置。准备成本线按行进度比例分配完整摄取总量；它们不是按时间计量的成本轨迹。评分累加的是查询持续时间，而非经过的摄取时间。

• 中位数 722.5 毫秒 - 比 BigQuery 快 4.47 倍

• P99 1.15 秒 - 快 3.90 倍

• 最大值 1.18 秒 - 快 4.05 倍

在 33 个双查询批次中，累计运行时间为 47.96 秒。在图表所示的大部分时间窗口内，两个下钻查询的耗时均接近或低于一秒。

• 中位数 3.232 秒

• P99 4.49 秒

• 最大值 4.78 秒

在相同的 33 个批次中，累计运行时间为 209.52 秒。随着原始表数据增长，两个 BigQuery 下钻查询的耗时始终保持在数秒级别。

在下钻工作负载中，ClickHouse Cloud 整体快 4.37 倍。

基于有序预聚合数据的交互式聚合 #

每日预聚合使 A1-A4 能够组合预先计算好的计数、求和以及价格最小值和最大值。A1-A2 按 symbol 过滤汇总数据；A3-A4 跨所有 symbol 读取。ClickHouse 读取当前汇总数据；BigQuery 还必须包含更新的基础表行。下图展示了数据持续写入期间的聚合延迟。

• 中位数 13 毫秒 - 比 BigQuery 快 270 倍

• P99 42 毫秒 - 快 141 倍

• 最大值 111 毫秒 - 快 62.5 倍

在 190 个四查询批次中，累计运行时间为 10.32 秒。

• 中位数 3.508 秒

• P99 5.86 秒

• 最大值 6.93 秒

在相同的 190 个批次中，累计运行时间为 45.86 分钟。所有四个聚合查询的耗时均保持在秒级，而 ClickHouse 仅需毫秒级即可完成。BigQuery 的当前答案路径除了刷新后的汇总数据外，还包含更新的行。

在交互式聚合工作负载中，ClickHouse Cloud 整体快 267 倍，且汇总数据在插入期间持续维护。

累计查询成本和运行时 #

交互式聚合占 BigQuery 累计查询运行时的大部分。下面的图表结合了两种工作负载，并展示了它们在 Capacity 和 On-demand 定价下的查询成本。

ClickHouse Cloud 累计查询运行时为 58.29 秒，BigQuery 为 49.36 分钟。归一化查询成本 ClickHouse 约为 $0.05，而 BigQuery 为 $4.75 Capacity 或 $24.80 On-demand。

ClickHouse Cloud 整体上以快 50.8× 的速度服务查询工作负载，归一化查询成本比 BigQuery Capacity 低 94×，比 On-demand 低 491×。

来自现场：METRO Markets 和 Fountain #

METRO Markets 采用 ClickHouse Cloud 展示了更快查询和更可预测成本对实时分析的生产效益。该团队在将 ClickHouse 与 BigQuery 和 Snowflake 针对其生产查询进行测试后选择了 ClickHouse。ClickHouse 在大查询和小查询上都运行得更快，其中一个查询从四秒改进到不到 200 毫秒。它现在为近实时卖家仪表盘和全公司分析提供支持，同时为团队提供更可预测的成本。阅读 METRO Markets 的故事。

Fountain 从包含 BigQuery 的批处理分析栈迁移到 ClickHouse Cloud，展示了更新数据和更快查询对实时应用的生产效益。它现在使用 ClickPipes 和 ClickHouse Cloud 为其一线招聘平台 Cue 提供支持。数据刷新延迟从三小时降至不到两分钟，大多数查询现在在一秒内返回，公司报告平台成本降低约 66%。增量物化视图在数据到达时准备传入数据，减少查询时所需的工作。阅读 Fountain 的故事。

CostBench 评估了从准备传入数据到服务查询的完整分析路径中的效率。

BigQuery 在实时分析方面无法与 ClickHouse Cloud 匹敌 #

在新鲜数据持续到达的同时，ClickHouse Cloud 在所有三个测量组件中都领先：

① 准备成本：比 BigQuery Capacity 低 8.5× / 比 On-demand 低 9.2×。② 归一化查询成本：比 Capacity 低 94× / 比 On-demand 低 491×。③ 累计查询运行时：在任一 BigQuery 定价模型下都低 50.8×。

最终图表将这些结果汇总在一起，绘制了新鲜数据到达时组合准备成本和归一化查询成本与累计查询运行时的关系。

上方表示更低的总建模成本；右侧表示更低的累计查询运行时间。

ClickHouse Cloud 每美元端到端性能比 BigQuery Capacity 高出 438 倍，比 On-demand 高出 512 倍，同时持续摄取数据并提供最新答案。

差异在查询到达之前就已开始。ClickHouse 在插入期间对原始数据排序并构建最新汇总。BigQuery 使新行可查询，同时聚类和物化视图刷新在后台继续进行；其聚合查询包含刷新尚未汇总的行。

这就是为什么 BigQuery 在实时分析方面无法与 ClickHouse Cloud 匹敌。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：ClickHouse Blog

原创地址：https://clickhouse.com/blog/clickhouse-vs-bigquery-real-time-performance-per-dollar