Google PDE: Data Engineering Architectuur en Ontwerp — 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

Architectuur en ontwerp van data-engineering op Google Cloud balanceert domeingrenzen, verwerkingspatronen en service-mogelijkheden om betrouwbare, schaalbare en kostenefficiënte dataplatforms te leveren. Effectieve ontwerpen maken opslag, compute, orkestratie en serving onafhankelijk schaalbaar; leggen contracten vast in code zodat domeinen kunnen samenwerken; en valideren risico’s vroegtijdig met meetbare service-level objectives (SLO’s). Dit gedeelte vat canonische architectuurstijlen (data mesh, lake, warehouse, lakehouse, operationele stores), verwerkingsmodi (batch, micro-batch, streaming, event-driven, lambda) en de afwegingen tussen schaalbaarheid, latency, beschikbaarheid, consistentie en kosten samen. Het behandelt ook regionale en multi-cloud plaatsing, schema-evolutie, de end-to-end datalevenscyclus, workload-gebaseerde servicekeuze en risicogestuurde validatiepraktijken die zijn afgestemd op Google Cloud.

Architectuurparadigma’s en Verwerkingspatronen

• Data mesh, domeinen en dataproducten:
  • Geef domeinteams de mogelijkheid om “dataproducten” te publiceren met duidelijk eigenaarschap, SLO’s, toegangsbeleid en documentatie. Gebruik Dataplex om domeinen te definiëren, metadata te beheren en consistent beleid toe te passen over BigQuery en Cloud Storage. Producten kunnen BigQuery-datasets, Pub/Sub-topics of Cloud Storage-paden aanbieden met contracten die worden afgedwongen via Pub/Sub-schema’s en BigQuery-tabelschema’s.
• Data lake:
  • Ruwe opslag in open formaten (Parquet/Avro) in Cloud Storage met lifecycle en versiebeheer. Geschikt voor heterogene workloads (Spark op Dataproc, Dataflow, Presto/Trino) en multi-cloud portabiliteit. Afweging: eventual consistency-semantiek in object stores; ontwerp voor idempotentie en metadata-gestuurde ontdubbeling.
• Data warehouse:
  • Gecureerde, beheerde analytics in BigQuery. Geoptimaliseerd voor ANSI SQL, scheiding van opslag en compute, en fijngranulaire beveiliging. Afwegingen: streaming inserts vertonen een korte ‘staleness’ (veroudering) op het moment van de query; geef de voorkeur aan batch-loads of inserts met gebufferde queries voor strikte SLA’s voor datactualiteit.
• Lakehouse:
  • Combineer open data lake-opslag met warehouse-functionaliteiten. Sla op Google Cloud Parquet/Avro op in Cloud Storage; gebruik BigQuery external tables voor kostenefficiëntie en BigQuery managed tables voor prestaties en governance. Dataflow of Dataproc onderhoudt ACID-achtige merge-semantiek met partitionerings- en clusteringstrategieën.
• Operationele-store architectuur:
  • Transactionele of key-value stores met lage latency die applicaties ondersteunen. Kies Cloud SQL voor traditionele OLTP, Cloud Spanner voor wereldwijd consistente SQL met horizontale schaalbaarheid, en Bigtable voor zeer hoge doorvoer en ‘wide-column’-toegangspatronen. Scheid operationele stores van analytics; gebruik CDC (Datastream) om veranderingen vast te leggen in Pub/Sub, Cloud Storage of BigQuery.

Verwerkingspatronen en wanneer ze te gebruiken:

• Batch: Periodieke, grootschalige transformaties (bv. nachtelijke generatie van features). Tools: Dataflow batch, Dataproc. Faalmodi: time-outs van langlopende jobs, skew (scheefgroei); beperk dit met autoscaling en herpartitionering.
• Micro-batch: Kleine, frequente batches (bv. elke minuut) om een balans te vinden tussen actualiteit, stabiliteit en kosten. Gebruik in BigQuery scheduled queries of Dataflow met vaste windows.
• Streaming: Latency van milliseconden tot seconden op onbegrensde data. Gebruik Pub/Sub + Dataflow. Verwerk te late of niet-volgordelijke events met event-time windows en watermarks; zorg voor idempotentie om duplicaten te voorkomen.
• Event-driven: Getriggerd door veranderingen (GCS finalize, Pub/Sub-berichten). Gebruik Cloud Functions of Cloud Run voor stateless reacties en Dataflow voor stateful verwerking. Afweging: kosten per event versus doorvoer.
• Lambda-patroon: Onderhoud zowel streaming- als batchpaden voor nauwkeurigheid en herverwerking. De complexiteit verdubbelt; overweeg een Kappa-achtige vereenvoudiging waarbij alles opnieuw kan worden afgespeeld vanuit een onveranderlijke log (Pub/Sub naar Cloud Storage-archivering).

