亮点

是的，你没看错。不到半分钟，10,000美元（约69,000人民币）就被烧光了。

并不是因为低效的查询。也不是因为计算资源使用过高。而是因为一种极其荒谬的价格体系，大多数工程师甚至都没有意识到这一点。

如果你使用 BigQuery，你可能在不知不觉中花冤枉钱。

上个月，我们帮助一位客户构建数据管道时，只是一个简单的任务——从大型公开表中抽取基本数据样本。考虑到数据集的规模，我们采取了一些预防措施。

• 使用了 LIMIT 语句将结果限制为 100K 行
• 查询瞬间完成，一切正常
• 反复运行了三次查询

查询详情如下

    导出数据：  
    选项： (  
        uri = 'gs://xxxxx/*.json',  
        格式 = 'JSON',  
        覆盖 = true)  
    作为： (  
        SELECT *  
        FROM bigquery-public-data.crypto_solana_xxxxx.Instructions  
        LIMIT 1000000;  
    );

此查询从 **crypto_solana** 数据集中的 **Instructions** 表中导出 100 万行 数据，并将这些数据以 JSON 格式存储到 Google Cloud Storage 存储桶中。

🔥🔥 BigQuery 竟然向我们收取了近 10,000 美元。 🔥🔥
🔥🔥 仅三个查询。扫描了 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 是最先进的一流云数据仓库之一。它拥有业界一些最好的查询优化功能。绝对不可能它只是为了返回 limit 查询的 100K 行数据就扫描了 509 TB 的数据。它怎么可能只是为了返回 limit 查询的 100K 行数据就扫描了 509 TB 的数据呢？

当时到底在搞什么？

在咨询了谷歌的朋友之后，我们发现了这个陷阱的真相。

BigQuery 不是根据处理的数据来收费，而是根据引用的数据量来收费。真的！

再看一遍。

显然，GCP 显然知道自己在做什么——就算这完全说不通！

如果你的查询触及一个1PB的表，哪怕它只返回几MB，BigQuery仍然按整个1PB的数据来计费。

这与其他云数据仓库处理查询的方式来看，完全不同之处。

要理解 BigQuery 的定价模型有多么离谱，我们来看看 LIMIT 在 Redshift、Snowflake 和 Databricks 中的行为。

例如 AWS Redshift、Snowflake 和 Databricks 这样的现代云数据仓库，利用了列式存储和谓词提前技术。

• 列式存储：这可以减少数据扫描量，只读取相关列。
• 谓词下推：将过滤条件（如 LIMIT, WHERE）尽可能提前应用，以优化查询执行。
• 分区裁剪：如果表是按日期等条件分区的，就只会扫描相关的分区。

比如说，在 Redshift、Snowflake 和 Databricks 中，当你运行：

从 huge_table (大表) 中选择前100条记录。

• 系统检索100行后停止，这样可以降低计算成本。

• 仅扫描必要的数据，费用仅根据实际使用的数据来计算。

不过，BigQuery 采取了截然不同的方法：

• 费用是根据总引用的数据量来计算的，而不是实际扫描的数据量。
• LIMIT 不会减少计费的数据量——如果你的查询涉及一个大表，你将被计费整个表的费用。
• 分区修剪是不可预测的——查询仍可能扫描整个表并计费整个表的大小。

比如说，运行这个查询。

    SELECT * FROM huge_table LIMIT 100;

此命令从 huge_table 表中选择前100条记录。

• 即使只返回了100行，你也得按扫描整个表来付费。
• 如果表的大小是1 PB，你将被收取1 PB的数据扫描费用。
• 过滤没用，只要用了这张表，你就得为此付钱。

在 BigQuery 中，查询优化不一定如你预期。与其它云端数据仓库不同，例如使用 LIMIT 语句的传统技术，并不一定能减少成本。只需几毫秒就完成的查询仍然可能带来高昂的账单。

这与常识相悖——其他每一家主要的云供应商都是根据实际处理过的数据来收费，而不是根据所有涉及的表。但在BigQuery中，计费与查询触及的所有数据相关联，迫使工程师以一种不符合直觉的方式重新思考成本计算。

结果？你可以很快就把云信用光了。许多团队认为 GCP 的免费额度能用几个月，却发现一个错误的查询就能一夜之间把它们耗光。

BigQuery这只是众多例子中的一个。云服务提供商喜欢用这样的“看似低成本”的定价模式来吸引用户，先随后却开始收取各种隐形费用。

• 存储便宜，但计算成本高昂。
• 标榜的费用是每TB扫描，但“scan”并不像你想象的那样。
• 云厂商依赖工程师不会仔细阅读细则。

这就是为什么很多公司经常会遇到意料之外的云账单——定价模式被设计得让人难以理解。

如果你在使用 BigQuery，建议你马上查看账单报告。为了不踩到云服务定价的坑，你可以注意以下几点：

• 探索成本效益高的替代方案，例如 Redshift、Snowflake 或 Databricks
• 使用像 Iceberg 这样的开放格式以防止供应商锁定
• 扩展查询前先进行成本模拟

这不仅仅是一个一时的错误，而是 BigQuery 定价模型中存在一个根本性的问题。

如果你在处理大规模数据任务，你需要清楚云是如何计费的，因为云的计费方式并不总是像你想象的那样。