Google PDE: BigQuery Analytics en Warehouse Engineering — 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

BigQuery is een serverless, kolommengebaseerd, MPP analytics warehouse dat opslag en compute scheidt, en zo bijna oneindige schaalbaarheid, ANSI SQL en geïntegreerde governance biedt. Warehouse engineering op BigQuery balanceert schemaontwerp (partitionering, clustering, denormalisatie vs. normalisatie, geneste records), ingestiepatronen (batch-ladingen, streaming, Storage Write API) en workloadbeheer (on-demand vs. op capaciteit gebaseerde edities en reserveringen). Robuuste beveiliging (authorized views, row/column policies, policy tags) bestaat naast kostenbeheersing en performance-tooling om het aantal gescande bytes te minimaliseren en de latentie te verlagen. Dit gedeelte behandelt de kernaspecten van ontwerp, operaties en faalscenario’s waarop u in productie moet anticiperen.

Opslag en Semantiek: Datasets, Tabellen, Views en Lake-toegang

• Datasets, tabellen, views:

  • Datasets bepalen de scope van IAM en governance. Gebruik per-tenant datasets voor isolatie en duidelijke facturering.
  • Standaardtabellen slaan data native op; partities en clustering bepalen de lay-out en pruning.
  • Views kapselen SQL-logica in zonder data op te slaan. Met authorized views kan een eigenaar van een view beperkte subsets blootstellen aan andere projecten of tenants, terwijl de onderliggende tabellen verborgen blijven.
  • Materialized views (MV’s) slaan vooraf berekende resultaten op en vernieuwen automatisch. Query rewrite gebruikt MV’s transparant wanneer ze compatibel zijn; incompatibele predicaten of functies omzeilen ze.
  • Externe tabellen verwijzen naar data in Cloud Storage, Google Drive of Google Sheets. Ze vermijden ingestie, maar ruilen doorvoersnelheid en functieondersteuning in voor gemak. Voor herhaalde analyses, laad de data in native tabellen.

• Partitionering, clustering en geneste records:

  • Partitioneer op ingestietijd, DATE/TIMESTAMP/DATETIME of een integer-bereik om scans te prunen. Gebruik WHERE-filters op de partitiekolom of decorators zoals _PARTITIONDATE om pruning mogelijk te maken.
  • Cluster op kolommen met een hoge kardinaliteit die vaak worden gefilterd of gejoint (maximaal 8). BigQuery herclustert automatisch; herhaalde kleine DML-operaties kunnen de kwaliteit van de clustering tijdelijk verminderen.
  • Geneste en herhaalde records (STRUCT, ARRAY) modelleren een-op-veel-relaties zonder de overhead van een join. Gebruik UNNEST oordeelkundig; herhaaldelijk UNNEST toepassen op grote arrays kan leiden tot een dramatische ‘fan-out’.

• Denormalisatie vs. normalisatie:

  • Denormaliseer dimensie-attributen in feitentabellen om joins te minimaliseren en te profiteren van kolommengebaseerde scans; dit is ideaal voor lees-intensieve analyses.
  • Normaliseer wanneer ‘write amplification’, ‘update hotspots’ of self-joins contentie of complexiteit veroorzaken (bijvoorbeeld, het scheiden van hoofdtabellen voor patiënten en bezoeken om ‘self-join blowups’ te voorkomen). Overweeg een hybride model: genormaliseerde kernentiteiten met brede, gedenormaliseerde feitentabellen of geneste ‘children’.

• Materialized views: ontwerpoverwegingen

  • Meest geschikt voor stabiele, incrementele aggregaties over gepartitioneerde basistabellen. Het vernieuwen van MV’s is asynchroon; downstream gebruikers moeten een zekere ‘staleness’ kunnen tolereren of de basistabellen als fallback bevragen.
  • Filter en groepeer op de partitiekolom voor incrementele vernieuwing. Niet-deterministische functies, niet-ondersteunde joins of UDF’s kunnen MV’s diskwalificeren voor rewrite.

