Google PDE: Streamverwerking met Dataflow en Apache Beam — 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

Streamverwerking op Google Cloud draait om het uniforme programmeermodel van Apache Beam, uitgevoerd door de Dataflow runner. Beam biedt een logische abstractie—pipelines van transforms over PCollections—die uw code loskoppelt van uitvoeringsdetails zoals parallellisme, autoscaling en fouttolerantie. Bij streaming hangt de correctheid af van tijdsemantiek (event time vs. processing time), windowing (fixed, sliding, session, global), watermarks, triggers en de verwerking van late data. Operationele uitmuntendheid op Dataflow vereist de juiste worker-grootte, autoscaling-beleid, streaming engine, shuffle-keuzes, een idempotent sink-ontwerp, dead-letter-verwerking en robuuste observability.

Apache Beam-model en tijdsemantiek

• Pipelines, transforms, PCollections, runners:

  • Een Beam-pipeline past een gerichte acyclische grafiek (DAG) van PTransforms toe op PCollections (bounded of unbounded).
  • Runners (Dataflow, Spark, Flink, Direct) voeren de pipeline uit; Dataflow biedt beheerde autoscaling, checkpointing en operationele zichtbaarheid.
  • Transforms omvatten element-wise (ParDo), groeperen en combineren (GroupByKey, Combine), joins (CoGroupByKey) en IO’s (PubSubIO, BigQueryIO, FileIO).

• Windows:

  • Fixed windows: niet-overlappende segmenten (bv. tumbling windows van 1 minuut) voor periodieke aggregaties.
  • Sliding windows: overlappende windows voor vloeiende, doorlopende statistieken (bv. windows van 5 minuten die elke minuut verschuiven).
  • Session windows: dynamische windows die sluiten na een periode van inactiviteit, ideaal voor gebruikerssessies of pieken in apparaatactiviteit.
  • Global window: de standaard weergave zonder windows van de gehele unbounded stream; vaak gecombineerd met triggers voor periodieke materialisatie.

• Event time vs. processing time:

  • Event time: wanneer het event bij de bron plaatsvond; maakt logisch consistente aggregaties mogelijk ondanks variabele transportlatenties.
  • Processing time: wanneer het event door de pipeline wordt waargenomen; nuttig voor operationele triggers, maar niet voor semantische correctheid.

• Watermarks:

  • Een watermark schat de volledigheid van de event-time (de inschatting van de runner dat alle events tot tijdstip T zijn gezien).
  • Watermarks kunnen onregelmatig voortschrijden of vastlopen door backpressure of vertragingen bij de bron; late data is alles wat arriveert met een timestamp < watermark.

• Triggers en vertraging (lateness):

  • Standaard: AfterWatermark-trigger die afgaat wanneer de watermark het einde van het window passeert; met allowed lateness = 0 worden late data verwijderd.
  • Vroege firings (op basis van processing-time of aantal) geven voorlopige resultaten met lage latentie.
  • Late firings maken correcties mogelijk wanneer late data arriveren; de accumulatiemodus bepaalt of panes resultaten accumuleren of eerdere output negeren.
  • Kies de toegestane vertraging (allowed lateness) op basis van bedrijfstolerantie en de afweging tussen opslag en rekenkracht; meer vertraging verhoogt de retentie van state en de kosten.

• Stateful processing, timers, sessionization, deduplicatie:

  • Stateful DoFns bewaren state per key (bv. laatst geziene event, lopende aggregaties) en stellen timers in om state uit te stoten of te wissen.
  • Sessionization wordt van nature uitgedrukt via SessionWindows; gebruik voor aangepaste logica keyed state en processing/event-time timers.
  • Deduplicatie: gebruik een stabiele ID per event en ofwel Distinct/Combine per window, ofwel state per key (bv. een Bloom-filter of een set met TTL). Maak een afweging tussen geheugengebruik en false positives versus strikte nauwkeurigheid.

Faalscenario’s en afwegingen:

• Het gebruik van processing-time windows voor bedrijfsstatistieken veroorzaakt afwijkingen (drift) bij pieken of retries; geef de voorkeur aan event-time windows.
• Te kleine windows met frequente vroege triggers veroorzaken een overmatige uitstoot van panes en write amplification naar de sink.
• Onbeperkte ‘allowed lateness’ kan de state enorm laten groeien; begrens altijd de state-TTL en stel timers in om slapende keys op te ruimen.

Dataflow beheren voor streaming workloads

