Google PDE: Messaggistica, Ingestione di Eventi e Servizi in Tempo Reale — Guida allo studio

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

Fa parte della Google Professional Data Engineer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

I servizi di messaggistica, ingestione di eventi e in tempo reale su Google Cloud si basano su Cloud Pub/Sub ed Eventarc per un trasporto disaccoppiato e durevole; Dataflow per l’elaborazione stateful di flussi di dati; e sink come BigQuery, Cloud Storage e database operazionali. La progettazione per una consegna at-least-once (almeno una volta), un consumo idempotente e l’osservabilità garantisce sistemi resilienti che scalano elasticamente mantenendo la correttezza in caso di fallimenti, backpressure ed evoluzione dello schema.

Messaggistica di Base con Pub/Sub

Topic e sottoscrizioni
- I publisher inviano messaggi a un topic; i subscriber si collegano tramite sottoscrizioni (più subscriber possono consumare indipendentemente gli stessi messaggi).
- Tipi di sottoscrizione:
  - Pull: i client richiedono esplicitamente i messaggi (pull); utilizzare lo streaming pull per il massimo throughput e un minor numero di round trip.
  - Push: Pub/Sub consegna tramite HTTPS; il tuo endpoint deve restituire un codice 2xx per confermare la ricezione (ack).
  - Esportazione in BigQuery: una sottoscrizione BigQuery consegna i messaggi a una tabella BigQuery senza codice; è la soluzione migliore quando i payload corrispondono allo schema dichiarato e è richiesta un’ingestione a bassa latenza per l’analisi.
Ordering keys (chiavi di ordinamento)
- Abilita l’ordinamento dei messaggi sul topic e sulla sottoscrizione per ricevere consegne in ordine per ciascuna ordering key. Il throughput per chiave è serializzato: un messaggio in-flight per chiave può bloccare quelli successivi; utilizza molte chiavi (ad esempio, hash(device_id)) per scalare.
Fan-out e replay
- Crea sottoscrizioni separate per consumatori diversi per isolare i carichi di lavoro e la ritenzione.
- Utilizza seek o snapshot per rieseguire (replay) da un timestamp o da uno snapshot per il ripristino e i backfill.

Compromessi:

L’ordinamento riduce il parallelismo e il throughput per chiave; disabilitalo a meno che non sia strettamente necessario.
La modalità push semplifica il codice del client ma introduce problematiche di scalabilità dell’endpoint HTTP, sicurezza e backoff; la modalità pull offre maggiore controllo e stabilità a throughput elevati.

Semantiche di Consegna, Conferma, Ritenzione e Dead Lettering

Conferma (Acknowledgment) e deadline
- Consegna at-least-once: possono verificarsi duplicati.
- Ogni consegna ha una ack deadline (predefinita 10 secondi). Estendila (ModifyAckDeadline) durante l’elaborazione di task di lunga durata; la mancata conferma (ack) prima della scadenza è la causa più comune di consegne push duplicate.
- Un Nack o la scadenza della deadline rendono il messaggio idoneo per una nuova consegna.
Ritenzione
- I messaggi non confermati (unacknowledged) vengono conservati per la durata della ack deadline della sottoscrizione e ritentati; i messaggi confermati possono essere conservati fino alla durata di ritenzione dei messaggi del topic per il replay. Configura la ritenzione in modo da coprire la durata massima di un’interruzione del servizio più il tempo di ripristino.
Tentativi (Retries)
- Pull: la riconsegna avviene dopo la scadenza della ack deadline; controlla la concorrenza con i limiti di flow control.
- Push: exponential backoff; solo un codice HTTP 2xx è considerato un successo. I codici 3xx/4xx/5xx attivano i tentativi. Implementa gestori idempotenti per tollerare le ripetizioni.
Dead-letter topics (DLT)
- Configura un topic DL e un numero massimo di tentativi di consegna (max delivery attempts) per sottoscrizione per mettere in quarantena i messaggi poison (dannosi).
- Monitora il volume della DLQ (Dead-Letter Queue); crea flussi di lavoro di triage e ripubblica sul topic principale dopo la correzione.

Esempio: gcloud pubsub subscriptions create orders-sub
–topic=orders
–dead-letter-topic=orders-dlt
–max-delivery-attempts=10

Riepilogo delle semantiche di consegna:

Pub/Sub: at-least-once, ordinamento best-effort all’interno di una ordering key se abilitato.
Sink: le API di inserimento di BigQuery forniscono una mitigazione dei duplicati (tramite insertId o gli offset dello stream della Storage Write API), ma progetta comunque consumer e writer in modo che siano idempotenti.