• Federated queries, BigLake en pushdown:

  • Federated queries lezen externe systemen (bijvoorbeeld Cloud SQL) rechtstreeks met SQL. Ze zijn handig voor lichte joins of eenmalige verkenningen, maar hebben een hogere latentie en strengere quota’s; extraheer data naar BigQuery voor zware analyses.
  • BigLake-tabellen verenigen de governance van lake en warehouse met controles op kolom- en rijniveau over data in Cloud Storage of open tabelformaten (zoals Parquet). Predicate en projection pushdown verminderen het aantal gedownloade bytes; voor grote scans geniet ingestie in native tabellen nog steeds de voorkeur voor maximale prestaties.

• Wildcard-tabellen en legacy shards:

  • Wildcard-queries zijn een legacy patroon voor op datum gesharde tabellen. Geef de voorkeur aan native partitionering, maar gebruik indien nodig: SELECT … FROM bigquery-public-data.noaa_gsod.gsod* WHERE _TABLE_SUFFIX >= ‘2010’.

Query-optimalisatie en Workloadbeheer

• Partitie-pruning en clustering:

  • Filter altijd op de partitiekolom om het scannen van koude partities te vermijden. Gebruik BETWEEN met smalle vensters.
  • Orden clusteringsleutels op selectiviteit; eerdere sleutels moeten overeenkomen met veelgebruikte filters en joins. Vermijd clustering op kolommen met een zeer lage kardinaliteit.

• Optimalisatie van queryplannen:

  • Gebruik EXPLAIN en uitvoeringsdetails om skewed joins, grote shuffles of niet-geprunede scans te vinden.
  • Reduceer kolommen vroegtijdig met SELECT-lijsten en subquery’s; BigQuery is kolomgeoriënteerd en verwijdert ongebruikte kolommen efficiënt.
  • Geef de voorkeur aan geschatte aggregaties (bijvoorbeeld APPROX_QUANTILES) voor afwegingen tussen snelheid en kosten bij grote datasets.

  • Pas deduplicatie toe met windowfuncties wanneer ingestiebronnen gebeurtenissen kunnen herhalen:

undefined

• Joins en denormalisatie:

  • Plaats join-sleutels samen als clusteringsleutels om shuffle te verminderen. Bloom-filters of pre-aggregatie kunnen helpen bij extreme skew.
  • Denormaliseer kleine, langzaam veranderende dimensies in feitentabellen om hot joins te vermijden. Voor zeer brede dimensies met frequente updates, normaliseer en vertrouw op clusteringsleutels en gematerialiseerde joins.

• Workloadbeheer, slots, edities en autoscaling:

  • On-demand: BigQuery schaalt compute elastisch per query; je betaalt per gescande TB. Beheers de kosten met ‘maximum bytes billed’ en partitie-pruning.
  • Op capaciteit gebaseerd met BigQuery-edities (Standard, Enterprise, Enterprise Plus) maakt gebruik van slotreserveringen. Koop baseline-commitments, maak reserveringen aan en wijs projecten of mappen toe. Autoscaling kan slots toevoegen tijdens pieken en vrijgeven wanneer de vraag daalt; gebruik aparte reserveringen voor ETL versus BI om interferentie te voorkomen.
  • Jobprioriteit: interactief (standaard) voor lage latency; batch voor backfills en geplande query’s. Batch-jobs worden in de wachtrij geplaatst totdat er ongebruikte capaciteit beschikbaar is in de reservering of in de service, en worden dan tegen normale kosten uitgevoerd.

• Concurrency en quota:

  • Gebruik reserveringen en toewijzingen om kritieke workloads te isoleren. Voor gemengde tenants, plaats ze in afzonderlijke reserveringen of projecten met op maat gemaakte concurrentielimieten.
  • Label jobs voor attributie; monitor INFORMATION_SCHEMA.JOBS en Cloud Monitoring-metrics voor slotgebruik en wachtrijvertragingen.

• BI-caching en actualiteit:

  • De cache voor queryresultaten verbetert de latency/kosten voor identieke query’s; schakel deze uit in clients die een actualiteit van minder dan een uur vereisen. Sommige BI-tools cachen data onafhankelijk—schakel rapportcaching uit om de meest recente resultaten weer te geven.

Ingestie, Federatie en Herstel

• Load-jobs:

  • Batch-loads vanuit Cloud Storage (Avro/Parquet heeft de voorkeur) zijn betrouwbaar en kosteneffectief. Stel schema en encoding expliciet in; niet-overeenkomende CSV-encodings zijn een veelvoorkomende oorzaak van byte-voor-byte discrepanties.
  • Gebruik partitiedecorators of laad naar gepartitioneerde tabellen om merges te vermijden. Paralleliseer grote loads per partitie.

