GCP-113：Cloud Bigtable 入門——PB 級寬列 NoSQL 資料庫完全指南

前言

資料量一旦衝到 TB、甚至 PB 級，又要穩定的個位數毫秒延遲來扛 IoT 感測器數據、時序分析或推薦引擎，這時候 Cloud Bigtable 就很對味了。它跟 Google 搜尋、Google Maps、Gmail 背後跑的是同一套技術。

下面我們先搞懂 Bigtable 到底是什麼、什麼時候該用它，再一路把 Row Key 設計、複製、自動擴縮這些容易踩雷的地方動手走一遍。它是這套 GCP 入門課裡核心服務的一環（課程代碼 GCP-113），不用先學過前面的課也讀得下去。

---

什麼是 Cloud Bigtable？

Bigtable 是 GCP 的寬列型 NoSQL 資料庫（Wide-Column Store），就是為了超大規模、低延遲的讀寫而生的：

Row Key          │ Column Family: profile      │ Column Family: metrics
─────────────────┼─────────────────────────────┼──────────────────────
sensor#2026-03   │ name: "TempSensor-A"        │ temp: 25.3
                 │ location: "Taipei"          │ humidity: 78
─────────────────┼─────────────────────────────┼──────────────────────
sensor#2026-04   │ name: "TempSensor-A"        │ temp: 26.1
                 │ location: "Taipei"          │ humidity: 72

核心特性

• PB 級儲存，自動分片到多台伺服器
• 個位數毫秒延遲（SSD：p99 約 6ms）
• 線性擴展：加 Node 就加吞吐量
• HBase API 相容：從 HBase 遷移幾乎零成本

---

SSD vs HDD

特性	SSD	HDD
讀取延遲	6 ms（p99）	200 ms
寫入延遲	6 ms（p99）	50 ms
每 Node 讀取	~17,000 rows/s	~500 rows/s
每 Node 寫入	~14,000 rows/s	~10,000 rows/s
每 Node 掃描	~220 MB/s	~180 MB/s
每 Node 儲存	5 TB	16 TB
適合場景	即時查詢、線上服務	批次分析、大量儲存

以上數字假設每行 1 KB，實際效能取決於 Schema 設計和存取模式。

# 建立 SSD 叢集
gcloud bigtable instances create my-instance \
  --display-name="Production" \
  --cluster-config=id=my-cluster,zone=asia-east1-a,nodes=3,storage-type=SSD

# 建立 HDD 叢集（大量儲存場景）
gcloud bigtable instances create analytics-instance \
  --display-name="Analytics" \
  --cluster-config=id=analytics-cluster,zone=us-central1-a,nodes=3,storage-type=HDD

---

Row Key 設計——最關鍵的決策

Bigtable 是照 Row Key 的**字典序（lexicographic order，就是像查字典那樣一個字元一個字元比大小排）**存資料的，再依 Row Key 範圍自動切成一塊一塊，分散到不同的 Tablet Server（Bigtable 內部負責存放並服務某一段 Row Key 範圍的伺服器節點）。所以 Row Key 怎麼設計，幾乎決定了效能。

避免熱點（Hotspot）

❌ 不好的 Row Key 設計（造成熱點）：

  timestamp                  → 所有新寫入集中在最後一個分片
  monotonic-id (1, 2, 3...)  → 同上
  domain/url                 → 同一個網域的資料集中在一起

✅ 好的 Row Key 設計：

  反轉 domain + timestamp    → com.google#2026-03-11
  Hash prefix + entity       → a3f2#sensor-001
  Field promotion            → region#device#timestamp

💡 重點提點

為什麼熱點（Hotspot）這麼致命，新手一定要先想通：Bigtable 是靠把 Row Key 範圍切片、分散到很多台 Tablet Server 來「一起出力」的。如果你用時間戳或遞增 ID 開頭，所有最新的寫入都會落在字典序的「最後一段」，等於全部塞給同一台機器——你加再多 Node 都沒用，因為忙的永遠只有那一台，其他全在納涼。這是 Bigtable 最常見、也最貴的設計失誤。記住一句話就好：讓新資料盡量「散開」，不要「排隊」。

時序資料的最佳實踐

# IoT 感測器資料的 Row Key 設計
# 格式：device_id#reverse_timestamp
import struct, time

device_id = "sensor-taipei-001"
reverse_ts = struct.pack(">q", 2**63 - int(time.time() * 1000000))
row_key = f"{device_id}#{reverse_ts.hex()}"

# 這樣同一個 device 的最新資料會排在最前面
# 不同 device 的資料分散在不同分片

Field Promotion（欄位提升）

將常用的查詢維度提升到 Row Key 中：

