Google PCA: 資料儲存、資料庫與分析架構 — 學習指南

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

屬於 Google Professional Cloud Architect — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

在 Google Cloud 上設計資料儲存、資料庫和分析時，需要將工作負載模式與服務進行匹配，同時規劃耐久性、可用性、存取控制、成本和營運彈性。本節涵蓋物件儲存與生命週期治理；營運型資料庫與快取；分析型倉儲與處理；擷取架構；以及治理、保護與效能實務。本節將指出設計選擇、營運考量，以及常見的故障模式或權衡取捨。

儲存與物件架構

Cloud Storage bucket 設計

• 位置：對於低延遲、對成本敏感的工作負載，選擇 region (區域)；對於需要可預測容錯移轉的業務連續性，選擇 dual-region (雙區域)；對於全球讀取存取，選擇 multi-region (多區域)。Dual-region 提供可選的 turbo replication，以獲得有 SLA 支持的低 RPO；否則複製是非同步的。
• 命名空間與隔離：為不同的資料領域、環境和敏感度等級使用獨立的 bucket。採用統一的 bucket 層級存取權限和公開存取預防機制，以確保權限一致。
• 儲存空間級別：Standard 適用於常用資料 (hot data)；Nearline 適用於不常存取 (每月) 的資料；Coldline 適用於每季存取的資料；Archive 適用於長期保留。Autoclass 可自動優化級別配置，只需極少的營運工作。
• 生命週期政策：根據物件存在時間、儲存空間級別或物件前綴自動轉換和刪除。刪除超過 90 天物件的範例如下： { “rule”: [ { “action”: {“type”: “Delete”}, “condition”: {“age”: 90} } ] } 使用以下指令套用： gsutil lifecycle set lifecycle.json gs://my-bucket
• 保留政策與訴訟保留：設定 bucket 保留政策，並可選擇鎖定以防止縮減 (為符合法規)。事件型保留和物件版本控制能夠從意外刪除或覆寫中復原。
• 複製：選擇 dual-region 以在 API 層級提供同步一致性語意，並在兩個區域間進行背景複製；使用 bucket-to-bucket 複製 (用於跨專案或跨位置的副本) 以滿足特定的 RPO/RTO 或職責分離需求。

故障模式與權衡取捨

• 級別不匹配會增加成本和延遲。Autoclass 能減少此問題，但會增加每個物件的管理開銷。
• 保留鎖定是不可逆的；請在非生產環境中測試政策。
• 複製能提高耐久性，但可能增加寫入延遲和成本；應針對目標位置設計讀寫路徑。

模式

• 資料湖 (Data lake)：在 Cloud Storage 上建立原始區和策展區；透過 Dataplex 進行治理；在 Data Catalog 中管理外部化的結構描述 (schema)。
• 封存：使用具備保留鎖定的 Archive 級別以符合法規，並搭配 BigQuery 外部資料表或依需求還原以進行罕見的分析。
• 湖倉一體 (Lakehouse)：使用 BigLake 統一對 Cloud Storage 和 BigQuery 的存取，並提供一致的安全性。

營運資料儲存庫與快取

Cloud SQL

• 高可用性 (High availability)：區域級 HA，透過同步複製到備用執行個體；自動容錯移轉通常在幾秒到幾分鐘內完成。執行個體端點保持不變，將應用程式變更降至最低。
• 讀取複本 (Read replicas)：區域內或跨區域，採非同步方式；適合讀取擴展 (read scale-out) 與災難復原 (DR)。需監控複製延遲；過時讀取可能影響正確性。
• 備份與時間點復原 (Backups and PITR)：排程備份加上使用交易日誌進行時間點復原 (通常視資料庫引擎而定，最多可達 7 天的窗口)。需定期測試還原。
• 私密連線 (Private connectivity)：透過 VPC 對等互連 (VPC peering) 使用私有 IP，可減少曝險與延遲；需規劃 IP 範圍以避免重疊。
• 遷移 (Migration)：Database Migration Service 支援從地端或其他雲端進行低停機時間的遷移；對於高流量的連線，建議使用 Dedicated 或 Partner Interconnect 而非 VPN，以減少封包遺失與延遲。

權衡取捨與故障模式

• HA 容錯移轉會重設連線；應用程式必須採用退避 (backoff) 策略重試。維護期間可能會短暫降低效能。
• 長時間執行的交易會增加複製延遲與 PITR 的復原時間。
• 超額配置儲存空間是便宜的保險；IOPS 配置不足會在尖峰時段導致潛在故障。

