Google PDE: Dataopslag, Lakes en Bestandsformaten — 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

Dataopslag op Google Cloud omvat ruwe object storage, gecureerde data lakes en voor analytics geoptimaliseerde formaten. Het bouwen van betrouwbare, beheerde en performante lakes vereist zorgvuldige keuzes in opslagklassen, bucket-instellingen, locaties, bestandsformaten, tabelindeling en levenscyclus. Dit gedeelte beschrijft de afwegingen in het ontwerp, te vermijden faalscenario’s en patronen die aansluiten bij BigQuery, Spark en streaming-pipelines op grote schaal.

Grondbeginselen van Cloud Storage: klassen, buckets, consistentie en levenscyclus

Cloud Storage is de duurzame, hoog beschikbare basis voor ruwe en gecureerde bestanden.

• Opslagklassen

  • Standard (heet): frequente toegang, laagste latency. Geen minimale opslagduur.
  • Nearline (koel): niet-frequente toegang (~maandelijks). Minimum van 30 dagen; ophaalkosten van toepassing.
  • Coldline (kouder): niet-frequente toegang (~per kwartaal). Minimum van 90 dagen; hogere ophaalkosten.
  • Archive (koudst): langetermijnbewaring (~jaarlijks). Minimum van 365 dagen; hoogste ophaalkosten.
  • Autoclass kan automatisch overgaan tussen klassen; verifieer dat kosten voor vroegtijdige verwijdering en toegangspatronen de besparingen niet tenietdoen.

• Bucket-locaties en replicatie

  • Regio: het beste voor datalokaliteit en compliance binnen één geografisch gebied.
  • Dual-region: twee gekoppelde regio’s met automatische replicatie; turbo-replicatie commit replica’s snel met een RPO gemeten in minuten; ideaal voor DR met een lage RPO.
  • Multi-region: geografisch gedistribueerd binnen een continent voor brede beschikbaarheid, contentdistributie en analytics over een groot gebied.
  • Kies locaties om te voldoen aan wetgeving voor dataresidentie en om egress/latency naar compute (Dataproc, Dataflow, BigQuery externe tabellen) te minimaliseren.

• Consistentie en semantiek

  • Cloud Storage biedt sterke wereldwijde ‘read-after-write’, ‘read-after-metadata-update’ en ’list-after-write’ consistentie.
  • Object-writes zijn atomair en onveranderlijk (immutable); ‘hernoemen’ is een kopieer+verwijder-patroon. Ontwerp voor idempotente kopieeracties en verifieer checksums om gedeeltelijke migraties te voorkomen.

• Toegangspatronen en prestaties

  • Parallelle samengestelde uploads en hervatbare uploads verbeteren de doorvoer voor grote bestanden.
  • Range reads maken efficiënte kolom-footers en selectieve leesacties mogelijk.
  • Vermijd veel kleine bestanden (<8 MB) die de metadata/listing-overhead verhogen; batch of comprimeer ze tot grotere objecten.
  • GZIP is niet ‘splittable’ (opdeelbaar) voor gedistribueerde leesacties; geef de voorkeur aan Parquet/ORC/Avro+Snappy voor schaalbare verwerking.

• Levenscyclus, retentie en versiebeheer

  • Retentiebeleid op bucket-niveau en object holds (gebeurtenisgebaseerd of tijdelijk) dwingen onveranderlijkheid af voor compliance en om onbedoelde verwijderingen te verminderen.
  • Objectversiebeheer bewaart eerdere generaties; nuttig voor herstel na overschrijven/verwijderen. Monitor de groei van opslagkosten.
  • Levenscyclusregels automatiseren overgangen en verwijderingen. Voorbeeld (JSON) om oudere data naar een koudere klasse te verplaatsen en na een jaar te verwijderen:

undefined

• Faalscenario’s: kosten voor vroegtijdige verwijdering als u te agressief overgaat; retentielocks kunnen niet worden ingekort; versiebeheer zonder compactie kan de kosten doen stijgen.

• Overdrachten en migratie

  • Gebruik Storage Transfer Service voor geparallelliseerde, gecheckpointte verplaatsingen vanaf on-prem of andere clouds; Transfer Appliance voor offline petabytes.
  • Valideer de integriteit met CRC32C/MD5 en ‘generation-match’-voorwaarden om race conditions te voorkomen.
  • Geef de voorkeur aan gsutil/gcloud storage met -m (parallel) en checksums; vermijd SFTP-knelpunten voor ingress met hoog volume.

