为什么BigQuery在实时分析上不及ClickHouse Cloud

所有基准测试代码和结果均可在 CostBench 仓库 中获取。股票行情数据集需要 单独的数据许可，因此数据本身无法重新分发。

为解释该结果，我们遵循与数据相同的路径：先准备，再查询服务。

ClickHouse Cloud 如何准备传入数据

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

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

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

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

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

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

四核摄取服务处理了多少工作？（点击展开） ClickHouse 写入器利用率结果 显示摄取与后台维护同时进行。CPU 使用率保持在 4 个可用核心中的约 3.1 个，跟踪的内存保持在容量范围内，后台合并每秒处理数百万行，每个分区的最大活动部分数保持在 100 左右。这些诊断信息描述了为此比较复用的 ClickHouse 源运行。

两个节点都保留用于高可用性，因此准备成本包括完整的两节点部署。

现在通过 BigQuery 遵循相同的三个准备任务，其中流式摄取、聚类和 MV 刷新分别推进。

BigQuery 如何准备传入数据

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

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

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

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

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

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

为什么选择这些摄取路径，以及它们是如何缓冲的？（点击展开） 相同的摄取问题

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

BIGQUERY 的流式路径

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

CLICKHOUSE 的原生路径

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

共享节奏控制

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

CLICKHOUSE 批次

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

BIGQUERY 批次

每个工作进程拥有一个已提交流，并发送序列化的 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 答案。

预聚合延迟是如何测量的？（点击展开） BIGQUERY 系列

该新鲜度监控器每分钟采样一次refresh_watermark。滞后是从该水位线到观测时刻的经过时间。1,889 个有效样本被纳入，直到首次完整行观测；441 个后续样本被排除。这是维护水位线指标，不是答案陈旧度。

显示与读数

图表从每个完整观测到的刷新水位线周期中选取一个测量的最大值，产生359 个周期峰值。首个和最后一个不完整周期被排除。它们的平均值为4.861 分钟，最大值为6.100 分钟，四舍五入为 4.9 和 6.1。完整的有效原始序列有一个8.023 分钟的启动峰值，它不在该周期峰值显示范围内。读数遵循所显示的曲线。

CLICKHOUSE 基线

零线是基准语义基线，不是单独轮询的提供商指标。原始表和增量 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 表中裁剪有序原始数据。按其 (sym, t) 排序键的前导列 symbol 进行过滤，可让读取服务跳过无关报价。

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

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

BigQuery 遵循相同的两条查询路径，但当聚类或摘要刷新落后时会有额外工作。

BigQuery 如何提供查询服务

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

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

交互式聚合： 查询以增量 MV为目标，并将其摘要与自上次刷新以来添加到基表中的变更合并。这种追赶工作即使 MV 水位线落后于传入数据，也能保持答案最新。

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

BIGQUERY 的当前答案和计算模型如何工作？（点击展开） 当前答案契约

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

刷新契约

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

计算契约

所测量的作业在按需动态分配的槽位上运行。Enterprise Capacity 定价按每槽小时 $0.06 应用于所测量作业的槽秒数。它不会在固定预留上重放这些作业，也不会改变其测量到的延迟。

按需契约

另一种方案是按每个作业的计费字节数，每 TiB 收取 6.25 美元。字节数和槽位秒数以不同的计价约定描述相同的作业；它们的成本永远不会相加。

可见性边界

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

结果是：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 使用其记录的运行器持续时间。中位数、P99 和最大值为池化未平滑的逐查询观测值，条件为0 < raw_rows ≤ 1000 亿。P99 使用线性插值。所记录的计时约定保留在累积运行时中。

延迟图表

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

交互式读数

图表下方的数值遵循所选行数处显示的走势。对数刻度使毫秒和秒可一起阅读；线性刻度显示绝对差异。每个图表都有自己的播放和行位置控件。

已接受的累积工作负载

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

累积图表

查询持续时间按对应的摄入计数以阶梯和的方式相加，不进行平滑或将未来执行插值到较早位置。准备成本线按行进度比例分配完整摄入总量；它们不是实时计量的成本轨迹。得分累加的是查询持续时间，而不是经过的摄入时间。

ClickHouse Cloud：

• 722.5 毫秒中位数 - 比 BigQuery 快 4.47 倍
• 1.15 秒 P99 - 快 3.90 倍
• 1.18 秒最大值 - 快 4.05 倍

累积运行时为47.96 秒，跨 33 个两查询批次。在大部分绘制窗口内，两次下钻都保持在大约或低于一秒。

BigQuery：

• 3.232 秒中位数
• 4.49 秒 P99
• 4.78 秒最大值

累积运行时为209.52 秒，跨同样的 33 个批次。随着原始表增长，两次 BigQuery 下钻都保持在数秒范围内。

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

对有序预聚合数据的交互式聚合

每日预聚合让A1-A4组合准备好的计数、总和以及价格最小值和最大值。A1-A2 按符号过滤摘要；A3-A4 跨所有符号读取。ClickHouse 读取当前摘要；BigQuery 还必须包括较新的基表行。下图显示摄入持续期间的聚合延迟。

ClickHouse Cloud：

• 13 毫秒中位数 - 比 BigQuery 快 270 倍
• 42 毫秒 P99 - 快 141 倍
• 111 毫秒最大值 - 快 62.5 倍

累积运行时为10.32 秒，跨 190 个四查询批次。

BigQuery：

• 3.508 秒中位数
• 5.86 秒 P99
• 6.93 秒最大值

累积运行时为45.86 分钟，跨同样的 190 个批次。四个聚合查询都保持在数秒级，而 ClickHouse 以毫秒级提供服务。BigQuery 的当前答案路径在刷新后的摘要之外还包括较新的行。

在整个交互式聚合工作负载中，ClickHouse Cloud 总体快 267 倍，且摘要在插入期间得到维护。

累积查询成本和运行时

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

ClickHouse Cloud 累积了58.29 秒的查询运行时，BigQuery 为49.36 分钟。归一化查询成本约为0.05 美元（ClickHouse），而 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 的采用展示了更快的查询和更可预测的成本为实时分析带来的生产效益。该团队在生产查询上将其与 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 匹敌。