Google PDE: 資料工程架構與設計 — 學習指南

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

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

總覽

在 Google Cloud 上進行資料工程的架構與設計，需要在領域邊界、處理模式與服務能力之間取得平衡，以交付可靠、可擴展且具成本效益的資料平台。有效的設計能讓儲存、運算、協調與服務層能夠獨立擴展；將合約程式碼化以使各領域能互相操作；並透過可衡量的服務等級目標 (SLO) 來及早驗證風險。本節概述了標準的架構風格 (資料網格、資料湖、資料倉儲、湖倉合一、營運型儲存)、處理模式 (批次、微批次、串流、事件驅動、Lambda)，以及在擴展性、延遲、可用性、一致性與成本之間的權衡取捨。此外，本節也涵蓋了區域與多雲部署、結構演進、端到端的資料生命週期、基於工作負載的服務選擇，以及針對 Google Cloud 量身打造、由風險驅動的驗證實務。

架構範式與處理模式

• 資料網格、領域與資料產品：
  • 賦予領域團隊權力，使其能發布具備明確所有權、SLO、存取政策與文件的「資料產品」。使用 Dataplex 來定義領域、治理中繼資料，並在 BigQuery 與 Cloud Storage 上應用一致的政策。產品可以暴露 BigQuery 資料集、Pub/Sub 主題或 Cloud Storage 路徑，並透過 Pub/Sub 結構與 BigQuery 資料表結構來強制執行合約。
• 資料湖：
  • 在 Cloud Storage 中以原始、開放格式 (Parquet/Avro) 儲存，並具備生命週期與版本控制。適合異質工作負載 (例如 Dataproc 上的 Spark、Dataflow、Presto/Trino) 與多雲的可攜性。權衡取捨：物件儲存中的最終一致性語意；設計時需考慮冪等性 (idempotency) 與由中繼資料驅動的重複資料刪除。
• 資料倉儲：
  • 在 BigQuery 中進行策劃、受治理的分析。為 ANSI SQL、儲存/運算分離及精細的安全性進行了優化。權衡取捨：串流插入在查詢時會展現短暫的資料過時；對於嚴格的資料新鮮度 SLA，應優先選擇批次載入或使用緩衝查詢進行插入。
• 湖倉合一 (Lakehouse)：
  • 將開放的資料湖儲存與倉儲能力相結合。在 Google Cloud 上，將 Parquet/Avro 儲存在 Cloud Storage 中；使用 BigQuery 外部資料表以符合經濟效益，並使用 BigQuery 受控資料表以獲得效能與治理。Dataflow 或 Dataproc 透過分區/叢集策略來維持類 ACID 的合併語意。
• 營運型儲存架構：
  • 支援應用程式的低延遲交易式或鍵值儲存。傳統 OLTP 選擇 Cloud SQL，具備水平擴展的全域一致性 SQL 選擇 Cloud Spanner，而極高吞吐量的寬欄存取模式則選擇 Bigtable。將營運型儲存與分析系統分開；使用 CDC (Datastream) 將變更捕獲至 Pub/Sub、Cloud Storage 或 BigQuery。

處理模式及其使用時機：

• 批次 (Batch)：週期性、大規模的轉換 (例如：夜間的特徵生成)。工具：Dataflow 批次模式、Dataproc。失敗模式：長時間執行的工作逾時、資料傾斜；透過自動擴展與重新分區來緩解。
• 微批次 (Micro-batch)：小而頻繁的批次 (例如：每分鐘一次)，以在新鮮度、穩定性與成本之間取得平衡。在 BigQuery 中，可使用排程查詢或具備固定時間視窗的 Dataflow。
• 串流 (Streaming)：對無邊界資料進行毫秒至秒級的延遲處理。使用 Pub/Sub + Dataflow。使用事件時間視窗與浮水印 (watermarks) 來處理延遲/亂序事件；確保冪等性以防止重複資料。
• 事件驅動 (Event-driven)：由變更觸發 (例如 GCS finalize、Pub/Sub 訊息)。使用 Cloud Functions 或 Cloud Run 進行無狀態的反應，使用 Dataflow 進行有狀態的處理。權衡取捨：單一事件成本 vs. 吞吐量。
• Lambda 模式：同時維護串流與批次路徑，以確保準確性與可重新處理性。複雜度加倍；可考慮類似 Kappa 的簡化架構，其中所有東西都可以從一個不可變的日誌 (例如從 Pub/Sub 封存到 Cloud Storage) 中重放。

