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 i 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 e deduplica efficiente per l'elaborazione dei messaggi esattamente una volta. 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 i messaggi in un argomento e Pub/Sub li consegna 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 consegna dei messaggi almeno una volta. Per ottenere la semantica almeno una volta, Pub/Sub riprova a inviare il messaggio se non riceve conferma da parte del sottoscrittore entro la scadenza prevista. I tentativi di invio ripetuti possono comportare l'invio di un messaggio più di una volta. Ad esempio, la reimportazione può verificarsi se il sottoscrittore conferma dopo la scadenza o se la conferma viene persa a causa di problemi temporanei della rete.

Se esegui la pipeline Dataflow utilizzando la modalità di streaming exactly-once, Dataflow deduplica i messaggi per ottenere la semantica exactly-once. Se la 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 contrappeso è che alcuni messaggi potrebbero essere elaborati due volte. Per ulteriori informazioni, consulta la sezione Scegliere la modalità di streaming da utilizzare.

Deduplica per attributo messaggio

Per impostazione predefinita, Dataflow esegue la 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 dell'origine originale potrebbero contenere record duplicati o l'applicazione potrebbe pubblicare erroneamente lo stesso messaggio due volte. Quest'ultimo può verificarsi a causa di ripetuti tentativi, se il riconoscimento è stato perso a causa di problemi di rete o altre interruzioni. In questi casi, i messaggi duplicati hanno ID 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 il publisher imposta questo attributo in modo coerente durante i tentativi di nuovo invio, Dataflow può rilevare i duplicati. Per la deduplica, i messaggi devono essere pubblicati in Pub/Sub entro 10 minuti l'uno dall'altro.

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

Abbonamenti

Quando configuri la pipeline, specifica un argomento Pub/Sub o un abbonamento Pub/Sub da cui leggere. Se specifichi un abbonamento, non utilizzare lo stesso abbonamento Pub/Sub per più pipeline. Se due pipeline leggono da un singolo abbonamento, ciascuna pipeline riceve parte dei dati in modo non deterministico, il che potrebbe causare messaggi duplicati, ritardo dell'acquarello e scalabilità automatica inefficiente. Crea invece un abbonamento distinto per ogni pipeline.

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

Timestamp e filigrane

Tutti i messaggi Pub/Sub hanno un timestamp, che rappresenta il momento in cui Pub/Sub riceve il messaggio. I dati possono anche avere un timestamp event, ovvero la data e 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 del messaggio Pub/Sub. In questo caso, il connettore utilizza il timestamp dell'evento per il watermarking. In caso contrario, per impostazione predefinita viene utilizzato 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 più vecchio in una sottoscrizione. Questa API offre una latenza inferiore a quella disponibile in Cloud Monitoring. Consente a Dataflow di avanzare le marcature di tempo della pipeline ed emettere risultati di calcolo con finestre con latenze ridotte.

Se configuri il connettore in modo che utilizzi i timestamp degli eventi, Dataflow crea una seconda sottoscrizione Pub/Sub. Lo script utilizza questa sottoscrizione per ispezionare le ore degli eventi dei messaggi che sono ancora nel backlog. Questo approccio consente a Dataflow di stimare con precisione il backlog in base al tempo dell'evento. Per ulteriori informazioni, consulta la pagina di StackOverflow che illustra come Dataflow calcola le watermark di Pub/Sub.

Pub/Sub Seek

Pub/Sub Seek consente agli utenti di riprodurre nuovamente i messaggi confermati in precedenza. 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ò causare messaggi duplicati o l'eliminazione di messaggi. Inoltre, invalida la logica della marcatura temporale di Dataflow e è in conflitto con lo stato di una pipeline che incorpora i dati elaborati.

Per eseguire nuovamente il trattamento dei 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. Scaricare o annullare il job Dataflow corrente.
  4. Invia di nuovo la pipeline utilizzando il nuovo abbonamento.

Per ulteriori informazioni, consulta Rielaborazione dei messaggi con lo snapshot e la ricerca di Pub/Sub.

Funzionalità di Pub/Sub non supportate

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

Backoff esponenziale

Quando crei una sottoscrizione Pub/Sub, puoi configurarla in modo da utilizzare un criterio di ripetizione con backoff esponenziale. Tuttavia, il backoff esponenziale non funziona con Dataflow. Crea invece l'abbonamento con il criterio di nuovo tentativo Riprova immediatamente.

Il backoff esponenziale viene attivato da un ack negativo o quando scade la scadenza dell'ack. Tuttavia, Dataflow non invia conferma negative quando il codice della pipeline non va a buon fine. Prova invece a ripetere l'elaborazione del messaggio a tempo indeterminato, estendendo continuamente la scadenza di conferma del messaggio.

Argomenti messaggi non recapitabili

Non utilizzare gli argomenti dei messaggi non recapitabili di Pub/Sub con Dataflow per i seguenti motivi:

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

  • Dataflow potrebbe confermare i messaggi prima che la pipeline elabori completamente i dati. Nello specifico, Dataflow conferma i messaggi dopo che sono stati elaborati correttamente dalla prima fase unita e gli effetti collaterali di quell'elaborazione sono stati scritti nella memoria permanente. Se la pipeline ha più fasi fuse e si verificano errori in qualsiasi momento dopo la prima fase, i messaggi sono già stati confermati e non vengono inviati all'argomento per le argomento messaggi non recapitabili.

Implementa invece il pattern dead-letter esplicitamente nella pipeline. Alcuni canali di I/O hanno il supporto integrato per le code di messaggi non recapitati. Gli esempi riportati di seguito implementano pattern di caselle postali virtuali.

Pub/Sub "exactly-once"

Poiché Dataflow dispone di propri meccanismi per l'elaborazione "exactly-once", non è consigliabile utilizzare la pubblicazione exactly-once di Pub/Sub con Dataflow. L'attivazione della consegna esattamente una volta di Pub/Sub riduce le prestazioni 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 mantenere l'ordinamento dei messaggi.
  • Apache Beam non definisce linee guida rigide per l'ordine in cui vengono elaborati gli elementi. Pertanto, l'ordinamento potrebbe non essere mantenuto nelle trasformazioni a valle.
  • L'utilizzo dell'ordinamento dei messaggi Pub/Sub con Dataflow può aumentare la latenza e diminuire le prestazioni.

Passaggi successivi