438倍差距，BigQuery输在哪

438倍。这是 CostBench 给出的数字——同样的实时分析负载，ClickHouse Cloud 每1美元买到的性能，是 BigQuery 的438倍。夸张到让人第一反应是怀疑基准有问题。但把『新数据到达』到『快速答案返回』这条链路逐段拆开看，你会发现差距不是玄学，而是两种架构哲学、两种计费模型，在同一类负载上的正面碰撞。这篇文章拆的就是这条链路。

📊 一个基准测试，捅破了窗户纸

场景你大概不陌生：一家电商公司的数据团队开选型会，业务方要求大促期间的交易看板秒级刷新、告警实时触发，数据平台负责人在 BigQuery 和 ClickHouse Cloud 之间摇摆。前者免运维、生态全，后者听起来快，但快多少、贵多少，谁也说不清。

CostBench 要回答的就是这个『说不清』。它测的不是一个孤立的查询速度，而是性能除以成本——单位美元买到的计算能力。结果就是那个438倍。更关键的是，这个基准覆盖的不是单点，而是从『新鲜数据进入系统』到『快速答案交回用户』的完整链路，摄入、存储、查询、并发，一段一段算账。

这背后的产业逻辑值得琢磨：数据平台的采购决策，正在从『能不能』转向『划不划算』。五年前大家比功能清单，三年前比TPC式的峰值性能，现在比的是每美元性能——因为云账单已经大到CEO会亲自过问的程度。圈子里流传的共识是：数据基础设施的竞争，正在从技术叙事切换到成本叙事。

438倍也许会在不同负载、不同配置下波动，但它把一个长期被『免运维』『托管』话术遮住的问题顶到了台面上：为了实时性，你到底在为哪种架构付钱？

💰 按扫描付费，撞上高并发实时负载

成本差距，往往不是引擎慢出来的，是计费模型『设计』出来的。

拆开实时分析的典型负载，你会发现它有一个鲜明特征：查询高频、单次很轻、并发极高。一个实时看板，几十个指标卡，每个几秒刷新一次，背后是几百个小查询在不断轰炸。这类负载在数据工程团队私下吐槽里有个形象说法——『薄利多销的反面：单笔很便宜，架不住笔笔都来』。

而两种平台对此的回应方式截然不同。以 BigQuery 为代表的这类托管分析服务，主流计费逻辑与扫描的数据量挂钩——查询触及多少数据，就按量付钱。这个模型在低频、重型的离线分析里很优雅：不用了不花钱，用多少付多少。但放进实时分析场景，公式就变形了：查询越频繁、并发越高，同样的数据被反复扫描的次数就越多，成本随之线性甚至超线性放大。数据没有被计算变重，是被『重复读』变贵了。

ClickHouse Cloud 这类引擎的计费逻辑则接近传统数据库：为持续运行的算力付费。它的设计目标恰恰是让单个查询尽可能少碰数据——靠预聚合、靠索引、靠局部性，把每次扫描的量压到最小。代价是你要为常驻资源买单，收益是边际查询几乎不再推高账单。

两种模型没有绝对优劣，但实时分析这个负载，天然站在按算力计费这一边。438倍的差距，相当一部分是账单结构性的，而不是引擎执行力的悬殊。

🔧 从数据落地到答案返回，两条路线

再往架构深处走一层。把整条数据链路画出来，两种平台的分野一目了然：

ClickHouse 这一路的打法，可以用三个词概括：本地、预聚合、向量化。数据写入本地节点的列式存储，配合物化视图在写入时就完成聚合，查询到来时大量工作已经做完，剩下的只是扫一小片高度浓缩的数据。向量化执行引擎再把这些少量数据的处理速度推向极致。它假设的是：我知道我的查询长什么样，我愿意在写入时多花功夫，换取读取时的极致便宜。

BigQuery 这一路则是另一套哲学：存算彻底分离，数据放远端共享存储，算力池按需分配，用户完全不感知机器。它的优雅在于『什么都不用管』，但实时场景下，免运维的另一面是：查询与数据之间的物理距离、查询之间缺乏共享的中间状态、以及每次执行都要重新面对全量明细的默认姿态。数据工程圈私下有个总结很传神——一个把功夫花在查询前，一个把功夫花在查询时；实时负载下，查询前花功夫的赢。

这就是438倍被逐段拆开后露出的结构性真相：差距不是在某个环节突然拉开的，而是在写入时就埋下、在计费时被放大的。架构哲学不同，天生擅长回答的问题就不同。

⚠️ 438倍之外，别急着宣判谁出局

看到这里，很容易得出『BigQuery要完了』的结论。恰恰相反，这是最容易犯的误读。

回到 CostBench 的测试边界：它比的是实时分析这一个细分负载。而 BigQuery 所代表的云数仓形态，面对的是另一大类工作负载——跨部门的一次性即席查询、TB级到PB级的重型离线扫描、与整个云生态绑定的数据工程流水线。在这些场景里，按扫描计费的『用多少付多少』依然成立，免运维的价值依然真实。一家公司的分析师一年跑不了几次超大查询，为这些查询常驻一套算力，反而是浪费。

真正的判断应该是：实时分析正在从数据平台这个大类里裂变出来，成为一个独立的战场，而通用数仓在这个战场上打不了歼灭战。负载越实时、查询越碎片化、并发越高，专用引擎的结构性优势就越大。这也解释了为什么近年专用OLAP引擎在可观测性、用户行为分析、实时风控这些场景攻城略地——它们不是在替代数仓，是在数仓够不着的缝隙里长成大树。

对采购者，这段公案的启示可以浓缩成三句话：先画清自己的负载画像，再选计费模型；别用一套平台回答所有问题，混搭不丢人；看任何基准，先看它测的是什么负载——438倍是真实的，但它是属于实时分析的那个真实。

438倍这个数字的价值，不在帮 ClickHouse Cloud 赢下一次对比，而在逼整个行业直面一个问题：通用性是有价格的，实时性是有架构的。接下来值得盯的是——云数仓厂商会否为实时负载推出更贴合的计费与预聚合能力，以及专用引擎与湖仓生态的融合能走多远。裂缝已经出现，补缝的动作不会太远。