💡 先搞懂問題
虛構公司「晴空食品」把三年來的訂單都放進 BigQuery 的一張 orders 資料表，每天新增約 500 萬筆，整張表已經到 1.5 TiB 左右（示意）。行銷分析師每天早上要看「上週各門市營收」，習慣先 SELECT * … LIMIT 100 瞄一下資料，再寫正式查詢。月底帳單出來，處理量高得嚇人：每一支查詢都掃過了整張表。
原因在 BigQuery 的隨選計價（on-demand pricing）：運算費依查詢處理的位元組（bytes processed）計算，看的是「讀了多少資料」，不是「回傳多少列」。新手最常卡在四個地方：以為加了 LIMIT 就只付 100 列的錢；以為 WHERE 篩掉的資料就不算錢；不知道 BigQuery 是欄式儲存（columnar storage），每個欄位分開存放，SELECT * 等於把每個欄位都讀一遍；也分不清分區（partitioning）和叢集（clustering）各自在省什麼。
這一頁的主角就是這兩個設定。分區把資料表依日期（或整數範圍）切成很多段，查詢條件有篩分區欄位時，BigQuery 只讀相關的分區，這叫分區修剪（partition pruning）；叢集讓資料在儲存時依指定欄位排序，查詢篩這些欄位時可以跳過不相符的資料區塊，這叫區塊修剪（block pruning）。再加上只選需要的欄位、執行前先試算（dry run），大部分「掃整張表」的帳單問題都能解決。
生活比喻：按年份分櫃、櫃內依作者排序的付費檔案室
想像一間收費的報刊檔案室，計費方式很特別：不管你最後抄了幾行，都依「翻過幾頁」收錢。最笨的找法是把整間檔案室每一本都從頭翻到尾。聰明的檔案室會做三件事。第一，每本刊物把「目錄」「財經版」「副刊」分開裝訂，你只要財經數字，就只翻財經那一冊，不用連副刊一起翻。第二，依年份與月份分成不同的櫃子，要找上週的資料，只打開上週那幾個櫃子。第三，每個櫃子裡再依作者姓名排好，要找某位作者時，直接翻到那一段，前後不相干的部分不用碰。
櫃台還有兩個規矩：進去之前可以先問館員「照這張借閱單，大概要翻幾頁」，館員不收費就能估出來；有些櫃子貼著「沒寫年份的借閱單不受理」，免得有人不小心把整間都翻一遍。
這個比喻有三個地方和實際不同。第一，檔案室是「翻到哪頁算到哪頁」，BigQuery 則是在被讀到的分區裡，選到的欄位整欄都算：WHERE store_id = 'TPE012' 篩掉的列，如果資料表沒有依 store_id 叢集，照樣要讀過才能篩掉，一樣算錢。第二，館員能精準告訴你要翻幾個櫃子，但叢集是「排序後跳過區塊」，執行前無法精準知道能跳過多少，所以對叢集資料表的試算只是上限，實際計費可能比較少。第三，櫃子分得越細不一定越好：BigQuery 每張資料表最多 10,000 個分區，每個分區太小（官方以約 10 GB 為參考）時，管理負擔變大、效益反而不如叢集。
🎮 互動實驗室一：查詢掃描量計算器
晴空食品的 orders 資料表有 10 個欄位、三年共 1,096 天、每天 500 萬筆，每列平均約 302 位元組（示意，依 BigQuery 的資料型別大小估算：DATE、TIMESTAMP、INT64 各 8 位元組，NUMERIC 16 位元組，STRING 為 2 位元組加文字長度）。請切換資料表設計（要不要依日期分區、要不要依門市叢集）與查詢寫法（日期範圍、SELECT * 或指定欄位、看全部或單一門市、有沒有 LIMIT），右邊即時算出試算會顯示的處理量、實際計費的處理量，以及用示意單價（每 TiB 100 點）換算的成本。示意單價不是實際價格，實際費用請以 BigQuery 定價頁與 Google Cloud Pricing Calculator 為準。每個情境下方有一題「先猜再看」。
一、資料表設計與查詢寫法
二、計算結果
叢集修剪：只看 1 家門市且依 store_id 叢集時，示意為只需讀約 2% 的區塊
示意成本 ＝ 處理量（TiB）× 100 點；每個被引用的資料表至少以 10 MB 計
隨選計價 vs Editions 容量計價：同一支查詢在兩種模式下怎麼算
先猜再看
規則查證：2026 年 10 月，依 BigQuery 官方文件（隨選計價依所選欄位的資料量計費、即使有 LIMIT 也一樣；叢集資料表的 LIMIT 可能讓掃描提早停止；叢集資料表的試算是上限；每個被引用的資料表與每支查詢至少以 10 MB 計）。資料量、2% 的叢集修剪比例與每 TiB 100 點都是示意；真實的修剪效果取決於資料分布與區塊大小。
🎮 互動實驗室二：最佳化手段分診台
每張卡是一個虛構公司的需求，請從九個選項裡挑出最直接解決問題的一個：三種分區（時間單位欄位、擷取時間、整數範圍）、叢集、具體化檢視表、BI Engine、Editions 預留、BigQuery sharing（原 Analytics Hub），或外部資料表／Lakehouse。答完會說明理由；選錯時會告訴你你選的那一項在做什麼、為什麼不是這題的答案。下方（桌機在右邊）的對照卡會亮起這題用得到的事實。
事實查證：2026 年 10 月，依 BigQuery 官方文件（分區類型與「分區平均 10 GB 以上才划算」的建議、每張資料表最多 10,000 個分區、叢集最多 4 欄、editions 功能差異、BigQuery sharing 與 Lakehouse 文件）。BigQuery sharing 原名 Analytics Hub，Lakehouse 原名 BigLake（2026-04-20 改名），考試大綱可能仍寫舊名。
🛠️ 操作教學：建立分區叢集資料表，再試算查詢
不用登入 Google Cloud，也能先把流程走一遍。左邊是簡化的主控台：選專案、建立資料集、建立依日期分區並依門市叢集的資料表，再到查詢編輯器看預估處理量、設定最大計費位元組後執行；右邊同步顯示等效的 bq／gcloud 指令、Terraform 與 SQL（DDL），黃色底的那幾行就是目前這一步對應的寫法。你可以故意填錯看看驗證訊息，也可以改資料集 ID、位置、分區方式或叢集欄位，看三個分頁怎麼跟著變。
terraform destroy 會刪除這份設定建立的資源；資料表在 provider 裡預設開啟 deletion_protection，資料集刪除時若還有資料表會失敗，範例為了練習分別設成 false 與 delete_contents_on_destroy = true，正式環境請三思。想讓 Google 代管 Terraform 的執行環境與 state，可以用 Infrastructure Manager；舊的 Cloud Deployment Manager 已在 2026 年 3 月底結束支援，新設計不要再用。
自己動手時要注意
權限：建立資料集需要專案層級的 bigquery.datasets.create 權限，例如 BigQuery 使用者（roles/bigquery.user，可以建立資料集並執行查詢工作）或 BigQuery 管理員（roles/bigquery.admin）；建立資料表與寫入資料需要資料集上的 BigQuery 資料編輯者（roles/bigquery.dataEditor）；只讀資料的人給 BigQuery 資料檢視者（roles/bigquery.dataViewer），要執行查詢還需要專案上的 BigQuery 工作使用者（roles/bigquery.jobUser）。依最小權限原則，把資料權限給在資料集上、查詢權限給在專案上。
API 與費用：BigQuery API 在新專案通常已預設啟用，沒有的話用 gcloud services enable bigquery.googleapis.com。BigQuery 每月有免費額度：查詢處理前 1 TiB、儲存前 10 GiB（以帳單帳戶計算，查證日期 2026-10-08）；超過後依隨選或 editions 計價，儲存另外計費，資料表或分區連續 90 天沒有修改會自動轉為長期儲存、價格約降一半。新帳戶的 Free Trial 是 90 天、300 美元抵用金。練習時建議替查詢設定最大計費位元組，或在專案設定每日查詢用量配額，避免意外的大查詢。
練習完怎麼刪：刪除資料集時加上 -r 會連同裡面的資料表一起刪；整個專案只拿來練習時，刪除專案最乾淨。
# 刪除練習用資料集（-r 連同資料表一起刪，-f 不再詢問確認）
bq rm -r -f -d my-project-id:qingkong_sales
# 用 Terraform 建立的就用 Terraform 刪
terraform destroy
# 整個專案只拿來練習時，刪除專案最乾淨（PROJECT_ID 換成你的專案 ID）
gcloud projects delete PROJECT_ID範例裡的專案 ID 與資料都是佔位或示意。不要把服務帳戶金鑰寫進排程腳本或筆記本：自己操作用 gcloud auth login 的使用者憑證；排程查詢、Dataflow 或 Cloud Run 這些執行環境直接用附加的服務帳戶身分；從外部 CI/CD 或其他雲端存取 BigQuery，用 Workload Identity Federation 換取短期憑證，不要下載服務帳戶金鑰。
AWS 服務地圖：Amazon Redshift ↗ AWS 服務地圖：Amazon Athena ↗ Azure 服務地圖：Microsoft Fabric ↗
📘 原理補完
BigQuery 怎麼算錢：儲存和運算分開計
BigQuery 是無伺服器的資料倉儲，儲存層和運算層分開，帳單也分成兩塊。儲存依資料量計費，資料表或分區連續 90 天沒有被修改，就自動轉為長期儲存，價格約降一半、效能不變；這也是分區的附帶好處之一，舊分區可以各自進入長期儲存。運算（分析）有兩種模式：隨選依查詢處理的 TiB 計費，每月前 1 TiB 免費；editions 依 slot（BigQuery 的虛擬運算單位）的使用時數計費。兩種模式可以依專案混用。
隨選模式的處理量有幾條規則要記住：依所選欄位的資料量計算，每個欄位的大小依資料型別而定；即使加了 LIMIT 也照選到的欄位計費（沒有叢集的資料表完全不會因此少讀；叢集資料表的 LIMIT 可能讓掃描提早停止）；每個被引用的資料表、每支查詢至少以 10 MB 計；命中快取的查詢與失敗的查詢不收費；查詢別人分享給你的資料，由執行查詢的一方付費。
三種分區
分區是資料表層級的設定，查詢條件篩到分區欄位時，BigQuery 只讀符合的分區，而且在執行前就能精準知道要讀哪些分區，所以試算很準。三種類型：時間單位欄位分區依資料本身的 DATE、TIMESTAMP 或 DATETIME 欄位切分（以 UTC 計），TIMESTAMP 與 DATETIME 可以選每小時、每日、每月、每年，DATE 欄位只能每日、每月、每年；擷取時間分區依資料寫進 BigQuery 的時間切分，查詢用 _PARTITIONTIME 或 _PARTITIONDATE 虛擬欄位篩選；整數範圍分區依 INT64 欄位切分，要指定起點、終點與間隔。每張資料表最多 10,000 個分區（查證時間 2026 年 10 月），可以替分區設定到期時間自動刪除舊資料，也可以啟用要求分區篩選器。
叢集：在分區裡再依欄位排序
叢集讓資料依最多 4 個欄位排序存放在儲存區塊裡。查詢篩這些欄位時，BigQuery 用區塊的中繼資料判斷哪些區塊不可能有符合的資料，直接跳過。欄位順序有意義：先依第一個欄位排序，再依第二個，所以最常篩選或彙總的欄位放第一個；只篩第二個欄位時效果會打折。叢集欄位必須是頂層、非重複的欄位，可以用 STRING、INT64、DATE、TIMESTAMP、NUMERIC 等型別。資料持續寫入後，BigQuery 會在背景自動重新叢集，不另外收費；建立後也可以修改叢集欄位。叢集可以單獨使用，也可以和分區一起用：先分區，每個分區內再叢集。
分區和叢集怎麼選
官方的建議是：一般情況先考慮叢集；以下情況才用分區（可以再加叢集）：需要在查詢執行前精準估算費用、每個分區平均至少約 10 GB、想要整個分區到期或刪除、想讓舊分區各自適用長期儲存價格。反過來，分區會太小、篩選欄位基數很高（例如客戶編號）、常同時篩好幾個欄位、DML 常常改動大部分分區時，叢集比較合適。下表整理差異（查證時間 2026 年 10 月）：
| 比較 | 分區 | 叢集 |
|---|---|---|
| 依什麼組織 | 一個欄位（時間單位、擷取時間或整數範圍） | 最多 4 個欄位，依順序排序 |
| 省讀取的方式 | 分區修剪：只讀符合的分區 | 區塊修剪：跳過不可能符合的區塊 |
| 試算準不準 | 精準：執行前就知道讀哪些分區 | 只是上限：實際可能更少 |
| 數量限制 | 每張資料表最多 10,000 個分區 | 沒有分區數的問題，適合高基數欄位 |
| 資料生命週期 | 可設分區到期、可整個分區刪除，舊分區各自進入長期儲存 | 沒有依叢集值到期的機制 |
| 防呆 | 可要求分區篩選器 | 沒有對應的強制條件 |
| 適合 | 常篩日期、每段資料量大、要依時間管理資料 | 高基數、多欄位條件、分區會太小 |
還有一種常見但不建議的做法：依日期分片成很多張表（例如 orders_20260930），再用萬用字元查詢。每張分片表都有自己的結構定義與中繼資料，BigQuery 要逐一檢查權限與結構，管理與效能都不如一張分區資料表，官方建議改用分區資料表。
防呆：讓「掃整張表」很難發生
技術上能省，還要讓人不會不小心花錢。資料表層級用要求分區篩選器：查詢沒有可用於修剪分區的條件就直接被拒絕。查詢層級用最大計費位元組（bq 的 --maximum_bytes_billed、控制台的查詢設定）：預估超過上限的查詢直接失敗、不收費，但叢集資料表的預估是上限，設太緊可能擋下其實很便宜的查詢。專案或使用者層級可以設定每日查詢用量的自訂配額。另外，想看資料長什麼樣子，用資料表的「預覽」分頁，不要用 SELECT * … LIMIT。
隨選還是 editions
隨選適合用量小、不固定、剛起步的團隊：不用規劃容量，用多少算多少，每月前 1 TiB 免費。用量大而且穩定時，可以改用 BigQuery editions：以 slot 的使用時數計費，透過預留（reservation）把容量分配給專案，預設最少計 1 分鐘。三個版本：Standard 只能自動擴縮、單一預留最多 1,600 slots、不能買容量承諾，沒有 BigQuery ML、BI Engine、continuous queries，月 SLO 99.9%；Enterprise 可設基準容量加自動擴縮，可買 1 年（20% 折扣）或 3 年（40% 折扣）承諾，有 BigQuery ML、BI Engine、continuous queries，99.99%；Enterprise Plus 再加受管災難復原與 Assured Workloads 合規控制。要改預留的版本，必須刪除再重建預留。不論哪種模式，讀得少都會跑得快：隨選直接少付錢，editions 則是少用 slot 時間、讓同一份容量做更多事。
其他最佳化工具各解決什麼
具體化檢視表（materialized view）預先計算並保存查詢結果，最常見的是彙總；基礎資料變動時 BigQuery 在背景重新整理，同一個彙總被反覆查詢時，不必每次重掃原始資料。BI Engine 是記憶體內的分析加速服務，替儀表板這類反覆、互動式的查詢縮短回應時間，Standard edition 沒有。BigQuery sharing（原 Analytics Hub）處理「把資料給別的組織或部門用」：建立交換與刊登項目，訂閱者拿到唯讀的連結資料集，不複製資料、永遠是最新版，發布者付儲存費、訂閱者付自己的查詢費，可以設定外流限制。外部資料表與 Lakehouse（原 BigLake，2026-04-20 改名）資料表讓 BigQuery 直接查 Cloud Storage 上的檔案，資料不必載入；Lakehouse 以 Apache Iceberg 等開放格式讓 BigQuery、Spark 等引擎共用同一份資料與目錄，並套用一致的存取控制。代價是部分功能與效能不如原生資料表。如果是要做機器學習，資料已經在 BigQuery 裡，BigQuery ML 可以直接用 SQL 建模，不必把資料搬出去。
判斷步驟
- 先看查詢寫法：只選需要的欄位（或 SELECT * EXCEPT），不要用 LIMIT 控制成本，執行前先試算。
- 看最常用的篩選條件：有可靠的日期欄位、每天資料量大，就依它做時間單位欄位分區；沒有可靠時間欄位、在乎寫入時間，用擷取時間分區；依整數編號範圍管理，用整數範圍分區。
- 分區會太小（平均遠低於約 10 GB）、篩選欄位基數高或要同時篩多個欄位，改用或加上叢集，最常篩的欄位放第一個，最多 4 個。
- 加上防呆：分區資料表啟用要求分區篩選器，查詢設最大計費位元組，必要時設定每日查詢配額。
- 同一個彙總反覆計算，用具體化檢視表；儀表板要互動延遲，用 BI Engine；用量大而穩定、想要可預測帳單，評估 Enterprise edition 預留與承諾。
- 資料要給其他組織用，選 BigQuery sharing；資料要留在 Cloud Storage 並給多個引擎共用，選外部資料表或 Lakehouse。
容易考錯的地方
LIMIT 省錢：這是最常見的干擾選項。沒有叢集的資料表，LIMIT 完全不減少讀取量；想控制成本靠的是欄位選擇、分區、叢集與計費上限。
WHERE 一定省錢：只有條件落在分區欄位（分區修剪）或叢集欄位（區塊修剪）上才會少讀。篩一般欄位只會少回傳結果，不會少讀；而且 WHERE 用到的欄位本身也要讀。
高基數欄位拿來分區：客戶編號、訂單編號這種數百萬種值的欄位，不可能每個值一個分區（上限 10,000 個），答案通常是叢集。反過來，每天資料很小卻依日期每日分區，也是官方不建議的設計。
DATE 欄位每小時分區：DATE 欄位只能每日、每月、每年；要每小時分區得用 TIMESTAMP 或 DATETIME 欄位，或擷取時間分區。
試算數字就是帳單數字：分區資料表的試算很準，叢集資料表的試算是上限。題目問「為什麼實際費用比預估少」，答案通常是叢集的區塊修剪。
Editions 能減少讀取量：editions 改變的是計價方式，不會讓查詢少讀資料；「查詢太慢太貴」先處理分區與叢集，「帳單不可預測」才是 editions 的題目。另外 Standard edition 沒有 BigQuery ML 與 BI Engine、不能買承諾，這是常見的細節題。
舊名：考試大綱與舊教材可能寫 Analytics Hub（現稱 BigQuery sharing）、BigLake（現稱 Lakehouse）、Looker Studio（現稱 Data Studio）、Dataplex（Knowledge Catalog），指的都是現行產品。
相關考試：PDE 大綱點名 BigQuery、BigQuery Editions 與 reservations、BigQuery sharing（Analytics Hub）、BI Engine 與 BigLake（現稱 Lakehouse），是這一頁最直接對應的考試；ADP 考 BigQuery 的查詢分析、BigQuery ML 與資料分享；ACE 會考 BigQuery 工作狀態與成本估算這類操作面的題目。
✅ 自我檢測
6 題原創題，選完立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6