Google PDE: Data Engineering-Architektur und -Design — 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 Architektur und das Design von Data Engineering auf Google Cloud bringen Domänengrenzen, Verarbeitungsmuster und die Fähigkeiten der Services in Einklang, um zuverlässige, skalierbare und kosteneffiziente Datenplattformen bereitzustellen. Effektive Designs gestalten Storage, Compute, Orchestrierung und Serving unabhängig voneinander skalierbar; kodifizieren Verträge, damit Domänen zusammenarbeiten können; und validieren Risiken frühzeitig mit messbaren Service-Level Objectives (SLOs). Dieser Abschnitt fasst kanonische Architekturstile (Data Mesh, Lake, Warehouse, Lakehouse, operative Speicher), Verarbeitungsmodi (Batch, Micro-Batch, Streaming, ereignisgesteuert, Lambda) und die Kompromisse zwischen Skalierbarkeit, Latenz, Verfügbarkeit, Konsistenz und Kosten zusammen. Er behandelt auch die regionale und Multi-Cloud-Platzierung, die Schema-Evolution, den End-to-End-Datenlebenszyklus, die Workload-basierte Service-Auswahl und risikogesteuerte Validierungspraktiken, die auf Google Cloud zugeschnitten sind.

Architekturparadigmen und Verarbeitungsmuster

• Data Mesh, Domänen und Datenprodukte:
  • Befähigen Sie Domänenteams, „Datenprodukte“ mit klaren Zuständigkeiten, SLOs, Zugriffsrichtlinien und Dokumentation zu veröffentlichen. Verwenden Sie Dataplex, um Domänen zu definieren, Metadaten zu verwalten und konsistente Richtlinien über BigQuery und Cloud Storage hinweg anzuwenden. Produkte können BigQuery-Datasets, Pub/Sub-Topics oder Cloud Storage-Pfade bereitstellen, deren Verträge über Pub/Sub-Schemas und BigQuery-Tabellenschemas durchgesetzt werden.
• Data Lake:
  • Rohdatenspeicherung in offenen Formaten (Parquet/Avro) in Cloud Storage mit Lifecycle-Management und Versionierung. Geeignet für heterogene Workloads (Spark auf Dataproc, Dataflow, Presto/Trino) und Multi-Cloud-Portabilität. Kompromiss: Eventual-Consistency-Semantik in Objektspeichern; entwerfen Sie für Idempotenz und metadatengesteuerte Deduplizierung.
• Data Warehouse:
  • Kuratierte, verwaltete Analysen in BigQuery. Optimiert für ANSI SQL, Trennung von Storage und Compute sowie granulare Sicherheit. Kompromisse: Streaming-Inserts weisen eine kurze Veralterung zur Abfragezeit auf; bevorzugen Sie Batch-Ladevorgänge oder Inserts mit gepufferten Abfragen für strikte Freshness-SLAs.
• Lakehouse:
  • Kombination von offenem Data-Lake-Speicher mit Warehouse-Funktionen. Speichern Sie auf Google Cloud Parquet/Avro in Cloud Storage; nutzen Sie externe BigQuery-Tabellen aus Kostengründen und verwaltete BigQuery-Tabellen für Leistung und Governance. Dataflow oder Dataproc sorgt für ACID-ähnliche Merge-Semantik mit Partitionierungs-/Clustering-Strategien.
• Architektur für operative Speicher:
  • Transaktionale oder Key-Value-Speicher mit niedriger Latenz, die Anwendungen unterstützen. Wählen Sie Cloud SQL für traditionelles OLTP, Cloud Spanner für global konsistentes SQL mit horizontaler Skalierung und Bigtable für sehr hohen Durchsatz und Wide-Column-Zugriffsmuster. Trennen Sie operative Speicher von Analysesystemen; verwenden Sie CDC (Datastream), um Änderungen in Pub/Sub, Cloud Storage oder BigQuery zu erfassen.

Verarbeitungsmuster und ihre Anwendungsfälle:

• Batch: Periodische, umfangreiche Transformationen (z. B. nächtliche Feature-Generierung). Tools: Dataflow Batch, Dataproc. Fehlermodi: Timeouts bei langlaufenden Jobs, Skew; Abhilfe durch Autoscaling und Repartitionierung schaffen.
• Micro-Batch: Kleine, häufige Batches (z. B. jede Minute), um Aktualität (Freshness) mit Stabilität und Kosten in Einklang zu bringen. Verwenden Sie in BigQuery geplante Abfragen oder Dataflow mit festen Fenstern (Fixed Windows).
• Streaming: Latenz im Millisekunden- bis Sekundenbereich bei unbegrenzten Daten (Unbounded Data). Verwenden Sie Pub/Sub + Dataflow. Behandeln Sie verspätete/außer der Reihe eintreffende Ereignisse mit Event-Time-Windows und Watermarks; stellen Sie Idempotenz sicher, um Duplikate zu vermeiden.
• Ereignisgesteuert (Event-driven): Ausgelöst durch Änderungen (GCS Finalize, Pub/Sub-Nachrichten). Verwenden Sie Cloud Functions oder Cloud Run für zustandslose Reaktionen und Dataflow für zustandsbehaftete Verarbeitung. Kompromiss: Kosten pro Ereignis vs. Durchsatz.
• Lambda-Pattern: Pflegen Sie sowohl Streaming- als auch Batch-Pfade für Genauigkeit und Wiederverarbeitung. Die Komplexität verdoppelt sich; erwägen Sie eine Kappa-ähnliche Vereinfachung, bei der alles aus einem unveränderlichen Log (Archivierung von Pub/Sub in Cloud Storage) wiederholbar ist.

Kurzes Beispiel für eine Dataflow-Streaming-Konfiguration für verspätete Daten:

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

Domänenverantwortung, Datenprodukte und Verträge

• Verantwortung und SLOs:
  • Jedes Domänenteam definiert und betreibt seine Datenprodukte mit SLOs für Verfügbarkeit, Latenz und Datenqualität. Veröffentlichen Sie SLOs über Dataplex-Kataloge und überwachen Sie sie mit Cloud Monitoring SLIs (z. B. zur pünktlichen Vollständigkeit von Partitionen).
• Verträge und Interoperabilität:
  • Setzen Sie Schemas mit der Pub/Sub Schema Registry (Avro/Proto) und BigQuery-Tabellenschemas durch. Validieren Sie bei der CSV-Ingestion in Dataflow und leiten Sie fehlerhafte Zeilen zur Analyse an eine Dead-Letter-Tabelle weiter. Arbeiten Sie mit offenen Formaten in Cloud Storage und externen BigQuery-Tabellen, wenn mehrere Engines dieselben Daten lesen müssen.
• Schema-Evolution:
  • Bevorzugen Sie abwärtskompatible Änderungen: Fügen Sie nullbare Spalten hinzu, fügen Sie optionale Felder in Avro/Proto hinzu, vermeiden Sie Umbenennungen/Löschungen ohne Deprecation-Zeitfenster. Kommunizieren Sie Änderungen über versionierte Verträge und Deprecation-Zeitpläne.
  • BigQuery-Beispiel (abwärtskompatibles Hinzufügen einer Spalte):

ALTER TABLE sales.orders
ADD COLUMN coupon_code STRING;

• Auswirkungen auf Consumer:
  • Führen Sie eine semantische Versionierung von Schemas durch; veröffentlichen Sie während der Migration sowohl v1 als auch v2. Leiten Sie beim Streaming an versionierte Topics weiter oder fügen Sie ein Feld für die Schemaversion hinzu. Stellen Sie autorisierte Ansichten (Authorized Views) in BigQuery bereit, um Consumer von physischen Änderungen zu isolieren.