Kort voorbeeld van een Dataflow streaming-configuratie voor late data:

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

Domeineigenaarschap, Dataproducten en Contracten

• Eigenaarschap en SLO’s:
  • Elk domeinteam definieert en beheert zijn dataproducten met SLO’s voor beschikbaarheid, latency en datakwaliteit. Publiceer SLO’s via Dataplex-catalogi en monitor met Cloud Monitoring SLI’s (bv. tijdige volledigheid van partities).
• Contracten en interoperabiliteit:
  • Dwing schema’s af met Pub/Sub Schema Registry (Avro/Proto) en BigQuery-tabelschema’s. Valideer bij CSV-inname in Dataflow en stuur onjuist geformatteerde rijen naar een ‘dead-letter’-tabel voor analyse. Werk samen met open formaten in Cloud Storage en BigQuery external tables wanneer meerdere engines dezelfde data moeten lezen.
• Schema-evolutie:
  • Geef de voorkeur aan backward-compatible wijzigingen: voeg nullable kolommen toe, voeg optionele velden toe in Avro/Proto, vermijd het hernoemen of verwijderen zonder ‘deprecation windows’ (uitfaseringsperiodes). Communiceer wijzigingen via geversioneerde contracten en uitfaseringsschema’s.
  • BigQuery-voorbeeld (backward-compatible toevoeging van een kolom):

ALTER TABLE sales.orders
ADD COLUMN coupon_code STRING;

• Impact op consumenten:
  • Houd semantische versiebeheer van schema’s aan; publiceer zowel v1 als v2 tijdens de migratie. Voor streaming, routeer naar geversioneerde topics of voeg een schemversieveld toe. Bied authorized views in BigQuery aan om consumenten te isoleren van fysieke wijzigingen.
• Governance en lineage:
  • Gebruik Dataplex en Data Catalog voor metadata, tags (bv. PII) en lineage. Pas beveiliging op rij- en kolomniveau toe in BigQuery. Voor data loss prevention, integreer Cloud DLP in de datainname (bv. Cloud Run of Dataflow-transformaties) om gevoelige velden te tokeniseren of te maskeren vóór opslag.

Niet-functionele afwegingen en implementatietopologie

• Schaalbaarheid:
  • BigQuery schaalt elastisch voor analytics; Bigtable schaalt lineair met het aantal nodes, maar vereist een zorgvuldig row-key-ontwerp (bijv. gehashte of geroteerde prefixes) om hotspotting te voorkomen. Dataflow autoscaling reageert op backlogs; ontwerp voor backpressure door gebruik te maken van Pub/Sub flow control.
• Latentie:
  • Streamen naar BigQuery biedt inserts met lage latentie, maar query’s kunnen een lichte vertraging ondervinden; ontwerp query’s met een ‘freshness buffer’ of op watermarks gebaseerde vensters. Voor leesacties op schaal van minder dan 100 ms, bereken data vooraf en serveer deze vanuit Bigtable of Memorystore.
• Beschikbaarheid en consistentie:
  • Cloud Spanner biedt sterk consistente, wereldwijd gedistribueerde SQL. Bigtable biedt hoge beschikbaarheid met ’eventual consistency’ over clusters heen. De beschikbaarheid van BigQuery is regionaal of multi-regionaal; materialiseer kritieke datasets in een multi-regio voor veerkracht.
• Kosten:
  • Optimaliseer BigQuery met partitionering en clustering om het aantal gescande bytes te verminderen. Voor kleine bestanden over netwerkverbindingen met beperkte bandbreedte, batch of bundel ze om de RPC-overhead te verlagen. Gebruik BigQuery BI Engine voor gecachte, interactieve dashboards waar dit van toepassing is.