• Streaming-ingestie en de Storage Write API:

  • Legacy streaming-inserts zijn eenvoudig maar hebben strengere quota en kunnen enkele seconden ’eventual consistency’ vertonen; time travel op zeer recente data kan achterlopen.
  • De Storage Write API is de aanbevolen methode voor high-throughput, low-latency writes met betere deduplicatiecontroles. Gebruik idempotentie (stream offsets) om duplicaten te voorkomen.
  • Het applicatieontwerp moet ‘in-flight events’ tolereren: stel interactieve query’s uit met de verwachte beschikbaarheid (bijvoorbeeld 2× de waargenomen latency) of gebruik watermarks op ingestietijd-partities.

• Dataflow en dead-letter-ontwerp:

  • Voor door partners aangeleverde CSV’s met misvormde rijen, gebruik Dataflow om te parsen en te valideren, schrijf geldige records naar BigQuery via de Storage Write API, en routeer fouten naar een dead-letter-tabel voor inspectie.
  • Wanneer je op grote schaal uit BigQuery leest, geef dan de voorkeur aan query-gebaseerde reads (fromQuery) om alleen de benodigde velden te selecteren en shuffle te verminderen.

• Geplande query’s en transformaties:

  • Gebruik geplande query’s voor ELT-transformaties, incrementele rollups en tabelonderhoud. Geef de voorkeur aan schrijven naar gepartitioneerde, geclusterde doeltabellen. Geplande query’s hebben standaard batch-prioriteit en integreren met reserveringen.

• Notificaties en observeerbaarheid:

  • Exporteer BigQuery-auditlogs met een log sink naar Pub/Sub om alerts te triggeren voor specifieke tabel-insert-jobs:
    • Filtervoorbeeld:

undefined

• Gebruik Cloud Logging-auditlogs en INFORMATION_SCHEMA-views om gebruikspatronen te ontdekken en governance af te dwingen.

• Time travel, snapshots en clones:

  • Met time travel kun je een tabel op een vorig tijdstip bevragen (standaard 7 dagen). Gebruik FOR SYSTEM_TIME AS OF om eerdere staten te lezen.
  • Tabel-snapshots leggen een point-in-time weergave vast met copy-on-write; gebruik ze voor consistente backfills of herstel. Tabel-clones bieden vrijwel onmiddellijke metadatakopieën voor ontwikkeling of what-if-analyses met minimale opslag totdat ze divergeren.
  • Herstelopties:
    • Kleine fouten: query met time travel en herstel met INSERT…SELECT.
    • Groot herstel: maak aan vanuit een snapshot of clone, en wissel dan om.
  • Stel tabel- en partitie-expiratie in om retentie af te dwingen; verifieer dat de retentie overeenkomt met de time-travel-behoeften.

• Gefedereerde bronnen:

  • Gebruik Cloud SQL-federatie voor lichte joins; voor langdurige analyses of grote scans, plan een extract-load naar native tabellen.
  • BigLake-tabellen over Parquet/ORC in Cloud Storage kunnen policy tags afdwingen en filters en kolomprojecties ‘pushen’; verwacht nog steeds een hogere latency dan bij native storage.

Beveiliging, Governance en Kostenbeheersing

• IAM en ’least privilege’:

  • Wijs rollen op datasetniveau (BigQuery Data Viewer, Data Editor) minimaal toe, alleen aan goedgekeurde gebruikers; beperk API-toegang tot service accounts en speciaal samengestelde groepen.
  • Scheid clients en omgevingen per dataset en project voor isolatie. Wijs reserveringen toe per project of folder om ’noisy neighbors’ (luidruchtige buren) te voorkomen.

• Geautoriseerde views en beveiliging op rijniveau:

  • Geautoriseerde views maken alleen geselecteerde kolommen/rijen beschikbaar voor externe projecten, terwijl het project van de view toegang tot de tabel behoudt. Houd de view en de bron in dezelfde dataset of gebruik autorisatie op datasetniveau voor het doelproject.
  • Beveiliging op rijniveau met ‘row access policies’ filtert rijen per gebruiker of groep op het moment van de query; combineer dit met geautoriseerde views voor gelaagde controle.

