Google PDE: Spark, Dataproc en Gedistribueerde Dataverwerking — Studiegids

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

Onderdeel van de Google Professional Data Engineer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Apache Spark op Google Cloud Dataproc biedt een beheerd, elastisch platform voor gedistribueerde dataverwerking. U kunt kiezen tussen langlopende of kortstondige (ephemeral) Dataproc-clusters en Dataproc Serverless for Spark, afhankelijk van de behoefte aan controle, variabiliteit in runtime en de hoeveelheid beheer. Spark biedt veerkrachtige abstracties (RDDs), relationele API’s (DataFrames en Spark SQL) en een fouttolerante DAG-execution-engine die is geoptimaliseerd voor iteratieve en batch-ETL op grote schaal. Op Google Cloud vervangt Cloud Storage HDFS voor duurzame, goedkope opslag; de BigQuery-connector maakt directe analytische offload mogelijk; en Dataproc Metastore centraliseert het schemabeheer. Effectieve oplossingen stemmen de levenscycli van opslag en compute op elkaar af, stemmen Spark af op de workload, implementeren observability en passen beveiliging toe met het ’least privilege’-principe en netwerkisolatie.

Dataproc-architectuur: Clusters, Serverless, Storage en Metastore

• Clustertypes en node-rollen
  • Primaire (master) nodes hosten YARN, de HDFS NameNode (indien gebruikt) en de UI’s van de Spark-driver; de HA-modus gebruikt meerdere primaire nodes.
  • Worker-nodes voeren executors en HDFS DataNodes uit (indien gebruikt).
  • Secundaire/auxiliaire workers zijn doorgaans preemptible/spot voor elastische, goedkopere capaciteit zonder HDFS-rollen.
  • Images bundelen OS- en componentversies (bijvoorbeeld 2.1-debian11, 2.2-ubuntu20); pin imageversies vast om de compatibiliteit van Spark/Hadoop te beheren en upgrades bewust uit te voeren.
  • Component Gateway publiceert UI’s (Spark History Server, YARN RM) veilig via HTTPS.
• Dataproc Serverless for Spark
  • Geen cluster-provisioning, automatische autoscaling en facturering per seconde voor executors en drivers. Ideaal voor sporadische of ‘bursty’ jobs, of wanneer de operationele overhead geminimaliseerd moet worden.
  • Afwegingen: minder low-level instellingen dan bij clusters; de opstartlatentie van een job kan hoger zijn dan bij ‘warme’ clusters; gebruik serverless metrics en event logs voor troubleshooting.
• Autoscaling
  • Autoscaling-beleidsregels voor clusters voegen workers toe of verwijderen ze op basis van YARN/Spark-metrics en cooldown-periodes, waarbij primaire en secundaire workergroepen afzonderlijk worden afgestemd.
  • Serverless autoscaling wordt beheerd door de service; ontwerp jobs om partitie-parallel te zijn en vermijd geserialiseerde knelpunten voor de beste schaalbaarheid.
• Storage en connectors
  • Geef de voorkeur aan Google Cloud Storage (GCS) als het ‘system-of-record’; het ontkoppelt compute van opslag, verlaagt de kosten van persistent disks en overleeft de levenscyclus van een cluster.
  • De GCS-connector (gs://) integreert met Hadoop/Spark. Schrijfacties naar object stores gebruiken commit-protocollen; stel het FileOutputCommitter-algoritme v2 in om de ‘rename’-overhead te verminderen en job-commits op GCS te versnellen:

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

  - Gebruik Parquet/ORC met 'column pruning' en 'predicate pushdown'. Beheer kleine bestanden via compactie om te streven naar 128–512 MiB per bestand voor een efficiënte scan.
- Hive metastore
  - Centraliseer schema's en tabelmetadata in Dataproc Metastore (een beheerde Apache Hive Metastore) of een door Cloud SQL ondersteunde metastore om catalogi te delen tussen clusters.
  - Gebruik externe tabellen die naar GCS verwijzen voor duurzaamheid; partitioneer op datum/uur om de scankosten te beperken.
- Jobs, initialisatie en workflows
  - Submit spark-, pyspark-, spark-sql- of hadoop-jobs. Initialisatie-acties installeren extra libraries of agents bij het aanmaken van het cluster (bijvoorbeeld connectors, Python-libs).
  - Workflow-templates parametriseren pipelines die uit meerdere stappen bestaan; ze kunnen per workflow kortstondige (ephemeral) clusters aanmaken en deze vervolgens weer verwijderen. Dit verbetert de isolatie en verlaagt de kosten voor ongebruikte resources.
  - Kortstondige (ephemeral) clusters worden aanbevolen voor batch-ETL; data en de metastore bevinden zich buiten het cluster (GCS, Dataproc Metastore, BigQuery).
- BigQuery-integratie
  - De Spark BigQuery-connector leest en schrijft rechtstreeks naar BigQuery; overweeg de BigQuery Storage Read API voor doorvoersnelheid en de Write API voor streaming inserts met lagere latentie en 'exactly-once'-garanties.
  - Voer voor tabelonderhoud downstream MERGE-operaties of partitie-overschrijvingen uit in BigQuery om laadacties atomair af te ronden.
### Spark-model, prestatie-tuning en betrouwbaarheid

- API's en uitvoering
  - RDDs: low-level, onveranderlijk (immutable), type-safe in Scala/Java; je beheert zelf partitionering en persistentie.
  - DataFrames/Datasets: relationeel, geoptimaliseerd door Catalyst; geef hier de voorkeur aan voor ETL vanwege query-optimalisatie en codegeneratie.
  - Transformaties zijn lazy (map, filter, join); actions activeren de uitvoering (count, collect, save). Spark bouwt een DAG van stages die worden gesplitst door shuffles; taken worden per partitie uitgevoerd.
- Partitionering en shuffle
  - Inputpartitionering: genoeg partities om alle cores te benutten; begin met 2–4x het totale aantal executor-cores. Beheer via spark.default.parallelism (voor RDDs) en reader-opties (voor DataFrames).
  - Shuffle-partities: de standaardwaarde van 200 is vaak te weinig of te veel. Pas aan:

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

• Streef naar ~100–256 MiB per partitie na wide transforms; te klein veroorzaakt scheduler-overhead en te groot riskeert een executor OOM.
• Shuffle is de meest dominante kostenpost bij joins, groupBy en orderBy. Zorg voor voldoende executor-geheugen en -schijfruimte; overweeg lokale SSD’s voor zware shuffles op clusters.
• Skew en join-strategie
  • Detecteer skew (taken met lange uitvoertijden, grote partitiegroottes). Oplossingen:
    • Broadcast kleine tabellen om shuffles te vermijden:

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

    - Salt keys voor 'hot' partities; pas map-side pre-aggregatie toe; filter vroegtijdig.
    - Schakel Adaptive Query Execution (AQE) in om partities na de shuffle samen te voegen (coalesce) en skewed joins te verwerken:

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

• Caching, checkpointing en lineage
  • Cache ‘hot’ intermediaire DataFrames spaarzaam wanneer ze hergebruikt worden; geef de voorkeur aan MEMORY_AND_DISK om OOM te voorkomen.
  • Maak checkpoints van lange lineages naar GCS of HDFS om herberekening bij fouten te beperken.
• Executors en dynamische allocatie
  • Kies de juiste grootte voor executors om parallellisme en GC-overhead in balans te brengen:
    • Cores per executor: 2–5 voor gebalanceerde I/O/CPU-taken; minder cores verminderen GC-pauzes.
    • Geheugenoverhead: stel spark.yarn.executor.memoryOverhead in voor wide shuffles.
    • Schakel dynamische allocatie in met een externe shuffle-service op clusters om executors te schalen met de workload:

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

- Fouttolerantiepatronen voor batch-ETL
  - Idempotente schrijfacties: schrijf naar een tijdelijk/staging-pad en promoveer dit vervolgens atomisch met een commit op directory-niveau; voor BigQuery, schrijf naar een staging-tabel en gebruik MERGE:

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

• Incrementele verwerking: gebruik op watermarks gebaseerde filtering op ingestion_date-partities; beheer een manifest van verwerkte bestanden in GCS om herverwerking te voorkomen.
• Dead-letter-afhandeling: bij parseer-/validatiefouten, splits foute records af naar een quarantainepad/-tabel met diagnostische informatie. Voor strikte schema-handhaving en ingebouwde DLQ’s, overweeg Dataflow; met Spark, implementeer een try/catch per record en een aparte sink.

Beveiliging, Waarneembaarheid en Kosten

• Identiteit en toegang
  • Voer clusters en jobs uit onder toegewijde serviceaccounts met least-privilege IAM. Wijs alleen de benodigde rollen toe, bijvoorbeeld:
    • roles/dataproc.worker aan instance serviceaccounts
    • roles/storage.objectViewer of objectAdmin voor GCS I/O-paden
    • roles/bigquery.dataEditor op doel-datasets
  • Gebruik voor Dataproc Serverless per-job serviceaccounts om de toegang af te bakenen.
• Netwerkisolatie en encryptie
  • Gebruik private IP-clusters in een VPC-subnet, beperk de toegang tot master-UI’s met een firewall en schakel Private Google Access in voor GCS/BigQuery zonder publieke egress.
  • Plaats clusters in Shared VPC-projecten voor gecentraliseerd beheer. Schakel optioneel Kerberos in op Dataproc voor in-cluster authenticatie.
  • Versleutel data-at-rest met CMEK: configureer CMEK op GCS-buckets, Persistent Disks, Dataproc Metastore en BigQuery; gebruik standaard TLS voor data-in-transit.
• Logging, geschiedenis en statistieken
  • Schakel Spark event logs naar GCS in en implementeer de History Server:

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

  - Dataproc streamt driver- en YARN-logs naar Cloud Logging; exporteer naar sinks voor retentie/forensisch onderzoek.
  - Monitor met Cloud Monitoring-statistieken: YARN pending containers, CPU, geheugen, HDFS-status (indien gebruikt), GCS-doorvoer. Stel alerts in voor langdurige stage-retries, verlies van executors en pieken in speculatieve uitvoering.
  - Foutanalyse: veelvoorkomende oorzaken zijn door skew veroorzaakte 'stragglers' (achterblijvers), executor OOM tijdens shuffle, fouten bij het committen naar object storage en verlies van preemptible/spot nodes. Verhoog het aantal retries oordeelkundig; overmatige retries kunnen de kosten en vertraging vergroten.
- Kostenoptimalisatie
  - Gebruik 'ephemeral' (tijdelijke) clusters of Dataproc Serverless om kosten voor inactiviteit te vermijden; bewaar data in GCS om het gebruik van persistent disk te minimaliseren.
  - Voeg preemptible/spot secundaire workers toe om piekbelasting op te vangen; ontwerp voor herberekening, aangezien taken op verloren nodes opnieuw worden geprobeerd. Plaats geen masters op preemptible nodes.
  - Kies de juiste machine types ('right-sizing') en gebruik autoscaling om de capaciteit te verkleinen wanneer wachtrijen leeg zijn. Geef de voorkeur aan Parquet/ORC met 'partition pruning' om scankosten en CPU-gebruik te verminderen.
  - Vermijd kleine bestanden door outputs te compacteren; minder, grotere bestanden verminderen de metadata-overhead en de uitvoertijd van de job.
  - Voor korte, periodieke jobs (bijvoorbeeld wekelijkse 30-minuten Spark ETL), bieden preemptible workers of serverless vaak het beste kostenprofiel.

#### Praktijkscenario

Acme Retail migreert een on-premise Hadoop-cluster van 30 nodes dat nachtelijke Spark- en Hive-ETL-processen uitvoert voor downstream analytics. Ze willen bestaande jobs hergebruiken met minimale aanpassingen, het fulltime beheren van clusters vermijden, data langer bewaren dan de levensduur van een cluster en de opslagkosten verlagen.

Aanpak:
1) Plaats data en metadata in managed services
   - Sla alle ruwe en gecureerde data op in Cloud Storage met Parquet en partitionering (bijvoorbeeld, dt=JJJJ-MM-DD).
   - Rationale: GCS is duurzaam, goedkoop en ontkoppelt compute van storage, zodat 'ephemeral' clusters en serverless jobs kunnen draaien zonder persistent disks. Gepartitioneerde Parquet maakt 'predicate pushdown' en efficiënte scans mogelijk.

2) Centraliseer de catalogus met Dataproc Metastore
   - Migreer de Hive metastore naar Dataproc Metastore. Maak externe Hive-tabellen aan die verwijzen naar GCS-paden en behoud de bestaande schema- en partitielogica.
   - Rationale: Een beheerde metastore stelt meerdere 'ephemeral' clusters en serverless jobs in staat om tabeldefinities te delen zonder een HA MySQL/PostgreSQL-instantie te hoeven draaien.

3) Gebruik 'ephemeral' Dataproc-clusters voor batch-ETL en workflow templates voor orkestratie
   - Definieer een workflow template die een cluster aanmaakt met de vereiste image (bijvoorbeeld 2.1-debian11), Spark-jobs uitvoert (spark-sql en pyspark) en het cluster na voltooiing verwijdert. Voeg initialisatieacties toe om eventuele custom libraries te installeren.
   - Rationale: 'Ephemeral' clusters elimineren kosten voor inactiviteit en isoleren job-afhankelijkheden. Workflow templates bieden herhaalbaarheid en parametrisering (datums, input-paden).

4) Schakel autoscaling en preemptible workers in
   - Koppel een autoscaling policy met een kleine groep core workers en een grotere pool van preemptible secundaire workers; stem de 'cooldowns' af om direct na uitvoering terug te schalen.
   - Rationale: Core workers handhaven de clusterstabiliteit; preemptible workers vangen shuffles en 'wide transformations' op tegen lagere kosten. Spark/YARN-retries verwerken verloren taken na preemption.

5) Integreer met BigQuery via de Spark BigQuery connector
   - Voor het laden van dimensie-/feitentabellen, schrijf Spark-resultaten naar staging BigQuery-tabellen en voer vervolgens MERGE-statements uit om doeltabellen atomair bij te werken. Waar direct overschrijven veilig is, schrijf naar gepartitioneerde tabellen met de 'partition overwrite'-modus.
   - Rationale: BigQuery dient analytics en BI op grote schaal; staging+MERGE levert transactioneel-achtige 'upserts' vanuit batch Spark, wat inconsistentie downstream vermindert.

6) Optimaliseer Spark voor prestaties en betrouwbaarheid
   - Stel shuffle-partities in relatief aan het aantal executor cores en schakel AQE in:

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

• Gebruik ‘broadcast joins’ voor kleine dimensies en maak checkpoints van lange ’lineages’ naar GCS voor stabiliteit.
• Rationale: Correcte partitionering vermindert skew en scheduler-overhead; AQE past zich tijdens runtime aan dataprofilen aan; checkpointing beperkt de herberekening na fouten.

7. Versterk de beveiliging en het netwerk

   • Voer clusters uit met toegewijde serviceaccounts die alleen de benodigde rollen voor GCS-paden, de metastore en BigQuery-datasets hebben. Maak private IP-clusters in een beperkt subnet met Private Google Access en beperk de toegang tot de UI via firewallregels.
   • Rationale: ‘Least privilege’ en netwerkisolatie verkleinen het aanvalsoppervlak; private control-plane egress voorkomt blootstelling aan het publieke internet.

8. Implementeer logging, geschiedenis en alerts

   • Schakel Spark event logs naar GCS in en implementeer de History Server; stuur driver-/YARN-logs naar Cloud Logging met retentie. Voeg Monitoring-alerts toe voor lang wachtende containers, herhaalde taakfouten of een buitensporige jobduur.
   • Rationale: Gecentraliseerde logs ondersteunen ‘root-cause analysis’; proactieve alerts detecteren skew, OOM’s of verminderde I/O-prestaties in een vroeg stadium.

9. Moderniseer selectief met Dataproc Serverless voor ad-hoc en elastische pieken

   • Verplaats sporadische of verkennende Spark SQL-workloads naar Dataproc Serverless; behoud de nachtelijke pipelines op ’ephemeral’ clusters totdat ze volledig gevalideerd zijn op serverless.
   • Rationale: Serverless elimineert clusterbeheer en schaalt automatisch, ideaal voor onvoorspelbare workloads; bestaande workflows kunnen doorgaan met minimale codewijzigingen.

10. Valideer object-store committers en het beheer van kleine bestanden

    • Stel het FileOutputCommitter-algoritme in op v2 en compacteer outputs naar 256–512 MiB per bestand via repartition/coalesce vóór het schrijven.
    • Rationale: Object stores missen atomaire ‘rename’-operaties; geoptimaliseerde committers verminderen de copy/rename-overhead. Compactie beperkt het ‘small-files’-probleem voor betere prestaties en lagere kosten.

Dit ontwerp hergebruikt bestaande Spark- en Hive-jobs met minimale refactoring, garandeert de duurzaamheid van data in GCS, centraliseert schema’s, beperkt de ‘blast radius’ van beveiligingsincidenten, biedt robuuste waarneembaarheid en optimaliseert de kosten door middel van ’ephemeral’ clusters, autoscaling, preemptible capaciteit en gericht gebruik van serverless uitvoering.

← Messaging · Alle domeinen · Data-ingestie →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →

Blader door Google →