• Governance und Lineage:
  • Verwenden Sie Dataplex und Data Catalog für Metadaten, Tags (z. B. PII) und Lineage. Wenden Sie Sicherheit auf Zeilen- und Spaltenebene in BigQuery an. Integrieren Sie zur Data Loss Prevention (DLP) Cloud DLP in die Ingestion (z. B. über Cloud Run- oder Dataflow-Transformationen), um sensible Felder vor der Speicherung zu tokenisieren oder zu schwärzen.

Nicht-funktionale Kompromisse und Bereitstellungstopologie

• Skalierbarkeit:
  • BigQuery skaliert elastisch für Analysen; Bigtable skaliert linear mit der Anzahl der Knoten, erfordert aber ein sorgfältiges Row-Key-Design (z. B. gehashte oder rotierte Präfixe), um Hotspotting zu vermeiden. Das Autoscaling von Dataflow reagiert auf Rückstände (Backlogs); entwerfen Sie für Gegendruck (Backpressure), indem Sie die Flusssteuerung von Pub/Sub nutzen.
• Latenz:
  • Das Streamen in BigQuery bietet Inserts mit geringer Latenz, aber Abfragen können eine leichte Verzögerung aufweisen; entwerfen Sie Abfragen mit einem Aktualitätspuffer oder auf Watermarks basierenden Fenstern. Für Lesevorgänge im Sub-100-ms-Bereich bei hoher Skalierung sollten Daten vorab berechnet und über Bigtable oder Memorystore bereitgestellt werden.
• Verfügbarkeit und Konsistenz:
  • Cloud Spanner bietet stark konsistentes, global verteiltes SQL. Bigtable bietet hohe Verfügbarkeit mit Eventual Consistency über Cluster hinweg. Die Verfügbarkeit von BigQuery ist regional oder multiregional; materialisieren Sie kritische Datensätze zur Erhöhung der Ausfallsicherheit in einer Multi-Region.
• Kosten:
  • Optimieren Sie BigQuery durch Partitionierung und Clustering, um die Anzahl der gescannten Bytes zu reduzieren. Bei kleinen Dateien über netzwerkbeschränkte Verbindungen sollten Sie diese bündeln (Batching/Bundling), um den RPC-Overhead zu verringern. Verwenden Sie die BigQuery BI Engine für gecachte, interaktive Dashboards, wo es angebracht ist.
• Regional, multiregional, hybrid und Multi-Cloud:
  • Ein regionales Design reduziert Latenz und Kosten; multiregionaler Speicher (z. B. BigQuery US/EU Multi-Region, Cloud Storage Dual-/Multi-Region) erhöht die Dauerhaftigkeit und die Optionen für die Datenlokalität. Definieren Sie für DR (Disaster Recovery) RPO/RTO und replizieren Sie kritische Datensätze. Verwenden Sie in hybriden Szenarien Datastream für CDC (Change Data Capture) und Transfer Appliances oder den Storage Transfer Service für die Massenmigration. Standardisieren Sie für Multi-Cloud-Szenarien auf offene Formate in Cloud Storage und nutzen Sie portable Rechenleistung (Apache Beam/Dataflow, Spark on Dataproc), wobei der Egress- und Betriebsaufwand zu berücksichtigen ist.

Schichten, Lebenszyklus und Serviceauswahl

• Trennung der Schichten:
  • Speicher: Cloud Storage für Roh-/Bronze-Daten und Archivierung; BigQuery für kuratierte/bereitgestellte Analysen; Bigtable für Schlüsselzugriff mit geringer Latenz; Spanner/Cloud SQL für OLTP.
  • Compute: Dataflow für serverloses Streaming/Batch; Dataproc für Spark/Hadoop-Ökosysteme; BigQuery für In-Warehouse-ELT; Cloud Run/Functions für ereignisgesteuerte Microservices.
  • Orchestrierung: Cloud Composer (Airflow) oder Workflows für DAGs und API-Choreografie; Scheduler für Cron-ähnliche Trigger.
  • Bereitstellung (Serving): Bigtable oder Spanner für Online-Lesezugriffe; BigQuery für BI; Looker/BI Engine für Dashboards; Memorystore für Caching.
