TerramEarth
一句話描述:一家生產重型工程機械、旗下數十萬台機具每秒回傳遙測資料的製造商,核心挑戰是在 PB 級別資料量下,既要提供即時預測性維護,又要保留長期歷史做趨勢分析。
🏢 商業背景
重型工程機械是個「機具昂貴 + 停機成本更貴」的產業。一台礦山運輸車或農耕重機動輒數千萬,一旦在作業現場故障,不只是維修費用,更可怕的是整條工地停擺—每小時損失可能是機器本身的數倍。因此這個產業過去十年最大的轉型,就是把單純的「賣機具」商業模式,轉成「賣機具 + 訂閱預測性維護服務」,用 IoT 感測器讓停機從「反應式搶修」變成「預測式保養」。
從規模來看,這類公司的活躍機具通常在 10 萬到 100 萬台之間,每台機具可能安裝數十到上百個感測器,涵蓋引擎溫度、油壓、扭矩、位置、震動頻率等。以每台機具每秒一筆、每筆 2KB 保守估算,單日資料量就能輕易達到數十 TB,累積三到五年就進入 PB 級數據湖等級。而且這些資料不能刪—監理法規、保修責任、歷史趨勢分析都要求至少保存 5-10 年。
商業上最棘手的地方在於資料的「雙重需求」:一方面,機具在現場回傳的異常訊號必須在秒級之內觸發警告(預測性維護的核心價值);另一方面,資料科學團隊想要跨越數年、跨越機型的歷史查詢,做故障模式挖掘與新機型研發。這兩種工作負載的存取模式完全相反—一個要超低延遲、小量讀寫,一個要大批次、大範圍掃描,同一套儲存架構很難兼顧。
⚡ 主要技術挑戰
- 資料擷取量級極端每秒數十萬筆感測資料同時湧入,傳統 message queue 會直接卡住。
- 即時 + 歷史雙向需求同一份資料既要做秒級警告,又要做多年長期分析,存取模式完全不同。
- 斷線與 late-arrival 普遍機具在偏遠地區作業,網路時斷時續,資料可能延遲數小時才上傳,處理管線要能容忍亂序。
- 長期冷儲存成本法規要求保存 5-10 年,全部放熱儲存成本爆表,必須設計自動分層生命週期。
- 分析要能跨越模型迭代資料科學團隊的 ML 模型會不斷更新,歷史資料必須可重跑、可回測。
🏗️ 建議 GCP 架構
這個案例的黃金管線是「Pub/Sub 擷取 → Dataflow 雙路輸出 → Bigtable 即時查詢 / BigQuery 歷史分析 / Cloud Storage 冷儲存」。Pub/Sub 負責吸收瞬間爆量的感測事件,Dataflow 做串流處理時分流:需要秒級警告的資料(如溫度異常)走 Bigtable 供 dashboard 查詢;所有資料都進 BigQuery 做歷史分析;超過 90 天的 BigQuery 分區資料自動匯出到 Cloud Storage Coldline,三年以上再沉到 Archive。
[數十萬台機具 / 全球現場]
│ (MQTT / HTTPS 上傳)
▼
┌─────────────┐
│ IoT Core 或 │
│ Cloud Run │ (資料前處理 + 認證)
│ gateway │
└──────┬──────┘
│
▼
┌─────────────┐
│ Pub/Sub │ (承接爆量、解耦)
└──────┬──────┘
│
▼
┌─────────────────────────────┐
│ Dataflow │
│ (streaming + windowing) │
└──┬──────┬──────────┬────────┘
│ │ │
▼ ▼ ▼
[Bigtable] [BigQuery] [Pub/Sub]
(即時 (分析倉儲) (警告事件)
時序) │ │
▼ ▼
[Cloud Storage] [Cloud Run]
Standard │
│ ▼
(90 天後) [通知系統]
▼ (Email / SMS)
[Nearline]
│
(1 年後)
▼
[Coldline]
│
(3 年後)
▼
[Archive]
為什麼選 Bigtable 而非 BigQuery 做即時查詢?Bigtable 的 row-key 設計天生就是為時序資料 + 秒級點查詢打造,單機具近一小時的查詢能在毫秒內返回;BigQuery 雖強但分析批次更適合。為什麼 Dataflow 而非 Dataproc?串流處理場景下 Dataflow 的 serverless 模型更省心,而且原生支援 event time + late-arrival 水位機制—這對 IoT 的亂序資料是剛需。
🎯 關鍵設計決策
| 決策 | 選這個的理由 | 替代方案 |
|---|---|---|
| Pub/Sub 作為擷取層 | 可無痛擴展到每秒百萬筆訊息,at-least-once 保證,自動分流給多個訂閱者 | Kafka on GCE(要自行維運)、Cloud Tasks(吞吐量不足) |
| Dataflow 做串流處理 | Apache Beam 統一 batch 與 streaming 程式模型,原生支援 event time windowing 處理亂序到達 | Dataproc(要管叢集)、自寫 consumer(處理 late data 太複雜) |
| Cloud Storage 生命週期分層 | Standard → Nearline → Coldline → Archive 自動降階,長期冷儲每 GB/月只要 $0.0012,合規保留成本可控 | 全部留在 Standard(成本吃不消)、手動搬(易出錯) |
📝 PCA 考點拆解
考點 1:時序資料選 Bigtable
IoT、金融 tick data、監控 metrics 這類「高寫入 + 範圍掃描 + 微秒查詢」場景,標準答案是 Bigtable。看到題目出現「每秒百萬筆寫入」「時序查詢」「sub-10ms 延遲」組合拳,直接挑 Bigtable。
考點 2:Pub/Sub + Dataflow + BigQuery 黃金管線
這條組合是 PCA 考試的常客。Pub/Sub 做擷取解耦,Dataflow 做 ETL/ETLT,BigQuery 做分析。只要看到「streaming analytics」「事件驅動」+ 「大規模分析」,幾乎就是這條答案。
考點 3:Cloud Storage 儲存類別分層
記熟四階儲存的存取頻率斷點:Standard(常用)→ Nearline(月存取一次)→ Coldline(季存取一次)→ Archive(年存取一次或合規保留)。題目出現「5 年法規保留」「幾乎不會讀取」就是 Archive。
考點 4:Event Time vs Processing Time
IoT 資料常見「event time 是機具產生時間,processing time 是雲端收到時間」的時間差異。Dataflow 的 windowing 支援 event time + watermark 處理 late data,這是 PCA 進階題會考的細節。
換你練習
TerramEarth 難度最高,也是練習資料管線設計的最佳案例。到 PCA 架構師設計工作坊 把它當作你的情境,重點走完「儲存選型」「網路與安全」「災難復原」「成本估算」這幾步,把 PB 級架構的取捨練熟。
前往工作坊🔗 延伸閱讀
- Google Cloud 官方 PCA exam guide — 原始情境敘述來源
- Bigtable 時序資料 schema 設計 — row-key 設計的最佳實踐
- Dataflow 串流處理與 Pub/Sub — event time windowing 深入解說
- Cloud Storage 儲存類別 — 四階儲存與生命週期管理