原始：sensor-001#2026-03-11T10:00:00
提升：asia-east1#sensor-001#2026-03-11T10:00:00

好處：可以高效查詢 "asia-east1 區域的所有感測器資料"

---

Column Family 設計

什麼是 Column Family？

Column Family 就是一組相關欄位的容器。同一個 Column Family 的資料會放在一起，所以一起讀的時候比較快。

# 建立表格和 Column Family
cbt createtable sensors
cbt createfamily sensors profile
cbt createfamily sensors metrics
cbt createfamily sensors raw

# 寫入資料
cbt set sensors "sensor-001#2026" \
  profile:name="TempSensor" \
  profile:location="Taipei" \
  metrics:temp="25.3" \
  metrics:humidity="78"

設計原則

• 最多約 100 個 Column Family（這就是官方建議的上限，超過可能會拖累效能）
• 將經常一起讀取的欄位放同一個 Family
• 不同存取頻率的資料放不同 Family
• Column Family 名稱盡量簡短（佔用儲存空間）

---

垃圾回收（Garbage Collection）

Bigtable 的每個 Cell 都可以有多個版本（用時間戳區分）。垃圾回收策略就是決定哪些版本要留、哪些該清掉：

常見策略

# 只保留最新 1 個版本
cbt setgcpolicy sensors metrics maxversions=1

# 只保留 7 天內的版本
cbt setgcpolicy sensors raw maxage=7d

# 組合策略（Union）：超過 7 天 OR 超過 3 個版本就刪除
cbt setgcpolicy sensors metrics "maxage=7d or maxversions=3"

# 組合策略（Intersection）：超過 7 天 AND 超過 3 個版本才刪除
cbt setgcpolicy sensors metrics "maxage=7d and maxversions=3"

垃圾回收是非同步執行的，設定後不會立即刪除舊資料。

---

複製（Replication）

Bigtable 支援多叢集複製，可以拉高可用性，讀取效能也會更好：

# 新增第二個叢集到既有實例
gcloud bigtable clusters create my-cluster-2 \
  --instance=my-instance \
  --zone=asia-east1-b \
  --num-nodes=3 \
  --storage-type=SSD

路由策略

策略	說明	SLA
Single-Cluster	所有流量導向指定叢集	99.9%
Multi-Cluster（< 3 區域）	就近路由，自動故障轉移	99.99%
Multi-Cluster（3+ 區域）	就近路由，自動故障轉移	99.999%

# 設定 App Profile 為 Multi-Cluster 路由
gcloud bigtable app-profiles create multi-read \
  --instance=my-instance \
  --route-any

複製限制

• 一個 instance 的叢集最多可分佈在 8 個區域（region）；每個 zone 只能有一個叢集，因此叢集總數取決於所選區域的可用 zone 數（例如 8 個各有 3 個 zone 的區域，最多可達 24 個叢集）。這層推導入門階段不用硬記，考試只要記住「最多 8 個區域」這個數字就夠了
• 複製是最終一致性（Eventually Consistent）
• 單叢集路由可以保證強一致性讀取

---

自動擴縮（Autoscaling）

Bigtable 支援 GA 的 Managed Autoscaling：

gcloud bigtable clusters update my-cluster \
  --instance=my-instance \
  --autoscaling-min-nodes=3 \
  --autoscaling-max-nodes=20 \
  --autoscaling-cpu-target=60

注意事項

• 最大 Node 數不能超過最小的 10 倍
• 適用 SSD 和 HDD 叢集
• 根據 CPU 使用率和儲存使用量自動調整

---

Change Streams

Bigtable Change Streams（GA）讓你即時追蹤資料變更：

# 建立啟用 Change Streams 的表格
cbt createtable sensors change-streams=true

常見用途

• 即時同步到 BigQuery 做分析（有 Dataflow 範本）
• 觸發 Pub/Sub 做事件驅動處理
• 歸檔到 Cloud Storage 做合規
• 同步到 Elasticsearch 做全文搜尋

---

Key Visualizer——效能診斷神器

Key Visualizer 是 Bigtable 內建的視覺化診斷工具，用熱力圖把存取模式畫出來：

Key Visualizer 熱力圖（顏色 = 存取密度）

Row Key 範圍
  ▲
  │  ████████  ← 熱點！某段 Row Key 被集中存取
  │  ▒▒▒▒▒▒▒▒
  │  ░░░░░░░░
  │  ▒▒▒▒▒▒▒▒
  └──────────────────→ 時間

能診斷的問題

