超碰人人人人人,色婷婷综合久久久久中文一区二区,国产-第1页-浮力影院,欧美老妇另类久久久久久

作者：Yingjun Wu

是的，你沒看錯(cuò)。不到半分鐘，1 萬美元灰飛煙滅。
不是因?yàn)椴樵冃实拖隆?br>不是因?yàn)橛?jì)算資源用得太多。
而是因?yàn)橐粋€(gè)完全荒謬的計(jì)費(fèi)模式，而且大多數(shù)工程師甚至都不知道它存在。
如果你在用 BigQuery，你很可能正在悄悄流血燒錢而毫不自知。

背景：一個(gè)簡(jiǎn)單的查詢——我們?cè)詾槭沁@樣
上個(gè)月，我們?cè)趲鸵粋€(gè)客戶搭建數(shù)據(jù)流水線。沒啥復(fù)雜的東西——只是從一個(gè)大型公共表中做個(gè)基礎(chǔ)的數(shù)據(jù)抽樣任務(wù)?？紤]到數(shù)據(jù)集的規(guī)模，我們做了一些預(yù)防措施：

• 用了 LIMIT 語句限制結(jié)果為 10 萬行
• 查詢瞬間完成——看起來一切正常
• 我們跑了這個(gè)查詢?nèi)?/li>

查詢的具體內(nèi)容如下：

EXPORT DATA

OPTIONS (

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

format = 'JSON',

overwrite = true)

AS (

SELECT *

FROM bigquery-public-data.crypto_solana_xxxxx.Instructions

LIMIT 1000000

);

這個(gè)查詢會(huì)從 crypto_solana 數(shù)據(jù)集的 Instructions 表中導(dǎo)出 1,000,000 行數(shù)據(jù)（BigQuery 的公共數(shù)據(jù)集里），以 JSON 格式導(dǎo)出到一個(gè) Google Cloud Storage 的 bucket 里。

賬單來了：三次查詢花了 $9,847.24？！
???? BigQuery 向我們收了將近一萬美元。????
???? 三次查詢。1,576.56 TB 的數(shù)據(jù)被“掃描”。????

我們的賬單截圖顯示，我們?cè)?22 秒內(nèi)“掃描”了 509.89 TB 的數(shù)據(jù)！

我們的賬單截圖顯示，我們因掃描了 1,576.56 TB 的數(shù)據(jù)被收了 $9,847.24！

這到底怎么回事？！
成本明細(xì)更離譜：

• 總共“掃描”的數(shù)據(jù)：三次查詢總計(jì) 1,576.56 TB
• 每次查詢，盡管用了 LIMIT，卻都被計(jì)費(fèi)為掃描了 509.89 TB
• 查詢運(yùn)行了 22 秒——也就是說每秒掃描了 23 TB？！

我們當(dāng)時(shí)都傻了。

真相：BigQuery 的隱藏計(jì)費(fèi)模型
BigQuery 是最先進(jìn)的云數(shù)據(jù)倉(cāng)之一。它的查詢優(yōu)化在業(yè)內(nèi)數(shù)一數(shù)二。不可能只是為了返回 LIMIT 的 10 萬行數(shù)據(jù)就真的掃描了 509 TB。

那到底怎么回事？

我們?nèi)柫嗽?Google 的朋友，結(jié)果揭開了這個(gè)陷阱：
BigQuery 不是按“處理的數(shù)據(jù)量”計(jì)費(fèi)，而是按“引用的數(shù)據(jù)量”計(jì)費(fèi)?。?！
請(qǐng)你再讀一遍。

顯然，GCP 自己心里有數(shù)——即便這邏輯完全說不通！

如果你的查詢“碰”到了一個(gè) 1 PB 的表，即使你只返回了幾 MB 的數(shù)據(jù)，BigQuery 也會(huì)按你掃描了整個(gè) 1 PB 來收費(fèi)。

這跟其他云數(shù)據(jù)倉(cāng)的處理方式完全不一樣。

其他數(shù)據(jù)倉(cāng)是怎么處理的？
為了更直觀地說明 BigQuery 的計(jì)費(fèi)有多離譜，我們來看看 LIMIT 在 Redshift、Snowflake 和 Databricks 中是怎么工作的。

現(xiàn)代云數(shù)據(jù)倉(cāng)（比如 AWS Redshift、Snowflake、Databricks）利用列式存儲(chǔ)和謂詞下推（Predicate Pushdown）等優(yōu)化技術(shù)：

