Google PDE: Maschinelles Lernen, KI und Datenbereitstellung — Lernleitfaden

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

Teil des Google Professional Data Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Die Erstellung von produktionsreifen Machine-Learning- und Datenbereitstellungssystemen auf Google Cloud erfordert disziplinierte Datenmodellierung, robuste Pipelines und operative Leitplanken. Dieser Abschnitt behandelt die Modellentwicklung in BigQuery ML, den verwalteten Lebenszyklus auf Vertex AI (Datasets, Training, Pipelines, Endpunkte, Feature-Engineering und Monitoring), das Design des Vorhersagepfads (Batch vs. Online), Feature-Stores und Point-in-Time-Korrektheit, Labeling und Bias-Kontrollen, Vektorsuche und Muster für Retrieval-Augmented Generation (RAG), Datenherkunft (Lineage) und Governance, Drift-Überwachung und Trigger für erneutes Training, Analyse- und Bereitstellungsschichten sowie die datenschutzkonforme Datennutzung. Der Schwerpunkt liegt auf Designentscheidungen, Skalierungsstrategien und häufigen Fehlermodi, die es zu vermeiden gilt.

BigQuery ML und Feature-Engineering

BigQuery ML ermöglicht das Training, die Evaluierung und die Vorhersage direkt in SQL, wodurch Datenverschiebungen vermieden und die Modellentwicklung an analytischen Datensätzen ausgerichtet wird.

• Modellerstellung: Verwenden Sie CREATE MODEL mit expliziten Label-Spalten und Feature-Transformationen, um Leakage zu vermeiden und Eingaben zu standardisieren. Beispiel: 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 – Unterstützung für zirkuläre Entscheidungsgrenzen hinzufügen, falls nützlich ) AS SELECT churned, tenure_months, monthly_spend, region, lat, lon, x, y FROM ds.customer_features;

• Evaluierung: Verwenden Sie ML.EVALUATE, um für den Modelltyp geeignete Metriken zu erhalten (z. B. ROC AUC für Klassifizierung, RMSE für Regression). Verfolgen Sie Baselines und Konfidenzintervalle; halten Sie Evaluierungsdatensätze zeitlich geordnet, um die zukünftige Leistung anzunähern. SELECT * FROM ML.EVALUATE(MODEL ds.churn_model, TABLE ds.eval_features);

• Vorhersage: Verwenden Sie ML.PREDICT für Online-ähnliches Scoring in BigQuery oder exportieren Sie Modelle zur Bereitstellung an anderer Stelle. Berücksichtigen Sie die Latenzbudgets des Modells, wenn Sie BigQuery für synchrones Scoring verwenden; für APIs mit hohen QPS (Queries Per Second) sollten Sie auf verwalteten Endpunkten bereitstellen. SELECT user_id, predicted_churn FROM ML.PREDICT(MODEL ds.churn_model, TABLE ds.scoring_candidates);

• Feature-Transformationen: Bevorzugen Sie deklarative TRANSFORM-Funktionen (standardize, one_hot_encoder, bucketize, quantile_bucketize, ml.feature_cross) für die Reproduzierbarkeit und um die Vorverarbeitung fest mit dem Modellartefakt zu verbinden. Halten Sie Transformationen idempotent und deterministisch.

Betriebliche Überlegungen und Fehlermodi:

• Streaming-Inserts und Aktualität von Abfragen: BigQuery-Streaming hat Eventual Consistency. Für Echtzeit-Aggregationen, die gerade geschriebene Zeilen enthalten müssen, führen Sie Abfragen mit einer Zeitverzögerung aus, die die gemessene Latenz des Streaming-Puffers übersteigt. Ein konservativer Ausgangspunkt ist, etwa das Zweifache der beobachteten durchschnittlichen Verfügbarkeitsverzögerung zu warten oder Watermarks und die Verarbeitung verspäteter Daten in Dataflow zu entwerfen, bevor die Daten in BigQuery landen.
• Kosten und Gleichzeitigkeit (Concurrency): Wenn die Concurrency-Limits von On-Demand-Slots zu einem Engpass werden, wechseln Sie zu Flatrate- oder flexiblen Reservierungen und implementieren Sie ein Workload-Management (Reservierungshierarchien und -zuweisungen), um eine vorhersagbare Kapazität sicherzustellen.
• Datenqualität: Verwenden Sie für GCS-Batch-Ladevorgänge mit fehlerhaften Zeilen Dataflow, um Datensätze zu parsen und zu validieren, wobei korrekte Zeilen in BigQuery und fehlerhafte Zeilen zur Überprüfung in eine Dead-Letter-Tabelle geschrieben werden. Vermeiden Sie, dass BigQuery ganze Dateien aufgrund einer kleinen Anzahl fehlerhafter Zeilen ablehnt.

