Google PCA: Dataopslag, Databases en Analytics-architectuur — Studiegids

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Overzicht

Het ontwerpen van dataopslag, databases en analytics op Google Cloud vereist het afstemmen van workloadpatronen op services, terwijl rekening wordt gehouden met duurzaamheid, beschikbaarheid, toegangsbeheer, kosten en operationele veerkracht. Dit gedeelte behandelt object storage en lifecycle governance; operationele databases en caches; analytics warehousing en -verwerking; ingestie-architecturen; en praktijken voor governance, bescherming en prestaties. Het benadrukt ontwerpkeuzes, operationele redeneringen en veelvoorkomende faalmodi of afwegingen.

Storage- en Objectarchitectuur

Ontwerp van Cloud Storage-buckets

• Locatie: kies een regio voor workloads die gevoelig zijn voor lage latentie en kosten; een dual-region voor bedrijfscontinuïteit met voorspelbare failover; een multi-region voor wereldwijde leestoegang. Dual-region biedt optionele turbo-replicatie voor een door een SLA ondersteunde, lage RPO; anders is de replicatie asynchroon.
• Naamruimte en scheiding: gebruik afzonderlijke buckets voor datadomeinen, omgevingen en gevoeligheidsniveaus. Pas uniforme toegang op bucketniveau en preventie van openbare toegang toe voor consistente permissies.
• Storage-klassen: Standard voor ‘hot’ data; Nearline voor data die niet frequent wordt benaderd (maandelijks); Coldline voor kwartaal-toegang; Archive voor langetermijnbewaring. Autoclass kan de plaatsing van klassen automatisch optimaliseren met minimale operationele inspanning.
• Lifecycle-beleid: automatiseer de overgang en verwijdering op basis van leeftijd, storage-klasse of object-prefix. Voorbeeld om objecten ouder dan 90 dagen te verwijderen: { “rule”: [ { “action”: {“type”: “Delete”}, “condition”: {“age”: 90} } ] } Toepassen met: gsutil lifecycle set lifecycle.json gs://my-bucket
• Retentie en juridische bewaarplicht (legal holds): configureer bewaarbeleid voor buckets en vergrendel dit optioneel om verlaging te voorkomen (compliance). Event-based holds en object-versiebeheer maken herstel mogelijk van onbedoelde verwijderingen of overschrijvingen.
• Replicatie: kies dual-region voor synchrone consistentiesemantiek op de API met achtergrondreplicatie over twee regio’s; gebruik bucket-naar-bucket-replicatie (voor kopieën over projecten of locaties heen) om te voldoen aan gespecialiseerde RPO/RTO of scheiding van taken.

Faalmodi en afwegingen

• Een mismatch in klasse verhoogt de kosten en latentie. Autoclass vermindert dit, maar voegt beheeroverhead per object toe.
• Retentievergrendeling is onomkeerbaar; test beleid in een niet-productieomgeving.
• Replicatie verbetert de duurzaamheid, maar kan de schrijflatentie en kosten verhogen; ontwerp lees-/schrijfpanden voor specifieke locaties.

Patronen

• Data lake: ‘raw’ en ‘curated’ zones op Cloud Storage; governance via Dataplex; geëxternaliseerde schema’s in Data Catalog.
• Archivering: Archive-klasse met retentievergrendeling voor compliance, met externe tabellen in BigQuery of on-demand herstel voor zeldzame analyses.
• Lakehouse: gebruik BigLake om de toegang over Cloud Storage en BigQuery te verenigen met consistente beveiliging.

Operationele Datastores en Caching

Cloud SQL

• Hoge beschikbaarheid: regionale HA met synchrone replicatie naar een standby; automatische failover duurt doorgaans enkele seconden tot een paar minuten. Het instance-eindpunt blijft hetzelfde, waardoor app-wijzigingen minimaal zijn.
• Read replica’s: binnen de regio of cross-region, asynchroon; goed voor read scale-out en DR. Monitor de lag; verouderde reads kunnen de correctheid beïnvloeden.
• Back-ups en PITR: geplande back-ups plus point-in-time recovery met behulp van transactielogs (meestal een venster van maximaal 7 dagen, afhankelijk van de engine). Test het herstellen regelmatig.
• Private connectiviteit: privaat IP via VPC-peering vermindert blootstelling en latency; plan IP-ranges om overlap te voorkomen.
• Migratie: Database Migration Service ondersteunt verplaatsingen met lage downtime vanaf on-prem of andere clouds; geef voor verbindingen met hoog volume de voorkeur aan Dedicated of Partner Interconnect boven VPN om pakketverlies en latency te verminderen.

Trade-offs en faalscenario’s