• 寫入熱點：某段 Row Key 範圍顏色特別深 → Row Key 設計不良
• 讀取傾斜：某些分片負載遠高於其他 → 考慮重新設計 Row Key
• 空洞區域：大片無存取 → 資料分佈不均勻
• 週期性尖峰：定時任務造成的流量集中

啟用條件

• 每個叢集至少有 1 GB 資料量，Bigtable 才會自動產生掃描資料（達到後最多要等 1 小時）
• Console → Bigtable → Instance → Key Visualizer

Key Visualizer 是 ACE 考試 Bigtable 效能調校題的常客。看到「如何診斷 Bigtable 效能問題」這種題目，Key Visualizer 通常就是答案。

---

監控與告警

關鍵監控指標

指標	建議閾值	說明
CPU utilization	< 70%	超過會影響延遲
Storage utilization	< 70% per node	接近上限需加 Node
Request latency (p99)	依 SSD/HDD	SSD 預期 < 10ms
Error count	= 0	任何非零值都需調查

# 用 Cloud Monitoring 建立 CPU 使用率告警
gcloud alpha monitoring policies create \
  --notification-channels=CHANNEL_ID \
  --display-name="Bigtable High CPU" \
  --condition-display-name="CPU > 70%" \
  --condition-filter='resource.type="bigtable_cluster" AND metric.type="bigtable.googleapis.com/cluster/cpu_load"' \
  --condition-threshold-value=0.7 \
  --condition-threshold-comparison=COMPARISON_GT

效能調校要點

1. CPU > 70% 持續 → 加 Node（線性擴展）
2. 延遲突然上升 → 查 Key Visualizer 找熱點
3. 新叢集前 20 分鐘延遲偏高是正常的——Bigtable 需要學習存取模式
4. 測試前先跑負載預熱——空叢集的效能數據不準確

---

Data Boost

Data Boost（GA）是 Bigtable 的無伺服器運算服務，可以讓你跑大量讀取，又不會拖累線上叢集的效能：

線上叢集（處理即時請求）
       │
       ├── 一般讀取 → 走叢集 Node
       │
       └── Data Boost 讀取 → 走獨立的無伺服器資源
           （不佔叢集效能配額）

適合場景：批次分析、ETL 作業、BigQuery 聯邦查詢。

💡 注意：Data Boost 用的是獨立的無伺服器資源，計費跟主叢集分開——現行是以 SPU（Serverless Processing Units，無伺服器處理單元，1,000 SPU 大約等於 1 個 Node 的效能）計價，跑之前先去官方定價頁查一下實際數字、抓好預算。

---

備份與還原

Bigtable 有託管備份功能，可以做時間點還原：

# 建立備份
gcloud bigtable backups create my-backup \
  --instance=my-instance \
  --cluster=my-cluster \
  --table=my-table \
  --retention-period=30d

# 從備份還原到新表格
gcloud bigtable backups restore \
  --source-backup=my-backup \
  --source-instance=my-instance \
  --source-cluster=my-cluster \
  --destination-table=my-table-restored \
  --destination-instance=my-instance

備份重點：

• 標準備份的保留期上限依 Bigtable 版本而定（Enterprise 最長 90 天、Enterprise Plus 最長 365 天）；30 天這個上限現在只適用於「備份複本（backup copy）」。實際以官方文件為準
• 備份不跨區域複製，要做跨區災難復原的話，請搭配多叢集複寫
• 備份不計入 Node 運算費用，僅收取備份儲存費

💡 考試小提示：題目問「Bigtable 如何災難復原」時，多叢集複寫是高可用首選，備份是時間點還原首選。兩者搭配使用才是完整策略。

---

定價

運算

項目	費用（美國區域）
Node（SSD/HDD 相同）	~$0.65 / Node / 小時

Node 運算費用不分 SSD 或 HDD，差異在儲存成本。

儲存

項目	費用
SSD 儲存	$0.17 / GB / 月
HDD 儲存	$0.026 / GB / 月

最低成本

• 最少 1 Node = ~$470/月（不含儲存）
• 沒有免費層（但有 Google Cloud $300 免費試用額度可以拿來練手）

💡 重點提點

這是 Bigtable 跟 Firestore、BigQuery 最不一樣的地方，新手很容易在帳單上踩到：它沒有免費層，只要叢集開著、哪怕一筆資料都沒進，最少一個 Node 就要燒掉差不多 $470/月（價格會浮動，請以官方定價頁為準）。所以動手前先估好「每月最低固定成本」，練習完記得把測試用的 instance 砍掉——別讓它默默跑整個月。想免費玩的話，就用那 $300 試用額度撐著。

---

Bigtable vs Firestore vs BigQuery

ACE 考試最高頻的大數據選型題：