Verenigde lake governance met BigLake en Dataplex

BigLake en Dataplex standaardiseren beveiliging en governance voor bestanden en tabellen.

• BigLake

  • Stelt Cloud Storage-data beschikbaar als door BigQuery beheerde tabellen (extern) met uniforme, fijnmazige toegangscontrole, inclusief toegangsbeleid op rijniveau en policy-tags op kolomniveau.
  • Maakt ‘column pruning’ en ‘predicate pushdown’ mogelijk voor Parquet/ORC, wat het aantal gescande bytes en de egress naar engines zoals BigQuery, Spark on Dataproc en Dataflow vermindert.
  • Centraliseert audits via Cloud Logging en centrale beleidshandhaving; één enkel controlepaneel voor lake-bestanden en warehouse-tabellen.

• Dataplex

  • Organiseert data in lakes, zones (raw, curated, trusted) en assets (buckets, datasets); beheert metadata, lineage en datakwaliteitsregels.
  • Integreert met policy-tags voor gevoelige kolommen en ondersteunt ’least privilege’ via IAM op het niveau van lake/zone/asset.
  • Stimuleert gestandaardiseerde naamgeving, partitionering en schemabeheer in omgevingen met meerdere teams om ‘rommellaadjes’ te voorkomen.

• Governance-patronen

  • Implementeer ‘dataset-per-tenant’- en ‘bucket-per-zone’-patronen; vermijd dat data tussen tenants ’lekt’.
  • Gebruik toegangsbeleid op rijniveau en policy-tags op kolomniveau voor PII. Beperk API-toegang tot goedgekeurde identiteiten.
  • Auditeer toegang met Cloud Logging; stuur gefilterde logs door naar Pub/Sub voor real-time monitoring.

Bestandsformaten, compressie en querygedrag

De keuze van het juiste formaat heeft een directe impact op de kosten en prestaties.

• Kolomgeoriënteerde formaten (Parquet, ORC)

  • Sterke punten: column pruning, predicate pushdown, codering en compressie per kolom, statistieken en splitsbare bestanden.
  • Nadelen: hoger CPU-gebruik tijdens het schrijven; schema-evolutie moet zorgvuldig worden beheerd (bijv. het toevoegen van kolommen is veilig; typewijzigingen zijn riskant).
  • Compressie: Snappy voor snelheid, ZSTD voor betere compressieratio’s waar ondersteund. Vermijd GZIP voor kolomgeoriënteerde formaten, tenzij interoperabiliteitsbeperkingen dit vereisen.

• Rijgeoriënteerde Avro

  • Sterke punten: schema-evolutie met sterke typering, compressie op blokniveau, splitsbaar; uitstekend voor landing zones voor streaming en voor data-uitwisseling.
  • Nadelen: minder efficiënt voor analyses dan kolomgeoriënteerde formaten; converteer naar Parquet/ORC in de gecureerde zones.

• CSV en JSON (semi-gestructureerd)

  • CSV: leesbaar voor mensen, kleinste overhead bij eenvoudige waarden; mist schema, typen en consistente escaping; duur om op grote schaal te parsen.
  • JSON: zelfbeschrijvend en flexibel; newline-delimited JSON is vereist voor schaalbare gedistribueerde leesbewerkingen; omslachtig en CPU-intensief om te parsen.
  • Indien mogelijk, land ruwe CSV/JSON, valideer en converteer deze vervolgens naar Avro/Parquet voor analyses.

