Google PDE: Spark, Dataproc und verteilte Datenverarbeitung — 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

Apache Spark auf Google Cloud Dataproc bietet eine verwaltete, elastische Plattform für die verteilte Datenverarbeitung. Abhängig von den Anforderungen an die Steuerung, der Variabilität der Laufzeit und dem Verwaltungsaufwand können Sie zwischen langlebigen oder ephemeren Dataproc-Clustern und Dataproc Serverless for Spark wählen. Spark bietet resiliente Abstraktionen (RDDs), relationale APIs (DataFrames und Spark SQL) und eine fehlertolerante DAG-Ausführungs-Engine, die für iterative und Batch-ETL-Prozesse im großen Maßstab optimiert ist. In Google Cloud ersetzt Cloud Storage HDFS als langlebigen, kostengünstigen Speicher, der BigQuery-Connector ermöglicht eine direkte analytische Auslagerung und der Dataproc Metastore zentralisiert die Schema-Verwaltung. Effektive Lösungen stimmen die Lebenszyklen von Speicher und Rechenleistung aufeinander ab, optimieren Spark für den jeweiligen Workload, instrumentieren die Observability und wenden Sicherheitsmaßnahmen nach dem Prinzip der geringsten Rechte (Least Privilege) und durch Netzwerkisolierung an.

Dataproc-Architektur: Cluster, Serverless, Speicher und Metastore

• Clustertypen und Knoten-Rollen
  • Primäre (Master-)Knoten hosten YARN, den HDFS NameNode (falls verwendet) und die Spark-Treiber-UIs; der HA-Modus verwendet mehrere primäre Knoten.
  • Worker-Knoten führen Executors und HDFS DataNodes (falls verwendet) aus.
  • Sekundäre/Hilfs-Worker sind typischerweise Preemptible/Spot-VMs für elastische, kostengünstigere Kapazität ohne HDFS-Rollen.
  • Images bündeln Betriebssystem- und Komponentenversionen (z. B. 2.1-debian11, 2.2-ubuntu20); pinnen Sie Image-Versionen fest, um die Kompatibilität von Spark/Hadoop zu steuern und Upgrades gezielt durchzuführen.
  • Das Component Gateway veröffentlicht UIs (Spark History Server, YARN RM) sicher über HTTPS.
• Dataproc Serverless for Spark
  • Keine Cluster-Bereitstellung, automatisches Autoscaling und sekundengenaue Abrechnung für Executors und Treiber. Ideal für sporadische oder stark schwankende Jobs oder zur Minimierung des Betriebsaufwands.
  • Nachteile: weniger Low-Level-Einstellmöglichkeiten als bei Clustern; die Startlatenz von Jobs kann höher sein als bei „warmen“ Clustern; verwenden Sie Serverless-Metriken und Ereignisprotokolle zur Fehlerbehebung.
• Autoscaling
  • Cluster-Autoscaling-Richtlinien fügen Worker basierend auf YARN/Spark-Metriken und Cooldown-Phasen hinzu oder entfernen sie, wobei primäre und sekundäre Worker-Gruppen getrennt voneinander optimiert werden.
  • Das Autoscaling bei Serverless wird vom Dienst verwaltet; achten Sie für beste Skalierung auf ein partitions-paralleles Design und vermeiden Sie serialisierte Engpässe.
