Leggere da Pub/Sub in Dataflow

Questa pagina descrive le best practice per la lettura da Pub/Sub in Dataflow.

Apache Beam fornisce un'implementazione di riferimento del connettore I/O Pub/Sub da utilizzare con runner non Dataflow. Tuttavia, il runner Dataflow utilizza una propria implementazione personalizzata del connettore. Questa implementazione sfrutta le API e i servizi interni di Google Cloudper offrire filigrane a bassa latenza, elevata accuratezza della filigrana e deduplicazione efficiente per l'elaborazione dei messaggi "exactly-once". Il connettore è disponibile per Java, Python e Go.

Elaborazione "exactly-once"

Pub/Sub disaccoppia i publisher di eventi dai consumer di eventi. L'applicazione pubblica messaggi in un argomento e Pub/Sub li recapita in modo asincrono ai sottoscrittori.

Pub/Sub assegna un ID messaggio univoco a ogni messaggio pubblicato correttamente in un argomento. Per impostazione predefinita, Pub/Sub esegue la distribuzione dei messaggi at-least-once. Per ottenere la semantica "at-least-once", se Pub/Sub non riceve la conferma di ricezione dal sottoscrittore entro la scadenza della conferma, riprova a inviare il messaggio. I tentativi possono verificarsi anche prima della scadenza della conferma di ricezione o dopo che un messaggio è stato confermato.

Dataflow riconosce i messaggi dopo che sono stati elaborati correttamente dalla prima fase unita e gli effetti collaterali di questa elaborazione sono stati scritti nello spazio di archiviazione permanente. Per ridurre il numero di messaggi duplicati, Dataflow estende continuamente il termine di riconoscimento mentre un batch di messaggi viene elaborato in questa fase.

Poiché Pub/Sub potrebbe riconsegnare un messaggio, è possibile che arrivino messaggi duplicati nella pipeline. Se la pipeline Dataflow utilizza la modalità di streaming "exactly-once", Dataflow deduplica questi messaggi per ottenere la semantica "exactly-once".

Se la tua pipeline può tollerare alcuni record duplicati, valuta la possibilità di utilizzare la modalità di streaming almeno una volta. Questa modalità può ridurre notevolmente la latenza e il costo totale della pipeline. Il compromesso è che i messaggi duplicati potrebbero essere elaborati due volte. Per saperne di più, consulta la sezione Scegliere la modalità di streaming da utilizzare.

Deduplica per attributo del messaggio

Per impostazione predefinita, Dataflow deduplica in base all'ID messaggio. Tuttavia, un'applicazione potrebbe inviare lo stesso record due volte come due messaggi Pub/Sub distinti. Ad esempio, i dati di origine originali potrebbero contenere record duplicati oppure l'applicazione potrebbe pubblicare erroneamente lo stesso messaggio due volte. Ciò può accadere a causa di nuovi tentativi, se la conferma è stata interrotta a causa di problemi di rete o altre interruzioni. In queste situazioni, i messaggi duplicati hanno ID messaggio diversi.

A seconda dello scenario, i dati potrebbero contenere un campo univoco che può essere utilizzato per la deduplicazione. Ad esempio, i record potrebbero contenere un ID transazione univoco. Puoi configurare il connettore Pub/Sub I/O per deduplicare i messaggi in base al valore di un attributo del messaggio, anziché utilizzare l'ID messaggio Pub/Sub. Se il publisher imposta questo attributo in modo coerente durante i tentativi, Dataflow può rilevare i duplicati. I messaggi devono essere pubblicati su Pub/Sub entro 10 minuti l'uno dall'altro per la deduplicazione.

Per ulteriori informazioni sull'utilizzo degli attributi ID, consulta i seguenti argomenti di riferimento dell'SDK:

Abbonamenti