Cloud Spanner

• 全球規模與一致性 (Global scale and consistency)：使用 TrueTime 與兩階段提交 (two-phase commit) 實現跨區域的強一致性讀寫。選擇區域性 (regional) 以獲得最低寫入延遲；選擇多區域 (multi-region) 以獲得更高的可用性與全球讀取。
• 交易 (Transactions)：跨資料列與資料表的外部一致性 (external consistency) 與完整的 ACID；唯讀交易可在複本之間擴展。
• 結構設計 (Schema design)：選擇能避免熱點 (hotspots) 的主鍵；使用交錯資料表 (interleaved tables) 以提高局部性 (locality)；考慮次要索引的寫入放大 (write amplification) 與回填 (backfill) 行為。
• 區域性 (Regionality)：領導者區域 (leader region) 的放置位置決定了寫入延遲；多區域會增加仲裁 (quorum) 成本與提交延遲。

權衡取捨

• 寫入延遲會隨著地理足跡的擴大而增加；除非可用性與全球分佈的需求證明其合理性，否則應避免使用多區域。
• 基礎成本高於單節點 VM 資料庫；容量規劃必須與 SLO 和成長保持一致。

Firestore、Bigtable、Memorystore 與選擇

• Firestore：用於行動/網頁後端的 文件資料庫；單一文件具備強一致性；精細的安全性；自動索引。需注意頻繁更新文件的競爭 (contention) 問題；可使用分散式計數器與批次寫入。
• Bigtable：寬欄、PB 等級、超低延遲的時間序列與物聯網 (IoT) 資料庫；設計資料列鍵 (row keys) 以避免熱點 (例如：雜湊或加鹽)；透過節點與叢集進行擴展；多叢集路由以提高可用性。複製是非同步的；強一致性是針對單一叢集。
• Memorystore for Redis：記憶體內快取；基本版 (Basic tier) 是單一執行個體 (無 HA)；標準版 (Standard tier) 提供複本與自動容錯移轉 (可能發生短暫斷線)。應視為快取，而非資料來源真相；持久性功能可降低揮發性，但不能取代資料庫備份。

依工作負載驅動的選擇

• 需要 join/ACID 且規模中等的關聯式資料庫：Cloud SQL。
• 需要水平擴展與外部一致性的全球關聯式資料庫：Cloud Spanner。
• 高吞吐量的時間序列/遙測或非常大的鍵值資料：Bigtable。
• 以應用程式為中心、具備階層式查詢的文件模型：Firestore。
• 暫時性的加速與速率限制：Memorystore。

分析、擷取與處理

BigQuery

• 資料集 (Datasets)：邏輯上的安全性與計費邊界；依領域和生命週期階段採用命名慣例。
• 分割 (Partitioning)：依擷取時間或欄位進行時間篩選；也支援整數範圍分割。對 event_ts 使用時間單位分割以修剪掃描範圍。
• 叢集 (Clustering)：最多四個欄位，將相關資料共同存放在儲存空間中；可改善選擇性查詢的效能與成本。
• 預留 (Reservations)：透過預留與指派來管理專用 slot；使用彈性 slot (flex slots) 進行突發性的實驗；隔離關鍵工作負載以避免資源不足 (starvation)。
• 存取控制 (Access control)：專案與資料集層級的 IAM；使用資料列層級政策與政策標籤進行資料表/欄位控制；透過授權檢視 (authorized views) 與常式 (routines) 分享整理過的資料。

實用範例：

undefined

undefined

權衡取捨與故障模式

• 不佳的分割會導致全資料表掃描與失控的成本。
• 只有在篩選或 join 包含叢集欄位時，叢集才有幫助；頻繁的重新洗牌 (reshuffles) 會降低效益。
• Slot 配置不足會導致工作排隊；超額配置會增加成本。需監控 slot 使用率與溢出的 shuffle (spilled shuffle)。

資料擷取與處理

• Pub/Sub：全球性、持久、至少一次 (at-least-once) 的傳遞；排序鍵 (ordering keys) 可強制執行每個鍵的順序，但會影響吞吐量。需設計冪等 (idempotent) 的消費者。
• Dataflow：統一的批次與串流處理，具備自動擴展、僅一次 (exactly-once) 的狀態處理、視窗化 (windowing) 與觸發器 (triggers)；Streaming Engine 會卸載狀態處理。使用無效信件主題 (dead-letter topics) 與可重播的來源。
• Dataproc：用於現有程式碼與生態系的代管式 Spark/Hadoop；可使用臨時叢集 (ephemeral clusters) 或自動擴展；當移植成本高昂或需要使用 ML 函式庫時使用。