Vertex AI-Lebenszyklus, Vorhersagepfade und Feature Stores

Vertex AI bietet durchgängig verwaltete Services für Training, Pipelines, Model Registry, Endpunkte und Monitoring.

• Datasets und Training: Registrieren Sie Datasets und Metadaten; verwenden Sie je nach Anforderung benutzerdefinierte Trainingsjobs oder AutoML. Wählen Sie Algorithmen basierend auf den Einschränkungen aus:

  • Ressourcenbeschränkte Workloads auf einzelnen VMs bevorzugen einfache Modelle (z. B. lineare Regression oder logistische Regression) aufgrund geringer Speicher-/CPU-Anforderungen.
  • Hochdimensionale Aufgaben profitieren oft von der Merkmalsauswahl (Feature Selection) oder der Kombination redundanter Merkmale, um das Training bei minimalem Genauigkeitsverlust zu beschleunigen.
  • Unüberwachte Anomalieerkennung eignet sich, wenn positive Beispiele selten sind und erwartet wird, dass zukünftige Anomalien bekannten anomalen Signaturen ähneln.

• Pipelines: Implementieren Sie Vertex AI Pipelines, um Datenvorbereitung, Training, Evaluierung und Deployment-Gates zu kodifizieren. Speichern Sie Parameter, Code-Commit-SHAs, Container-Digests und Dataset-Snapshots dauerhaft, um die Reproduzierbarkeit zu garantieren.

• Endpunkte und Vorhersage:

  • Online-Vorhersage für Workloads mit geringer Latenz. Konfigurieren Sie minimale und maximale Replikate sowie Autoscaling-Richtlinien; erstellen Sie ein Profil der Modelllatenz bei P95 und legen Sie entsprechende SLOs fest. Fügen Sie Canary-Deployments und Traffic-Splitting für sichere Rollouts hinzu.
  • Batch-Vorhersage für Jobs, bei denen der Durchsatz im Vordergrund steht (z. B. nächtliches Scoring). Batch-Verarbeitung vermeidet den Overhead pro Anfrage, ist bei großen Volumina kostengünstiger, bietet aber eine höhere Latenz.

• Feature Engineering und Feature Stores: Verwenden Sie Vertex AI Feature Store für:

  • Offline-Speicher in BigQuery für das Training.
  • Online-Speicher für Abfragen mit geringer Latenz nach Entitäts-ID. Stellen Sie die Konsistenz zwischen Training und Bereitstellung (Training-Serving Consistency) sicher, indem Sie dieselbe Transformationslogik (z. B. Dataflow-Bibliothek oder Feature-Definitionen) gemeinsam nutzen und Feature-Zeitstempel verwenden, um Datenlecks (Leakage) zu verhindern. Sorgen Sie für zeitpunktgenaue Korrektheit (Point-in-Time Correctness) mit temporalen Joins:

undefined

Design-Abwägungen:

• Latenz vs. Aktualität des Online-Speichers: Bigtable-gestützte Online-Speicher bieten eine geringe Latenz; stellen Sie sicher, dass Backfills und Streaming-Upserts idempotent sind. Übermäßiger Write Skew oder Hot Keys beeinträchtigen die Leistung – gestalten Sie Entitäts-IDs so, dass der Traffic gleichmäßig verteilt wird.
• Batch vs. Online: Batch-Verarbeitung reduziert die Komplexität und die Kosten der Bereitstellung, kann aber veraltete Vorhersagen liefern. Für dynamisches Verhalten (z. B. Empfehlungen) kombinieren Sie periodisches Neutraining mit aktuellen Features zum Zeitpunkt der Bereitstellung.