• Beveiliging op kolomniveau en policy tags:

  • Gebruik Data Catalog policy tags om gevoelige kolommen te beschermen en data masking mogelijk te maken. Wijs toegang toe aan tags (niet aan tabellen) om aan te sluiten bij de dat classificatie. Voor toegang door partners, maskeer of weiger PII-kolommen via tags.

• BigQuery ML en in-warehouse analytics:

  • Train en serveer modellen direct in BigQuery (bijvoorbeeld lineaire/logistische regressie, XGBoost, K-means, tijdreeksen) met CREATE MODEL en ML.PREDICT. Sla features op in gepartitioneerde tabellen en gebruik geplande hertraining.
  • Met remote models kun je Vertex AI of externe endpoints aanroepen vanuit SQL voor scoring binnen een ‘federated governance’-model. Cache de outputs naar tabellen om de latentie voor herhaalde query’s te amortiseren.

• Kostenbeheersing en performance troubleshooting:

  • Verminder het aantal gescande bytes:
    • Partitioneer en cluster; filter altijd op deze sleutels.
    • SELECT alleen de benodigde kolommen; vermijd SELECT *.
    • Gebruik ‘materialized views’ en ‘result caching’ waar van toepassing.
    • Stel maximum_bytes_billed in om de kosten te maximeren.
  • Troubleshoot de performance:
    • Inspecteer de uitvoeringsdetails van een job op ‘skew’, niet-geprunede partities of ‘shuffle hotspots’. Pas de sleutels van joins aan of pre-aggregeer om ‘shuffle’ te verminderen.
    • Valideer ‘MV rewrites’; zorg voor compatibele predicaten en deterministische functies.
    • Voor dashboards waarin recente streaming data ontbreekt, houd rekening met de consistentievertraging of schakel client-side caching uit.
  • Zichtbaarheid van governance: voer audits uit met Cloud Logging, INFORMATION_SCHEMA en fijnmazige job-labels om kosten door te belasten en uitschieters te identificeren.

Praktijkscenario

NovaCare Health beheert een regionaal telegeneeskundeplatform. Een ontwerp met een enkele tabel, patient_and_visit, was voldoende voor een pilot, maar bij 100x schaal krijgen rapporten een time-out, verschijnen er duplicaten door streaming upserts en vereisen partners strikte data-isolatie.

Aanpak:

1. Herontwerp het schema en de lay-out

   • Creëer genormaliseerde kerntabellen: patients(patient_id, demographics, updated_at) en visits(visit_id, patient_id, visit_ts, metrics, updated_at).
   • Maak van visits een gepartitioneerde tabel op DATE(visit_ts), geclusterd op patient_id en visit_id. Houd kleine referentiedimensies gedenormaliseerd in de visits-tabel voor snellere dashboards.
   • Reden: Normalisatie voorkomt dure self-joins en zware rij-updates op één enkele ‘hot’ tabel. Partitionering snoeit in historische scans; clustering plaatst joins en filters op patient_id bij elkaar, wat ‘shuffle’ vermindert.

2. Ingestie met de Storage Write API en afdwingen van idempotentie

   • Gebruik een Dataflow-pipeline om inkomende events te parsen, te valideren en naar benoemde streams in de Storage Write API te schrijven met idempotente offsets.
   • Routeer foutief geformatteerde events naar een ‘dead-letter’ BigQuery-tabel voor triage.
   • Reden: De Storage Write API biedt een hogere doorvoersnelheid, lagere latentie en betere garanties voor ontdubbeling dan de verouderde streaming-methode. Het gebruik van een dead-letter-tabel behoudt het inzicht in datakwaliteitsproblemen bij partners.

3. Ontwerp voor actualiteit en ontdubbeling in query’s

   • Voeg voor interactieve analyses een korte ‘watermark’ toe (bijvoorbeeld 2x de geobserveerde beschikbaarheid) voordat de laatste partitie wordt bevraagd; of filter op _PARTITIONDATE waar partition_date <= CURRENT_DATE() om rijen die nog binnenkomen uit te sluiten.
   • Gebruik ROW_NUMBER() OVER (PARTITION BY visit_id ORDER BY event_ts DESC) = 1 in views die bestand moeten zijn tegen retries van upstream systemen.
   • Reden: Streaming is ’eventually consistent’ gedurende een kort interval. Watermarking en ontdubbeling op basis van window-functies beschermen dashboards tegen tijdelijke hiaten en duplicaten.

