Lo sviluppo della pipeline prevede diverse fasi e attività, come la programmazione sviluppo, test e distribuzione in produzione. Questo documento spiega:
- Considerazioni sull'integrazione e la distribuzione continue (CI/CD) per supportare build, test e deployment automatizzati di pipeline in ambienti diversi.
- Funzionalità di Dataflow per ottimizzare prestazioni e risorse all'utilizzo in produzione.
- Approcci e watchpoint per l'aggiornamento delle pipeline in modalità flusso in produzione.
- Best practice per migliorare l'affidabilità della pipeline in produzione.
Integrazione continua
L'integrazione continua (CI) richiede agli sviluppatori di unire spesso il codice in un repository condiviso, il che è utile per le applicazioni che cambiano molto, ad esempio i siti web aggiornati di frequente. Sebbene le pipeline di dati di solito non cambino molto come altri tipi di applicazioni, le pratiche di CI offrono molti vantaggi sviluppo del prodotto. Ad esempio, l'automazione dei test fornisce un feedback rapido quando vengono rilevati difetti e riduce la probabilità che le regressioni vengano inserite nella base di codice.
L'automazione dei test è una parte importante dell'integrazione continua. Quando viene combinato con copertura dei test, l'automazione del test di eseguire la suite di test su ogni commit di codice. Il tuo Il server CI può funzionare in combinazione con uno strumento di automazione delle build come Maven eseguire la suite di test come uno o più passaggi della pipeline CI. Puoi pacchettizzare il codice che supera i test delle unità e i test di integrazione negli elementi di deployment da cui vengono lanciate le pipeline. Questa build è indicata come build che supera i test.
Il numero e i tipi di artefatti di deployment creati da una build di passaggio varia a seconda di come vengono avviate le pipeline. Utilizzo di Apache Beam Java SDK, puoi pacchettizzare il codice della pipeline in un file JAR a esecuzione automatica. Puoi quindi archiviare il file JAR in un bucket ospitato nel progetto per un ambiente di deployment, come il progetto Google Cloud di preproduzione o produzione. Se utilizzi i modelli classici (un tipo di esecuzione basata su modelli), gli elementi di deployment includono un file modello JSON, il file JAR per la pipeline e un modello di metadati facoltativo. Puoi quindi eseguire il deployment degli artefatti in diversi ambienti di deployment utilizzando la distribuzione continua, come spiegato nella sezione seguente.
Distribuzione e deployment continui
La distribuzione continua (CD) copia gli elementi di deployment in uno o più ambienti di deployment pronti per essere avviati manualmente. In genere, gli artefatti creati dal server CI vengono distribuiti in uno o più ambienti di pre-produzione per l'esecuzione test end-to-end. L'ambiente di produzione viene aggiornato se tutti i test end-to-end vengono superati.
Per le pipeline batch, il deployment continuo può avviare direttamente la pipeline come nuovo job Dataflow. In alternativa, altri sistemi possono utilizzare gli artefatti per avviare job batch quando obbligatorio. Ad esempio, puoi utilizzare Cloud Composer per eseguire job batch all'interno di un flusso di lavoro, oppure Cloud Scheduler per pianificare in batch.
Il deployment delle pipeline in modalità flusso può essere più complesso rispetto a quello delle pipeline in modalità batch. può quindi essere più difficile automatizzare utilizzando il deployment continuo. Ad esempio, potresti dover capire come sostituire o aggiornare una pipeline di streaming esistente. Se non riesci ad aggiornare una pipeline o se scegli di non farlo, puoi utilizzare altri metodi, ad esempio il coordinamento di più job Dataflow, per ridurre al minimo o prevenire l'interruzione dell'attività.
Identità e ruoli richiesti per CI/CD
La tua pipeline CI/CD interagisce con diversi sistemi per creare, testare ed eseguire il deployment pipeline di dati. Ad esempio, la pipeline deve accedere al repository del codice sorgente. Per abilitare queste interazioni, assicurati che la pipeline abbia le identità e i ruoli appropriati. Le seguenti attività della pipeline richiedono che la pipeline abbia identità e ruoli specifici.
Test di integrazione con servizi esterni, tra cui Google Cloud
Quando utilizzi Direct Runner per eseguire test ad hoc o test di integrazione di sistema, la pipeline utilizza le credenziali di Google Cloud CLI per utilizzare origini dati e destinazioni Google Cloud oppure le credenziali fornite dalla variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS. Assicurati che l'account di servizio utilizzato per ottenere le credenziali
Le risorse Google Cloud a cui accede la pipeline dispongono di un numero sufficiente
ruoli e autorizzazioni.
Esegui il deployment degli elementi in ambienti di deployment diversi
Se possibile, utilizza credenziali univoche per ogni ambiente (in pratica per ciascun progetto) e limitare di conseguenza l'accesso alle risorse.
Utilizza account di servizio univoci per ogni progetto per leggere e scrivere gli elementi di deployment nei bucket di archiviazione. A seconda che la pipeline utilizzi un modello, la procedura di deployment potrebbe dover eseguire il deployment di più elementi. Ad esempio, la creazione e l'implementazione di un modello Dataflow richiedono le autorizzazioni per scrivere in un bucket Cloud Storage gli elementi di deployment necessari per avviare la pipeline, ad esempio il file del modello della pipeline.
Esegui il deployment delle pipeline in ambienti di deployment diversi
Se possibile, utilizza account di servizio univoci per ogni progetto per accedere e gestire le risorse Google Cloud al suo interno, incluso l'accesso a Dataflow stesso.
L'account di servizio che utilizzi per creare e gestire i job Dataflow deve disporre di autorizzazioni IAM sufficienti per la gestione dei job. Per maggiori dettagli, consulta Account di servizio Dataflow della pagina Sicurezza e autorizzazioni di Dataflow.
L'account di servizio worker che utilizzi per eseguire i job Dataflow deve disporre dell'autorizzazione per gestire le risorse Compute Engine durante l'esecuzione del job e per gestire l'interazione tra la pipeline Apache Beam e il servizio Dataflow. Per maggiori dettagli, consulta la sezione Account di servizio worker nella pagina Sicurezza e autorizzazioni di Dataflow.
Per specificare un
account di servizio worker gestito dall'utente
per un lavoro, utilizza
l'opzione pipeline --serviceAccount.
Se non specifichi un account di servizio del worker quando crei un job, Dataflow tenta di utilizzare l'account di servizio predefinito di Compute Engine.
Ti consigliamo invece di specificare un account di servizio worker gestito dall'utente per gli ambienti di produzione, in quanto l'account di servizio predefinito di Compute Engine in genere ha un insieme di autorizzazioni più ampio rispetto a quello necessario per i job Dataflow.
Negli scenari di produzione, ti consigliamo di utilizzare account di servizio distinti per la gestione dei job Dataflow e per l'account di servizio worker, che offrono una maggiore sicurezza rispetto all'utilizzo di un singolo account di servizio. Ad esempio, l'account di servizio utilizzato per creare job di Dataflow potrebbe non dover accedere alle origini dati e alle destinazioni o utilizzare altre risorse utilizzate dalla pipeline. In questo dello scenario, l'account di servizio worker utilizzato per eseguire Ai job Dataflow sono concesse le autorizzazioni per utilizzare la pipeline Google Cloud. È stato concesso un account di servizio diverso per la creazione del job autorizzazioni per gestire (compresa la creazione) dei job Dataflow.
Pipeline CI/CD di esempio
Il seguente diagramma fornisce una visione generale e indipendente dagli strumenti di CI/CD per pipeline di dati. Inoltre, il diagramma mostra la relazione tra le attività di sviluppo, gli ambienti di deployment e i runner della pipeline.
Il diagramma mostra le seguenti fasi:
Sviluppo del codice: durante lo sviluppo del codice, uno sviluppatore esegue il codice della pipeline localmente utilizzando Direct Runner. Inoltre, gli sviluppatori utilizzano un ambiente sandbox per l'esecuzione di pipeline ad hoc utilizzando Dataflow Runner.
Nelle pipeline CI/CD standard, il processo di integrazione continua viene attivato quando uno sviluppatore apporta una modifica al sistema di controllo del codice sorgente, ad esempio esegue il push di nuovo codice in un repository.
Creazione e test: il processo di integrazione continua compila il codice della pipeline ed esegue test delle unità e test di trasformazione di integrazione usando Direct Runner. Test di integrazione del sistema facoltativi, che includono eseguire test di integrazione con origini e sink esterni utilizzando di set di dati.
Se i test hanno esito positivo, il processo CI archivia gli artefatti di deployment, che potrebbero includere file JAR, immagini Docker e metadati dei modelli, necessario per avviare la pipeline in località accessibile al processo di distribuzione continua. In base ai tipi di artefatti di deployment generati, potresti utilizzare Cloud Storage e Artifact Registry per archiviare le diverse tipi di artefatti.
Importazione e deployment: il processo di importazione continua copia gli elementi di deployment in un ambiente di preproduzione o li rende disponibili per l'utilizzo in quell'ambiente. Gli sviluppatori possono eseguire manualmente test end-to-end usando l'esecutore Dataflow, oppure possono usare per avviare il test automaticamente. In genere, un approccio di deployment continuo è più facile da attivare per le pipeline batch rispetto alle pipeline di streaming. Poiché le pipeline batch non vengono eseguite continuamente, è più facile sostituirle con una nuova release.
Il processo di aggiornamento delle pipeline di streaming può essere semplice o complesso, e devi testare gli aggiornamenti nell'ambiente di preproduzione. Le procedure di aggiornamento potrebbero non essere sempre coerenti tra le release. Ad esempio, un la pipeline potrebbe cambiare in modo tale da rendere impossibili gli aggiornamenti in loco. Per questo motivo, a volte è difficile automatizzare gli aggiornamenti della pipeline utilizzando il deployment continuo.
Se tutti i test end-to-end superano, puoi copiare gli elementi di deployment o metterli a disposizione dell'ambiente di produzione nell'ambito del processo di distribuzione continua. Se la nuova pipeline aggiorna o sostituisce una pipeline di streaming esistente, utilizza le procedure testate nell'ambiente di preproduzione per eseguire il deployment della nuova pipeline.
Esecuzione di job senza modello e con modello
Puoi creare un job Dataflow utilizzando l'SDK Apache Beam direttamente da un ambiente di sviluppo. Questo tipo di lavoro è chiamato job non basato su modelli. Sebbene questo approccio sia pratico per gli sviluppatori, potresti preferire separate le attività di sviluppo ed esecuzione delle pipeline. Per effettuare questa separazione, puoi utilizzare modelli Dataflow, che ti consentono di eseguire il commit e di eseguire le pipeline come attività indipendenti. Dopo aver archiviato un modello, altri utenti, inclusi quelli non sviluppatori, possono eseguire i job dal modello utilizzando l'interfaccia a riga di comando Google Cloud, la console Google Cloud o l'API REST Dataflow.
Dataflow offre i seguenti tipi di modelli di job:
- Modelli classici: gli sviluppatori utilizzano l'SDK Apache Beam per eseguire il codice della pipeline e salvare il grafo di esecuzione serializzato in JSON come modello. L'SDK Apache Beam esegue la gestione delle fasi del file modello in una posizione Cloud Storage, insieme a eventuali dipendenze richieste dal codice della pipeline.
- Flex Templates: gli sviluppatori utilizzano Google Cloud CLI per impacchettare la pipeline come immagine Docker, che viene poi archiviata in Artifact Registry. Anche il file delle specifiche del modello flessibile viene generato e archiviato automaticamente una località di Cloud Storage specificata dall'utente. Il file di specifiche del modello flessibile contiene metadati che descrivono come eseguire il modello, ad esempio i parametri della pipeline.
Oltre alle funzionalità del modello flessibile spiegato nella documentazione collegata, I modelli flessibili offrono dei vantaggi rispetto ai modelli classici per la gestione dei modelli.
- Con i modelli classici, è possibile archiviare più artefatti, ad esempio file JAR, in una posizione di staging di Cloud Storage, ma senza funzionalità per gestirli. In confronto, un modello flessibile è incapsulato un'immagine Docker. L'immagine pacchettizza tutte le dipendenze, ad eccezione di Specifiche del modello, necessarie per la pipeline in un artefatto di deployment gestito da Artifact Registry.
- Puoi usare la gestione delle immagini Docker per i tuoi modelli flessibili. Ad esempio, puoi condividere in modo sicuro Modelli concedendo le autorizzazioni di pull (e facoltativamente push) a Artifact Registry e usare i tag immagine Docker per le diverse versioni i tuoi modelli flessibili.
Gli sviluppatori possono utilizzare i modelli classici e i modelli flessibili per avviare i job in un un progetto diverso il progetto proprietario del registro e il bucket di archiviazione che ospita il modello o solo il bucket di archiviazione, se utilizzi i modelli classici. Questa funzionalità è utile se devi isolare l'elaborazione dei dati per più clienti in progetti e job di pipeline diversi. Con i modelli flessibili, puoi specificare ulteriormente diverse versioni di un'immagine Docker da utilizzare quando avvii una pipeline. Questa funzionalità semplifica la sostituzione graduale delle pipeline batch o streaming in più progetti quando aggiorni i modelli in un secondo momento.
Funzionalità di Dataflow per ottimizzare l'utilizzo delle risorse
Dataflow offre le seguenti funzionalità specifiche per i runner ottimizzare l'utilizzo delle risorse, con un conseguente miglioramento delle prestazioni e una riduzione dei costi:
- Streaming Engine: Streaming Engine sposta l'esecuzione delle pipeline in modalità flusso all'esterno di worker VM in un servizio dedicato. I vantaggi includono una maggiore reattività della scalabilità automatica, riduzioni delle risorse VM worker consumate e gli aggiornamenti automatici dei servizi senza rieseguire il deployment. In alcuni casi, puoi anche ridurre l'utilizzo delle risorse utilizzando l'elaborazione almeno una volta per i casi d'uso che possono tollerare i duplicati. L'abilitazione di Streaming Engine è consigliata per le pipeline in modalità flusso. La funzionalità è abilitata per impostazione predefinita quando utilizzi le versioni più recenti dell'SDK Apache Beam Java o dell'SDK Python.
- Dataflow Shuffle: Dataflow Shuffle si sposta le operazioni di shuffling raggruppa le pipeline in batch dai worker VM a un servizio dedicato. La i vantaggi includono un'esecuzione più rapida per la maggior parte delle pipeline batch, consumo di risorse da parte delle VM worker, migliore reattività della scalabilità automatica e una maggiore tolleranza agli errori. L'abilitazione di Dataflow Shuffle è consigliato per le pipeline in modalità batch. La funzionalità viene attivata per impostazione predefinita tramite SDK Java Apache Beam e l'SDK Python più recente.
- Flexible Resource Scheduling (FlexRS): FlexRS riduce i costi di elaborazione batch grazie a tecniche di pianificazione avanzate, al servizio Dataflow Shuffle e a una combinazione di istanze VM prerilasciabili e VM normali.
Aggiornare le pipeline in modalità flusso in produzione
Consulta Eseguire l'upgrade di una pipeline di inserimento flussi.
Ciclo di vita di un job Dataflow
Un job Dataflow attraversa un ciclo di vita rappresentato da
vari
stati dei job.
Per eseguire un job Dataflow, invialo a un
region.
Il job viene quindi instradato a un backend Dataflow disponibile in una delle
le zone all'interno della regione. Prima che Dataflow assegni un backend,
che tu abbia quota e autorizzazioni sufficienti per eseguire il job. Quando
sono stati completati ed è stato assegnato
un backend, il job
passa allo stato JOB_STATE_PENDING. Per
FlexRS
job, l'assegnazione del backend potrebbe essere ritardata a un momento futuro e questi job
inserisci uno stato JOB_STATE_QUEUED.
Il backend assegnato recupera il job da eseguire e tenta di avviare i worker Dataflow nel tuo progetto Google Cloud. La zona scelta delle VM worker dipende da una serie di fattori. Per i job batch che utilizzano Dataflow Shuffle, il servizio cerca anche di assicurare che il backend Dataflow Le VM worker si trovano nella stessa zona per evitare il traffico tra zone.
Dopo l'avvio, i worker di Dataflow richiedono lavoro al backend di Dataflow. Il backend è responsabile della suddivisione del lavoro in blocchi parallelizzabili, chiamati bundle, che vengono distribuiti tra i worker. Se i worker non sono in grado di gestire il lavoro esistente e se la scalabilità automatica è attivata, il backend avvia più worker per gestire il lavoro. Analogamente, se vengono avviati più worker del necessario, alcuni vengono chiusi.
Dopo l'avvio dei worker Dataflow,
Il backend Dataflow funge da
il piano di controllo per orchestrare l'esecuzione del job. Durante l'elaborazione,
il piano dati esegue operazioni di shuffling come GroupByKey, CoGroupByKey e Combine.
I job utilizzano una delle seguenti implementazioni del piano dati per le operazioni di ordinamento casuale:
- Il piano dati viene eseguito sui worker Dataflow e i dati su cui viene eseguito lo shuffle vengono archiviati su dischi permanenti.
- Il piano dati viene eseguito come servizio, esterno alle VM worker. Questa implementazione ha due varianti, che puoi specificare quando crei il job: Dataflow Shuffle per le pipeline batch e Streaming Engine per le pipeline in modalità flusso. Lo shuffle basato su servizi migliora notevolmente le prestazioni e la scalabilità delle operazioni di ordinamento dei dati rispetto allo shuffle basato su worker.
I job di flussi di dati in stato JOB_STATE_RUNNING continuano a essere eseguiti
a tempo indeterminato finché non
annullato
o
svuotato,
a meno che non si verifichi
un errore nel job. I job batch si arrestano automaticamente quando tutti
viene completata l'elaborazione o se si verifica un errore irreversibile. In base a come
il job viene arrestato, Dataflow imposta
in uno dei vari stati terminale, tra cui JOB_STATE_CANCELLED,
JOB_STATE_DRAINED o JOB_STATE_DONE.
Best practice per l'affidabilità della pipeline
Questa sezione illustra gli errori che potrebbero verificarsi quando lavori con Dataflow e best practice per Dataflow di lavoro.
Seguire i principi di isolamento
Un consiglio generale per migliorare l'affidabilità complessiva della pipeline è seguire i principi di isolamento alla base regioni e zone. Assicurati che le pipeline non abbiano istanze critiche tra regioni delle dipendenze. Se hai una pipeline con una dipendenza critica dai servizi di più regioni, un guasto in una di queste regioni può influire sulla pipeline. Per evitare questo problema, esegui il deployment in più regioni per la ridondanza e il backup.
Crea snapshot di Dataflow
Dataflow offre una funzionalità di snapshot che fornisce un backup dello stato di una pipeline. Puoi ripristinare lo snapshot della pipeline in una nuova pipeline Dataflow in modalità flusso in un'altra zona o regione. Puoi quindi avviare il rielaborare dei messaggi negli argomenti Pub/Sub o Kafka a partire dal timestamp dello snapshot. Se configuri snapshot regolari delle tue pipeline, puoi ridurre al minimo il tempo di recupero obiettivo (RTO).
Per ulteriori informazioni sugli snapshot Dataflow, consulta Usa gli snapshot Dataflow.
Gestire gli errori di invio del job
Invii job Dataflow non basati su modelli utilizzando l'SDK Apache Beam. Per inviare il job, devi esegui la pipeline utilizzando Dataflow Runner che viene specificato come parte del percorso opzioni. L'SDK Apache Beam mette in pausa i file in Cloud Storage, crea un job di richiesta e invia il file a Dataflow.
In alternativa, i job creati dai modelli Dataflow utilizzano diversi metodi di invio, che in genere si basano sull'API dei modelli.
Potresti visualizzare diversi errori restituiti da Dataflow che indicano l'errore del job per i job basati su modelli e non. Questa sezione illustra i diversi tipi di errori di invio dei job e le best practice per e la loro gestione o mitigazione.
Riprova a inviare i job in caso di errori temporanei
Se un job non riesce ad avviarsi a causa di un problema del servizio Dataflow, riprova alcune volte. Il nuovo tentativo riduce i problemi temporanei del servizio.
Riduci gli errori a livello di zona specificando una regione di worker
Dataflow fornisce disponibilità regionale ed è disponibile in più regioni. Quando un utente invia un job a un region [regione] senza specificare esplicitamente una zona, le route Dataflow il job in una zona della regione specificata in base alla disponibilità delle risorse.
L'opzione consigliata per l'inserimento di lavoro è specificare una regione dei worker
mediante il flag --region
anziché il flag --zone, quando possibile. Questo passaggio consente a Dataflow di fornire un livello aggiuntivo di tolleranza ai guasti per le pipeline scegliendo automaticamente la zona migliore possibile per il job. I job che specificano una zona esplicita non hanno questo vantaggio.
non riescono se si verificano problemi all'interno della zona. Se l'invio di un job non va a buon fine a causa di
a livello di zona, spesso puoi
risolvere il problema riprovando il job senza specificare esplicitamente una zona.
Riduci al minimo gli errori regionali archiviando i dati in più regioni
Se un'intera regione non è disponibile, prova il job in un'altra regione. È è importante considerare la disponibilità dei dati quando i job non vengono regioni. Per proteggerti da errori in una singola regione senza copiare manualmente i dati in più regioni, utilizza le risorse Google Cloud che archiviano automaticamente i dati in più regioni. Ad esempio, utilizza le località multiregionali di BigQuery per i set di dati o i bucket Cloud Storage a due regioni e multiregioni. Se una regione non è più disponibile, puoi eseguire nuovamente la pipeline in in un'altra regione in cui sono disponibili i dati.
Per un esempio di utilizzo di servizi multi-regionali con Dataflow, consulta Elevata disponibilità e ridondanza geografica.
Gestire gli errori nelle pipeline in esecuzione
Dopo che un job è stato inviato e accettato, le uniche operazioni valide per il job sono le seguenti:
- annulla per job batch
- aggiorna, svuota o annulla per i job di flussi di dati
Non puoi modificare la posizione dei job in esecuzione dopo averli inviati. Se non utilizzi FlexRS, i job di solito iniziano a elaborare i dati entro minuti dopo l'invio. I job FlexRS possono richiedere fino a sei ore per i dati per iniziare l'elaborazione.
Questa sezione illustra gli errori dei job in esecuzione e le best practice per come gestirli.
Monitora i job per identificare e risolvere i problemi causati da errori temporanei
Per i job batch, i bundle che includono un elemento con errori vengono ritentati quattro volte. Dataflow termina il job quando un singolo bundle ha avuto esito negativo quattro volte. Questo processo risolve molti problemi temporanei. Tuttavia, se un errore prolungato il numero massimo di nuovi tentativi viene raggiunto rapidamente, il che consente al job a fallire rapidamente.
Per il monitoraggio e la gestione degli incidenti, configura le regole di avviso per rilevare i job non riusciti. Se un job non viene completato, esamina i log del job per identificare gli errori del job causati da elementi di lavoro non riusciti che hanno superato il limite di tentativi.
Per i job di streaming, Dataflow riprova gli elementi di lavoro non riusciti indefinitamente. Il job non è stato interrotto. Tuttavia, il job potrebbe bloccarsi finché è stato risolto. Crea di monitoraggio al fine di rilevare di una pipeline bloccata, ad esempio un di aumento della latenza di sistema e di una diminuzione dell'aggiornamento dei dati. Implementa la registrazione degli errori nel codice della pipeline per identificare gli arresti anomali della pipeline causati da elementi di lavoro che non riescono ripetutamente.
Riavvia job in una zona diversa se si verifica un'interruzione a livello di zona
Dopo l'avvio di un job, i worker Dataflow che eseguono il codice utente vengono vincolato a una singola zona. Se si verifica un'interruzione a livello di zona, Dataflow dei job subiscono spesso l'impatto, a seconda della portata dell'interruzione.
Per le interruzioni che interessano solo i backend di Dataflow, il servizio gestito esegue automaticamente la migrazione dei backend in un'altra zona in modo che possano continuare il job. Se il job utilizza Dataflow Shuffle, il backend non può essere spostato tra le zone. Se si verifica una migrazione del backend Dataflow, i job potrebbero essere temporaneamente bloccati.
Se si verifica un'interruzione a livello di zona, è probabile che i job in esecuzione non vadano a buon fine o si blocchino fino al ripristino della disponibilità della zona. Se una zona non è più disponibile per un lungo periodo, arrestare job (annulla per job batch scarica per i job di flussi di dati) e riavviarli per lasciare che Dataflow scelga una nuova zona salutare.
Riavvia job batch in una regione diversa se si verifica un'interruzione a livello di regione
Se si verifica un'interruzione a livello di regione in una regione in cui i job Dataflow sono in esecuzione, i job possono non riuscire o bloccarsi. Per i job batch, se possibile, riavvia il job in un'altra regione. È importante assicurarsi che i dati siano disponibili in regioni diverse.
Mitigare le interruzioni a livello di regione utilizzando l'alta disponibilità o il failover
Per i job di flussi, a seconda della tolleranza di errore e del budget per l'applicazione, sono disponibili diverse opzioni per la mitigazione degli errori. In caso di interruzione regionale, l'opzione più semplice ed economica è attendere che l'interruzione sia terminata. Tuttavia, se la tua applicazione è sensibile alla latenza o se l'elaborazione dei dati non deve essere interrotta o deve essere ripresa con un ritardo minimo, le sezioni seguenti illustrano le opzioni a tua disposizione.
Alta disponibilità: sensibile alla latenza senza perdita di dati
Se la tua applicazione non può tollerare la perdita di dati, esegui pipeline duplicate in in parallelo in due regioni diverse e fare in modo che le pipeline utilizzino gli stessi dati. Le stesse origini dati devono essere disponibili in entrambe le regioni. Le applicazioni a valle che dipendono dall'output di queste pipeline devono essere in grado di passare dall'output di una regione all'altra. A causa della duplicazione di risorse, questa opzione comporta il costo più elevato rispetto ad altre opzioni. Per un esempio di implementazione, consulta la sezione Alta disponibilità e ridondanza geografica.
Failover: sensibile alla latenza con potenziale perdita di dati
Se l'applicazione può tollerare la potenziale perdita di dati, crea i flussi di dati ed è disponibile in più regioni. Ad esempio, utilizzando Pub/Sub, mantenere due abbonamenti indipendenti per lo stesso argomento, uno per ogni regione. Se si verifica un'interruzione a livello di regione, avvia una pipeline sostitutiva in un'altra regione e fai in modo che la pipeline consumi i dati dell'abbonamento di backup.
Riproduci l'iscrizione al backup in un momento opportuno per ridurre al minimo la perdita di dati senza sacrificare la latenza. Le applicazioni downstream devono sapere come passare all'output della pipeline in esecuzione, in modo simile all'opzione di alta disponibilità. Questa opzione utilizza meno risorse rispetto all'esecuzione di pipeline duplicate perché vengono duplicati solo i dati.
Disponibilità elevata e ridondanza geografica
Puoi eseguire più pipeline di streaming in parallelo per l'elaborazione di dati ad alta disponibilità. Ad esempio, puoi eseguire due job di streaming in parallelo in regioni diverse, il che fornisce ridondanza geografica e tolleranza ai guasti per l'elaborazione dei dati.
Considerando la disponibilità geografica di origini dati e sink, puoi gestire pipeline end-to-end in una configurazione multiregionale ad alta disponibilità. Il seguente diagramma mostra un esempio di implementazione.
Il diagramma mostra il seguente flusso:
Pub/Sub viene eseguito nella maggior parte delle regioni del mondo, il che consente al servizio di offrire un accesso rapido e globale ai dati, garantendo al contempo il controllo sulla posizione in cui vengono archiviati i messaggi. Pub/Sub può archiviare automaticamente i messaggi pubblicati nella regione Google Cloud più vicina agli iscritti oppure puoi configurarlo per utilizzare una regione o un insieme di regioni specifico utilizzando i criteri di archiviazione dei messaggi.
Pub/Sub recapita quindi i messaggi ai sottoscrittori indipendentemente da dove sono archiviati i messaggi. I client Pub/Sub non devono essere a conoscenza delle località dei server a cui si connettono, perché i meccanismi di bilanciamento del carico globale indirizzano il traffico al data center Google Cloud più vicino in cui vengono archiviati i messaggi.
Dataflow viene eseguito in regioni Google Cloud specifiche. Eseguendo pipeline parallele in regioni Google Cloud separate, lattina isolare i job dagli errori che interessano una singola regione. Il diagramma mostra due istanze della stessa pipeline, ciascuna in esecuzione in una regione Google Cloud distinta.
BigQuery fornisce località dei set di dati regionali e multiregionali. Quando scegli una località multiregionale, il set di dati si trova in almeno due regioni geografiche. Il diagramma mostra due pipeline separate, ciascuna delle quali scrive in un set di dati multiregionale distinto.