Flussi di dati con Pub/Sub

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questa pagina fornisce una panoramica concettuale dell'integrazione di Dataflow con Pub/Sub. La panoramica descrive alcune ottimizzazioni disponibili nell'implementazione del runner Dataflow del connettore I/O Pub/Sub. Pub/Sub è un sistema di importazione e pubblicazione degli eventi scalabile e durevole. Dataflow integra il modello di distribuzione scalabile di almeno il sistema Pub/Sub con una deduplicazione dei messaggi, elaborazione "exactly-once" e generazione di una filigrana dei dati da eventi con timestamp. Per utilizzare Dataflow, scrivi la tua pipeline utilizzando l'SDK Apache Beam, quindi esegui il codice della pipeline sul servizio Dataflow.

Prima di iniziare, approfondisci i concetti di base di Apache Beam e delle pipeline in modalità flusso. Per ulteriori informazioni, consulta le seguenti risorse:

Creazione di pipeline in modalità flusso con Pub/Sub

Per ottenere i vantaggi dell'integrazione di Dataflow's con Pub/Sub, puoi creare le tue pipeline in modalità flusso in uno dei seguenti modi:

Funzionalità di integrazione Pub/Sub e Dataflow

Apache Beam fornisce l'implementazione dell'origine I/O di riferimento (PubsubIO) per Pub/Sub (Java, Python e Go). Questa implementazione dell'origine I/O è utilizzata da runner non Dataflow, come il runner Apache Spark, il runner Apache Flink e il runner diretto.

L'esecutore Dataflow utilizza un'implementazione privata diversa di PubsubIO (per Java, Python e Go). Questa implementazione sfrutta le API e i servizi interni di Google Cloud per offrire tre vantaggi principali: filigrane a bassa latenza, alta precisione della filigrana (e quindi completezza dei dati) ed deduplicazione efficiente (elaborazione "exactly-once") dei messaggi".

I connettori I/O Apache Beam ti consentono di interagire con Dataflow utilizzando origini e sink controllati. L'implementazione del corridore Dataflow di PubsubIO riconosce automaticamente i messaggi dopo essere stati elaborati correttamente dalla prima fase e gli effetti collaterali di tale elaborazione vengono scritti nello spazio di archiviazione permanente. Consulta la documentazione per la fusione per ulteriori dettagli. I messaggi vengono quindi riconosciuti solo quando Dataflow può garantire che non si verifichi alcuna perdita di dati in caso di arresto anomalo di alcuni componenti o di perdita di connessione.

Filigrana a bassa latenza

Dataflow ha accesso all'API privata di Pub/Sub che fornisce l'età del messaggio meno recente non confermato in una sottoscrizione, con una latenza più bassa di quella disponibile in Cloud Monitoring. Per confronto, le metriche di backlog Pub/Sub disponibili in Cloud Monitoring in genere subiscono un ritardo di due o tre minuti, ma le metriche vengono ritardate solo di circa dieci secondi per Dataflow. Questo consente a Dataflow di far avanzare le filigrane delle pipeline ed emettere prima i risultati del calcolo con finestra.

Alta precisione della filigrana

Un altro problema importante risolto in modo nativo dall'integrazione di Dataflow con Pub/Sub è la necessità di una robusta filigrana per le finestre definite nel tempo dell'evento. L'ora dell'evento è un timestamp specificato dall'applicazione dell'editore come attributo di un messaggio Pub/Sub, anziché il campo publish_time impostato su un messaggio dal servizio Pub/Sub stesso. Poiché Pub/Sub calcola le statistiche backlog solo in base ai timestamp assegnati al servizio (o al tempo di elaborazione), per la stima della filigrana ora evento è necessario un meccanismo separato.

Per risolvere questo problema, se l'utente sceglie di utilizzare i timestamp degli eventi personalizzati, il servizio Dataflow crea un secondo abbonamento di monitoraggio. Questa sottoscrizione al monitoraggio viene utilizzata per esaminare gli orari degli eventi dei messaggi nel backlog della sottoscrizione di base e stimare il backlog degli eventi. Per saperne di più, consulta la pagina StackOverflow che illustra il modo in cui Dataflow calcola le filigrane Pub/Sub.