• 列式存儲(chǔ)：只讀取相關(guān)列，盡量減少掃描數(shù)據(jù)量
• 謂詞下推：過濾條件（LIMIT、WHERE）盡可能早地應(yīng)用在查詢過程中
• 分區(qū)剪枝：如果表按日期等字段分區(qū)，只掃描相關(guān)分區(qū)

例如，在 Redshift、Snowflake 和 Databricks 中，你執(zhí)行：

SELECT * FROM huge_table LIMIT 100;

• 系統(tǒng)會(huì)取出 100 行然后停止，節(jié)省計(jì)算資源
• 只掃描必要的數(shù)據(jù)，費(fèi)用按實(shí)際使用計(jì)算

而 BigQuery 完全不是這么回事：

• 它按“引用數(shù)據(jù)總量”收費(fèi)，而不是“實(shí)際掃描數(shù)據(jù)”
• LIMIT 并不會(huì)減少計(jì)費(fèi)數(shù)據(jù)量——你的查詢只要“碰”到了大表，你就得為整個(gè)表買單
• 分區(qū)剪枝是否生效不可預(yù)測(cè)——你可能還是會(huì)被算整個(gè)表的費(fèi)用

舉個(gè)例子，執(zhí)行下面這個(gè)查詢：

SELECT * FROM huge_table LIMIT 100;

• 即使只返回了 100 行，你也要按整個(gè)表掃描來付費(fèi)
• 如果這個(gè)表有 1 PB，那你就得為掃描 1 PB 付費(fèi)
• 加不加過濾條件沒用——只要你引用了表，你就得掏錢

工程師的噩夢(mèng)
BigQuery 的查詢優(yōu)化跟你想象的不一樣。跟其他主流云數(shù)據(jù)倉(cāng)不同，傳統(tǒng)技巧比如 LIMIT 并不一定能降低成本。一個(gè)執(zhí)行時(shí)間只有幾毫秒的查詢，可能會(huì)讓你賬單爆炸。

這簡(jiǎn)直違反常識(shí)——其他云廠商都是按“實(shí)際處理的數(shù)據(jù)”收費(fèi)，而不是按“引用的總表大小”。但 BigQuery 的賬單，是綁定到你的查詢“碰到”的整個(gè)數(shù)據(jù)集上的，這讓工程師在估算成本時(shí)完全抓瞎。

結(jié)果是什么？你的云積分分分鐘燒光。很多團(tuán)隊(duì)以為 GCP 的免費(fèi)額度能撐好幾個(gè)月，結(jié)果一個(gè)糟糕的查詢，幾個(gè)小時(shí)就燒完了。

云計(jì)費(fèi)：一個(gè)赤裸裸的陷阱
BigQuery 只是其中一個(gè)例子。云服務(wù)商最喜歡用“低成本”的說法來吸引用戶，然后在細(xì)節(jié)里埋藏隱形費(fèi)用。

• 存儲(chǔ)便宜，計(jì)算昂貴
• 廣告上說的是“每 TB 掃描費(fèi)用”，但“掃描”根本不是你以為的意思
• 云廠商賭的就是工程師不會(huì)認(rèn)真讀計(jì)費(fèi)條款

這也是為什么很多公司會(huì)收到莫名其妙的巨額云賬單——這些定價(jià)策略本來就是設(shè)計(jì)得不透明又容易誤導(dǎo)。

最后的話
如果你在用 BigQuery，趕緊去看你的賬單報(bào)告。想要避開這些云計(jì)費(fèi)陷阱，可以考慮：

• 去看看性價(jià)比更高的替代方案，比如 Redshift、Snowflake 或 Databricks
• 用 Iceberg 這樣的開放格式，避免被廠商鎖死
• 在查詢放大之前先做成本模擬

這不是一次性的小錯(cuò)誤。這是 BigQuery 計(jì)費(fèi)模型的一個(gè)根本性缺陷。

如果你在跑大規(guī)模的數(shù)據(jù)工作負(fù)載，一定要搞清楚自己到底是怎么被收費(fèi)的——因?yàn)樵品?wù)的收費(fèi)方式，遠(yuǎn)遠(yuǎn)不是你想的那樣。

?轉(zhuǎn)自https://juejin.cn/post/7490977437674373155