Lettura da Pub/Sub a Dataflow

In questa pagina vengono descritte le best practice per la lettura da Pub/Sub in Dataflow.

Apache Beam fornisce un'implementazione di riferimento del connettore I/O Pub/Sub per l'utilizzo da parte di runner non Dataflow. Tuttavia, il runner Dataflow utilizza la propria implementazione personalizzata del connettore. Questa implementazione sfrutta le API e i servizi interni di Google Cloud per offrire filigrane a bassa latenza, elevata precisione delle filigrane 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 consumatori di eventi. L'applicazione pubblica i messaggi in un argomento e Pub/Sub li consegna in modo asincrono ai sottoscrittori.

Pub/Sub assegna un ID messaggio univoco a ciascun messaggio pubblicato in un argomento. Per impostazione predefinita, Pub/Sub esegue la consegna dei messaggi at-least-once. Per ottenere la semantica "at-least-once", Pub/Sub ritenta la consegna se non riceve conferma da parte del sottoscrittore entro la scadenza di conferma. Più tentativi possono comportare la consegna di un messaggio più di una volta. Ad esempio, la ripubblicazione può avvenire se l'abbonato conferma dopo la scadenza o se la conferma viene persa a causa di problemi di rete temporanei.

Se esegui la pipeline Dataflow utilizzando la modalità flusso di dati "exactly-once", Dataflow deduplica i messaggi per ottenere una semantica "exactly-once". Se la pipeline può tollerare alcuni record duplicati, valuta l'utilizzo della modalità flusso di dati Almeno una volta. Questa modalità può ridurre significativamente la latenza e il costo totale della pipeline. Alcuni messaggi potrebbero essere elaborati due volte. Per maggiori informazioni, vedi Scegliere la modalità flusso di dati da utilizzare.

Deduplica in base all'attributo del messaggio

Per impostazione predefinita, Dataflow deduplica in base all'ID messaggio. Tuttavia, un'applicazione potrebbe inviare lo stesso record due volte di due messaggi Pub/Sub distinti. Ad esempio, i dati di origine originali potrebbero contenere record duplicati o l'applicazione potrebbe pubblicare erroneamente lo stesso messaggio due volte. Quest'ultimo caso può verificarsi 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 I/O Pub/Sub per deduplicare i messaggi in base al valore di un attributo del messaggio, anziché utilizzare l'ID messaggio Pub/Sub. Se l'editore imposta questo attributo in modo coerente durante i nuovi tentativi, Dataflow è in grado di rilevare i duplicati. I messaggi devono essere pubblicati in 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 SDK:

Abbonamenti

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

Se specifichi un argomento, il connettore crea una nuova sottoscrizione temporanea. Questo abbonamento è univoco per pipeline.

Timestamp e filigrane

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

Puoi configurare il connettore in modo che legga il timestamp dell'evento da un attributo nel messaggio Pub/Sub. In questo caso, il connettore usa il timestamp dell'evento per la filigrana. Altrimenti, per impostazione predefinita, usa il timestamp del messaggio Pub/Sub.

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

Il connettore Pub/Sub ha accesso all'API privata di Pub/Sub, che specifica l'età del messaggio non confermato meno recente in una sottoscrizione. Questa API fornisce una latenza inferiore rispetto a quella disponibile in Cloud Monitoring. Consente a Dataflow di far avanzare le filigrane delle pipeline e di emettere risultati di calcolo con finestre con basse latenze.

Se configuri il connettore in modo che utilizzi i timestamp degli eventi, Dataflow crea una seconda sottoscrizione Pub/Sub. Utilizza questa sottoscrizione per ispezionare gli orari degli eventi dei messaggi ancora nel backlog. Questo approccio consente a Dataflow di stimare il backlog evento-tempo in modo accurato. Per ulteriori informazioni, consulta la pagina StackOverflow relativa a come Dataflow calcola le filigrane Pub/Sub.

Ricerca Pub/Sub

Pub/Sub Seek consente agli utenti di riprodurre i messaggi confermati in precedenza. Puoi usare 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 a ritroso in una pipeline in esecuzione può portare all'eliminazione di messaggi duplicati o di messaggi. Inoltre, invalida la logica della filigrana di Dataflow e crea conflitti con lo stato di una pipeline che incorpora dati elaborati.

Per rielaborare i messaggi utilizzando Pub/Sub Seek, si consiglia di seguire questo flusso di lavoro:

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

Per maggiori informazioni, consulta Rielaborazione dei messaggi con snapshot Pub/Sub e Seek.

Funzionalità Pub/Sub non supportate

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

Backoff esponenziale

Quando crei una sottoscrizione Pub/Sub, puoi configurarla per utilizzare un criterio per i nuovi tentativi con backoff esponenziale. Tuttavia, il backoff esponenziale non funziona con Dataflow.

Il backoff esponenziale viene attivato da un riconoscimento negativo o alla scadenza della scadenza di conferma. Tuttavia, Dataflow non invia conferme negative in caso di errore del codice della pipeline. Al contrario, ritenta l'elaborazione dei messaggi a tempo indeterminato, estendendo continuamente la scadenza di conferma per il messaggio.

Argomenti messaggi non recapitabili

Non è consigliabile utilizzare argomenti messaggi non recapitabili Pub/Sub con Dataflow per i seguenti motivi:

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

  • Dataflow può confermare i messaggi prima che la pipeline elabori completamente i dati. In particolare, Dataflow riconosce i messaggi dopo essere stati elaborati correttamente nella prima fase unificata e gli effetti collaterali dell'elaborazione sono stati scritti nello spazio di archiviazione permanente. Se la pipeline ha più fasi unite e gli errori si verificano in qualsiasi momento dopo la prima fase, i messaggi sono già confermati e non vanno all'argomento dei messaggi non recapitabili.

Implementa invece il pattern di messaggi non recapitabili esplicitamente nella pipeline. Alcuni sink di I/O dispongono di supporto integrato per le code di messaggi non recapitabili. I seguenti esempi implementano i pattern dei messaggi non recapitabili;

Consegna "exactly-once" in Pub/Sub

Poiché Dataflow ha i suoi meccanismi per l'elaborazione "exactly-once", non è consigliabile utilizzare la distribuzione Pub/Sub "exactly-once" con Dataflow. L'abilitazione della consegna "exactly-once" di Pub/Sub riduce le prestazioni della pipeline, poiché 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 di I/O Pub/Sub potrebbe non conservare l'ordinamento dei messaggi.
  • Apache Beam non definisce linee guida rigide sull'ordine in cui vengono elaborati gli elementi. Di conseguenza, l'ordinamento potrebbe non essere conservato nelle trasformazioni downstream.
  • Usare l'ordinamento dei messaggi Pub/Sub con Dataflow può aumentare la latenza e diminuire le prestazioni.

Passaggi successivi