• Datenlebenszyklus:
  • Ingest (Aufnahme): Pub/Sub für Streams; Storage Transfer oder gsutil für Dateien; Data Transfer Service für SaaS. Validieren, deduplizieren und unveränderliche Rohdaten in Cloud Storage mit Objektversionierung ablegen.
  • Process (Verarbeitung): Dataflow oder BigQuery verwenden, um Rohdaten in Silver (bereinigt, konform) und dann in Gold (geschäftsfertige Marts) umzuwandeln.
  • Serve (Bereitstellen): BigQuery-Views/Tabellen für Analysen veröffentlichen; Features oder Vorhersagen für APIs vorab berechnen und in Bigtable schreiben.
  • Retain and Archive (Aufbewahren und Archivieren): Cloud Storage-Lebenszyklusregeln anwenden, um Daten in Coldline/Archive-Speicherklassen zu überführen; BigQuery-Zeitpartitionierung mit Partitionsablauf für die Aufbewahrung verwenden. CMEK bei Bedarf aktivieren und VPC Service Controls zum Schutz vor Datenexfiltration einsetzen.
• Serviceauswahl basierend auf Workload-Merkmalen:
  • Zeitreihen mit hohem Durchsatz, breiten Zeilen und geringer Latenz: Bigtable.
  • Stark konsistentes, globales OLTP mit ANSI SQL: Cloud Spanner.
  • Traditionelle relationale Transaktionen mit moderatem Umfang: Cloud SQL.
  • Analysen im Petabyte-Maßstab mit ANSI SQL und Trennung von Speicher/Compute: BigQuery.
  • Echtzeit-Aufnahme und -Verarbeitung: Pub/Sub + Dataflow.
  • Batch-Verarbeitung mit Spark/Hadoop oder bibliotheksspezifischen Tools: Dataproc.

Kurzes Beispiel für BigQuery-Partitionierung:

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

Praktisches Problemszenario

Contoso Mobility betreibt eine globale E-Scooter-Flotte und benötigt Echtzeit-Aufnahme, -Verarbeitung, -Speicherung und -Analyse für Fahrttelemetrie und Abrechnung. Sie müssen Millionen von Ereignissen pro Minute, Betrugserkennungsregeln im Subsekundenbereich, aktuelle Dashboards, Datenschutzkontrollen und einen ausfallsicheren, multiregionalen Betrieb unterstützen.

Ansatz:

1. Ereignisaufnahme mit Cloud Pub/Sub einrichten.

• Begründung: Pub/Sub bietet einen einzigen globalen Endpunkt, dauerhafte Pufferung und horizontale Skalierung für stoßweisen Geräteverkehr. Geordnete Schlüssel pro Scooter verwenden, um die geräteinterne Reihenfolge für 1-Stunden-Fenster beizubehalten.

2. Streaming-Verarbeitung mit Cloud Dataflow (Apache Beam) implementieren.

• Begründung: Das Autoscaling von Dataflow bewältigt Lastspitzen und bietet Exactly-Once-Sinks in Kombination mit idempotenten Schlüsseln. Ereigniszeit-Fenster und Watermarks verwenden, um verspätete oder unsortierte Telemetriedaten zu verarbeiten. Einen Haupt-Output in kuratierte Streams und einen Side-Output für Dead-Letter-Datensätze ausgeben.
• Konfiguration:

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

3. Rohdaten und kuratierte Daten in Cloud Storage bzw. BigQuery persistieren.

• Begründung: Rohe (Bronze) Avro-Dateien in einem dual-regionalen Cloud Storage Bucket für Replay und Audits ablegen. Kuratierte (Silver) Streams in partitionierte BigQuery-Tabellen für Analysen schreiben, mit Clustering nach scooter_id für effiziente Punktabfragen. Einen kleinen Aktualitätspuffer auf Dashboard-Abfragen anwenden, um vorübergehende Veraltung durch Streaming zu vermeiden.

4. Operative Abfragen und Betrugsprüfungen über Cloud Bigtable bereitstellen.