Datenqualität, Labeling, Bias, Datenschutz und Governance

Hochwertige Labels und eine strikte Governance sind die Grundlage für vertrauenswürdige Modelle.

• Labeling und Ungleichgewicht (Imbalance):

  • Verwenden Sie klare Richtlinien für das Labeling und QA-Stichproben. Verfolgen Sie das Inter-Annotator-Agreement.
  • Beheben Sie Klassenungleichgewichte (Class Imbalance) durch geschichtete Stichproben (Stratified Sampling), Neugewichtung (Reweighting) oder Resampling; überwachen Sie Precision/Recall pro Klasse, nicht nur die Gesamtgenauigkeit.
  • Behalten Sie Nullwerte absichtlich bei. Wenn ein Modell numerische Eingaben erfordert, kodieren Sie Nullwerte explizit (z. B. 0 mit einem „was_null“-Indikator) und validieren Sie die nachgelagerten Auswirkungen; vermeiden Sie das stillschweigende Verwerfen informativer fehlender Werte.

• Overfitting und Generalisierung:

  • Zu den Gegenmaßnahmen gehören vielfältigere Trainingsdaten, kleinere Feature-Sets und eine stärkere Regularisierung.
  • Early Stopping und Kreuzvalidierung (Cross-Validation) sind für neuronale Netze unerlässlich; Subsampling kann die Trainingszeit reduzieren, wenn eine Skalierung der Architektur oder Hardware nicht möglich ist.

• Governance und Herkunft (Lineage):

  • Verfolgen Sie die Herkunft (Lineage) mit Vertex ML Metadata, Model Registry und Data Catalog. Erfassen Sie Dataset-Versionen, Transformationen, Hyperparameter und die Umgebung.
  • Genehmigungsworkflows: Fordern Sie vor dem Deployment eine manuelle Genehmigung an, indem Sie die Zustände der Model Registry und Cloud Build/Deploy mit Richtlinienprüfungen verwenden. Speichern Sie Artefakte in der Artifact Registry; signieren Sie Container und erzwingen Sie Binary Authorization für gesteuerte Rollouts (Gated Rollouts).

• Monitoring, Drift und Neutraining:

  • Aktivieren Sie das Modell-Monitoring für Prediction Skew, Feature Drift und Leistungsabfall. Verwenden Sie Verteilungsmetriken (z. B. PSI, KL-Divergenz) und eine Evaluierung, die die Verzögerung von Ground-Truth-Daten berücksichtigt, wenn Labels später eintreffen.
  • Richten Sie Auslöser für das Neutraining ein, die auf statistisch signifikantem Drift, SLO-Verletzungen oder Geschäftsereignis-Fenstern basieren. Automatisieren Sie Neutrainings-Pipelines, aber steuern Sie die Beförderung (Promotion) durch Evaluierungen und Bias-Prüfungen.
  • Achten Sie auf stillen Datendrift (Silent Data Drift) durch vorgelagerte Schemaänderungen; setzen Sie Schema-Verträge durch und lassen Sie sich bei fehlenden oder verschobenen Features benachrichtigen.

• Datenschutzorientiertes Design:

  • Klassifizieren Sie Daten mit Data Catalog Policy-Tags; erzwingen Sie Sicherheit auf Spalten- und Zeilenebene in BigQuery mit Datenmaskierungsrichtlinien.
  • Minimieren Sie die Datenerfassung; implementieren Sie SLAs für die Datenaufbewahrung und -löschung, die an die Zweckbindung gekoppelt sind.
  • Wenden Sie DLP zur Erkennung und De-Identifizierung an; verschlüsseln Sie Daten mit CMEK; isolieren Sie Services mit VPC Service Controls; stellen Sie feingranulares IAM sicher und verwenden Sie dedizierte Service Accounts nach dem Prinzip der geringsten Rechte (Least Privilege).
  • Schwärzen Sie für Monitoring und Logging personenbezogene Daten (PII) und vermeiden Sie Payload-Logging, wo es nicht notwendig ist.

Vektorsuche, RAG-Pipelines und Analytics-Serving-Layer

Modernes Retrieval und Serving erfordern sowohl vektor-native Komponenten als auch bewährte Analytics-Speicher.