deduplicazione efficace

La deduplicazione dei messaggi è obbligatoria per l'elaborazione "exactly-once" dei messaggi e puoi usare il modello di programmazione Apache Beam per ottenere l'elaborazione "exactly-once" dei flussi di messaggi Pub/Sub. Dataflow deduplica i messaggi in relazione all'ID messaggio Pub/Sub. Di conseguenza, tutta la logica di elaborazione può presumere che i messaggi siano già univoci rispetto all'ID messaggio Pub/Sub. Il meccanismo di aggregazione incrementale ed efficiente per raggiungere questo obiettivo è astratto nell'API PubsubIO.

Se PubsubIO è configurato per utilizzare l'attributo del messaggio Pub/Sub per la deduplicazione anziché l'ID messaggio, Dataflow deduplica i messaggi pubblicati in Pub/Sub entro 10 minuti l'uno dall'altro. Le API di ordinamento standard del servizio Dataflow consentono di utilizzare l'elaborazione ordinata con Dataflow. In alternativa, per utilizzare l'ordinamento con Pub/Sub, vedi Ordinazione messaggi.

Funzionalità Pub/Sub non supportate

Argomenti non recapitabili e criteri di ripetizione del ritardo del backoff esponenziale

Gli argomenti non recapitabili Pub/Sub e i criteri di ripetizione del ritardo del backoff esponenziale non sono completamente supportati da Dataflow. Implementa invece questi pattern esplicitamente nella pipeline. Nell'applicazione di vendita al dettaglio e nel modello Pub/Sub-BigQuery sono disponibili due esempi di pattern non recapitabili.

Esistono due motivi per cui gli argomenti non recapitabili e i criteri di ripetizione del ritardo di backoff esponenziale non funzionano con Dataflow.

Prima di tutto, Dataflow non invia messaggi NACK (ovvero invia un riconoscimento negativo) a Pub/Sub quando il codice della pipeline ha esito negativo. Dataflow prova invece a elaborare il messaggio a tempo indeterminato, estendendo continuamente la scadenza di conferma per il messaggio. Tuttavia, il backend Dataflow potrebbe inviare messaggi NACK per vari motivi interni, quindi è possibile che i messaggi vengano recapitati nell'argomento messaggi non recapitabili anche quando non ci sono stati errori nel codice della pipeline.

In secondo luogo, Dataflow potrebbe riconoscere i messaggi prima che la pipeline elabora completamente i dati. Nello specifico, Dataflow riconosce che i messaggi sono stati elaborati correttamente per la prima fase e gli effetti collaterali di tale elaborazione sono stati scritti nello spazio di archiviazione permanente. Se la pipeline ha più fasi fuse e gli errori si verificano in qualsiasi momento dopo la prima fase, i messaggi sono già confermati.

Migrazione imminente da Pull sincrono a Streaming Pull (solo Streaming Engine)

Al momento Streaming Engine utilizza Synchronous Pull per consumare dati da Pub/Sub. In futuro, Streaming Engine utilizzerà la piattaforma Streaming Pull per migliorare le prestazioni.

Durante la migrazione, un job potrebbe utilizzare la modalità di sincronizzazione sincrona per un periodo di tempo e la modalità di pull in streaming per un altro periodo di tempo. Questa transizione influirà sulle metriche Pub/Sub visualizzate nell'interfaccia utente di Dataflow e riportate in Cloud Monitoring. Dopo che un job passa alla modalità Pull di streaming, alcune metriche esistenti non vengono segnalate. Per ulteriori informazioni, consulta la pagina relativa all'utilizzo dell'interfaccia di monitoraggio di Dataflow.

La modalità Pull sincrona e Streaming Pull consumano quote separate. Il team di Dataflow aumenta proattivamente le quote per i progetti che già consumano grandi quantità di dati utilizzando la modalità di sincronizzazione sincrona.

I job di flusso che non utilizzano Streaming Engine non saranno migrati in Streaming Pull e non saranno interessati da questa modifica.

In caso di domande sulla migrazione, contatta il team dedicato al tuo account.