處理延遲資料的 Dataflow 串流設定簡短範例：

events
  .apply(Window.into(FixedWindows.of(Duration.standardMinutes(5)))
    .withAllowedLateness(Duration.standardMinutes(10))
    .accumulatingFiredPanes());

領域所有權、資料產品與合約

• 所有權與 SLO：
  • 每個領域團隊定義並營運其資料產品，並附帶可用性、延遲與資料品質的 SLO。透過 Dataplex 目錄發布 SLO，並使用 Cloud Monitoring SLI (例如：準時分區完整性) 進行監控。
• 合約與互操作性：
  • 使用 Pub/Sub Schema Registry (Avro/Proto) 與 BigQuery 資料表結構來強制執行結構。對於 CSV 擷取，在 Dataflow 中進行驗證，並將格式錯誤的資料列路由到死信 (dead-letter) 資料表以進行分類處理。當多個引擎必須讀取相同資料時，透過 Cloud Storage 中的開放格式與 BigQuery 外部資料表來進行互操作。
• 結構演進：
  • 偏好向後相容的變更：新增可為空值的欄位、在 Avro/Proto 中新增可選欄位、避免在沒有棄用緩衝期的情況下重新命名/刪除欄位。透過版本化的合約與棄用時程表來溝通變更。
  • BigQuery 範例 (向後相容的欄位新增)：

ALTER TABLE sales.orders
ADD COLUMN coupon_code STRING;

• 對消費者的影響：
  • 維護結構的語意化版本；在遷移期間同時發布 v1 和 v2。對於串流，將資料路由到版本化的主題，或在資料中包含結構版本欄位。在 BigQuery 中提供授權檢視表，以隔離消費者使其不受實體變更的影響。
• 治理與資料血緣：
  • 使用 Dataplex 與 Data Catalog 進行中繼資料、標籤 (例如 PII) 與資料血緣管理。在 BigQuery 中應用資料列層級與資料欄層級的安全性。為了防止資料外洩，在擷取過程 (例如透過 Cloud Run 或 Dataflow 轉換) 中整合 Cloud DLP，以便在儲存前對敏感欄位進行權杖化或遮蔽處理。

非功能性權衡與部署拓撲

• 擴展性 (Scalability):
  • BigQuery 可彈性擴展以進行分析；Bigtable 則隨節點數量線性擴展，但需要謹慎的 row-key 設計（例如，雜湊或輪替的前綴）以避免熱點 (hotspotting) 問題。Dataflow 的自動擴展會回應積壓的工作；設計時應利用 Pub/Sub 的流量控制來處理背壓 (backpressure)。
• 延遲 (Latency):
  • 串流至 BigQuery 提供低延遲的插入，但查詢時可能會有些微延遲；設計查詢時可加入新鮮度緩衝區或基於浮水印 (watermark) 的視窗。若需大規模且低於 100 毫秒的讀取，可預先計算並從 Bigtable 或 Memorystore 提供服務。
• 可用性與一致性 (Availability and consistency):
  • Cloud Spanner 提供強一致性的全球分散式 SQL。Bigtable 提供高可用性，但在叢集間為最終一致性。BigQuery 的可用性為區域級或多區域級；可將關鍵資料集實體化至多區域以提高彈性。
• 成本 (Cost):
  • 透過分區 (partitioning) 與叢集 (clustering) 來優化 BigQuery，以減少掃描的位元組數。對於在受限的網路連結上傳輸小檔案，可進行批次處理或綑綁以減少 RPC 的額外開銷。在適當的情況下，使用 BigQuery BI Engine 來提供快取的互動式儀表板。