• Speicher und Connectors
  • Bevorzugen Sie Google Cloud Storage (GCS) als System-of-Record; es entkoppelt Rechenleistung vom Speicher, reduziert die Kosten für nichtflüchtige Speicher und überdauert die Lebenszyklen von Clustern.
  • Der GCS-Connector (gs://) integriert sich mit Hadoop/Spark. Schreibvorgänge in Objektspeicher verwenden Commit-Protokolle; stellen Sie den FileOutputCommitter-Algorithmus v2 ein, um den Overhead bei Umbenennungen zu reduzieren und Job-Commits auf GCS zu beschleunigen:

    --conf mapreduce.fileoutputcommitter.algorithm.version=2
    ```

  - Verwenden Sie Parquet/ORC mit Column Pruning und Predicate Pushdown. Verwalten Sie kleine Dateien durch Komprimierung (Compaction), um eine Zieldateigröße von 128–512 MiB für effiziente Scans zu erreichen.
- Hive Metastore
  - Zentralisieren Sie Schemata und Tabellen-Metadaten im Dataproc Metastore (ein verwalteter Apache Hive Metastore) oder einem Cloud SQL-gestützten Metastore, um Kataloge clusterübergreifend zu teilen.
  - Verwenden Sie externe Tabellen, die auf GCS verweisen, um Langlebigkeit zu gewährleisten; partitionieren Sie nach Datum/Stunde, um die Scan-Kosten zu begrenzen.
- Jobs, Initialisierung und Workflows
  - Übermitteln Sie spark-, pyspark-, spark-sql- oder hadoop-Jobs. Initialisierungsaktionen installieren zusätzliche Bibliotheken oder Agenten bei der Cluster-Erstellung (z. B. Connectors, Python-Bibliotheken).
  - Workflow-Vorlagen parametrisieren mehrstufige Pipelines; sie können pro Workflow ephemere Cluster erstellen und diese anschließend wieder löschen. Dies verbessert die Isolation und reduziert Kosten durch Leerlauf.
  - Ephemere Cluster werden für Batch-ETL empfohlen; Daten und Metastore befinden sich außerhalb des Clusters (GCS, Dataproc Metastore, BigQuery).
- BigQuery-Integration
  - Der Spark BigQuery Connector liest und schreibt direkt in BigQuery; ziehen Sie die BigQuery Storage Read API für hohen Durchsatz und die Write API für Streaming-Inserts mit geringerer Latenz und Exactly-Once-Semantik in Betracht.
  - Für die Tabellenwartung führen Sie nachgelagerte MERGE-Operationen oder das Überschreiben von Partitionen in BigQuery durch, um Ladevorgänge atomar abzuschließen.
### Spark-Modell, Leistungsoptimierung und Zuverlässigkeit

- APIs und Ausführung
  - RDDs: Low-Level, unveränderlich, typsicher in Scala/Java; Sie steuern Partitionierung und Persistenz.
  - DataFrames/Datasets: relational, Catalyst-optimiert; bevorzugen Sie diese für ETL aufgrund von Abfrageoptimierung und Codegenerierung.
  - Transformationen sind lazy (map, filter, join); Aktionen lösen die Ausführung aus (count, collect, save). Spark erstellt einen DAG aus Stufen (Stages), die durch Shuffles getrennt sind; Tasks werden pro Partition ausgeführt.
- Partitionierung und Shuffle
  - Eingabepartitionierung: genügend Partitionen, um alle Kerne auszulasten; beginnen Sie mit dem 2- bis 4-fachen der gesamten Executor-Kerne. Steuerung über spark.default.parallelism (für RDDs) und Leseoptionen (für DataFrames).
  - Shuffle-Partitionen: Der Standardwert 200 ist oft zu niedrig oder zu hoch angesetzt. Anpassen:

--conf spark.sql.shuffle.partitions= {total_executor_cores * 2 to 3}
```

• Zielgröße von ~100–256 MiB pro Partition nach Wide-Transformationen anstreben; zu kleine Partitionen verursachen Scheduler-Overhead, zu große bergen das Risiko von Executor-OOM.
• Shuffle ist der dominierende Kostenfaktor bei joins, groupBy und orderBy. Stellen Sie ausreichend Executor-Speicher und Festplattenspeicher sicher; ziehen Sie bei starkem Shuffle auf Clustern lokale SSDs in Betracht.
• Skew und Join-Strategie
  • Skew erkennen (lange Laufzeiten von Tasks, große Partitionsgrößen). Gegenmaßnahmen:
    • Broadcast kleiner Tabellen, um Shuffles zu vermeiden:

      --conf spark.sql.autoBroadcastJoinThreshold=64m
      ```

    - Keys für „heiße“ Partitionen salzen (Salting); Map-seitige Vor-Aggregation anwenden; frühzeitig filtern.
    - Adaptive Query Execution (AQE) aktivieren, um Partitionen nach dem Shuffle zusammenzuführen und Skewed Joins zu behandeln:

  --conf spark.sql.adaptive.enabled=true
  ```

• Caching, Checkpointing und Lineage
  • „Heiße“ zwischengespeicherte DataFrames bei Wiederverwendung sparsam cachen; MEMORY_AND_DISK bevorzugen, um OOM zu vermeiden.
  • Lange Lineages in GCS oder HDFS checkpointen, um Neuberechnungen bei Fehlern zu begrenzen.
• Executoren und dynamische Allokation
  • Executor-Größe richtig wählen, um Parallelität und GC-Overhead auszugleichen:
    • Kerne pro Executor: 2–5 für ausgewogene I/O/CPU-Tasks; weniger Kerne reduzieren GC-Pausen.
    • Memory-Overhead: spark.yarn.executor.memoryOverhead für Wide Shuffles setzen.
    • Dynamische Allokation mit externem Shuffle-Service auf Clustern aktivieren, um Executoren mit der Arbeitslast zu skalieren:

      --conf spark.dynamicAllocation.enabled=true
      --conf spark.shuffle.service.enabled=true
      --conf spark.dynamicAllocation.minExecutors=0
      --conf spark.dynamicAllocation.maxExecutors=200
      ```

- Fehlertoleranzmuster für Batch-ETL
  - Idempotente Schreibvorgänge: In einen temporären/Staging-Pfad schreiben, dann atomar durch ein Commit auf Verzeichnisebene hochstufen; für BigQuery in eine Staging-Tabelle schreiben und MERGE verwenden:

MERGE target t USING staging s
ON t.id = s.id
WHEN MATCHED THEN UPDATE SET ...
WHEN NOT MATCHED THEN INSERT (...)
```

• Inkrementelle Verarbeitung: Wasserzeichen-basiertes Filtern auf ingestion_date-Partitionen verwenden; ein Manifest der verarbeiteten Daten in GCS pflegen, um eine erneute Verarbeitung zu vermeiden.
• Dead-Letter-Handling: Bei Parse-/Validierungsfehlern fehlerhafte Datensätze in einen Quarantänepfad/eine Quarantänetabelle mit Diagnosedaten auslagern. Für eine strikte Schema-Durchsetzung und integrierte DLQs (Dead-Letter Queues) Dataflow in Betracht ziehen; mit Spark pro Datensatz try/catch und eine separate Senke (Sink) implementieren.

Sicherheit, Beobachtbarkeit und Kosten

• Identität und Zugriff
  • Führen Sie Cluster und Jobs unter dedizierten Dienstkonten mit IAM nach dem Prinzip der geringsten Rechte (Least Privilege) aus. Vergeben Sie nur die erforderlichen Rollen, zum Beispiel:
    • roles/dataproc.worker für Instanz-Dienstkonten
    • roles/storage.objectViewer oder objectAdmin für GCS-E/A-Pfade
    • roles/bigquery.dataEditor für Ziel-Datasets
  • Verwenden Sie für Dataproc Serverless Dienstkonten pro Job, um den Zugriffsbereich zu definieren.
• Netzwerkisolierung und Verschlüsselung
  • Verwenden Sie Cluster mit privaten IPs in einem VPC-Subnetz, schränken Sie die Master-UIs per Firewall ein und aktivieren Sie den privaten Google-Zugriff für GCS/BigQuery ohne öffentlichen Egress.
  • Platzieren Sie Cluster in Shared-VPC-Projekten für eine zentrale Steuerung. Aktivieren Sie optional Kerberos auf Dataproc für die Authentifizierung innerhalb des Clusters.
  • Verschlüsseln Sie ruhende Daten (at rest) mit CMEK: Konfigurieren Sie CMEK für GCS-Buckets, Persistent Disks, Dataproc Metastore und BigQuery; verwenden Sie standardmäßig TLS für die Datenübertragung (in transit).
• Logging, Verlauf und Metriken
  • Aktivieren Sie Spark-Ereignisprotokolle in GCS und stellen Sie den History Server bereit:

    --conf spark.eventLog.enabled=true
    --conf spark.eventLog.dir=gs://bucket/spark-events/
    ```

  - Dataproc streamt Treiber- und YARN-Protokolle zu Cloud Logging; exportieren Sie sie in Senken (Sinks) zur Aufbewahrung/Forensik.
  - Überwachen Sie mit Cloud Monitoring-Metriken: ausstehende YARN-Container, CPU, Arbeitsspeicher, HDFS-Zustand (falls verwendet), GCS-Durchsatz. Richten Sie Benachrichtigungen für langanhaltende Stage-Wiederholungen, Executor-Verluste und Spitzen bei der spekulativen Ausführung ein.
  - Fehleranalyse: Häufige Ursachen sind durch Schiefe (Skew) verursachte Nachzügler (Stragglers), Executor-OOM während des Shuffle, Fehler beim Commit im Objektspeicher und der Verlust von preemptible/Spot-Knoten. Erhöhen Sie die Anzahl der Wiederholungsversuche mit Bedacht; übermäßige Wiederholungen können Kosten und Verzögerungen verstärken.
- Kostenoptimierung
  - Verwenden Sie ephemere Cluster oder Dataproc Serverless, um Leerlaufkosten zu vermeiden; speichern Sie Daten in GCS, um die Nutzung von Persistent Disks zu minimieren.
  - Fügen Sie preemptible/Spot Secondary Worker hinzu, um Bedarfsspitzen abzufangen; legen Sie das Design auf Neuberechnung aus, da Aufgaben auf verlorenen Knoten wiederholt werden. Platzieren Sie keine Master-Knoten auf preemptible Knoten.
  - Wählen Sie die richtige Größe für Maschinentypen und verwenden Sie Autoscaling, um die Kapazität bei leeren Warteschlangen zu verringern. Bevorzugen Sie Parquet/ORC mit Partition Pruning, um Scankosten und CPU-Auslastung zu reduzieren.
  - Vermeiden Sie kleine Dateien durch Komprimierung der Ausgaben; weniger, aber größere Dateien reduzieren den Metadaten-Overhead und die Job-Laufzeit.
  - Für kurze, periodische Jobs (z. B. wöchentliche 30-minütige Spark-ETL-Prozesse) bieten preemptible Worker oder Serverless oft das beste Kostenprofil.

#### Praktisches Problemszenario

Acme Retail migriert einen lokalen 30-Knoten-Hadoop-Cluster, auf dem nächtliche Spark- und Hive-ETL-Prozesse laufen, die nachgelagerte Analysen versorgen. Sie möchten bestehende Jobs mit minimalen Änderungen wiederverwenden, die Vollzeitverwaltung von Clustern vermeiden, Daten über die Lebensdauer von Clustern hinaus persistent speichern und die Speicherkosten senken.

Ansatz:
1) Daten und Metadaten in verwalteten Diensten ablegen
   - Speichern Sie alle Roh- und aufbereiteten Daten in Cloud Storage unter Verwendung von Parquet mit Partitionierung (z. B. dt=YYYY-MM-DD).
   - Begründung: GCS ist langlebig, kostengünstig und entkoppelt Rechenleistung von Speicher, sodass ephemere Cluster und Serverless-Jobs ohne Persistent Disks ausgeführt werden können. Partitioniertes Parquet ermöglicht Predicate Pushdown und effiziente Scans.

2) Katalog mit Dataproc Metastore zentralisieren
   - Migrieren Sie den Hive-Metastore zu Dataproc Metastore. Erstellen Sie externe Hive-Tabellen, die auf GCS-Pfade verweisen, und behalten Sie die bestehende Schema-/Partitionslogik bei.
   - Begründung: Ein verwalteter Metastore ermöglicht es mehreren ephemeren Clustern und Serverless-Jobs, Tabellendefinitionen gemeinsam zu nutzen, ohne eine hochverfügbare MySQL/PostgreSQL-Instanz betreiben zu müssen.

3) Ephemere Dataproc-Cluster für Batch-ETL und Workflow-Vorlagen für die Orchestrierung verwenden
   - Definieren Sie eine Workflow-Vorlage, die einen Cluster mit dem erforderlichen Image (z. B. 2.1-debian11) erstellt, Spark-Jobs (spark-sql und pyspark) ausführt und den Cluster nach Abschluss löscht. Fügen Sie Initialisierungsaktionen hinzu, um benutzerdefinierte Bibliotheken zu installieren.
   - Begründung: Ephemere Cluster eliminieren Leerlaufkosten und isolieren Job-Abhängigkeiten. Workflow-Vorlagen bieten Wiederholbarkeit und Parametrisierung (Daten, Eingabepfade).

4) Autoscaling und preemptible Worker aktivieren
   - Fügen Sie eine Autoscaling-Richtlinie mit einer kleinen Gruppe von Core-Workern und einem größeren Pool von preemptible Secondary Workern hinzu; passen Sie die Cooldown-Phasen an, um nach der Ausführung zeitnah herunterzuskalieren.
   - Begründung: Core-Worker erhalten die Cluster-Stabilität; preemptible Worker fangen Shuffles und breite Transformationen zu geringeren Kosten ab. Spark/YARN-Wiederholungsversuche behandeln verlorene Aufgaben bei einer Preemption.

5) Integration mit BigQuery über den Spark BigQuery Connector
   - Schreiben Sie für das Laden von Dimensions-/Faktentabellen die Spark-Ergebnisse in Staging-Tabellen in BigQuery und führen Sie dann MERGE-Anweisungen aus, um die Ziele atomar zu aktualisieren. Wo ein direktes Überschreiben sicher ist, schreiben Sie partitionierte Tabellen im Modus zum Überschreiben von Partitionen (Partition Overwrite Mode).
   - Begründung: BigQuery dient der Analyse und BI im großen Maßstab; Staging+MERGE ermöglicht transaktionsähnliche Upserts aus Batch-Spark-Prozessen, was die Inkonsistenz in nachgelagerten Systemen reduziert.

6) Spark auf Leistung und Zuverlässigkeit abstimmen
   - Legen Sie die Shuffle-Partitionen relativ zu den Executor-Kernen fest und aktivieren Sie AQE:

 --conf spark.sql.shuffle.partitions=600
 --conf spark.sql.adaptive.enabled=true
 ```

• Verwenden Sie Broadcast Joins für kleine Dimensionen und erstellen Sie Checkpoints für lange Lineages in GCS, um die Stabilität zu erhöhen.
• Begründung: Eine korrekte Partitionierung reduziert Skew und Scheduler-Overhead; AQE passt sich zur Laufzeit an Datenprofile an; Checkpointing begrenzt die Neuberechnung nach Ausfällen.

7. Sicherheit und Netzwerk härten

   • Führen Sie Cluster mit dedizierten Dienstkonten aus, die nur die für GCS-Pfade, den Metastore und BigQuery-Datasets erforderlichen Rollen gewähren. Erstellen Sie Cluster mit privaten IPs in einem eingeschränkten Subnetz mit privatem Google-Zugriff und beschränken Sie den UI-Zugriff über Firewall-Regeln.
   • Begründung: Das Prinzip der geringsten Rechte und die Netzwerkisolierung reduzieren die Angriffsfläche; ein privater Egress der Steuerungsebene vermeidet die Offenlegung im öffentlichen Internet.

8. Logging, Verlauf und Benachrichtigungen instrumentieren

   • Aktivieren Sie Spark-Ereignisprotokolle in GCS und stellen Sie den History Server bereit; leiten Sie Treiber-/YARN-Protokolle mit Aufbewahrungsrichtlinien an Cloud Logging weiter. Fügen Sie Monitoring-Benachrichtigungen für lange ausstehende Container, wiederholte Aufgabenfehler oder übermäßige Job-Dauer hinzu.
   • Begründung: Zentralisierte Protokolle unterstützen die Ursachenanalyse; proaktive Benachrichtigungen erkennen frühzeitig Skew, OOMs oder eine verschlechterte E/A-Leistung.

9. Selektive Modernisierung mit Dataproc Serverless für Ad-hoc- und elastische Spitzenlasten

   • Verlagern Sie sporadische oder explorative Spark-SQL-Workloads auf Dataproc Serverless; behalten Sie die nächtlichen Pipelines auf ephemeren Clustern, bis sie vollständig auf Serverless validiert sind.
   • Begründung: Serverless eliminiert den Cluster-Betrieb und skaliert automatisch, was ideal für unvorhersehbare Lasten ist; bestehende Workflows laufen mit minimalen Code-Änderungen weiter.

10. Object-Store-Committer und Verwaltung kleiner Dateien validieren

    • Stellen Sie den FileOutputCommitter-Algorithmus auf v2 ein und komprimieren Sie die Ausgaben vor dem Schreiben durch repartition/coalesce auf 256–512 MiB pro Datei.
    • Begründung: Objektspeicher bieten keine atomare Umbenennung; optimierte Committer reduzieren den Kopier-/Umbenennungs-Overhead. Die Komprimierung entschärft das Problem kleiner Dateien im Hinblick auf Leistung und Kosten.

Dieses Design verwendet bestehende Spark- und Hive-Jobs mit minimalem Refactoring wieder, gewährleistet die Datenlanglebigkeit in GCS, zentralisiert Schemata, begrenzt den Sicherheits-Blast-Radius, bietet robuste Beobachtbarkeit und optimiert die Kosten durch ephemere Cluster, Autoscaling, preemptible Kapazität und den gezielten Einsatz von Serverless-Ausführung.

← Messaging · Alle Domänen · Daten-Ingestion →

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

Google durchsuchen →