• Begründung: Die Regelauswertung unter 100 ms erfordert wahlfreien Zugriff mit geringer Latenz. Aggregate (z. B. Fahrten pro Gerät pro 5-Minuten-Fenster) in Dataflow vorab berechnen und in Bigtable schreiben, wobei ein Zeilenschlüssel mit einem gehashten Präfix (z. B. h(präfix)+device_id+window_start) verwendet wird, um Hotspotting zu vermeiden und Lesezugriffe über Tablets zu parallelisieren.

5. Transaktionale Abrechnung in Cloud Spanner verwalten.

• Begründung: Die Abrechnung erfordert global konsistentes SQL, starke Konsistenz und hohe Verfügbarkeit. Einen Leader in der primären geografischen Region mit schreibgeschützten Replikaten in sekundären Regionen verwenden, um die Lese-Latenzen für Kundenportale zu reduzieren.

6. Governance mit Dataplex, Data Catalog und Cloud DLP durchsetzen.

• Begründung: PII-Felder klassifizieren, Datasets taggen und Sicherheit auf Spaltenebene in BigQuery anwenden. Cloud DLP in die Dataflow-Pipeline integrieren, um sensible Attribute vor der Speicherung zu tokenisieren. Dataplex-Domains spiegeln die organisatorische Zuständigkeit wider; jede Domain veröffentlicht dokumentierte Datenprodukte mit SLOs.

7. Orchestrierung und Betrieb mit Cloud Composer und Cloud Monitoring.

• Begründung: Composer koordiniert Batch-Backfills, Komprimierungen und die Materialisierung von ML-Features. Monitoring überwacht End-to-End-SLIs: Pub/Sub-Backlog, Dataflow-Watermark-Verzögerung, Vollständigkeit der BigQuery-Partitionen und Tail-Latenzen von Bigtable. Bei SLO-Verletzungen alarmieren; Dataflow basierend auf dem Backlog-Wachstum automatisch skalieren.

8. Kosten und Lebenszyklus mit Partitionierung und Tiering optimieren.

• Begründung: BigQuery-Tabellen werden nach event_ts partitioniert mit einer Aufbewahrungsfrist von 90 Tagen und nach scooter_id geclustert. Cloud Storage verwendet Lebenszyklusregeln, um Rohdaten nach 30 Tagen in Coldline und nach 180 Tagen in Archive zu überführen. Geplante BigQuery-Jobs komprimieren kleine Micro-Batch-Dateien zu größeren Parquet-Objekten, um den Overhead durch die Dateianzahl für nachgelagerte Spark-Jobs zu reduzieren.

9. Risiken und Ausfallsicherheit validieren.

• Begründung: Lasttests mit dem doppelten erwarteten Spitzenwert durchführen, um Pub/Sub-Kontingente und das Dataflow-Autoscaling zu validieren. Eine regionale Failover-Übung durchführen: Multiregionale BigQuery-Datasets und dual-regionale Buckets erhalten die Verfügbarkeit aufrecht; die multiregionale Instanz von Spanner hält RPO=0 und das konfigurierte RTO durch automatisches Failover ein. Infrastructure as Code (Terraform) mit Richtlinienvalidierung verwenden, um CMEK und VPC Service Controls durchzusetzen.

Diese Architektur trennt die Verantwortlichkeiten sauber: Pub/Sub puffert die Aufnahme, Dataflow führt Berechnungen durch, Cloud Storage und BigQuery speichern und stellen Analysen bereit, Bigtable beschleunigt operative Lesezugriffe und Spanner garantiert konsistente Transaktionen. Sie schafft ein Gleichgewicht zwischen Skalierbarkeit und Latenz, während die Kosten durch Partitionierung, Clustering, Lebenszyklusrichtlinien und Autoscaling kontrolliert werden, und sie verankert Governance und Zuverlässigkeit durch dokumentierte Datenprodukte, Verträge und kontinuierliche Validierung.

Alle Domänen · Datenspeicherung →

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

Google durchsuchen →