Schemi, Compatibilità e Validazione

Schemi di Pub/Sub
- Supporto nativo per Avro e Protocol Buffers con schemi archiviati centralmente.
- Impostazioni dello schema a livello di topic: codifica (Avro o Protobuf) e applicazione (enforcement) (nessuna, solo convalida, o richiesta).
- Il producer pubblica payload codificati; Pub/Sub li convalida rispetto allo schema corrente quando l’applicazione è abilitata.
Evoluzione e compatibilità
- Utilizza modifiche retrocompatibili (aggiungi campi opzionali, aggiungi campi con valori predefiniti in Avro, non riutilizzare mai i tag in Protobuf, evita di rimuovere o rinominare i campi).
- Versiona gli schemi in modo esplicito. Per le breaking change, pubblica su due topic (v1 e v2), oppure aggiungi un campo di versione e instrada di conseguenza.
Contratti producer–consumer
- I consumer dovrebbero ignorare i campi sconosciuti e utilizzare valori predefiniti per quelli mancanti.
- Testa la compatibilità dello schema su tutti i consumer prima della promozione in produzione; convalida su sottoscrizioni di staging con la stessa applicazione dello schema dell’ambiente di produzione.

Breve esempio Avro (estratto): { “type”:“record”,“name”:“Order”, “fields”:[ {“name”:“order_id”,“type”:“string”}, {“name”:“ts”,“type”:{“type”:“long”,“logicalType”:“timestamp-micros”}}, {“name”:“amount”,“type”:[“null”,“double”],“default”:null} ] }

Integrazione event-driven, Eventarc e interoperabilità con Kafka

Eventarc e CloudEvents
- Eventarc instrada gli eventi provenienti dai servizi Google Cloud (e da sorgenti personalizzate tramite Pub/Sub) a Cloud Run, GKE o Workflows utilizzando la specifica CloudEvents. Attributi come type, source e subject consentono un filtraggio granulare e l’auditabilità.
- Utilizzare i filtri sugli attributi per minimizzare il fan-out e ridurre il carico a valle (downstream).
- La consegna è di tipo at-least-once (almeno una volta); rendere gli handler idempotenti e stateless dove possibile.
Esempio di trigger Eventarc: gcloud eventarc triggers create gcs-finalize-to-run
–destination-run-service=ingestor
–event-filters=“type=google.cloud.storage.object.v1.finalized”
–event-filters=“bucket=my-data-bucket”
–service-account=eventarc-sa@PROJECT_ID.iam.gserviceaccount.com
Interoperabilità con Kafka e migrazione gestita
- I template di Dataflow connettono Kafka <-> Pub/Sub per una migrazione a fasi. Eseguire il mirroring dei topic preservando le chiavi; effettuare prima il cut-over (passaggio) dei consumer, poi dei producer, oppure scrivere su entrambi i sistemi (dual-write) durante la transizione.
- Pub/Sub Lite offre streaming partizionato con capacità pre-allocata (capacity-provisioned), instradamento basato su chiave e un costo inferiore; è un servizio a livello regionale/zonale e adatto a carichi di lavoro simili a Kafka, dove la capacità prevedibile e l’ordinamento per partizione sono le preoccupazioni principali.
- Considerazioni sulla migrazione:
  - Ordinamento: mappare le chiavi di Kafka sulle chiavi di ordinamento (ordering keys) di Pub/Sub o sulle partizioni di Lite.
  - Offset: trasportare gli offset come attributi del messaggio per scopi diagnostici; i consumer non possono fare affidamento sugli offset di Kafka dopo la migrazione.
  - Consegna: accettare la semantica at-least-once; imporre l’idempotenza a valle (downstream).
  - Schemi: migrare le definizioni di Confluent Schema Registry verso gli schemi di Pub/Sub o standardizzare su Protobuf/Avro con regole di evoluzione compatibili.

Pattern di Ingestione in Streaming, Throughput, Scalabilità, Sicurezza e Operatività

Pattern di ingestione in tempo reale
- Pub/Sub -> Dataflow -> BigQuery: utilizzare il sink della BigQuery Storage Write API per un throughput elevato e idempotenza con offset di stream; instradare i fallimenti a una tabella dead-letter per ispezione.
- Pub/Sub -> Dataflow -> Cloud Storage: archiviare gli eventi grezzi per la rielaborazione; utilizzare scritture finestrate e compresse per bilanciare costi e latenza.
- Pub/Sub -> datastore operativi: scrivere su Bigtable per lookup a bassa latenza, su Spanner per transazioni a consistenza forte (strongly consistent), o su Cloud SQL/Firestore in base alle esigenze del carico di lavoro. Garantire upsert idempotenti basati su un ID evento univoco.
Garanzia at-least-once, prevenzione dei duplicati e idempotenza
- Includere un event_id e un event_time univoci in ogni messaggio; imporre UUID lato producer.
- De-duplicazione in streaming su BigQuery: impostare l’insertId o usare la Storage Write API con stream ordinati; proteggere comunque le query con una logica di de-duplicazione.
- Esempio di de-duplicazione a tempo di query:

undefined

Per gli endpoint di tipo push, restituire un codice 2xx solo dopo l’elaborazione andata a buon fine; altrimenti, aspettarsi una riconsegna.
Throughput dei messaggi, quote e scalabilità
- Publisher: raggruppare i messaggi in batch e riutilizzare le connessioni; parallelizzare su più client. Usare molte ordering key per scalare i carichi di lavoro ordinati.
- Subscriber: preferire lo streaming pull con controllo di flusso (max outstanding bytes/messages). Dimensionare le deadline di ack in base al tempo di elaborazione ed estenderle quando necessario.
- Monitorare e richiedere aumenti di quota per il throughput di publish e subscribe all’aumentare dei volumi; progettare con un margine (ad esempio, 2x il picco previsto) per assorbire i burst.
Consistenza e disponibilità
- Lo streaming di BigQuery è eventually consistent per la visibilità nelle query; per le query interattive che devono includere le righe inserite in streaming, attendere in base alla latenza osservata (ad esempio, 2 volte il ritardo di disponibilità P50) o progettare utilizzando aggregazioni allineate al watermark in Dataflow e interrogare i risultati materializzati.
Sicurezza
- IAM: concedere ruoli con il principio del privilegio minimo (pubsub.publisher ai producer sul topic; pubsub.subscriber ai consumer sulla sottoscrizione). Usare service account dedicati per ogni carico di lavoro.
- Autenticazione push: configurare le sottoscrizioni di tipo push per allegare token OIDC da un service account; imporre la validazione dell’audience sull’endpoint. Preferire endpoint privati di Cloud Run per autenticazione e TLS integrati.
- Crittografia: Pub/Sub crittografa i dati in transito e a riposo (at rest); usare CMEK sui topic per le chiavi gestite dal cliente. Applicare VPC Service Controls per ridurre il rischio di esfiltrazione dei dati. Usare la crittografia lato client per i campi sensibili del payload, se necessario.
Diagnosi operativa di lag, riconsegne e fallimenti dei subscriber
- Monitoraggio con Cloud Monitoring:
  - subscription/num_undelivered_messages e oldest_unacked_message_age per il backlog.
  - expired_ack_deadline_count per rilevare ack mancati che causano duplicati.
  - publish_request_count e pull_request_count per il throughput.
- Indagare sugli eventi mancanti nelle dashboard rieseguendo un dataset noto attraverso la pipeline e confrontando gli output di ogni fase per isolare la trasformazione o il sink difettoso.
- Per lo streaming con Dataflow:
  - Usare l’autoscaling con un valore maxWorkers appropriato per assorbire il carico da molte sorgenti.
  - Effettuare il drain delle pipeline in caso di aggiornamenti incompatibili per consentire il completamento del lavoro in corso e prevenire la perdita di dati.
- Per le notifiche di inserimento in BigQuery, instradare le voci di audit di Cloud Logging tramite un sink, filtrato su tabelle specifiche, a un topic Pub/Sub per la gestione degli alert.

Scenario Pratico

Contoso Freight necessita di una piattaforma di eventing globale e in tempo reale per ingerire 10.000 messaggi di telemetria IoT al minuto provenienti dai camion, arricchire gli eventi, alimentare analisi interattive e attivare workflow al rilascio di file da parte di partner esterni. Alcuni file CSV dei partner contengono righe malformate e il team di analisi deve poter ispezionare gli errori senza bloccare lo stream.

Creare il layer di base per la messaggistica e lo schema

Azione: Definire uno schema Avro per la telemetria e associarlo a un topic Pub/Sub telemetry con l’applicazione dello schema (schema enforcement) impostata su require. Abilitare l’ordinamento dei messaggi e pubblicare con ordering_key = hash(device_id).
Motivazione: L’applicazione dello schema a livello di topic rifiuta precocemente gli eventi malformati. L’ordinamento per dispositivo supporta l’elaborazione ordinata quando necessario, mentre l’hashing distribuisce le chiavi per preservare il throughput.

Effettuare il provisioning delle sottoscrizioni con isolamento e dead-lettering