• Regionaal, multi-regionaal, hybride en multi-cloud:
  • Een regionaal ontwerp verlaagt de latentie en kosten; multi-regionale opslag (bijv. BigQuery US/EU multi-region, Cloud Storage dual-/multi-region) verhoogt de duurzaamheid en de lokaliteitsopties. Definieer voor DR de RPO/RTO en repliceer kritieke datasets. Gebruik in hybride scenario’s Datastream voor CDC en Transfer Appliances of Storage Transfer Service voor bulkmigratie. Standaardiseer voor multi-cloud op open formaten in Cloud Storage en gebruik portable compute (Apache Beam/Dataflow, Spark on Dataproc), en houd daarbij rekening met egress- en operationele overhead.

Laagindeling, Levenscyclus en Servicekeuze

• Scheiding van lagen:
  • Opslag: Cloud Storage voor ruwe/bronze en archiefdata; BigQuery voor gecureerde/serving analytics; Bigtable voor key-toegang met lage latentie; Spanner/Cloud SQL voor OLTP.
  • Compute: Dataflow voor serverless streaming/batch; Dataproc voor Spark/Hadoop-ecosystemen; BigQuery voor in-warehouse ELT; Cloud Run/Functions voor event-microservices.
  • Orchestratie: Cloud Composer (Airflow) of Workflows voor DAG’s en API-choreografie; Scheduler voor cron-achtige triggers.
  • Serving: Bigtable of Spanner voor online leesacties; BigQuery voor BI; Looker/BI Engine voor dashboards; Memorystore voor caching.
• Data-levenscyclus:
  • Ingest: Pub/Sub voor streams; Storage Transfer of gsutil voor bestanden; Data Transfer Service voor SaaS. Valideer, ontdubbel en plaats onveranderlijke ruwe data in Cloud Storage met object versioning.
  • Process: Gebruik Dataflow of BigQuery om ruwe data te transformeren naar silver (opgeschoond, geconformeerd) en vervolgens naar gold (bedrijfsklare marts).
  • Serve: Publiceer BigQuery-views/tabellen voor analytics; precompute features of voorspellingen naar Bigtable voor API’s.
  • Retain en archiveer: Pas Cloud Storage lifecycle-regels toe om data over te zetten naar Coldline/Archive-opslagniveaus; gebruik BigQuery-tijdpartitionering met partitie-expiratie voor retentie. Activeer CMEK waar nodig en VPC Service Controls voor bescherming tegen data-exfiltratie.
• Servicekeuze op basis van workload-kenmerken:
  • Time-series met hoge doorvoersnelheid, brede rijen en lage latentie: Bigtable.
  • Sterk consistente, wereldwijde OLTP met ANSI SQL: Cloud Spanner.
  • Traditionele relationele transacties op bescheiden schaal: Cloud SQL.
  • Analytics op petabyte-schaal met ANSI SQL en scheiding van opslag/compute: BigQuery.
  • Realtime ingestie en verwerking: Pub/Sub + Dataflow.
  • Batch Spark/Hadoop of tooling voor specifieke libraries: Dataproc.

Kort voorbeeld van BigQuery-partitionering:

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

Praktisch Probleemscenario

Contoso Mobility beheert een wereldwijde vloot e-scooters en heeft realtime ingestie, verwerking, opslag en analytics nodig voor rit-telemetrie en facturering. Ze moeten miljoenen events per minuut, frauderegels die binnen een subseconde werken, up-to-date dashboards, privacycontroles en veerkrachtige multi-regionale operaties ondersteunen.

Aanpak:

1. Zet event-ingestie op met Cloud Pub/Sub.

• Rationale: Pub/Sub biedt één globaal eindpunt, duurzame buffering en horizontale schaalbaarheid voor pieken in apparaatverkeer. Gebruik geordende sleutels per scooter om de interne volgorde per apparaat te behouden voor vensters van 1 uur.

2. Implementeer streaming-verwerking met Cloud Dataflow (Apache Beam).