• BigQuery external en BigLake-tabellen

  • Parquet/ORC external-tabellen profiteren van pushdown en column pruning; CSV/JSON doen dit doorgaans niet, wat leidt tot meer gescande bytes.
  • Gecomprimeerde CSV (GZIP) external-tabellen kunnen niet worden opgesplitst over workers; verwacht tragere leesbewerkingen.
  • Voorbeeld: een Parquet BigLake-tabel aanmaken met Hive-stijl partities: CREATE EXTERNAL TABLE lake.sales WITH CONNECTION us.biglake_conn OPTIONS ( format = ‘PARQUET’, hive_partitioning_mode = ‘AUTO’, hive_partitioning_source_uri_prefix = ‘gs://corp-raw/sales/’, uris = [‘gs://corp-raw/sales/date=/region=/part-*.parquet’] );

Indeling, partitionering, performance-engineering, residentie en migratie

• Objectindeling en -partitionering

  • Gebruik Hive-stijl paden voor partities en clusteringsleutels: gs://bucket/dataset/table/date=YYYY-MM-DD/hour=HH/region=us/part-00001.parquet
  • Houd de grootte van individuele bestanden tussen 128 en 1024 MB voor een gebalanceerd parallellisme en taakoverhead. Vermijd miljoenen bestanden per partitie.
  • Beperk problemen met kleine bestanden door:
    • Uploads aan de clientzijde te batchen.
    • Dataflow/Spark-compactietaken te gebruiken om kleine bestanden buiten de piekuren samen te voegen.
    • De originele kleine bestanden te archiveren en alleen de gecomprimeerde data beschikbaar te stellen voor analyses.

• BigQuery-partitionering en -clustering

  • Partitioneer op ingestietijd of een filterkolom met hoge kardinaliteit (bijv. event_date). Vermijd overpartitionering (bijv. per minuut) waardoor de metadata explodeert.
  • Cluster op dimensies waarop vaak wordt gefilterd/gesorteerd (maximaal vier). Clusteren verhoogt de datalocaliteit en vermindert het aantal gescande bytes.
  • Geef de voorkeur aan native BigQuery-tabellen voor zware interactieve analyses; gebruik BigLake/externe tabellen voor beheerde toegang tot het lake, delen tussen engines en kostenisolatie.

• Implicaties voor queryprestaties

  • Kolomgeoriënteerde formaten verlagen de kosten voor externe scans aanzienlijk; externe tabellen in CSV/JSON vereisen vaak volledige bestandsscans.
  • Consistentiegaranties elimineren de noodzaak voor kunstmatige vertragingen bij het lezen uit Cloud Storage, maar downstream systemen (bijv. BigQuery streaming inserts) kunnen een korte vertraging in de zichtbaarheid van data vertonen — ontwerp waar nodig met watermarks of leesvertragingen.

• Residentie, duurzaamheid en herstel

  • Selecteer bucket-/datasetlocaties om te voldoen aan residentievereisten; colloceer compute om egress en latentie te verminderen.
  • Gebruik dual-region met turbo-replicatie voor een lage RPO; versiebeheer plus bewaarbeleid voor herstelbaarheid na menselijke fouten en ransomware.
  • Voor DR, repliceer buckets naar een afzonderlijk project/regio met behulp van bucket-replicatie en bescherm met afzonderlijke IAM-grenzen.

• Veilige migratie en validatie

  • Plan in meerdere fasen: seed (bulkoverdracht), incrementele synchronisatie (mtime/windowed copy), cutover (alleen-lezen bron) en validatie na de cutover.
  • Valideer met checksums, aantallen, byte-totalen en steekproefdecodering. Vergelijk voor tabeldata het aantal rijen en hash-aggregaten:

undefined

• Gebruik precondities (ifGenerationMatch) om overschrijvingen tijdens parallelle kopieeracties te voorkomen. Houd een rollback-venster aan met versiebeheer of een behouden bron.
• Activeer na de migratie lifecycle en Autoclass volgens het nieuwe toegangsprofiel; vermijd het inschakelen van retention lock totdat de validaties zijn geslaagd.

Praktijkscenario

Acme Retail ontvangt dagelijks CSV-drops van een logistieke partner in een regionale Cloud Storage-bucket. De bestanden bevatten af en toe ongeldige rijen. Acme moet de data landen, valideren, converteren naar een analyse-klaar formaat en laden in BigQuery voor near-real-time dashboards, terwijl ongeldige rijen bewaard blijven voor inspectie en governance wordt afgedwongen.

Aanpak:

1. Ruwe data landen en beheren in Dataplex

   • Maak een Dataplex-lake met een raw zone-asset die is gekoppeld aan gs://acme-raw/logistics/.
   • Rationale: Gecentraliseerde governance, metadata en lineage. Dwing IAM af op zoneniveau en tag gevoelige velden met policy-tags voor downstream-handhaving.

2. Lifecycle en retentie afdwingen

   • Pas een bucket-retentiebeleid van 30 dagen toe en schakel object-versiebeheer in op acme-raw.
   • Rationale: Beschermt tegen onbedoeld overschrijven/verwijderen door de partner; een korte retentieperiode balanceert kosten en herstelbaarheid. Versiebeheer maakt een rollback van slechte leveringen mogelijk.

3. Valideren en opnemen met een Dataflow-batchpipeline

   • Trigger een dagelijkse Dataflow-taak op basis van ‘object finalize’-meldingen. Lees CSV met schema en validatie per record; schrijf geldige records naar een BigQuery-stagingtabel (gepartitioneerd op event_date) en stuur parseer-/validatiefouten naar een dead-letter BigQuery-tabel.
   • Rationale: Dataflow biedt schaalbare parallelle parsing en robuuste dead-letter-afhandeling, zodat analisten ongeldige rijen kunnen inspecteren. Dit weerspiegelt de best practice voor heterogene CSV-kwaliteit.

4. Compacteer en converteer naar Parquet in een curated zone

   • Dezelfde pipeline schrijft gevalideerde data naar gs://acme-curated/logistics/date=YYYY-MM-DD/ als Parquet-bestanden van ~256–512 MB.
   • Rationale: Parquet maakt column pruning en predicate pushdown mogelijk in BigQuery en Spark, waardoor het aantal gescande bytes afneemt en de latentie verbetert; compactie beperkt de overhead van kleine bestanden die voortkomt uit het leveringspatroon van de partner.

5. Beheerde analyses beschikbaar stellen via BigLake

   • Maak een externe BigLake-tabel over het curated Parquet-pad met Hive auto-partitionering; pas policy-tags op kolomniveau en rij-toegangsbeleid toe voor partnerspecifieke filters.
   • Rationale: Uniforme, fijnmazige toegang over BigQuery en Spark met gecentraliseerde audit. Partition pruning verlaagt de scankosten bij datumfilters.

6. Laad kritieke aggregaten in native BigQuery

   • Voer voor ‘hot’ dashboards een geplande BigQuery-taak uit die de laatste N dagen opneemt uit de externe curated Parquet-tabel in een native geclusterde, gepartitioneerde tabel.
   • Rationale: Native opslag versnelt BI met hoge concurrency, terwijl de externe BigLake-tabel het beheerde ‘system-of-record’ blijft voor bredere toegang.

7. Monitoren en alarmeren met Cloud Logging en Pub/Sub

   • Maak een log-sink die de resultaten van Dataflow- en BigQuery-laadtaken filtert naar Pub/Sub; integreer met de monitoringtool voor directe waarschuwingen bij storingen of verhoogde percentages ongeldige rijen.
   • Rationale: Gerichte, tabelspecifieke operationele zichtbaarheid zonder polling; ondersteunt SRE-praktijken.

8. Optimaliseer opslagklasse en residentie

   • Bewaar de curated Parquet-data 14 dagen in Standard, zet na 30 dagen over naar Coldline via een lifecycle-regel; sla zowel de raw als de curated buckets op in dezelfde regio als de BigQuery-datasets om egress te vermijden.
   • Rationale: Balanceert ‘hot read’-prestaties met kosten. Co-locatie handhaaft compliance en minimaliseert latentie en egress-kosten.

9. Valideer end-to-end kwaliteit

   • Vergelijk na elke run de aantallen en hash-aggregaten tussen de staging-, curated externe en native BigQuery-tabellen; plaats afwijkingen in quarantaine.
   • Rationale: Vroege detectie van schema-drift of regressies in de opname; cryptografische of fingerprint-hashes bieden lichtgewicht zekerheid zonder volledige re-scans.

Dit ontwerp biedt een veerkrachtige opname met dead-letter-analyse, analyse-klaar Parquet voor efficiënte query’s, gecentraliseerde governance via Dataplex en BigLake, en kosten-geoptimaliseerd lifecycle-beleid, terwijl het principe van ’least-privilege access’ en auditeerbare operaties wordt gevolgd.

← Data Engineering Architectuur en Ontwerp · Alle domeinen · BigQuery Analytics en Warehouse Engineering →

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

Blader door Google →