特性	Bigtable	Firestore	BigQuery
類型	寬列型 NoSQL	文件型 NoSQL	分析型資料倉儲
延遲	個位數 ms	個位數 ms	秒級
規模	PB 級	GB-TB 級	PB 級
查詢	Row Key Scan	Document Query	SQL
寫入	超高吞吐	中等	批次/串流
最適合	IoT、時序、推薦	Mobile/Web App	分析、BI、報表
免費層	無	50K 讀/天	1 TB 查詢/月

選型公式

PB 級時序資料、IoT、低延遲高吞吐？
  → Bigtable ✅

Mobile/Web App、需要即時同步？
  → Firestore ✅

SQL 分析、BI 報表、ad-hoc 查詢？
  → BigQuery ✅

全球規模 OLTP、需要 SQL + ACID？
  → Cloud Spanner ✅

---

ACE 考試重點整理

必背知識點

1. Bigtable 是寬列型 NoSQL，適合 PB 級、低延遲、高吞吐場景
2. Row Key 設計決定效能——避免時間戳或遞增 ID 開頭（熱點）
3. SSD 延遲 ~6ms、HDD 延遲 ~200ms，依場景選擇
4. Multi-Cluster 3+ 區域 = 99.999% SLA
5. HBase API 相容——從 HBase 遷移的首選
6. 沒有免費層，最少 1 Node
7. Change Streams 可即時同步到 BigQuery 或 Pub/Sub
8. Key Visualizer 是診斷效能問題（熱點、讀取傾斜）的首選工具
9. CPU > 70% 需要擴容，新叢集前 20 分鐘延遲偏高是正常行為

常見陷阱題

Q：需要存 PB 級的 IoT 感測器時序資料，選什麼？ A：Bigtable。BigQuery 適合分析但延遲高；Firestore 不適合 PB 級。

Q：Bigtable 用時間戳作為 Row Key 會有什麼問題？ A：考場上這題常常包裝成「某團隊抱怨寫入越來越慢、加了 Node 也沒改善」這種情境敘述，看到「時間戳開頭的 Row Key」就要直接反應過來——這是寫入熱點：新資料全擠到同一個 Tablet，分散式擴展完全使不上力。解法：反轉時間戳，或在前面加一段 Hash prefix 把資料打散。

Q：從 HBase 遷移到 GCP 最適合用什麼服務？ A：Bigtable。原因是 Bigtable 提供 HBase API 相容性，應用程式碼幾乎不用改。

Q：Bigtable 讀取延遲突然升高，如何診斷？ A：使用 Key Visualizer 檢查是否有寫入熱點或讀取傾斜。同時監控 Cloud Monitoring 的 CPU 使用率是否超過 70%。

Q：Bigtable 和 BigQuery 有什麼不同？ A：Bigtable 是低延遲 NoSQL（讀寫毫秒級），適合線上服務。BigQuery 是分析型資料倉儲（查詢秒級），適合 BI 和 ad-hoc 分析。

---

寫在最後

Bigtable 的東西看起來很多，但真要你帶走的其實沒幾樣。它就是 GCP 上專門扛「PB 級、毫秒延遲、超高吞吐」這種狠活的寬列 NoSQL；而它玩得好不好，幾乎都壓在 Row Key 設計這一件事上——只要你能讓新資料散得開、不要排隊擠到同一台，後面的複製、自動擴縮、Data Boost 都是錦上添花。剩下的選型直覺也很單純：IoT 跟時序資料想到 Bigtable，Mobile/Web 即時同步想到 Firestore，要跑 SQL 分析就找 BigQuery，這三個分清楚，大數據選型題你就先穩住一半。

下一步往資料處理管線走 ACE-214：Dataflow 與 Dataproc 深度解析，看 GCP 怎麼把資料搬進搬出、做轉換。

順帶說明課程代碼：本站 GCP-1xx 是入門系列、ACE-2xx 是 ACE 認證進階系列，兩套課號是同一條學習路徑的不同階段，內容會互相銜接（像資料庫選型就橫跨兩個系列），看到不同前綴不用擔心，照著連結往下走就行。

資料庫選型系列

課程	服務	適合場景
GCP-108	Cloud SQL	中小型 OLTP、傳統 SQL 應用
GCP-112	Firestore	Mobile/Web App、即時同步
本課 GCP-113	Bigtable	PB 級 IoT/時序、低延遲高吞吐
ACE-211	BigQuery	PB 級分析、BI 報表
ACE-213	Spanner	全球規模 OLTP、強一致性
GCP-115	Memorystore	微秒級快取、Session 管理

📖 完整比較：想一次看懂所有資料庫差異？參考 GCP 資料庫選型完全指南。