• HA-failovers resetten verbindingen; applicaties moeten opnieuw proberen met backoff. Onderhoudsvensters kunnen de prestaties kortstondig verminderen.
• Langlopende transacties verhogen de replicatie-lag en de hersteltijd van PITR.
• Over-provisioned opslag is een goedkope verzekering; onder-provisioned IOPS veroorzaken latente storingen tijdens piekbelasting.

Cloud Spanner

• Wereldwijde schaal en consistentie: sterk consistente reads/writes over regio’s heen met behulp van TrueTime en two-phase commit. Kies regionaal voor de laagste write-latency; multi-region voor hogere beschikbaarheid en wereldwijde reads.
• Transacties: externe consistentie en volledig ACID over rijen en tabellen; read-only transacties schalen over replica’s.
• Schemaontwerp: kies primary keys die hotspots vermijden; gebruik interleaved tabellen voor lokaliteit; houd rekening met de write-amplification en het backfill-gedrag van secundaire indexen.
• Regionaliteit: de plaatsing van de leader-regio bepaalt de write-latency; multi-region voegt quorumkosten en commit-latency toe.

Trade-offs

• Write-latency groeit met de geografische voetafdruk; vermijd multi-region tenzij beschikbaarheid en wereldwijde distributie dit rechtvaardigen.
• De basiskosten zijn hoger dan die van single-node VM-databases; capaciteitsplanning moet aansluiten bij SLO’s en groei.

Firestore, Bigtable, Memorystore en selectie

• Firestore: documentdatabase voor mobiele/web-backends; sterke consistentie voor afzonderlijke documenten; fijnmazige beveiliging; automatische indexering. Pas op voor contentie op frequent bijgewerkte documenten; gebruik gedistribueerde tellers en batched writes.
• Bigtable: wide-column, petabyte-schaal, ultra-lage latency voor time-series en IoT; ontwerp row keys om hotspots te vermijden (bijv. hashen of salting); schaal op basis van nodes en clusters; multi-cluster routing voor beschikbaarheid. Replicatie is asynchroon; sterke consistentie is per cluster.
• Memorystore for Redis: in-memory cache; Basic-tier is een enkele instance (geen HA); Standard-tier biedt een replica en automatische failover (korte onderbrekingen mogelijk). Behandel het als cache, niet als ‘source of truth’; persistentiefuncties verminderen de volatiliteit maar vervangen geen databaseback-ups.

Workload-gedreven selectie

• Relationeel met joins/ACID en gematigde schaal: Cloud SQL.
• Wereldwijd relationeel met horizontale schaal en externe consistentie: Cloud Spanner.
• High-throughput time-series/telemetrie of zeer grote key-value: Bigtable.
• App-centrische documentmodellen met hiërarchische query’s: Firestore.
• Efemerale versnelling en rate limiting: Memorystore.

Analytics, Ingestie en Verwerking

BigQuery

• Datasets: logische grenzen voor beveiliging en facturering; hanteer naamgevingsconventies per domein en levenscyclusfase.
• Partitionering: op basis van ingestion-tijd of kolom voor temporele filtering; ook integer-range partitionering. Gebruik time-unit partitionering voor event_ts om scans te ‘prunen’.
• Clustering: tot vier kolommen om gerelateerde data samen op te slaan; verbetert de prestaties en kosten van selectieve query’s.
• Reservations: beheer dedicated slots via reserveringen en toewijzingen; gebruik flex slots voor ‘bursty’ experimenten; isoleer kritieke workloads om ‘starvation’ te voorkomen.
• Toegangscontrole: IAM op project- en datasetniveau; controle op tabel/kolom met row-level policies en policy tags; deel gecureerde data via authorized views en routines.

Nuttig voorbeeld: bq mk –dataset myproj:analytics bq mk –table –time_partitioning_field=event_ts –clustering_fields=user_id,device_type myproj:analytics.events ./schema.json

Trade-offs en faalscenario’s

• Slechte partitionering leidt tot full-table scans en uit de hand lopende kosten.
• Clustering helpt alleen als filters of joins de geclusterde kolommen bevatten; frequente ‘reshuffles’ kunnen het voordeel verminderen.
• Onder-provisioning van slots plaatst jobs in de wachtrij; over-provisioning verhoogt de kosten. Monitor het slotgebruik en ‘spilled shuffle’.

Data-ingestie en -verwerking

