Questa pagina descrive le best practice per la lettura da Pub/Sub in Dataflow.
Apache Beam fornisce un'implementazione di riferimento di Pub/Sub Connettore I/O per l'utilizzo da parte di runner non Dataflow. Tuttavia, Il runner Dataflow utilizza la propria implementazione personalizzata di rete. Questa implementazione sfrutta le API e i servizi interni di Google Cloud per offrire filigrane a bassa latenza, elevata precisione della filigrana 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 ciascun messaggio pubblicata in un argomento. Per impostazione predefinita, Pub/Sub esegue la consegna dei messaggi almeno una volta. Per ottenere la semantica "at-least-once", Pub/Sub ritenta la consegna se non riceve conferma dall'abbonato entro la scadenza di conferma. I nuovi tentativi possono comportare messaggio recapitato più di una volta. Ad esempio, la nuova invio può avvenire 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 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 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 l'articolo Scegliere la modalità streaming da utilizzare.
Deduplica in base all'attributo del messaggio
Per impostazione predefinita, Dataflow esegue la deduplica in base all'ID messaggio. Tuttavia, un'applicazione può inviare lo stesso record il doppio di due i messaggi Pub/Sub. 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, invece di utilizzare 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:
withIdAttribute
(Java)ReadFromPubSub
(Python)ReadOptions
(Vai)
Abbonamenti
Quando configuri la pipeline, specifica un argomento Pub/Sub o un abbonamento Pub/Sub da cui leggere. Se specifichi un abbonamento Pub/Sub, non usare la stessa sottoscrizione Pub/Sub per pipeline di dati. Se due pipeline leggono da un singolo abbonamento, ogni 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 tuoi dati potrebbe anche avere un timestamp event, che indica l'ora in cui il record è stato generati 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 l'evento per la filigrana. Altrimenti, per impostazione predefinita, Timestamp del messaggio Pub/Sub.
Per saperne di più sull'utilizzo dei timestamp degli eventi, consulta l'SDK seguente argomenti di riferimento:
withTimestampAttribute
(Java)ReadFromPubSub
(Python)ReadOptions
(Go)
Il connettore Pub/Sub ha accesso API privata che indica l'età del messaggio non confermato meno recente in un abbonamento. Questa API offre una latenza inferiore rispetto a quella disponibile in e configurazione in Cloud Monitoring. Consente a Dataflow di avanzare nella pipeline filigrane ed emettono 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. it utilizza questa sottoscrizione per controllare gli orari degli eventi dei messaggi che sono ancora in per gestire l'arretrato. Questo approccio consente a Dataflow di stimare arretrato e ora dell'evento in modo accurato. Per ulteriori informazioni, consulta la pagina di StackOverflow dedicata a come Dataflow calcola le watermark di Pub/Sub.
Pub/Sub Seek
La ricerca di Pub/Sub 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:
- Crea uno snapshot della abbonamento.
- Crea una nuova sottoscrizione per l'argomento Pub/Sub. Il nuovo abbonamento eredita lo snapshot.
- Svuota o annulla il job Dataflow attuale.
- 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.
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. Ritenta, invece, il messaggio elaborazione a tempo indeterminato, estendendo costantemente la scadenza di conferma per il 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 sia completamente elabora i dati. Nello specifico, Dataflow riconosce i messaggi Dopo essere stati elaborati correttamente nella prima fase e nel primo lato sono stati scritti nello spazio di archiviazione 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 email inutilizzate.
Implementa invece il pattern di messaggi non recapitabili esplicitamente nella pipeline. Alcuni canali di I/O hanno il supporto integrato per le code di messaggi non recapitati. I seguenti esempi implementare pattern di messaggi non recapitabili;
Consegna "exactly-once" in Pub/Sub
Poiché Dataflow ha i suoi meccanismi per eseguire la verifica "exactly-once", di elaborazione, sconsigliamo di utilizzare Distribuzione "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 per i seguenti motivi:
- Il connettore I/O Pub/Sub potrebbe non mantenere l'ordinamento dei messaggi.
- Apache Beam non definisce linee guida rigide sull'ordine in cui vengono elaborati. Pertanto, l'ordinamento potrebbe non essere mantenuto nelle trasformazioni a valle.
- L'uso dell'ordinamento dei messaggi Pub/Sub con Dataflow può aumentare la latenza e diminuire le prestazioni.
Passaggi successivi
- Elaborazione dei flussi con Pub/Sub e Dataflow: Qwik Start (self-paced lab)
- Esegui lo streaming da Pub/Sub a BigQuery
- Trasmetti flussi di messaggi da Pub/Sub utilizzando Dataflow
- Pipeline di flussi di dati
- exactly-once in Dataflow
- After Lambda: elaborazione "exactly-once" in Dataflow Parte 1 e Parte 3: origini e destinazioni (post del blog)