Azione: Creare una sottoscrizione di tipo pull telemetry-stream-sub per Dataflow con un topic dead-letter telemetry-dlt e max_delivery_attempts=10. Aggiungere una sottoscrizione BigQuery telemetry-raw-bq per far atterrare gli eventi grezzi in una tabella partizionata per tempo per la lineage e il replay.
Motivazione: La DLQ (Dead-Letter Queue) isola i messaggi “poison” per l’analisi. Una sottoscrizione BigQuery separata fornisce un percorso di esportazione a bassa gestione operativa (low-ops) per la conservazione degli eventi grezzi, indipendente dalla pipeline di elaborazione.

Costruire una pipeline di streaming Dataflow per l’arricchimento e i sink

Azione: Ingerire dalla sottoscrizione telemetry-stream-sub usando lo streaming pull con controllo di flusso. Validare rispetto allo schema, arricchire con dati di riferimento e calcolare aggregati finestrati. Scrivere su BigQuery usando la Storage Write API con uno stream nominativo e insertId = event_id; scrivere backup grezzi su Cloud Storage ogni ora; reindirizzare i record errati/falliti a una tabella BigQuery dead-letter.
Motivazione: La Storage Write API offre scritture a throughput elevato e bassa latenza con idempotenza tramite insertId/offset dello stream. Una tabella dead-letter supporta l’ispezione senza bloccare lo stream e gli archivi su Cloud Storage abilitano il replay.

Gestire i duplicati e la consistenza finale (eventual consistency) nelle analisi

Azione: Per le query interattive che devono escludere i duplicati, pubblicare event_id e event_time in ogni record e usare una vista di de-duplicazione:

undefined

Introdurre un breve ritardo nella query basato sulla disponibilità osservata dello streaming di BigQuery (ad esempio, il doppio della latenza mediana).

Motivazione: La consegna at-least-once richiede scritture idempotenti e de-duplicazione a tempo di query. L’attesa riduce le mancate visualizzazioni di righe in transito, data la latenza di visibilità dello streaming.

Integrare il rilascio di file dei partner con Eventarc

Azione: Configurare Eventarc per instradare gli eventi object.finalized di Cloud Storage per il bucket partner-drops a un servizio Cloud Run che avvia un job Dataflow di tipo batch per caricare i CSV in BigQuery, inviando gli errori di parsing a una tabella dead-letter.
Motivazione: Eventarc fornisce un’orchestrazione guidata dagli eventi con filtraggio CloudEvents su bucket e prefisso dell’oggetto. Un job Dataflow di tipo batch separa le righe malformate per l’analisi, caricando tempestivamente i dati corretti.

Mettere in sicurezza la piattaforma

Azione: Usare service account distinti: i producer ottengono il ruolo pubsub.publisher sul topic telemetry; il SA del worker Dataflow ottiene pubsub.subscriber sulla sottoscrizione telemetry-stream-sub e l’accesso in scrittura ai dataset BigQuery di destinazione e a Cloud Storage; il trigger di Eventarc usa un SA dedicato con il ruolo di invoker su Cloud Run. Abilitare CMEK sul topic telemetry e sui dataset BigQuery. Configurare gli endpoint di tipo push, se presenti, con OIDC e controlli sull’audience.
Motivazione: L’uso di IAM secondo il principio del privilegio minimo e di CMEK soddisfa i requisiti di sicurezza e conformità; la consegna autenticata previene lo spoofing.

Gestire e scalare in modo affidabile

Azione: Impostare l’autoscaling di Dataflow con un valore maxWorkers generoso per assorbire i picchi. Monitorare subscription/oldest_unacked_message_age e expired_ack_deadline_count; impostare alert quando le soglie vengono superate. Per modifiche alla pipeline che rompono la compatibilità, effettuare il deploy con l’opzione drain per evitare la perdita di messaggi. Se il lag aumenta, incrementare il parallelismo dei subscriber ed estendere le deadline di ack in modo proporzionale al tempo di elaborazione.
Motivazione: Il monitoraggio proattivo rileva precocemente lag e riconsegne. L’autoscaling e le deadline di ack ottimizzate prevengono le “tempeste” di duplicati. Il drain preserva i messaggi in transito durante gli aggiornamenti.

Questo design fornisce un’ingestione in tempo reale resiliente, sicura e osservabile, con integrazione batch guidata dagli eventi, supporta la tolleranza ai duplicati e l’evoluzione dello schema, e offre analisi veloci isolando al contempo i dati errati per

← Elaborazione di Flussi con Dataflow e Apache Beam · Tutti i domini · Spark →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →