Google PDE: 資料儲存、資料湖與檔案格式 — 學習指南

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

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

總覽

Google Cloud 上的資料儲存涵蓋了原始物件儲存、經整理的資料湖，以及為分析最佳化的格式。要建立可靠、受監管且高效能的資料湖，需要在儲存空間級別、值區設定、位置、檔案格式、資料表佈局和生命週期方面謹慎選擇。本節詳述了設計上的權衡取捨、應避免的故障模式，以及能與 BigQuery、Spark 和大規模串流管道對齊的模式。

Cloud Storage 基礎：級別、值區、一致性和生命週期

Cloud Storage 是儲存原始檔案和經整理檔案的耐用、高可用性基礎。

儲存空間級別
- Standard (熱層)：頻繁存取、延遲最低。無最短儲存時間限制。
- Nearline (冷層)：不頻繁存取 (約每月一次)。最短儲存 30 天；會收取擷取費用。
- Coldline (更冷層)：不頻繁存取 (約每季一次)。最短儲存 90 天；擷取費用較高。
- Archive (最冷層)：長期封存 (約每年一次)。最短儲存 365 天；擷取費用最高。
- Autoclass 可自動在不同級別間轉換物件；請確認提早刪除的費用和存取模式不會侵蝕節省的成本。
值區位置與複製
- Region (單一地區)：最適合在單一地理區域內滿足資料本地性和合規性要求。
- Dual-region (雙地區)：兩個配對的地區，具備自動複製功能；turbo replication 可快速提交複本，RPO 以分鐘為單位計算；是低 RPO 災難復原的理想選擇。
- Multi-region (多地區)：在一個洲內進行地理分佈，以實現廣泛的可用性、內容分發，以及涵蓋大範圍的分析。
- 選擇位置時，應滿足資料駐留法規，並將傳輸到運算資源 (Dataproc、Dataflow、BigQuery 外部資料表) 的輸出流量/延遲降到最低。
一致性與語意
- Cloud Storage 提供強大的全域性「寫入後讀取」、「中繼資料更新後讀取」以及「寫入後列出」的一致性。
- 物件寫入是不可分割 (atomic) 且不可變的；「重新命名」其實是「複製後刪除」的模式。設計時應考慮冪等 (idempotent) 複製，並驗證校驗和 (checksum) 以防止部分遷移。
存取模式與效能
- 平行複合上傳 (Parallel composite uploads) 和可續傳上傳 (resumable uploads) 可提高大型檔案的傳輸通量。
- 範圍讀取 (Range reads) 可實現高效率的欄式儲存頁尾 (columnar footers) 和選擇性讀取。
- 避免產生大量小檔案 (<8 MB)，這會增加中繼資料/列出操作的開銷；應將它們批次處理或壓縮成較大的物件。
- GZIP 不可分割，不適用於分散式讀取；建議優先使用 Parquet/ORC/Avro+Snappy 以進行可擴展的處理。
生命週期、保留與版本控制
- 值區層級的保留政策和物件鎖定 (事件型或暫時性) 可強制執行不可變性，以符合法規並減少意外刪除。
- 物件版本控制會保留先前的世代；有助於從覆寫/刪除中復原。需監控儲存成本的增長。
- 生命週期規則可自動化轉換和刪除操作。範例 (JSON)，將較舊的資料移至較冷的儲存層，並在一年後刪除： { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 30}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }
- 故障模式：如果轉換過於頻繁，會產生提早刪除費用；保留鎖定無法縮短；版本控制若無搭配壓縮，會導致成本增加。
傳輸與遷移
- 使用 Storage Transfer Service 進行從地端或其他雲端平行化、具備檢查點的遷移；對於 PB 等級的離線資料，則使用 Transfer Appliance。
- 使用 CRC32C/MD5 和 generation-match 前置條件來驗證完整性，以防止競爭條件 (race conditions)。
- 優先使用帶有 -m (平行) 和校驗和功能的 gsutil/gcloud storage；避免使用 SFTP，以免在高流量傳入時造成瓶頸。

使用 BigLake 和 Dataplex 進行統一的資料湖治理

BigLake 和 Dataplex 將跨檔案和資料表的安全性和治理標準化。

BigLake
- 將 Cloud Storage 資料公開為 BigQuery 管理的資料表 (外部)，並提供統一的精細存取控制，包括資料列層級存取政策和資料欄層級的政策標籤。
- 為 Parquet/ORC 啟用資料欄修剪 (column pruning) 和述詞下推 (predicate pushdown)，從而減少掃描的位元組數以及到 BigQuery、Dataproc 上的 Spark 和 Dataflow 等引擎的輸出流量。
- 透過 Cloud Logging 集中稽核並集中執行政策；為資料湖檔案和資料倉儲表格提供單一的控制平面。
Dataplex
- 將資料組織成湖 (lakes)、區 (zones) (原始、整理、可信) 和資產 (assets) (值區、資料集)；管理中繼資料、資料歷程和資料品質規則。
- 與敏感資料欄的政策標籤整合，並透過 IAM 在湖/區/資產範圍支援最小權限原則。
- 鼓勵在多團隊環境中進行標準化的命名、分區和結構定義管理，以避免產生「垃圾抽屜」。
治理模式
- 實作「每個租戶一個資料集」和「每個區一個值區」的模式；避免租戶間的資料洩漏。
- 對 PII 使用資料列存取政策和資料欄政策標籤。將 API 存取權限限制於經核准的身分。
- 使用 Cloud Logging 稽核存取；將過濾後的日誌路由到 Pub/Sub 以進行即時監控。