批次與串流的權衡取捨

• 串流可降低延遲並支援即時處理，但會增加複雜性 (狀態、浮水印、延遲資料) 與持續性成本。
• 批次處理簡化了正確性與成本控制；當 SLA 容許延遲時是可接受的。
• 混合模式：將原始事件存入 Cloud Storage，將匯總的 KPI 串流至 BigQuery，並在夜間執行批次重新計算以確保準確性。

資料倉儲模式

• 倉儲 (Warehouse)：以 BigQuery 作為分析系統；使用具體化檢視 (materialized views) 與排程查詢來服務 BI。
• 湖倉 (Lakehouse)：在 Cloud Storage 中以開放格式管理資料；透過 BigLake 將其公開給 BigQuery，並維持一致的安全性。

治理、保護與效能

資料治理與安全性

• 中繼資料與資料血緣：使用 Data Catalog 處理技術性和業務性的中繼資料；從 Dataflow、BigQuery 和 Dataproc 啟用資料血緣擷取，以追蹤依賴關係。
• 品質：使用 Dataplex data quality 強制執行規則，並在 Composer 或 Dataform 中編排檢查；隔離不良記錄。
• 存取邊界：在 BigQuery 和 Cloud Storage 周圍使用 VPC Service Controls 以降低資料外洩風險；使用 IAM Conditions 進行情境感知存取；使用 CMEK 進行加密控制；使用政策標籤 (policy tag) 進行欄位級限制。
• 保留：使 Cloud Storage 儲存桶保留政策、BigQuery 資料表的時間旅行 (time travel) 功能（可配置長達 7 天）以及資料集/資料表到期時間，與法律要求保持一致。

備份、PITR 與刪除保護

• 驗證備份：定期將 Cloud SQL 和 Spanner 的備份還原到隔離的環境中，並執行校驗和 (checksum) 與應用程式層級的驗證。
• Bigtable：啟用 PITR 以便在設定的保留期限內回復到指定的時間戳；測試資料表或叢集層級的還原。
• Spanner：使用備份進行災難復原；在版本保留期限內利用過時讀取 (stale read) 進行稽核查詢。
• Cloud Storage：啟用物件版本控管和儲存桶保留鎖定，以防止意外刪除；複製到一個獨立的專案以隔離操作人員的錯誤。
• BigQuery：使用時間旅行 (time travel) 和資料表快照；透過必要的審批和資料集層級的刪除保護，避免在生產資料集上執行 drop 操作。

資料效能與成本控制

• 避免熱點鍵 (hot key)：分散 Bigtable 的資料列鍵（使用雜湊前綴），選擇能隨機化領導者選舉的 Spanner 主鍵，以及分片 Firestore 計數器。
• 索引：維護必要的 SQL 和 NoSQL 索引；在 BigQuery 中，根據常用篩選條件進行叢集化；在 Cloud SQL 中，監控慢查詢並定期對 Postgres 執行 vacuum/analyze。
• 容量規劃：透過負載測試建立基準；設定 SLO 和錯誤預算；監控 BigQuery slot 使用率、Bigtable CPU/讀取-修改-寫入延遲、Cloud SQL CPU/IOPS，以及 Pub/Sub 的積壓 (backlog)。
• 成本控制：對穩定的工作負載使用 BigQuery slot 承諾，對 Cloud Storage 使用 Autoclass，壓縮 Bigtable 資料表並調整布隆過濾器 (Bloom filter)，讓舊的分區和資料集過期，並為每個團隊實施預算和警報。

實務問題情境

Acme 零售集團需要一個統一、低延遲的點擊流 (clickstream) 與訂單分析平台。需求包括：10 秒內提供即時 KPI、使用 SQL 進行超過五年的歷史分析、小時級的復原目標、嚴格的美國資料落地 (data residency) 要求，以及防止意外的資料遺失。

1. 存放原始事件並實作持久化擷取

• 建立 us-central1/us-east1 雙區域的 Cloud Storage 儲存桶，用於原始區和策展區；在原始區啟用 Autoclass 和物件版本控管。
• 理由：雙區域滿足了持久性和落地要求；版本控管可防止錯誤的回填；Autoclass 自動優化儲存成本。