4. Versnel veelvoorkomende aggregaties met materialized views

   • Creëer op partities uitgelijnde MV’s over de visits-tabel voor dagelijkse KPI’s, gegroepeerd op DATE(visit_ts) en patiëntcohorten. Zorg ervoor dat de predicaten compatibel zijn met ‘rewrite’.
   • Reden: MV’s verminderen de latentie en het aantal gescande bytes voor terugkerende rapporten; BigQuery herschrijft query’s transparant om de MV te gebruiken.

5. Dwing tenant-isolatie en fijnmazige beveiliging af

   • Plaats elke partner in een eigen, dedicated dataset. Wijs ’least-privilege’ rollen op datasetniveau toe aan partnergroepen.
   • Publiceer geautoriseerde views voor gedeelde, partner-overstijgende benchmarks zonder de ruwe tabellen bloot te geven.
   • Pas policy tags toe op PII-kolommen en voeg ‘row access policies’ toe aan de visits-tabel om de toegang te beperken op basis van partner_id voor interne multi-tenant analyses.
   • Reden: Segmentatie per tenant op datasetniveau, gecombineerd met geautoriseerde views en policy tags, dwingt ’least privilege’ af en maakt tegelijkertijd beheerde datadeling mogelijk.

6. Beheer workloads met edities, reserveringen en autoscaling

   • Koop capaciteit in via BigQuery-edities en creëer twee reserveringen: etl (Dataflow sinks, geplande transformaties) en bi (ad hoc/rapportage). Wijs projecten dienovereenkomstig toe en schakel autoscaling in om pieken op te vangen.
   • Plan ELT-query’s als batch met duidelijke SLA’s; stel maximum_bytes_billed in voor interactieve projecten.
   • Reden: Aparte reserveringen voorkomen dat ETL de BI-workloads verdringt. Autoscaling vangt piekbelastingen op zonder overprovisioning.

7. Beheer de kosten en observeer het gebruik

   • Vereis filters op visit_ts; wijs SELECT * af in gedeelde views. Gebruik INFORMATION_SCHEMA.JOBS om niet-geprunede scans en ‘skewed joins’ te detecteren.
   • Exporteer BigQuery-auditlogs naar Pub/Sub met een ’log sink’ die filtert op ‘insert jobs’ op de visits-tabel om monitoring-alerts te triggeren bij onverwachte pieken.
   • Reden: Kostenbeheersing door ‘byte-pruning’ en kolomprojectie; auditlogs maken toegangspatronen en afwijkingen bijna in real-time zichtbaar.

8. Plan herstel en backfills

   • Schakel standaard beleidsregels voor tabelverloop in die aansluiten bij compliance-eisen en de behoefte aan ’time-travel’. Maak voor grote bewerkingen een snapshot, voer de wijzigingen door en rol indien nodig snel terug. Gebruik tabelklonen voor dev/test what-if-analyses zonder opslag te dupliceren.
   • Reden: Snapshots en klonen bieden snelle, ruimte-efficiënte vangnetten; ’time-travel’ dekt kleine, corrigerende herstelacties.

9. Integreer in-warehouse ML

   • Sla ’engineered features’ op in gepartitioneerde tabellen en train BigQuery ML-classificatiemodellen voor het risico op heropname. Voor externe modellen die op Vertex AI worden gehost, creëer je remote models en cache je de voorspellingen in een geclusterde tabel voor joins met lage latentie.
   • Reden: Door ML dicht bij de data te houden, wordt dataverplaatsing en de complexiteit van governance verminderd; het cachen van remote inference amortiseert de latentie en kosten.

Met dit ontwerp bereikt NovaCare voorspelbare prestaties onder 100x belasting, sterke tenant-isolatie en beheerste kosten, terwijl low-latency analytics en reproduceerbaar herstel behouden blijven.

← Dataopslag · Alle domeinen · Streamverwerking met Dataflow en Apache Beam →

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

Blader door Google →