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

前言

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

這篇是 GCP 入門系列第 13 課，帶你搞懂 Bigtable 的核心概念，順便動手操作一遍。

什麼是 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 讀取	~10,000 rows/s	~500 rows/s
每 Node 寫入	~10,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 的字典序存資料的，再依 Row Key 範圍自動切片，分散到不同的 Tablet Server。所以 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

時序資料的最佳實踐

# 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（Google 建議不超過 10 個以獲得最佳效能）
將經常一起讀取的欄位放同一個 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.95%
Multi-Cluster（3+ 區域）	就近路由，自動故障轉移	99.999%

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

複製限制

一個 instance 的叢集最多可分佈在 8 個區域；每個 zone 只能有一個叢集，因此叢集總數取決於所選區域的可用 zone 數（例如 8 個各有 3 個 zone 的區域，最多可達 24 個叢集）
複製是最終一致性（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
空洞區域：大片無存取 → 資料分佈不均勻
週期性尖峰：定時任務造成的流量集中

啟用條件

表格至少有 30 GB 資料量才會自動產生掃描資料
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

效能調校要點

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

Data Boost

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

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

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

💡 注意：Data Boost 使用獨立的無伺服器資源，計費與主叢集分開（約 $0.35/vCPU-hour），使用前請確認預算。

備份與還原

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

備份重點：

備份保留期限最長 30 天
備份不跨區域複製，要做跨區災難復原的話，請搭配多叢集複寫
備份不計入 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 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 考試重點整理

必背知識點

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

常見陷阱題

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

Q：Bigtable 用時間戳作為 Row Key 會有什麼問題？ A：造成寫入熱點。新資料全部寫到同一個 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 分析。

總結

Cloud Bigtable 是 GCP 上跑大規模 NoSQL 的看家方案，重點整理一下：

定位：PB 級、低延遲、高吞吐的寬列型 NoSQL
Row Key 設計：避免熱點，用 Hash/反轉時間戳/Field Promotion
SSD vs HDD：即時服務用 SSD（6ms），批次分析用 HDD
複製：Multi-Cluster 3+ 區域 = 99.999% SLA
整合：HBase API 相容、Dataflow、Spark、BigQuery 聯邦
選型：IoT/時序 → Bigtable；Mobile → Firestore；分析 → BigQuery

下一課 ACE-214：Dataflow 與 Dataproc 深度解析，來看看 GCP 資料處理管線的核心工具。

資料庫選型系列

課程	服務	適合場景
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 資料庫選型完全指南。

GCP 核心服務 — 8/10 完成查看系列全覽 →

前言