• Vektorsuche und Embeddings:

  • Verwenden Sie Vertex AI Vector Search oder BigQuery Vektorsuche für groß angelegtes Nearest-Neighbor-Retrieval mit niedriger Latenz; wählen Sie AlloyDB for PostgreSQL mit pgvector für anwendungszentrierte Semantik und transaktionale Anforderungen.
  • Generieren Sie Embeddings im Batch-Verfahren mit Vertex Pipelines; speichern Sie Vektoren zusammen mit dichten Metadaten; partitionieren und indizieren Sie intelligent (z. B. nach Dokumentendomäne), um die Latenz zu begrenzen.

• Retrieval-Augmented-Generation-Pipelines:

  • Inhalte über Dataflow oder Dataproc aufnehmen (Ingestion), Text extrahieren, in Chunks aufteilen, einbetten und in einem Vektorspeicher indizieren. Source-of-Truth-Referenzen für die Nachverfolgbarkeit beibehalten.
  • Implementieren Sie Freshness-Strategien: periodisches Re-Embedding, Invalidierung bei Quell-Updates und Canary-Indizierung zur Validierung der Qualität vor dem Austausch von Indizes.
  • Überwachen Sie die Retrieval-Qualität (Hit Rate, MRR, nDCG) und die Inhaltssicherheit; setzen Sie Guardrails und Zugriffskontrollen für eingeschränkte Daten durch.

• Analytics-Serving-Layer und Datenprodukte:

  • Kuratieren von Bronze/Silver/Gold-Datenprodukten in BigQuery; verwenden Sie Partitionierung und Clustering, um die Scan-Kosten zu minimieren. Materialisierte Sichten können gängige Abfragen beschleunigen.
  • Für Key-Value-Speicher mit niedriger Latenz oder Zähler mit hohem QPS-Wert Bigtable mit gut verteilten Zeilenschlüsseln verwenden; Hot-Spotting durch Salting oder Hashing von Präfixen vermeiden.
  • Für OLTP-Workloads und starke Konsistenz Cloud SQL oder Spanner verwenden; Analytics über geplantes ELT nach BigQuery auslagern.
  • Streaming-Design: Pub/Sub → Dataflow → BigQuery/Bigtable mit Autoscaling. Backlog- und Watermark-Metriken überwachen; das Standard-Autoscaling reicht für elastische Lasten aus und hält die Kosten unter Kontrolle.

Tipp für den Betrieb:

• Um Benachrichtigungen für bestimmte Einfügejobs in BigQuery-Tabellen auszulösen, exportieren Sie relevante Cloud Logging-Einträge über einen erweiterten Filter nach Pub/Sub und verknüpfen Sie dann Alerts mit der Subscription:

undefined

Praktisches Problemszenario

AcmeStyle, ein Mode-Marktplatz, möchte die Empfehlungen auf seiner Website aktuell halten, da sich die Nutzerpräferenzen stündlich ändern. Sie streamen das Klick- und Kaufverhalten und müssen dies mit Katalogkontext kombinieren, um Empfehlungen mit geringer Latenz und kontrollierten Kosten zu aktualisieren.

Ansatz:

1. Stream-Ingestion und Quality Gates

• Verwendung von Pub/Sub für die Event-Ingestion von Web und Mobilgeräten. Ein Dataflow-Streaming-Job validiert Schemata, reichert sie mit Katalogdaten an und schreibt:
  • Bereinigte Events in partitionierte BigQuery-Tabellen (event_date) für Offline-Analytics und Training.
  • Aggregierte User-Feature-Updates in den Vertex AI Feature Store (Online-Store), geschlüsselt nach user_id. Begründung: Pub/Sub entkoppelt Producer und Consumer; Dataflow bietet Exactly-Once-Semantik mit idempotenten Upserts; partitioniertes BigQuery verwaltet Kosten und Aufbewahrung; der Online-Store ermöglicht Lookups im Millisekundenbereich.

2. Feature-Definitionen mit Point-in-Time-Korrektheit