檔案格式、壓縮與查詢行為

選擇正確的格式對成本與效能有著最直接的影響。

欄式格式 (Parquet, ORC)
- 優點：欄位裁剪 (column pruning)、謂詞下推 (predicate pushdown)、每欄的編碼與壓縮、統計資訊以及可分割的檔案。
- 取捨：寫入時 CPU 耗用較高；結構演進 (schema evolution) 必須謹慎管理 (例如：ADD 新增欄位是安全的；變更型別則有風險)。
- 壓縮：追求速度用 Snappy，在支援的情況下追求更佳壓縮比用 ZSTD。除非互通性限制要求，否則應避免對欄式格式使用 GZIP。
列式導向的 Avro
- 優點：具備強型別的結構演進、區塊級壓縮 (block-level compression)、可分割；非常適合用於串流資料的落地暫存區 (landing zones) 與資料交換。
- 取捨：對於分析工作，其掃描效率低於欄式格式；應在整理過的區域 (curated zones) 中轉換為 Parquet/ORC。
CSV 與 JSON (半結構化)
- CSV：人類可讀，當值很單純時，額外開銷最小；缺乏結構、型別和一致的跳脫字元處理；大規模解析時成本高昂。
- JSON：自我描述且彈性高；若要進行可擴展的分散式讀取，必須使用換行符號分隔的 JSON (newline-delimited JSON)；格式冗長且解析時 CPU 負擔重。
- 盡可能先將原始的 CSV/JSON 落地，然後進行驗證並轉換為 Avro/Parquet 以供分析使用。
BigQuery 外部資料表與 BigLake 資料表
- Parquet/ORC 外部資料表可受益於謂詞下推和欄位裁剪；CSV/JSON 通常不行，導致掃描的位元組數更高。
- 經壓縮的 CSV (GZIP) 外部資料表無法跨 worker 分割處理；預期讀取速度會較慢。
- 範例：建立一個帶有 Hive 風格分割區的 Parquet BigLake 資料表： CREATE EXTERNAL TABLE lake.sales WITH CONNECTION us.biglake_conn OPTIONS ( format = ‘PARQUET’, hive_partitioning_mode = ‘AUTO’, hive_partitioning_source_uri_prefix = ‘gs://corp-raw/sales/’, uris = [‘gs://corp-raw/sales/date=/region=/part-*.parquet’] );

版面配置、分割、效能工程、駐留性與遷移

物件版面配置與分割
- 針對分割區與叢集鍵，採用 Hive 風格的路徑： gs://bucket/dataset/table/date=YYYY-MM-DD/hour=HH/region=us/part-00001.parquet
- 將個別檔案大小維持在 128–1024 MB 範圍內，以平衡平行處理能力與任務開銷。避免每個分割區有數百萬個檔案。
- 透過以下方式緩解小檔案問題：
  - 在用戶端批次上傳。
  - 在離峰時段使用 Dataflow/Spark 的壓縮作業來合併小檔案。
  - 將原始小檔案封存，並只將壓縮後的資料提供給分析使用。
BigQuery 分割與叢集
- 根據擷取時間或高基數的篩選欄位（例如 event_date）進行分割。避免過度分割（例如每分鐘分割），以免中繼資料暴增。
- 根據常用的篩選/排序維度（最多四個）進行叢集。叢集能增加資料的局部性並減少掃描的位元組數。
- 對於高負載的互動式分析，優先使用原生 BigQuery 資料表；對於受監管的資料湖存取、跨引擎共享和成本隔離，則使用 BigLake/外部資料表。
查詢效能的影響
- 欄式格式能大幅降低外部掃描成本；CSV/JSON 外部資料表通常需要掃描整個檔案。
- 一致性保證消除了讀取 Cloud Storage 時人為延遲的需求，但下游系統（例如 BigQuery 串流插入）可能會出現短暫的資料可見度延遲——在需要時，應透過浮水印或讀取延遲來設計。
駐留性、耐用性與復原
- 選擇 bucket/dataset 的位置以符合駐留性限制；將運算資源共置一處以減少出口流量和延遲。
- 使用雙區域搭配 turbo replication 以達成低 RPO；使用版本控制加上保留政策，以從人為錯誤和勒索軟體中復原。
- 為了 DR，使用 bucket replication 將 bucket 複寫到一個獨立的專案/區域，並用獨立的 IAM 邊界來保護。
安全遷移與驗證
- 規劃多階段遷移：植入（大量傳輸）、增量同步（mtime/視窗化複製）、切換（來源唯讀）以及切換後驗證。
- 使用校驗和、計數、位元組總數和範例解碼來進行驗證。對於表格式資料，比較資料列計數和雜湊彙總值：

undefined

使用先決條件（ifGenerationMatch）以防止在平行複製期間發生覆寫。透過版本控制或保留來源資料來維持一個可回復的視窗期。
遷移後，根據新的存取模式啟用生命週期和 Autoclass；在驗證通過前，避免啟用保留鎖定。

實務問題情境

Acme Retail 每天從物流合作夥伴接收 CSV 檔案，這些檔案會被投放到一個區域級的 Cloud Storage bucket 中。檔案偶爾會包含格式錯誤的資料列。Acme 必須將資料落地、驗證、轉換為適合分析的格式，並載入到 BigQuery 以支援近乎即時的儀表板，同時保留錯誤的資料列以供檢查，並強制執行治理。

方法：

在 Dataplex 中落地並治理原始資料
- 建立一個 Dataplex lake，並將一個 raw zone asset 對應到 gs://acme-raw/logistics/。
- 理由：集中化的治理、中繼資料和資料血緣。在 zone 層級強制執行 IAM，並使用 policy tags 標記敏感欄位，以便下游系統強制執行。
強制執行生命週期與保留政策
- 在 acme-raw 上套用 30 天的 bucket 保留政策，並啟用物件版本控制。
- 理由：保護資料免於合作夥伴的意外覆寫/刪除；較短的保留期能在成本與可復原性之間取得平衡。版本控制有助於回復錯誤的交付內容。
使用 Dataflow 批次管道進行驗證與擷取
- 透過物件完成通知來觸發每日的 Dataflow 作業。使用 schema 讀取 CSV 並進行逐筆記錄驗證；將有效的記錄寫入 BigQuery 的中繼站（依 event_date 分割），並將解析/驗證錯誤的資料路由到一個 dead-letter BigQuery 資料表。
- 理由：Dataflow 提供可擴展的平行解析和強健的 dead-letter 處理機制，讓分析師可以檢查錯誤的資料列。這反映了處理品質不一的 CSV 檔案的最佳實踐。
在 curated zone 中壓縮並轉換為 Parquet 格式
- 同一個管道將已驗證的資料以 Parquet 格式寫入 gs://acme-curated/logistics/date=YYYY-MM-DD/，檔案大小約為 256–512 MB。
- 理由：Parquet 讓 BigQuery 和 Spark 能夠進行欄位修剪和述詞下推，從而降低掃描的位元組數並改善延遲；壓縮則緩解了因合作夥伴交付模式所造成的小檔案開銷。
透過 BigLake 提供受監管的分析資料
- 在 curated Parquet 路徑上建立一個 BigLake 外部資料表，並啟用 Hive 自動分割；套用欄位級的 policy tags 和資料列存取政策，以實現針對特定合作夥伴的篩選。
- 理由：在 BigQuery 和 Spark 之間實現統一的細粒度存取，並進行集中式稽核。分割區修剪可降低基於日期篩選的掃描成本。
將關鍵彙總資料載入原生 BigQuery
- 對於熱門儀表板，執行一個排程的 BigQuery 作業，將 curated Parquet 外部資料表中最近 N 天的資料擷取到一個原生的叢集化、分割化資料表中。
- 理由：原生儲存能加速高並行性的 BI，而外部 BigLake 資料表則作為受監管的記錄系統，供更廣泛的存取使用。
使用 Cloud Logging 和 Pub/Sub 進行監控與警示
- 建立一個 log sink，將 Dataflow 和 BigQuery 載入作業的結果篩選到 Pub/Sub；與監控工具整合，以便在發生故障或錯誤資料列比率升高時立即發出警示。
- 理由：無需輪詢即可獲得針對特定資料表的營運可見性；支援 SRE 實踐。
優化儲存類別與駐留性
- 將 curated Parquet 在 Standard 儲存類別中保留 14 天，30 天後透過生命週期規則轉換到 Coldline；將 raw 和 curated bucket 與 BigQuery dataset 儲存在同一區域，以避免出口流量費用。
- 理由：在熱讀取效能與成本之間取得平衡。共置一處可維持合規性，並將延遲和出口流量費用降至最低。
驗證端到端的品質
- 每次執行後，比較 staging、curated external 和原生 BigQuery 資料表之間的計數與雜湊彙總值；隔離異常情況。
- 理由：及早偵測 schema 變動或擷取迴歸問題；密碼學或指紋雜湊能在無需完整重新掃描的情況下，提供輕量級的保證。