公交车上荫蒂添的好舒服的电影-公用玩物(np双xing总受)-公用小荡货芊芊-公与妇仑乱hd-攻把受做哭边走边肉楼梯play-古装一级淫片a免费播放口

作者：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