作者：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 计费模型的一个根本性缺陷。
如果你在跑大规模的数据工作负载，一定要搞清楚自己到底是怎么被收费的------因为云服务的收费方式，远远不是你想的那样。