• Pub/Sub: wereldwijd, duurzaam, at-least-once delivery; ordering keys forceren een per-key-volgorde met trade-offs in doorvoersnelheid. Ontwerp idempotente consumers.
• Dataflow: geünificeerde batch en streaming met autoscaling, exactly-once stateful processing, windowing en triggers; Streaming Engine offloadt de state. Gebruik dead-letter topics en herbruikbare bronnen.
• Dataproc: beheerde Spark/Hadoop voor bestaande code en ecosystemen; efemere clusters of autoscaling; gebruik voor ML-bibliotheken of wanneer porteren kostbaar is.

Trade-offs batch vs. streaming

• Streaming verlaagt de latency en ondersteunt real-time, maar verhoogt de complexiteit (state, watermarking, late data) en de doorlopende kosten.
• Batch vereenvoudigt correctheid en kostenbeheersing; acceptabel wanneer SLA’s vertraging tolereren.
• Hybride patronen: laat ruwe events landen in Cloud Storage, stream geaggregeerde KPI’s naar BigQuery, en voer nachtelijke batch-herberekeningen uit voor nauwkeurigheid.

Warehouse-patronen

• Warehouse: BigQuery als het analysesysteem; materialized views en scheduled queries voor het bedienen van BI.
• Lakehouse: beheer data in Cloud Storage met open formaten; stel deze beschikbaar via BigLake aan BigQuery met consistente beveiliging.

Governance, Bescherming en Prestaties

Data governance en beveiliging

• Metadata en lineage: gebruik Data Catalog voor technische en zakelijke metadata; schakel lineage capture in vanuit Dataflow, BigQuery en Dataproc om afhankelijkheden te traceren.
• Kwaliteit: dwing regels af met Dataplex data quality en orkestreer controles in Composer of Dataform; plaats slechte records in quarantaine.
• Toegangsbeperkingen: VPC Service Controls rond BigQuery en Cloud Storage om het risico op exfiltratie te verminderen; IAM Conditions voor contextbewuste toegang; CMEK voor cryptografische controle; policy tags voor beperkingen op kolomniveau.
• Retentie: stem de retentie van Cloud Storage-buckets, BigQuery table time travel (configureerbaar tot 7 dagen) en de vervaldatum van datasets/tabellen af op wettelijke vereisten.

Back-up, PITR en bescherming tegen verwijdering

• Valideer back-ups: herstel periodiek Cloud SQL- en Spanner-back-ups naar geïsoleerde omgevingen en voer checksums en validaties op applicatieniveau uit.
• Bigtable: schakel PITR in om te herstellen naar een tijdstip binnen een geconfigureerde retentieperiode; test hersteloperaties op tabel- of clusterniveau.
• Spanner: gebruik back-ups voor disaster recovery; maak gebruik van stale reads binnen de versie-retentie voor audit-queries.
• Cloud Storage: schakel object versioning en bucket retention lock in als bescherming tegen onbedoelde verwijderingen; repliceer naar een afzonderlijk project voor isolatie van operatorfouten.
• BigQuery: gebruik time travel en table snapshots; vermijd drops op productie-datasets met vereiste goedkeuringen en bescherming tegen verwijdering op datasetniveau.

Dataprestaties en kostenbeheersing

• Vermijd hot keys: distribueer Bigtable row keys (hash-prefixen), kies Spanner primary keys die leadership elections randomiseren, shard Firestore-tellers.
• Indexen: onderhoud de benodigde SQL- en NoSQL-indexen; in BigQuery, cluster op veelgebruikte filters; in Cloud SQL, monitor trage queries en voer regelmatig vacuum/analyze uit op Postgres.
• Capaciteitsplanning: stel een baseline vast met loadtests; stel SLO’s en error budgets in; monitor het gebruik van BigQuery-slots, Bigtable CPU/read-modify-write-latencies, Cloud SQL CPU/IOPS en de Pub/Sub-backlog.
• Kostenbeheersing: gebruik BigQuery slot commitments voor stabiele workloads, Autoclass voor Cloud Storage, comprimeer Bigtable-tabellen en stem Bloom filters af, laat oude partities en datasets verlopen, en implementeer budgetten en waarschuwingen per team.

Praktijkscenario

Acme Retail Group heeft een uniform analyseplatform nodig voor clickstream- en orderdata met lage latency. Vereisten: real-time KPI’s binnen 10 seconden, historische analyse over vijf jaar met SQL, hersteldoelstellingen van minder dan een uur, strikte dataresidentie in de VS en het voorkomen van onbedoeld dataverlies.

1. Ruwe events opslaan en duurzame ingestion implementeren

• Maak dual-region us-central1/us-east1 Cloud Storage-buckets voor ruwe en gecureerde zones; schakel Autoclass en object versioning in voor de ruwe data.
• Rationale: dual-region voldoet aan de eisen voor duurzaamheid en residentie; versioning beschermt tegen foutieve backfills; Autoclass optimaliseert automatisch de opslagkosten.