Quando configuri la pipeline, specifichi un argomento Pub/Sub o una sottoscrizione Pub/Sub da cui leggere. Se specifichi un abbonamento, non utilizzare lo stesso abbonamento Pub/Sub per più pipeline. Se due pipeline leggono da una singola sottoscrizione, ogni pipeline riceve parte dei dati in modo non deterministico, il che potrebbe causare messaggi duplicati, ritardo della filigrana e scalabilità automatica inefficiente. Crea invece un abbonamento separato per ogni pipeline.

Se specifichi un argomento, il connettore crea un nuovo abbonamento temporaneo. Questo abbonamento è univoco per pipeline.

Timestamp e filigrane

Tutti i messaggi Pub/Sub hanno un timestamp, che rappresenta l'ora in cui Pub/Sub riceve il messaggio. I tuoi dati potrebbero anche avere un timestamp evento, ovvero l'ora in cui il record è stato generato dall'origine.

Puoi configurare il connettore per leggere il timestamp dell'evento da un attributo del messaggio Pub/Sub. In questo caso, il connettore utilizza il timestamp dell'evento per la filigrana. In caso contrario, per impostazione predefinita utilizza il timestamp del messaggio Pub/Sub.

Per ulteriori informazioni sull'utilizzo dei timestamp degli eventi, consulta i seguenti argomenti di riferimento dell'SDK:

Il connettore Pub/Sub ha accesso all'API privata di Pub/Sub che fornisce l'età del messaggio senza ACK meno recente in una sottoscrizione. Questa API offre una latenza inferiore rispetto a quella disponibile in Cloud Monitoring. Consente a Dataflow di far avanzare i watermark della pipeline ed emettere risultati di calcolo in finestra con latenze ridotte.

Se configuri il connettore per utilizzare i timestamp degli eventi, Dataflow crea una seconda sottoscrizione Pub/Sub, chiamata sottoscrizione di monitoraggio. Dataflow utilizza l'abbonamento di monitoraggio per esaminare gli orari degli eventi dei messaggi ancora presenti nel backlog. Questo approccio consente a Dataflow di stimare con precisione il backlog dell'ora dell'evento. Il service account worker deve disporre almeno delle seguenti autorizzazioni sul progetto che contiene l'abbonamento di monitoraggio:

  • pubsub.subscriptions.create
  • pubsub.subscription.consume
  • pubsub.subscription.delete

Inoltre, richiede l'autorizzazione pubsub.topics.attachSubscription per l'argomento Pub/Sub. Ti consigliamo di creare un ruolo Identity and Access Management personalizzato che contenga solo queste autorizzazioni.

Per saperne di più sui watermark, consulta la pagina di Stack Overflow che spiega come Dataflow calcola i watermark Pub/Sub.

Se una pipeline ha più origini Pub/Sub e una di queste ha un volume molto basso o è inattiva, ritarda l'avanzamento dell'intera filigrana, aumentando la latenza complessiva della pipeline. Se nella pipeline sono presenti timer o aggregazioni di finestre basati sul watermark, anche questi vengono ritardati.

Pub/Sub Seek

Pub/Sub Seek consente agli utenti di riprodurre i messaggi già confermati. Puoi utilizzare Pub/Sub Seek con Dataflow per rielaborare i messaggi in una pipeline.

Tuttavia, non è consigliabile utilizzare Pub/Sub Seek in una pipeline in esecuzione. La ricerca all'indietro in una pipeline in esecuzione può comportare la duplicazione o l'eliminazione dei messaggi. Inoltre, invalida la logica della filigrana di Dataflow ed è in conflitto con lo stato di una pipeline che incorpora i dati elaborati.

Per rielaborare i messaggi utilizzando Pub/Sub Seek, è consigliato il seguente flusso di lavoro:

  1. Crea uno snapshot dell'abbonamento.
  2. Crea una nuova sottoscrizione per l'argomento Pub/Sub. Il nuovo abbonamento eredita lo snapshot.
  3. Esegui lo svuotamento o annulla il job Dataflow corrente.
  4. Invia di nuovo la pipeline utilizzando il nuovo abbonamento.