2. 使用 Pub/Sub 和 Dataflow 可靠地串流事件

• 將點擊流和訂單事件發布到 Pub/Sub 主題，並為每個 user_id 設定排序鍵；實作一個 Dataflow 串流管道來驗證、去除重複、豐富化，並將輸出分支到 BigQuery（用於熱門 KPI）和 Cloud Storage（在策展區存放 parquet 格式）。
• 理由：Pub/Sub 提供全球性、持久的至少一次傳遞保證；Dataflow 提供正好一次的狀態處理和自動擴展；分支輸出維持了一個 lakehouse 模式，以便重新處理。

3. 在 Bigtable 和 Redis 中提供即時特徵

• 將一部分豐富化後的事件寫入 Bigtable，使用加鹽的 user_id#timestamp 作為資料列鍵；使用 Memorystore for Redis 作為前端快取，存放最近的 session 資料。
• 理由：Bigtable 為時間序列資料提供低延遲、高吞吐量的寫入；加鹽可避免熱點；Redis 降低了即時個人化服務的長尾延遲。

4. 在 BigQuery 中建立資料倉儲並優化查詢

• 建立依 event_date 分區、並依 user_id 和 channel 叢集化的資料集。使用具體化視觀表 (materialized view) 處理 KPI，並透過排程壓縮來處理小檔案載入；購買一個基準的 slot 預留，並帶有少量的彈性 slot 緩衝區以應對突發流量。
• 理由：分區和叢集化可裁剪掃描範圍並降低成本；具體化視觀表可加速儀表板；預留可控制成本上限並保護關鍵工作負載免於排隊。

5. 治理存取並防止資料外洩

• 為分析師群組應用資料集層級的 IAM；使用政策標籤 (policy tag) 限制 PII 欄位，並使用授權視觀表 (authorized view) 提供給供應商存取。在 BigQuery 和 Cloud Storage 周圍強制執行 VPC Service Controls；對受監管的資料集使用 CMEK。
• 理由：在資料集和欄位層級實施最小權限原則；VPC SC 降低了資料外洩的風險；CMEK 滿足了加密控制的要求。

6. 實作備份、PITR 和還原測試

• 啟用 Bigtable PITR，保留 7-14 天；為交易型訂單儲存庫（如 Spanner 或 Cloud SQL）建立每週備份；每日快照 BigQuery 的關鍵資料表，並依賴時間旅行 (time travel) 功能來處理錯誤。每季在一個隔離的專案中執行還原演練。
• 理由：分層的復原選項可應對邏輯錯誤和災難；定期的演練可驗證 RPO/RTO 和操作手冊 (runbook)。

7. 控制資料保留和生命週期

• 應用生命週期規則，在 30 天後清除原始物件，五年後清除策展物件；鎖定一個符合法規的儲存桶層級保留政策。為暫時性資料集設定 BigQuery 資料集/資料表的預設到期時間。
• 理由：自動化強制執行可降低操作風險；保留鎖定可防止意外或未經授權的政策削弱。

8. 監控效能與成本，並緩解熱點

• 追蹤 BigQuery slot 使用率、掃描位元組數和 BI 查詢並行度；監控 Bigtable CPU 和讀取-修改-寫入延遲；對 Pub/Sub 的積壓 (backlog) 設定警報。如果出現 user_id 熱點，增加鹽值寬度並透過 Dataflow 回填鍵值。
• 理由：持續的遙測能及早發現瓶頸；主動的鍵值策略變更可在無需全面重新架構的情況下維持 SLO。

9. 提供私有連線與隔離

• 對於混合雲的依賴關係，使用 Partner 或 Dedicated Interconnect 搭配 Cloud Router；確保 IP 範圍不重疊；使用 Private Service Connect 連接託管服務的端點。
• 理由：私有路徑可減少延遲和封包遺失；清晰的 IP 規劃和 PSC 可強制執行隔離和可預測的路由。

10. 將可靠性納入維運

• 啟用金絲雀 (canary) Dataflow 管道和藍/綠 (blue/green) BigQuery 視觀表；透過 Data Catalog 的審批來強制執行結構演進；將無法處理的信件佇列 (DLQ) 與事件應變流程整合。
• 理由：受控的部署可限制爆炸半徑；受治理的結構變更可維持資料品質；DLQ 確保在事件期間不會遺失資料。

← 運算、應用程式平台與工作負載架構 · 所有領域 · 網路、混合式連線與流量架構 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Google →