• 區域、多區域、混合雲與多雲 (Regional, multi-regional, hybrid, and multi-cloud):
  • 區域級設計可降低延遲與成本；多區域儲存（例如，BigQuery US/EU 多區域、Cloud Storage 雙區域/多區域）可增加耐用性與本地性選項。針對災難復原 (DR)，需定義 RPO/RTO 並複製關鍵資料集。在混合雲場景中，使用 Datastream 進行 CDC，並使用 Transfer Appliances 或 Storage Transfer Service 進行大量遷移。針對多雲環境，應在 Cloud Storage 中標準化使用開放格式，並採用可攜式運算（Apache Beam/Dataflow、Spark on Dataproc），同時認知到出口流量與維運的額外開銷。

分層、生命週期與服務選擇

• 分層切割：
  • 儲存層：Cloud Storage 用於原始/銅級 (raw/bronze) 和封存資料；BigQuery 用於策展/伺服分析 (curated/serving analytics)；Bigtable 用於低延遲鍵值存取；Spanner/Cloud SQL 用於 OLTP。
  • 運算層：Dataflow 用於無伺服器串流/批次處理；Dataproc 用於 Spark/Hadoop 生態系；BigQuery 用於倉儲內 ELT；Cloud Run/Functions 用於事件驅動微服務。
  • 編排層：Cloud Composer (Airflow) 或 Workflows 用於 DAGs 和 API 編排；Scheduler 用於類似 cron 的觸發器。
  • 服務層：Bigtable 或 Spanner 用於線上讀取；BigQuery 用於 BI；Looker/BI Engine 用於儀表板；Memorystore 用於快取。
• 資料生命週期：
  • 擷取：Pub/Sub 用於串流；Storage Transfer 或 gsutil 用於檔案；Data Transfer Service 用於 SaaS。驗證、去重，並將不可變的原始資料落地到啟用物件版本控制的 Cloud Storage 中。
  • 處理：使用 Dataflow 或 BigQuery 將原始資料 (raw) 轉換為銀級 (silver)（已清理、已整合），再轉換為金級 (gold)（可供業務使用的資料超市）。
  • 提供服務：發布 BigQuery 的視圖/資料表以供分析；將特徵或預測結果預先計算並存入 Bigtable 以供 API 使用。
  • 保留與封存：套用 Cloud Storage 生命週期規則，將資料轉移至 Coldline/Archive 儲存級別；使用 BigQuery 的時間分區搭配分區過期設定來進行資料保留。在需要時啟用 CMEK，並使用 VPC Service Controls 保護資料以防外洩。
• 根據工作負載特性選擇服務：
  • 高吞吐量、寬資料列、低延遲的時間序列資料：Bigtable。
  • 具備 ANSI SQL 的強一致性全球 OLTP：Cloud Spanner。
  • 規模不大的傳統關聯式交易：Cloud SQL。
  • PB 等級的分析，具備 ANSI SQL 及儲存/運算分離架構：BigQuery。
  • 即時擷取與處理：Pub/Sub + Dataflow。
  • 批次的 Spark/Hadoop 或特定函式庫的工具：Dataproc。

簡短的 BigQuery 分區範例：

CREATE TABLE ops.events
PARTITION BY DATE(event_ts)
CLUSTER BY device_id AS
SELECT * FROM staging.events_clean;

實務問題情境

Contoso Mobility 營運一個全球性的電動滑板車隊，需要對騎乘遙測和計費資料進行即時的擷取、處理、儲存和分析。他們必須支援每分鐘數百萬次的事件、次秒級的詐欺偵測規則、即時更新的儀表板、隱私控制，以及具備彈性的多區域營運。

方法：

1. 使用 Cloud Pub/Sub 建立事件擷取機制。

• 理由：Pub/Sub 提供單一的全球端點、持久的緩衝區，以及針對突發設備流量的水平擴展能力。每個滑板車使用有序鍵 (ordered keys)，以在 1 小時的視窗內保持單一設備的事件順序。

2. 使用 Cloud Dataflow (Apache Beam) 實作串流處理。

• 理由：Dataflow 的自動擴展功能可處理流量高峰，並在與冪等鍵 (idempotent keys) 結合時提供 exactly-once 的接收端 (sink)。使用事件時間視窗 (event-time windows) 和浮水印 (watermarks) 來處理延遲或順序錯亂的遙測資料。將主輸出發送到策展過的串流，並將一個旁支輸出 (side output) 用於無法處理的記錄 (dead-letter records)。
• 設定：