2. Events betrouwbaar streamen met Pub/Sub en Dataflow

• Publiceer clickstream- en orderevents naar Pub/Sub-topics met ordering keys per user_id; implementeer een Dataflow-streamingpipeline om de output te valideren, ontdubbelen, verrijken en te vertakken naar BigQuery (hot KPI’s) en Cloud Storage (parquet in de gecureerde zone).
• Rationale: Pub/Sub biedt wereldwijde, duurzame at-least-once delivery; Dataflow biedt exactly-once state en autoscaling; vertakking onderhoudt een lakehouse-patroon voor herverwerking.

3. Real-time features aanbieden met Bigtable en Redis

• Schrijf een subset van verrijkte events naar Bigtable met een gesalte user_id#timestamp row key; gebruik Memorystore for Redis als een front-cache voor de meest recente sessies.
• Rationale: Bigtable levert schrijfacties met lage latency en hoge doorvoer voor time-series; salting voorkomt hotspots; Redis vermindert tail latency voor live personalisatie.

4. Data warehousen en queries optimaliseren in BigQuery

• Maak datasets die gepartitioneerd zijn op event_date en geclusterd op user_id, channel. Gebruik materialized views voor KPI’s en geplande compactions voor het laden van kleine bestanden; koop een basis slot-reservering met een kleine flex-slotbuffer voor pieken.
• Rationale: partitionering en clustering snoeien scans en verlagen de kosten; materialized views versnellen dashboards; reserveringen beperken de kosten en beschermen kritieke workloads tegen wachtrijen.

5. Toegang beheren en exfiltratie voorkomen

• Pas IAM op datasetniveau toe voor analistengroepen; gebruik policy tags om PII-kolommen te beperken en authorized views voor toegang door leveranciers. Dwing VPC Service Controls af rond BigQuery en Cloud Storage; gebruik CMEK voor gereguleerde datasets.
• Rationale: least-privilege op dataset- en kolomniveau; VPC SC vermindert het risico op data-exfiltratie; CMEK voldoet aan de cryptografische controlevereisten.

6. Back-ups, PITR en hersteltests implementeren

• Schakel Bigtable PITR in voor 7–14 dagen; maak wekelijkse Spanner- of Cloud SQL-back-ups voor transactionele order-stores; maak dagelijks snapshots van kritieke BigQuery-tabellen en vertrouw op time travel voor fouten. Voer per kwartaal hersteloefeningen uit naar een geïsoleerd project.
• Rationale: gelaagde herstelopties pakken logische fouten en calamiteiten aan; regelmatige oefeningen valideren RPO/RTO en runbooks.

7. Dataretentie en lifecycle beheren

• Pas een lifecycle-regel toe om ruwe objecten na 30 dagen en gecureerde na vijf jaar te verwijderen (purgen); vergrendel een retentiebeleid op bucketniveau dat aan de compliance voldoet. Stel de standaard vervaldatum in voor tijdelijke BigQuery-datasets/tabellen.
• Rationale: automatische handhaving vermindert het operationele risico; retention lock voorkomt onbedoelde of ongeautoriseerde verzwakking van het beleid.

8. Prestaties en kosten monitoren en hotspots mitigeren

• Volg het gebruik van BigQuery-slots, gescande bytes en de concurrency van BI-queries; monitor Bigtable CPU en read-modify-write-latency; waarschuw bij een Pub/Sub-backlog. Als er user_id-hotspots ontstaan, vergroot dan de salt-breedte en backfill de keys via Dataflow.
• Rationale: continue telemetrie vindt knelpunten vroegtijdig; proactieve wijzigingen in de key-strategie behouden SLO’s zonder een volledige herarchitecturering.

9. Private connectiviteit en isolatie voorzien

• Gebruik voor hybride afhankelijkheden Partner of Dedicated Interconnect met Cloud Router; zorg voor niet-overlappende IP-ranges; gebruik Private Service Connect voor managed service-eindpunten.
• Rationale: private paden verminderen latency en packet loss; een duidelijke IP-planning en PSC dwingen isolatie en voorspelbare routing af.

10. Betrouwbaarheid operationaliseren

• Activeer canary Dataflow-pipelines en blue/green BigQuery-views; dwing schema-evolutie af via goedkeuringen in Data Catalog; integreer dead-letter queues met de incidentrespons.
• Rationale: gecontroleerde rollouts beperken de blast radius; beheerde schemawijzigingen handhaven de datakwaliteit; DLQ’s zorgen ervoor dat er geen data verloren gaat tijdens incidenten.

← Compute · Alle domeinen · Netwerken →

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

Blader door Google →