Google PDE: 機器學習、AI 與資料服務 — 學習指南
屬於 Google Professional Data Engineer — 學習指南. 使用經過驗證的解答練習: Google 考試中心, 或參加限時模擬考試: ExamRoll.io.
總覽
在 Google Cloud 上建構生產等級的機器學習與資料服務系統,需要嚴謹的資料模型、穩健的管線以及維運上的防護機制。本節涵蓋 BigQuery ML 中的模型開發、Vertex AI 上的託管生命週期(資料集、訓練、管線、端點、特徵工程與監控)、預測路徑設計(批次 vs. 線上)、特徵儲存庫與特定時間點正確性 (point-in-time correctness)、標註與偏差控制、向量搜尋與檢索增強生成 (retrieval-augmented generation) 模式、血緣與治理、漂移監控與再訓練觸發器、分析服務層,以及注重隱私的資料使用方式。重點將放在設計決策、擴展策略,以及應避免的常見故障模式。
BigQuery ML 與特徵工程
BigQuery ML 讓您能直接在 SQL 中進行訓練、評估和預測,無需移動資料,並讓模型開發與分析資料集保持一致。
模型建立:使用
CREATE MODEL搭配明確的標籤欄位和特徵轉換,以避免資料洩漏並標準化輸入。 範例: CREATE OR REPLACE MODEL ds.churn_model OPTIONS( model_type=‘logistic_reg’, input_label_cols=[‘churned’], l1_reg=0.0, l2_reg=1.0, data_split_method=‘AUTO’ ) TRANSFORM( standardize(tenure_months) AS tenure_std, quantile_bucketize(monthly_spend, 10) AS spend_bkt, one_hot_encoder(region) AS region_ohe, ml.feature_cross(struct(bucketize(lat, 60), bucketize(lon, 60))) AS latlon_cross, (xx + yy) AS r2 – 當有助於增加圓形決策邊界支援時使用 ) AS SELECT churned, tenure_months, monthly_spend, region, lat, lon, x, y FROM ds.customer_features;評估:使用
ML.EVALUATE取得適合該模型類型的指標(例如,分類模型的 ROC AUC,迴歸模型的 RMSE)。追蹤基準線和信賴區間;保持評估資料集按時間排序,以近似未來的效能。 SELECT * FROM ML.EVALUATE(MODEL ds.churn_model, TABLE ds.eval_features);預測:在 BigQuery 中使用
ML.PREDICT進行類線上的評分,或將模型匯出至其他地方提供服務。當使用 BigQuery 進行同步評分時,需考慮模型的延遲預算;對於高 QPS 的 API,應部署到託管端點。 SELECT user_id, predicted_churn FROM ML.PREDICT(MODEL ds.churn_model, TABLE ds.scoring_candidates);特徵轉換:優先使用宣告式的
TRANSFORM函式(standardize、one_hot_encoder、bucketize、quantile_bucketize、ml.feature_cross)以確保可重現性,並將預處理鎖定在模型產物中。保持轉換的冪等性 (idempotent) 和確定性 (deterministic)。
維運考量與故障模式:
- 串流插入與查詢新鮮度:BigQuery 串流具有最終一致性。對於必須包含剛寫入資料列的即時彙總,執行查詢時應加上一個時間延遲,該延遲需超過測量到的串流緩衝區延遲。一個保守的起點是等待大約觀察到的平均可用性延遲的 2 倍時間,或是在資料落地到 BigQuery 之前,先在 Dataflow 中設計浮水印 (watermarks) 和延遲資料處理機制。
- 成本與並行性:如果按需 (on-demand) 的 slot 並行性限制成為瓶頸,請切換到固定費率 (flat-rate) 或彈性 (flexible) 預留,並實施工作負載管理(預留階層與指派),以確保可預測的容量。
- 資料品質:對於包含格式錯誤資料列的 GCS 批次載入,使用 Dataflow 來解析和驗證記錄,將正確的資料列寫入 BigQuery,並將錯誤的資料列寫入一個死信 (dead-letter) 資料表以供檢查。避免因少數幾筆錯誤資料列而導致 BigQuery 拒絕整個檔案。
Vertex AI 生命週期、預測路徑與特徵存放區
Vertex AI 為訓練、管道、模型註冊、端點和監控提供端對端的託管服務。
資料集與訓練:註冊資料集和元資料;在適當情況下使用自訂訓練任務或 AutoML。根據限制條件選擇演算法:
- 資源受限的單一 VM 工作負載偏好使用簡單模型 (例如,線性迴歸或邏輯迴歸),因為其記憶體/CPU 需求較低。
- 高維度任務通常可透過特徵選取或結合多餘特徵來加速訓練,同時將準確度損失降至最低。
- 當正向樣本稀少,且預期未來的異常會與已知的異常特徵相似時,適合使用非監督式異常偵測。
管道:實作 Vertex AI Pipelines 以將資料準備、訓練、評估和部署關卡程式碼化。持久化保存參數、程式碼提交的 SHA 值、容器摘要和資料集快照,以保證可重現性。
端點與預測:
- 用於低延遲工作負載的線上預測。設定最小和最大複本數以及自動擴展政策;分析模型的 P95 延遲,並據此設定 SLO。新增金絲雀部署和流量分割以進行安全的推出。
- 用於處理量優先任務 (例如,夜間評分) 的批次預測。批次預測可避免每個請求的額外開銷,對於大量資料來說成本較低,但延遲較高。
特徵工程與特徵存放區:使用 Vertex AI Feature Store 進行:
- 用於訓練的離線存放區 (在 BigQuery 中)。
- 用於依實體 ID 進行低延遲查詢的線上存放區。 透過共享相同的轉換邏輯 (例如,Dataflow 函式庫或特徵定義) 並使用特徵時間戳記來防止資料洩漏,以強制執行訓練與服務的一致性。透過時間性聯結 (temporal join) 維護時間點正確性:
undefined
設計上的權衡取捨:
- 線上存放區的延遲與新鮮度:由 Bigtable 支援的線上存放區提供低延遲;確保回填和串流更新插入操作具備冪等性。過度的寫入偏斜或熱點鍵會降低效能——應設計實體 ID 以均勻分佈流量。
- 批次與線上:批次處理可降低服務的複雜度和成本,但可能提供過時的預測。對於動態行為 (例如推薦系統),應結合定期重新訓練與在服務時使用最新的特徵。
資料品質、標註、偏見、隱私與治理
高品質的標註和嚴謹的治理是建立可信賴模型的基礎。
標註與不平衡:
- 使用清晰的標註指南和品質保證 (QA) 抽樣。追蹤標註者之間的一致性。
- 透過分層抽樣、重新加權或重抽樣來處理類別不平衡問題;監控每個類別的精確率/召回率,而不僅僅是整體準確度。
- 刻意保留空值 (null)。如果模型需要數值輸入,應明確地對空值進行編碼 (例如,用 0 並加上一個「was_null」指標),並驗證對下游的影響;避免默默地丟棄帶有資訊的缺失值。
過擬合與泛化:
- 緩解方法包括使用更多樣化的訓練資料、更小的特徵集和更強的正規化。
- 提早停止和交叉驗證對神經網路至關重要;當架構或硬體擴展不可行時,子抽樣可以減少訓練時間。
治理與血緣:
- 使用 Vertex ML Metadata、Model Registry 和 Data Catalog 來追蹤血緣。記錄資料集版本、轉換、超參數和環境。
- 核准工作流程:在部署前需要人工核准,使用 Model Registry 的狀態以及帶有政策檢查的 Cloud Build/Deploy。將產出物儲存在 Artifact Registry;簽署容器並強制執行 Binary Authorization 以進行門控式推出。
監控、漂移與重新訓練:
- 啟用模型監控以偵測預測偏斜、特徵漂移和效能下降。使用分佈指標 (例如,PSI、KL 散度) 以及在標籤延遲到達時,考量到真實標籤延遲的評估方法。
- 根據統計上顯著的漂移、違反 SLO 或業務事件窗口來建立重新訓練的觸發器。自動化重新訓練管道,但透過評估和偏見檢查來把關模型的晉升。
- 注意上游結構變更導致的無聲資料漂移;強制執行結構合約,並在特徵缺失或偏移時發出警報。
具備隱私意識的設計:
- 使用 Data Catalog 政策標籤對資料進行分類;在 BigQuery 中強制執行欄和列層級的安全性,並搭配資料遮罩政策。
- 最小化資料收集;實施與目的限制相關的資料保留和刪除服務等級協議 (SLA)。
- 應用 DLP 進行探索和去識別化;使用 CMEK 加密資料;使用 VPC Service Controls 隔離服務;確保細緻的 IAM 並使用具備最低權限的專用服務帳戶。
- 對於監控和日誌記錄,應編輯個人識別資訊 (PII),並在非必要時避免記錄酬載。
向量搜尋、RAG 管線與分析服務層
現代的檢索與服務,同時需要原生支援向量的元件以及經過驗證的分析儲存庫。
向量搜尋與嵌入:
- 使用 Vertex AI Vector Search 或 BigQuery 向量搜尋來進行大規模、低延遲的最近鄰擷取;若有以應用程式為中心的語意和交易需求,則選擇 AlloyDB for PostgreSQL 搭配 pgvector。
- 使用 Vertex Pipelines 批次產生嵌入;將向量與密集的元資料一同儲存;聰明地進行分割與索引(例如,依文件領域)以限制延遲。
檢索增強生成 (RAG) 管線:
- 透過 Dataflow 或 Dataproc 擷取內容,然後提取文字、分塊、嵌入並索引至向量儲存庫。維護真實來源的參考以確保可追溯性。
- 實作新鮮度策略:定期重新嵌入、來源更新時的失效處理,以及在交換索引前用 Canary 索引來驗證品質。
- 監控檢索品質(命中率、MRR、nDCG)與內容安全;對受限制的資料強制執行防護機制與存取控制。
分析服務層與資料產品:
- 在 BigQuery 中整理出銅級/銀級/金級的資料產品;使用分割與叢集來最小化掃描成本。具體化視觀表可以加速常見的查詢。
- 對於低延遲的鍵值儲存或高 QPS 的計數器,使用 Bigtable 並搭配分佈均勻的資料列鍵;透過對前綴進行加鹽或雜湊來避免熱點問題。
- 對於 OLTP 工作負載與強一致性需求,使用 Cloud SQL 或 Spanner;透過排程的 ELT 將分析工作卸載至 BigQuery。
- 串流設計:Pub/Sub → Dataflow → BigQuery/Bigtable 並啟用自動擴展。監控待辦項目與浮水印指標;預設的自動擴展足以應對彈性負載,同時控制成本。
操作提示:
- 若要在特定的 BigQuery 資料表插入作業完成時觸發通知,可使用進階篩選器將相關的 Cloud Logging 項目匯出至 Pub/Sub,然後從該訂閱設定警示: resource.type=“bigquery_resource” protoPayload.methodName=“jobservice.jobcompleted” protoPayload.serviceData.jobCompletedEvent.job.jobConfiguration.load.destinationTable.tableId=“target_table”
實際問題情境
AcmeStyle 是一家時尚市集,希望隨著使用者偏好每小時的變化,即時更新站內推薦。他們串流處理點擊與購買行為,並需要將這些行為與商品目錄情境結合,以低延遲和可控的成本來更新推薦內容。
方法:
- 串流擷取與品質閘門
- 使用 Pub/Sub 從網站和行動裝置擷取事件。一個 Dataflow 串流作業會驗證結構、用商品目錄資料來豐富內容,並寫入:
- 乾淨的事件至 BigQuery 的分割資料表 (依 event_date) 中,用於離線分析與訓練。
- 匯總後的使用者特徵更新至 Vertex AI Feature Store (線上儲存庫),並以 user_id 為鍵。 理由:Pub/Sub 解耦了生產者與消費者;Dataflow 提供精確一次的語意與冪等的新增或更新操作;分割的 BigQuery 管理成本與資料保留;線上儲存庫則實現了毫秒級的查詢。
- 具備時間點正確性的特徵定義
- 定義如滾動點擊率、品牌偏好度與近期性等特徵,並明確指定 event_time。將其具體化至:
- BigQuery 中的離線儲存庫,用於訓練,並透過時間性聯結限制 feature_ts <= label_ts。
- 線上儲存庫,用於服務,並設定 TTL 以防止過時的值。 理由:明確的時間戳記可防止標籤洩漏;離線與線上一致的定義確保了訓練與服務之間的一致性。
- 模型訓練與血緣
- 實作一個 Vertex AI Pipeline,它會:
- 使用時間視窗(例如,過去 30 天)從 BigQuery 提取訓練資料。
- 應用與服務時相同的轉換(使用共用函式庫)。
- 訓練一個排序模型;將元資料(資料集快照 ID、程式碼 commit SHA、超參數)記錄到 ML Metadata,並將模型註冊到 Model Registry。 理由:Pipelines 使執行過程可重現且可稽核;Model Registry 則集中管理版本與核准。
- 批次與線上預測路徑
- 每晚進行批次預測,對完整的商品目錄-使用者矩陣進行評分,並將結果存入 BigQuery 以供回填與 A/B 測試。
- 透過一個 Vertex 端點進行線上預測,該端點會:
- 從線上儲存庫擷取最新的使用者特徵。
- 對依庫存和可得性篩選後的前 K 個候選項目進行評分。
- 將結果快取一小段時間以吸收突發流量。 理由:批次處理提供廣度與成本效益;線上處理則捕捉高價值工作階段的最新行為。自動擴展的端點維持延遲 SLOs;快取則降低了尾部延遲與成本。
- 監控、漂移偵測與重新訓練策略
- 啟用模型監控以偵測特徵漂移與預測偏移;將分佈情況與訓練基準線進行比較。追蹤 CTR/CVR 的 SLOs,並在效能下降時發出警示。
- 使用結合歷史與新資料的滾動視窗持續重新訓練;當漂移超過閾值或至少每週一次時觸發重新訓練。 理由:時尚趨勢變化迅速;融合歷史與近期信號可以在保持更新的同時穩定學習過程。
- 隱私與治理
- 使用 Data Catalog 政策標籤標記 PII 欄位;在 BigQuery 中強制執行欄位級安全性,並在需要時進行遮罩。對原始事件執行 DLP 掃描;僅儲存必要的欄位。
- 透過與 Model Registry 核准狀態整合的 Cloud Build 觸發器,要求人工核准才能將模型從預備環境推廣至生產環境。 理由:最小權限存取降低了風險;部署前的閘門控管確保了合規性與安全性。
- 成本與容量控制
- 使用 BigQuery 預留來保證訓練視窗期間有可預測的 slot 容量。
- 根據待辦項目量自動擴展 Dataflow worker;透過雜湊 user_id 前綴來分片特徵儲存庫中的熱鍵,以防止熱點問題。 理由:可預測的容量避免了資源競爭;自動擴展使支出與需求相符;平衡的鍵則維持了低延遲的更新。
此設計透過將用於服務的串流特徵與基於近期資料的定期重新訓練相結合,來保持推薦內容的新鮮度,同時在大規模下維持正確性、治理與可預測的效能。
← 工作流程編排與管線自動化 · 所有領域 · 資料治理、安全性、可靠性與成本營運 →
練習這些題目 → · 在 ExamRoll.io 上限時練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通過考試 →