.withAllowedLateness(Duration.standardMinutes(15))
.discardingFiredPanes();

3. 分別將原始資料和策展後的資料永久儲存於 Cloud Storage 和 BigQuery。

• 理由：將原始 (bronze) 的 Avro 檔案落地到一個雙區域 (dual-region) 的 Cloud Storage 儲存桶中，以供重播和稽核。將策展過的 (silver) 串流寫入 BigQuery 的分區資料表以進行分析，並在 scooter_id 上建立叢集以提高單點查詢效率。在儀表板查詢上應用一個小的新鮮度緩衝，以避免短暫的串流資料延遲。

4. 從 Cloud Bigtable 提供營運查詢和詐欺檢查服務。

• 理由：次於 100 毫秒的規則評估需要低延遲的隨機存取。在 Dataflow 中預先計算匯總資料（例如，每 5 分鐘視窗內每個設備的騎乘次數），並使用雜湊前綴的資料列鍵 (row key)（例如，h(prefix)+device_id+window_start）寫入 Bigtable，以避免熱點 (hotspotting) 並將讀取平行分散到各個 tablet。

5. 在 Cloud Spanner 中管理交易式計費。

• 理由：計費需要全球一致的 SQL、強一致性和高可用性。在主要地理區域使用一個領導者 (leader)，並在次要區域部署唯讀副本，以降低客戶入口網站的讀取延遲。

6. 使用 Dataplex、Data Catalog 和 Cloud DLP 強制執行治理。

• 理由：在 BigQuery 中分類 PII (個人可識別資訊) 欄位、為資料集加上標籤，並應用欄位級別的安全性。在 Dataflow 管線中整合 Cloud DLP，以便在儲存前將敏感屬性進行權杖化 (tokenize)。Dataplex 網域反映組織所有權；每個網域都會發布帶有 SLO 的、文件化的資料產品。

7. 使用 Cloud Composer 和 Cloud Monitoring 進行編排與維運。

• 理由：Composer 協調批次資料回填、壓縮 (compaction) 和機器學習特徵的具體化 (materialization)。Monitoring 監控端到端的 SLI：Pub/Sub 的積壓量、Dataflow 的浮水印延遲、BigQuery 的分區完整性，以及 Bigtable 的尾部延遲 (tail latencies)。在違反 SLO 時發出警報；根據積壓量增長自動擴展 Dataflow。

8. 透過分區和分層來優化成本與生命週期。

• 理由：BigQuery 資料表依 event_ts 進行分區，保留 90 天，並依 scooter_id 進行叢集。Cloud Storage 使用生命週期規則，在 30 天後將原始資料轉移到 Coldline，180 天後轉移到 Archive。排程的 BigQuery 工作會將小的微批次檔案壓縮成較大的 Parquet 物件，以減少下游 Spark 工作的檔案數量開銷。

9. 驗證風險與彈性。

• 理由：以預期峰值的 2 倍進行負載測試，以驗證 Pub/Sub 的配額和 Dataflow 的自動擴展功能。執行一次區域性故障轉移演練：BigQuery 的多區域資料集和雙區域儲存桶能維持可用性；Spanner 的多區域實例透過自動故障轉移，可維持 RPO=0 和設定的 RTO。使用基礎設施即程式碼 (Infrastructure as Code, Terraform) 搭配策略驗證，來強制執行 CMEK 和 VPC Service Controls。

這個架構清楚地分離了各層的關注點：Pub/Sub 緩衝擷取流量，Dataflow 負責運算，Cloud Storage 和 BigQuery 儲存並提供分析服務，Bigtable 加速營運讀取，而 Spanner 則保證交易的一致性。此架構在擴展性與延遲之間取得平衡，同時透過分區、叢集、生命週期政策與自動擴展來控制成本，並且透過文件化的資料產品、合約和持續驗證，將治理與可靠性嵌入其中。

所有領域 · 資料儲存、資料湖與檔案格式 →

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

瀏覽 Google →