• Worker-sizing en autoscaling:

  • Horizontale autoscaling voegt workers toe of verwijdert ze op basis van backlog, watermark-vertraging, CPU en doorvoer; stel een verstandige maxWorkers in om pieken op te vangen.
  • Kies machinetypes voor knelpunten: CPU-gebonden (meer vCPU’s), geheugengebonden (high-memory types), netwerkgebonden (grotere VM’s verminderen shuffle-overhead).
  • Vergroot de opstartschijf voor zware shuffles of op bestanden gebaseerde sinks. Monitor systeemvertraging en backlog in seconden.

• Streaming Engine en shuffle:

  • Streaming Engine externaliseert state en shuffle naar de service-backend, wat de elasticiteit verbetert, de geheugendruk op workers vermindert en snellere updates mogelijk maakt.
  • Gebruik voor batch-intensieve stadia of massale key-groepering Dataflow Shuffle om shuffle-I/O van workers te offloaden. Beide verminderen hot-worker-fouten en disk thrashing.

• Backpressure, hot keys en skew:

  • Dataflow beheert backpressure via dynamische werkherverdeling; pas desondanks de flow control van de bron aan (bijv. Pub/Sub openstaande berichten/bytes) waar van toepassing.
  • Hot keys (bijv. populaire id’s) creëren ‘stragglers’. Mitigeer dit met key sharding (key#N), gedeeltelijke pre-aggregatie gevolgd door re-keying, of op schetsen gebaseerde benaderingen.
  • Skew door uitschieters (enorme payloads) of ‘bursty’ publishers kan partities per publisher, batching of compressie vereisen.

• Pub/Sub-integratie:

  • Gebruik Pub/Sub-topics voor opname; schakel berichtattributen in voor metadata (bijv. deviceId, event-timestamp).
  • Neem data op met PubSubIO; extraheer event-timestamps uit attributen of uit de payload, of val anders terug op de publicatietijd.
  • Ordering keys zorgen voor per-key-volgorde; Dataflow vereist nog steeds idempotent downstream-gedrag vanwege at-least-once-levering.

• Patronen voor streamen naar BigQuery:

  • Geef de voorkeur aan BigQueryIO met de Storage Write API voor hoge doorvoer, lage latentie en ’exactly-once’-semantiek binnen een stream via stream-offsets en automatische retries.
  • Voor eenvoudige pipelines met een lage frequentie zijn streaming inserts acceptabel; stel insertId in om client-retries te dedupliceren.
  • Query’s over streaming buffers zijn ’eventually consistent’; voor tijd-kritische analyses, voer de query uit na een buffervertraging (bijv. wacht ~2x de waargenomen beschikbaarheidslatentie), of materialiseer via micro-batch-windows en de ‘committed mode’ van de Storage Write API.

• ‘Exactly-once’-effecten, idempotentie, replay en sinks:

  • Beam garandeert at-least-once-verwerking; ’exactly-once’ moet worden bereikt bij de sink door middel van idempotente schrijfacties, transacties of deduplicatiesleutels.
  • BigQuery: gebruik Storage Write API default streams of committed streams voor ’exactly-once’ binnen een stream; met streaming inserts, stel een stabiele insertId in.
  • Bestanden: schrijf tijdelijke bestanden met unieke namen, finaliseer bij voltooiing van het window en zorg voor atomaire renames; vermijd overschrijven om gedeeltelijke duplicaten te voorkomen.
  • Externe databases: gebruik upserts met een stabiele id als sleutel of implementeer deduplicatie-windows.
  • Ontwerp voor replay: onderhoud deterministische transformaties; zorg ervoor dat sinks dedupliceren bij een retry.

• Afhandeling van dead-letters, error-routing en observability:

  • Plaats riskante parsing/verrijking in een try/catch binnen een ParDo en stuur mislukkingen naar een dead-letter PCollection via een TupleTag; voeg payload, foutcode en context toe.
  • Routeer DLQ’s naar BigQuery of Cloud Storage voor analyse; overweeg een apart Pub/Sub-topic voor herverwerking.
  • Observability: gebruik Dataflow job-metrics (watermark-vertraging, systeemvertraging, doorvoer), custom counters, distributiemetrics en per-stap-logs in Cloud Logging. Maak alerts aan voor vertraging en foutpercentages in Cloud Monitoring. Gebruik Error Reporting om excepties te aggregeren.

• Patronen voor performance-tuning:

  • Lees efficiënt: geef voor BigQuery-bronnen de voorkeur aan de Storage Read API of op query’s gebaseerde leesacties die alleen de benodigde velden en filters selecteren.
  • Gebruik combiners om het shuffle-volume te verminderen vóór een GroupByKey.
  • Side inputs: cache kleine referentiedata in het geheugen; let op fanout en de updatefrequentie.
  • Serialisatie: gebruik compacte schema’s (Avro/Proto) en vermijd overmatige JSON-parsing op ‘hot paths’.

Implementatie, templates en upgradestrategieën

• Flex Templates:

  • Verpak pipelines in gecontaineriseerde, geparametriseerde templates voor reproduceerbare implementaties. Flex Templates ondersteunen aangepaste dependencies, GPU-images en omgevingsisolatie.
  • Externaliseer runtime parameters (bijv. input-subscription, output-tabel, dead-letter-sink, maxWorkers) om omgevingsspecifieke implementaties mogelijk te maken.

• Pipeline-updates en compatibiliteit:

  • Dataflow ondersteunt in-place updates voor veel streaming-pipelines als de namen van transforms, state-specificaties en output-types compatibel blijven. Gebruik stabiele PTransform-namen.
  • Voer voor incompatibele grafiek- of state-wijzigingen een gecontroleerde overschakeling uit: start de nieuwe job en ‘drain’ vervolgens de oude job om het werk dat onderweg is af te maken en te stoppen met het lezen van nieuwe elementen.

• Drainen en snapshots:

  • ‘Drainen’ voltooit de verwerking op een nette manier, schrijft de resterende output weg en beëindigt de job; coördineer met Pub/Sub-retentie of snapshots om hiaten te vermijden.
  • Om continuïteit te garanderen, kunt u een Pub/Sub-snapshot maken, de nieuwe pipeline starten vanaf het snapshot of een geschikte timestamp, de output verifiëren en vervolgens de oude job ‘drainen’.

• Configuratievoorbeelden:

  • Voorbeeld van windowing met vroege/late triggers en accumulatie:

undefined

• Voorbeeld van BigQueryIO met Storage Write API:

undefined

• Veelvoorkomende valkuilen:
  • Schrijven naar bestandsgebaseerde sinks in streaming zonder ‘windowed writes’ kan de afronding vertragen; schakel ‘windowed writes’ en triggers in.
  • Onbegrensde groei: het vergeten te begrenzen van state of toegestane vertraging kan geheugenlekken en schaalproblemen veroorzaken.
  • Ontbrekende timestamps: het niet toewijzen van event-timestamps zorgt ervoor dat de pipeline standaard de verwerkingstijd gebruikt en de correctheid verliest bij variabele vertragingen.

Praktisch probleemscenario

NovaTrack Inc. verwerkt wereldwijde IoT-telemetrie van 50.000 temperatuursensoren en moet aggregaties op minuutniveau leveren, ruwe data persisteren en een real-time dashboard voorzien. Af en toe worden misvormde berichten en ‘out-of-order’ levering verwacht. De oplossing moet automatisch schalen, foute records tonen voor inspectie en upgrades zonder downtime ondersteunen.

Aanpak:

1. Ingestie en tijdsemantiek

   • Maak een regionaal Pub/Sub-topic en per-regio publishers aan met de attributen deviceId en eventTs (RFC3339). Schakel waar mogelijk ‘ordering keys’ in op basis van deviceId.
   • Rationale: Pub/Sub biedt duurzame, elastische ingress met ‘at-least-once’ levering. Het toevoegen van event-timestamps aan de ’edge’ behoudt de ware event-tijd; ordening per apparaat vermindert herschikking binnen een apparaat zonder centrale knelpunten.

2. Dataflow streaming-pipeline met event-time windows

   • Lees vanuit een toegewijde subscription via PubSubIO, extraheer eventTs als de Beam-timestamp en val terug op publishTime indien deze ontbreekt.
   • Pas FixedWindows van 1 minuut toe met een vroege trigger na 30 seconden en ’late firings’ voor elk te laat element; stel de toegestane vertraging (‘allowed lateness’) in op 10 minuten en accumuleer ‘panes’.
   • Rationale: Event-time windows zorgen voor nauwkeurige aggregaties per minuut; vroege ‘firings’ voeden het dashboard met een actualiteit van minder dan een minuut; late ‘firings’ corrigeren aggregaties naarmate vertraagde data binnenkomt. De begrenzing op vertraging beperkt de omvang van de state en de kosten.

3. Validatie, verrijking en dead-letter-routering

   • Implementeer een ParDo die JSON parset, schema en bereiken valideert, en verrijkt met kleine statische referentiedata via een ‘side input’ die bij het starten van de job uit BigQuery wordt geladen.
   • Gebruik TupleTags om valide records naar de hoofdoutput te sturen en fouten naar een dead-letter PCollection die de payload, foutmelding, deviceId en parse-timestamp bevat; schrijf de DLQ naar een gepartitioneerde BigQuery-tabel.
   • Rationale: ‘Side inputs’ houden referentiedata in het geheugen voor lage latentie. Het vastleggen in een dead-letter-queue maakt inspectie en gerichte herverwerking van foute rijen mogelijk zonder de hoofdstroom te blokkeren.

4. Aggregatie en hot-key-mitigatie

   • Gebruik deviceId als sleutel en bereken per minuut avg/min/max met CombineFns. Voor top-N regionale statistieken, shard op region#N om ‘hot keys’ te vermijden en aggregeer daarna opnieuw.
   • Rationale: Combiners minimaliseren het shuffle-volume en de kosten; ‘key sharding’ voorkomt knelpunten bij één enkele sleutel tijdens de regionale ‘fan-in’.

5. Sinks en ’exactly-once’-effecten

   • Schrijf ruwe gevalideerde events en aggregaties per minuut naar BigQuery met BigQueryIO en de Storage Write API. Stel een stabiele ‘insert id’ in op basis van deviceId + eventTs voor idempotentie bij eventuele aangepaste ‘retries’.
   • Rationale: De Storage Write API biedt high-throughput, low-latency ingestie met ’exactly-once’-semantiek binnen een stream. Stabiele id’s zorgen voor downstream ontdubbeling als ‘replays’ optreden.

6. Strategie voor dashboardconsistentie

   • Het dashboard bevraagt gepartitioneerde aggregatietabellen met een terugkijkperiode van 2 minuten ten opzichte van de watermark of een vaste vertraging van 2x de waargenomen beschikbaarheidslatentie voor streaming data.
   • Rationale: De zichtbaarheid van streaming data in BigQuery is ’eventually consistent’; het iets uitstellen van leesoperaties voorkomt het missen van rijen die onderweg zijn, terwijl het near-real-time gedrag behouden blijft.

7. Operations: autoscaling en streaming engine

   • Schakel Streaming Engine in; stel maxWorkers in op basis van de verwachte piek (bijv. 3x het gemiddelde), selecteer een machinetype dat is gedimensioneerd voor CPU-gebonden parsing en encryptie, en vergroot de ‘boot disk’ om ruimte te bieden voor tijdelijke shuffle.
   • Monitor de watermark-vertraging, backlog in seconden, CPU en doorvoer per stap; stel alerts in voor aanhoudende vertraging en pieken in de DLQ-rate.
   • Rationale: Streaming Engine externaliseert state/shuffle voor elasticiteit en eenvoudigere upgrades; juiste dimensionering en monitoring voorkomen stille schendingen van de SLO.

8. Implementatie en upgrades met Flex Templates

   • Verpak de pipeline als een Flex Template met parameters: input-subscription, output-tabellen, DLQ-tabel, maxWorkers en regio. Start voor een incompatibele wijziging de nieuwe pipeline die gericht is op hetzelfde topic met een nieuwe subscription, verifieer de outputs en ‘drain’ vervolgens de oude job. Maak optioneel een Pub/Sub-snapshot aan en laat de nieuwe subscription vanaf het snapshot beginnen om te garanderen dat er geen hiaten zijn.
   • Rationale: Flex Templates maken herhaalbare, geparametriseerde implementaties mogelijk. Een geverifieerde blue/green-overschakeling met ‘drain’ zorgt voor nul dataverlies en minimale downtime.

9. Herverwerking en batch-backfills

   • Sla gecomprimeerde Avro-bestanden van ruwe events op in Cloud Storage via een ‘side output’; voer een batch Dataflow-pipeline uit om te ‘backfillen’ of opnieuw te verwerken naar BigQuery wanneer modellen of schema’s veranderen.
   • Rationale: Duurzame ruwe archieven ondersteunen reproduceerbaarheid en schema-evolutie zonder het ‘hot path’ te beïnvloeden.

Dit ontwerp levert correcte aggregaties met lage latentie en begrensde kosten, duidelijke foutisolatie, sterke observeerbaarheid en veilige upgradepaden, terwijl het omgaat met out-of-order en late data op wereldwijde schaal.

← BigQuery Analytics en Warehouse Engineering · Alle domeinen · Messaging →

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

Blader door Google →