作者：Yingjun Wu

是的，你没看错。不到半分钟，1 万美元灰飞烟灭。
不是因为查询效率低下。
不是因为计算资源用得太多。
而是因为一个完全荒谬的计费模式，而且大多数工程师甚至都不知道它存在。
如果你在用 BigQuery，你很可能正在悄悄流血烧钱而毫不自知。

背景：一个简单的查询——我们原以为是这样
上个月，我们在帮一个客户搭建数据流水线。没啥复杂的东西——只是从一个大型公共表中做个基础的数据抽样任务。考虑到数据集的规模，我们做了一些预防措施：

• 用了 LIMIT 语句限制结果为 10 万行
• 查询瞬间完成——看起来一切正常
• 我们跑了这个查询三次

查询的具体内容如下：

EXPORT DATA

OPTIONS (

uri = 'gs://xxxxx/*.json',

format = 'JSON',

overwrite = true)

AS (

SELECT *

FROM bigquery-public-data.crypto_solana_xxxxx.Instructions

LIMIT 1000000

);

这个查询会从 crypto_solana 数据集的 Instructions 表中导出 1,000,000 行数据（BigQuery 的公共数据集里），以 JSON 格式导出到一个 Google Cloud Storage 的 bucket 里。

账单来了：三次查询花了 $9,847.24？！
🔥🔥 BigQuery 向我们收了将近一万美元。🔥🔥
🔥🔥 三次查询。1,576.56 TB 的数据被“扫描”。🔥🔥

我们的账单截图显示，我们在 22 秒内“扫描”了 509.89 TB 的数据！

我们的账单截图显示，我们因扫描了 1,576.56 TB 的数据被收了 $9,847.24！

这到底怎么回事？！
成本明细更离谱：

• 总共“扫描”的数据：三次查询总计 1,576.56 TB
• 每次查询，尽管用了 LIMIT，却都被计费为扫描了 509.89 TB
• 查询运行了 22 秒——也就是说每秒扫描了 23 TB？！

我们当时都傻了。

真相：BigQuery 的隐藏计费模型
BigQuery 是最先进的云数据仓之一。它的查询优化在业内数一数二。不可能只是为了返回 LIMIT 的 10 万行数据就真的扫描了 509 TB。

那到底怎么回事？

我们去问了在 Google 的朋友，结果揭开了这个陷阱：
BigQuery 不是按“处理的数据量”计费，而是按“引用的数据量”计费！！！
请你再读一遍。

显然，GCP 自己心里有数——即便这逻辑完全说不通！

如果你的查询“碰”到了一个 1 PB 的表，即使你只返回了几 MB 的数据，BigQuery 也会按你扫描了整个 1 PB 来收费。

这跟其他云数据仓的处理方式完全不一样。

其他数据仓是怎么处理的？
为了更直观地说明 BigQuery 的计费有多离谱，我们来看看 LIMIT 在 Redshift、Snowflake 和 Databricks 中是怎么工作的。

现代云数据仓（比如 AWS Redshift、Snowflake、Databricks）利用列式存储和谓词下推（Predicate Pushdown）等优化技术：

• 列式存储：只读取相关列，尽量减少扫描数据量
• 谓词下推：过滤条件（LIMIT、WHERE）尽可能早地应用在查询过程中
• 分区剪枝：如果表按日期等字段分区，只扫描相关分区

例如，在 Redshift、Snowflake 和 Databricks 中，你执行：

SELECT * FROM huge_table LIMIT 100;

• 系统会取出 100 行然后停止，节省计算资源
• 只扫描必要的数据，费用按实际使用计算

而 BigQuery 完全不是这么回事：

• 它按“引用数据总量”收费，而不是“实际扫描数据”
• LIMIT 并不会减少计费数据量——你的查询只要“碰”到了大表，你就得为整个表买单
• 分区剪枝是否生效不可预测——你可能还是会被算整个表的费用

举个例子，执行下面这个查询：

SELECT * FROM huge_table LIMIT 100;

• 即使只返回了 100 行，你也要按整个表扫描来付费
• 如果这个表有 1 PB，那你就得为扫描 1 PB 付费
• 加不加过滤条件没用——只要你引用了表，你就得掏钱

工程师的噩梦
BigQuery 的查询优化跟你想象的不一样。跟其他主流云数据仓不同，传统技巧比如 LIMIT 并不一定能降低成本。一个执行时间只有几毫秒的查询，可能会让你账单爆炸。

这简直违反常识——其他云厂商都是按“实际处理的数据”收费，而不是按“引用的总表大小”。但 BigQuery 的账单，是绑定到你的查询“碰到”的整个数据集上的，这让工程师在估算成本时完全抓瞎。

结果是什么？你的云积分分分钟烧光。很多团队以为 GCP 的免费额度能撑好几个月，结果一个糟糕的查询，几个小时就烧完了。

云计费：一个赤裸裸的陷阱
BigQuery 只是其中一个例子。云服务商最喜欢用“低成本”的说法来吸引用户，然后在细节里埋藏隐形费用。

• 存储便宜，计算昂贵
• 广告上说的是“每 TB 扫描费用”，但“扫描”根本不是你以为的意思
• 云厂商赌的就是工程师不会认真读计费条款

这也是为什么很多公司会收到莫名其妙的巨额云账单——这些定价策略本来就是设计得不透明又容易误导。

最后的话
如果你在用 BigQuery，赶紧去看你的账单报告。想要避开这些云计费陷阱，可以考虑：

• 去看看性价比更高的替代方案，比如 Redshift、Snowflake 或 Databricks
• 用 Iceberg 这样的开放格式，避免被厂商锁死
• 在查询放大之前先做成本模拟

这不是一次性的小错误。这是 BigQuery 计费模型的一个根本性缺陷。

如果你在跑大规模的数据工作负载，一定要搞清楚自己到底是怎么被收费的——因为云服务的收费方式，远远不是你想的那样。

​转自https://juejin.cn/post/7490977437674373155