Per ulteriori informazioni, consulta la pagina Rielaborazione dei messaggi con Pub/Sub Snapshot e Seek.

Funzionalità di Pub/Sub non supportate

Le seguenti funzionalità di Pub/Sub non sono supportate nell'implementazione del connettore I/O Pub/Sub di Dataflow Runner.

Backoff esponenziale

Quando crei una sottoscrizione Pub/Sub, puoi configurarla per utilizzare un criterio di ripetizione con backoff esponenziale. Tuttavia, il backoff esponenziale non funziona con Dataflow. Crea invece la sottoscrizione con il criterio di nuovo tentativo immediato.

Il backoff esponenziale viene attivato da un riconoscimento negativo o quando scade il termine per il riconoscimento. Tuttavia, Dataflow non invia riconoscimenti negativi quando il codice della pipeline non va a buon fine. Al contrario, riprova a elaborare il messaggio a tempo indeterminato, estendendo continuamente la scadenza di conferma per il messaggio.

Argomenti messaggi non recapitabili

Non utilizzare argomenti dead letter di Pub/Sub con Dataflow per i seguenti motivi:

  • Dataflow invia riconoscimenti negativi per vari motivi interni (ad esempio, se un worker si sta spegnendo). Di conseguenza, i messaggi potrebbero essere inviati all'argomento messaggi non recapitabili anche se non si verificano errori nel codice della pipeline.

  • Dataflow riconosce i messaggi dopo che un bundle di messaggi è stato elaborato correttamente dalla prima fase unita. Se la pipeline ha più fasi unite e si verificano errori in qualsiasi punto dopo la prima fase, i messaggi sono già stati riconosciuti e non vengono inviati all&#3argomento messaggi non recapitabilier.

Implementa invece il pattern di messaggi non recapitabili in modo esplicito nella pipeline, indirizzando i messaggi non riusciti a una destinazione per l'elaborazione successiva. Alcuni sink I/O supportano le code di messaggi non recapitabili. I seguenti esempi implementano pattern di messaggi non recapitabili:

Consegna "exactly-once" di Pub/Sub

Poiché Dataflow dispone di meccanismi propri per l'elaborazione "exactly-once", non è consigliabile utilizzare la distribuzione "exactly-once" di Pub/Sub con Dataflow. L'attivazione della funzionalità di Pub/Sub di invio esattamente una volta riduce il rendimento della pipeline, perché limita il numero di messaggi disponibili per l'elaborazione parallela.

Ordinamento dei messaggi Pub/Sub

L'ordinamento dei messaggi è una funzionalità di Pub/Sub che consente a un sottoscrittore di ricevere i messaggi nell'ordine in cui sono stati pubblicati.

Non è consigliabile utilizzare l'ordinamento dei messaggi con Dataflow per i seguenti motivi:

  • Il connettore I/O Pub/Sub potrebbe non conservare l'ordine dei messaggi.
  • Apache Beam non definisce linee guida rigorose in merito all'ordine in cui vengono elaborati gli elementi. Pertanto, l'ordinamento potrebbe non essere mantenuto nelle trasformazioni downstream.
  • L'utilizzo dell'ordinamento dei messaggi Pub/Sub con Dataflow può aumentare la latenza e ridurre le prestazioni.

Trasformazioni di un singolo messaggio Pub/Sub

Le trasformazioni di un singolo messaggio (SMT) consentono di manipolare, convalidare e filtrare i messaggi in base ai relativi attributi o dati durante lo streaming nel sistema. Gli abbonamenti che alimentano Dataflow non devono utilizzare SMT che filtrano i messaggi, in quanto possono interferire con la scalabilità automatica. Ciò accade perché il filtro SMT delle sottoscrizioni può far sembrare il backlog più grande di quanto viene inviato a Dataflow finché i messaggi filtrati non vengono effettivamente elaborati dall'SMT. Gli SMT degli argomenti che filtrano i messaggi non causano problemi con la scalabilità automatica.

Passaggi successivi