• Rationale: Dataflow autoscaling vangt pieken op en biedt exactly-once sinks in combinatie met idempotente sleutels. Gebruik event-time windows en watermarks om late/niet-op-volgorde telemetrie te verwerken. Genereer een hoofd-output naar gecureerde streams en een side-output voor dead-letter records.
• Configuratie:

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

3. Persisteer ruwe en gecureerde data in respectievelijk Cloud Storage en BigQuery.

• Rationale: Plaats ruwe (bronze) Avro-bestanden in een dual-region Cloud Storage-bucket voor replay en audit. Schrijf gecureerde (silver) streams naar gepartitioneerde BigQuery-tabellen voor analytics, met clustering op scooter_id voor efficiënte point lookups. Pas een kleine ‘freshness buffer’ toe op dashboard-query’s om tijdelijke veroudering door streaming te voorkomen.

4. Serveer operationele lookups en fraudecontroles vanuit Cloud Bigtable.

• Rationale: Regel-evaluatie onder de 100 ms vereist willekeurige toegang met lage latentie. Precompute aggregaten (bijv. ritten per apparaat per venster van 5 minuten) in Dataflow en schrijf deze naar Bigtable met een ‘hashed prefix row key’ (bijv. h(prefix)+device_id+window_start) om hotspotting te vermijden en leesacties over tablets te parallelliseren.

5. Beheer transactionele facturering in Cloud Spanner.

• Rationale: Facturering vereist wereldwijd consistente SQL, sterke consistentie en hoge beschikbaarheid. Gebruik een leader in de primaire geografische regio met read-only replica’s in secundaire regio’s om de leeslatentie voor klantenportals te verlagen.

6. Dwing governance af met Dataplex, Data Catalog en Cloud DLP.

• Rationale: Classificeer PII-velden, tag datasets en pas beveiliging op kolomniveau toe in BigQuery. Integreer Cloud DLP in de Dataflow-pipeline om gevoelige attributen te tokenizen vóór opslag. Dataplex-domeinen weerspiegelen organisatorisch eigendom; elk domein publiceert gedocumenteerde dataprocucten met SLO’s.

7. Orchestreer en beheer met Cloud Composer en Cloud Monitoring.

• Rationale: Composer coördineert batch-backfills, compactions en de materialisatie van ML-features. Monitoring observeert end-to-end SLI’s: Pub/Sub-backlog, Dataflow watermark-vertraging, volledigheid van BigQuery-partities en Bigtable tail-latencies. Alarmeer bij SLO-schendingen; schaal Dataflow automatisch op basis van de groei van de backlog.

8. Optimaliseer kosten en levenscyclus met partitionering en tiering.

• Rationale: BigQuery-tabellen worden gepartitioneerd op event_ts met een retentie van 90 dagen, en geclusterd op scooter_id. Cloud Storage gebruikt lifecycle-regels om ruwe data na 30 dagen over te zetten naar Coldline en na 180 dagen naar Archive. Geplande BigQuery-taken comprimeren kleine micro-batch-bestanden tot grotere parquet-objecten om de overhead van het aantal bestanden voor downstream Spark-taken te verminderen.

9. Valideer risico’s en veerkracht.

• Rationale: Voer loadtests uit op 2x de verwachte piek om Pub/Sub-quota’s en Dataflow-autoscaling te valideren. Voer een regionale failover-oefening uit: BigQuery multi-region datasets en dual-region buckets behouden de beschikbaarheid; de multi-region instance van Spanner handhaaft RPO=0 en de geconfigureerde RTO via automatische failover. Gebruik Infrastructure as Code (Terraform) met beleidsvalidatie om CMEK en VPC Service Controls af te dwingen.

Deze architectuur scheidt de verantwoordelijkheden duidelijk: Pub/Sub buffert de ingestie, Dataflow voert berekeningen uit, Cloud Storage en BigQuery slaan data op en serveren analytics, Bigtable versnelt operationele leesacties en Spanner garandeert consistente transacties. Het balanceert schaalbaarheid en latentie terwijl de kosten worden beheerst door partitionering, clustering, lifecycle-beleid en autoscaling, en het verankert governance en betrouwbaarheid door middel van gedocumenteerde dataprocucten, contracten en continue validatie.

Alle domeinen · Dataopslag →

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

Blader door Google →