• Definition von Features wie rollierender CTR, Markenaffinität und Aktualität (Recency) mit explizitem event_time. Materialisierung in:
  • Offline-Store in BigQuery für das Training mit temporalen Joins, die auf feature_ts <= label_ts beschränkt sind.
  • Online-Store für das Serving mit TTLs, um veraltete Werte zu verhindern. Begründung: Eindeutige Zeitstempel verhindern Label Leakage; konsistente Definitionen über Offline und Online hinweg gewährleisten die Parität zwischen Training und Serving.

3. Modelltraining und Lineage

• Implementierung einer Vertex AI Pipeline, die:
  • Trainingsdaten aus BigQuery unter Verwendung von Zeitfenstern (z. B. die letzten 30 Tage) extrahiert.
  • Dieselben Transformationen anwendet, die auch im Serving verwendet werden (gemeinsame Bibliothek).
  • Ein Ranking-Modell trainiert; Metadaten (Dataset-Snapshot-IDs, Code-Commit-SHA, Hyperparameter) in ML Metadata protokolliert und das Modell in der Model Registry registriert. Begründung: Pipelines machen Ausführungen reproduzierbar und auditierbar; die Model Registry zentralisiert Versionen und Genehmigungen.

4. Batch- und Online-Prediction-Pfade

• Nächtliche Batch-Predictions, die die gesamte Katalog-Nutzer-Matrix bewerten (Scoring) und für Backfill und A/B-Tests in BigQuery schreiben.
• Online-Predictions über einen Vertex-Endpunkt, der:
  • Frische Nutzer-Features aus dem Online-Store abruft.
  • Die Top-K-Kandidaten bewertet (Scoring), gefiltert nach Inventar und Verfügbarkeit.
  • Ergebnisse für kurze Zeit zwischenspeichert, um Lastspitzen abzufangen. Begründung: Batch bietet Breite und Kosteneffizienz; Online erfasst das neueste Verhalten für hochwertige Sitzungen. Autoscaling-Endpunkte halten Latenz-SLOs ein; Caching reduziert die Tail-Latenz und die Kosten.

5. Monitoring, Drift-Erkennung und Retraining-Richtlinie

• Modell-Monitoring für Feature-Drift und Prediction-Skew aktivieren; Verteilungen mit den Trainings-Baselines vergleichen. CTR/CVR-SLOs verfolgen und bei Verschlechterung alarmieren.
• Kontinuierliches Retraining unter Verwendung eines rollierenden Fensters, das historische und neue Daten kombiniert; Retraining auslösen, wenn der Drift Schwellenwerte überschreitet oder mindestens wöchentlich. Begründung: Modetrends ändern sich schnell; die Mischung aus historischen und aktuellen Signalen stabilisiert das Lernen und hält es gleichzeitig auf dem neuesten Stand.

6. Datenschutz und Governance

• PII-Spalten mit Data Catalog Policy Tags versehen; Sicherheit auf Spaltenebene in BigQuery durchsetzen und bei Bedarf maskieren. DLP-Scans auf Roh-Events ausführen; nur notwendige Felder speichern.
• Menschliche Genehmigung für die Beförderung von Modellen von Staging nach Produktion über Cloud Build-Trigger erfordern, die mit den Genehmigungsstatus der Model Registry integriert sind. Begründung: Zugriff nach dem Least-Privilege-Prinzip reduziert das Risiko; die Steuerung von Deployments gewährleistet Compliance und Sicherheit.

7. Kosten- und Kapazitätskontrollen

• BigQuery-Reservierungen verwenden, um eine vorhersagbare Slot-Kapazität für Trainingsfenster zu garantieren.
• Dataflow-Worker automatisch basierend auf dem Backlog skalieren; Hot Keys im Feature Store durch Hashing von user_id-Präfixen sharden, um Hot-Spotting zu verhindern. Begründung: Vorhersagbare Kapazität vermeidet Konkurrenzsituationen; Autoscaling passt die Ausgaben an die Nachfrage an; ausbalancierte Schlüssel gewährleisten Updates mit geringer Latenz.

Dieses Design hält Empfehlungen aktuell, indem es Streaming-Features für das Serving mit regelmäßigem Retraining auf neuen Daten vereint, während Korrektheit, Governance und vorhersagbare Leistung bei Skalierung aufrechterhalten werden.

← Workflow-Orchestrierung und Pipeline-Automatisierung · Alle Domänen · Data Governance →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Google durchsuchen →