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
Integrazione continua (CI) richiede agli sviluppatori di unire spesso il codice in un repository condiviso, è utile per le applicazioni che cambiano molto, come i siti web che vengono aggiornati spesso. 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 in caso di difetti e riduce la probabilità che le regressioni entrino nel codebase.
L'automazione dei test è una parte importante della CI. 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 gli artefatti di deployment da cui vengono avviate le pipeline. Questa build è denominata come build con passaggio.
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 ambiente di deployment, come il progetto Google Cloud di preproduzione o produzione. Se utilizzi la versione classica Modelli (un tipo esecuzione con modello), Gli artefatti di deployment includono File modello JSON, il file JAR per la pipeline e 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
Distribuzione continua (CD) copia gli artefatti di deployment in uno o più ambienti di deployment pronto per essere avviato 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 hanno esito positivo.
Per le pipeline in modalità batch, deployment continuo puoi avviare direttamente la pipeline come un 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. Per Ad esempio, potresti dover stabilire come sostituire o aggiornare una pipeline di inserimento flussi esistente. Se non riesci ad aggiornare una pipeline o scegli di non aggiornarla, puoi utilizzare ad altri metodi, come il coordinamento di più job Dataflow per ridurre al minimo o prevenire interruzioni 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 poter accedere al codice sorgente repository Git. Per abilitare queste interazioni, assicurati che la pipeline abbia il 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 l'esecuzione di test ad hoc o di integrazione del sistema, la pipeline utilizza
le credenziali Google Cloud CLI per utilizzare origini dati e sink Google Cloud,
o utilizza le credenziali fornite
GOOGLE_APPLICATION_CREDENTIALS
variabile di ambiente. 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 artefatti in diversi ambienti di deployment
Se possibile, utilizza credenziali univoche per ogni ambiente (in pratica per ciascun progetto) e limitare di conseguenza l'accesso alle risorse.
Utilizza indirizzi account di servizio che ogni progetto legge e scrive gli artefatti di deployment nei bucket di archiviazione. A seconda che la pipeline utilizzi o meno template, il processo di deployment potrebbe dover preparare più artefatti. Ad esempio: creazione e gestione temporanea di un modello Dataflow richiede le autorizzazioni per scrivere artefatti di deployment necessari per avviare la pipeline, ad esempio il modello in un bucket Cloud Storage.
esegui il deployment delle pipeline in diversi ambienti di deployment
Se possibile, utilizza account di servizio univoci per ciascun progetto per accedere e gestire le risorse Google Cloud all'interno del progetto, incluso l'accesso e Dataflow.
L'account di servizio che utilizzi per creare e gestire I job Dataflow devono avere IAM sufficiente autorizzazioni per la gestione dei job. Per maggiori dettagli, consulta Account di servizio Dataflow della pagina Sicurezza e autorizzazioni di Dataflow.
Account di servizio worker che utilizzi per eseguire i job Dataflow richiede l'autorizzazione per gestire alle 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 Account di servizio worker della 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 per il worker
quando crei un job, Dataflow tenta di utilizzare
Account di servizio predefinito Compute Engine.
Ti consigliamo invece di specificare un account di servizio per il worker gestito dall'utente
per gli ambienti di produzione, perché il servizio
di solito dispone di un insieme più ampio di autorizzazioni rispetto alle autorizzazioni
richiesta per i tuoi job Dataflow.
Negli scenari di produzione, consigliamo di utilizzare un servizio separato per la gestione dei job Dataflow e un account di servizio, che offre una maggiore sicurezza rispetto all'uso di un con un singolo account di servizio. Ad esempio, l'account di servizio utilizzato creare job Dataflow potrebbe non aver bisogno di accedere alle origini dati e i sink o di 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 della pipeline in locale usando Direct Runner. Inoltre, gli sviluppatori utilizzano un ambiente sandbox per l'esecuzione di pipeline ad hoc utilizzando Esecutore Dataflow.
Nelle pipeline CI/CD tipiche, il processo di integrazione continua viene viene attivata quando uno sviluppatore apporta una modifica al sistema di controllo del codice sorgente. come 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.
Distribuzione e deployment: il processo di distribuzione continua copia gli artefatti di deployment in un ambiente di pre-produzione o li rende disponibili per l'uso all'interno di quell'ambiente. Gli sviluppatori possono eseguire manualmente test end-to-end con Dataflow Runner o i team per avviare il test automaticamente. In genere, un è più facile da abilitare per le pipeline in modalità batch. rispetto alle pipeline in modalità flusso. Poiché le pipeline batch non vengono eseguite in modo continuo, è più facile sostituirli con una nuova release.
Il processo di aggiornamento delle pipeline in modalità flusso potrebbe semplici o complesse, e dovresti testare gli aggiornamenti nell'ambiente di preproduzione. Aggiorna e le procedure potrebbero non essere sempre coerenti tra una release e l'altra. 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 vengono superati, puoi copiare gli artefatti di deployment disponibile nell'ambiente di produzione come parte del processo di distribuzione continua. Se aggiorna o sostituisce una pipeline in modalità flusso esistente, utilizza testate nell'ambiente di pre-produzione per eseguire il deployment della nuova pipeline.
Esecuzione di job non basati su modelli ed esecuzione di job basati su modelli
Puoi creare un job Dataflow utilizzando direttamente l'SDK Apache Beam 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 fare questa separazione, puoi utilizzare Modelli Dataflow, che ti consentono di organizzare ed eseguire le pipeline come attività indipendenti. Dopo un il modello è in fase temporanea, altri utenti, anche non sviluppatori, possono eseguire i job il modello utilizzando Google Cloud CLI, console Google Cloud o API REST Dataflow.
Dataflow offre quanto segue: tipi di modelli di prestazioni:
- Modelli classici: gli sviluppatori utilizzano l'SDK Apache Beam per eseguire codice della pipeline e salva il grafico di esecuzione serializzata JSON come modello. L'SDK Apache Beam archivia in un percorso di Cloud Storage il file del modello, con eventuali dipendenze richieste dal codice della pipeline.
- Modelli flessibili: gli sviluppatori utilizzano Google Cloud CLI per pacchettizzare la pipeline come un'immagine Docker, che viene quindi archiviata 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 delle specifiche del modello flessibile contiene metadati che descrivono come eseguire il modello, ad esempio la pipeline parametri.
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, potrebbero essere archiviati più elementi, come i file JAR in una posizione temporanea di Cloud Storage, ma senza funzionalità da gestire di questi vari artefatti. 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 asset o solo il bucket di archiviazione, se utilizzi Modelli classici. Questa funzionalità è utile se devi isolare l'elaborazione dati di più clienti in diversi di progetti e job della pipeline. Utilizzando i modelli flessibili, è possibile specificare ulteriormente diverse versioni di un'immagine Docker da usare quando si avvia una pipeline. Questo semplifica la sostituzione graduale di pipeline in modalità batch o flusso 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 la reattività della scalabilità automatica, le riduzioni delle risorse VM worker consumate e gli aggiornamenti automatici dei servizi senza rieseguire il deployment. In alcuni casi, puoi anche di ridurre l'utilizzo delle risorse elaborazione "at-least-once" per i e cover compatibili con 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 utilizzando SDK Java Apache Beam e l'SDK Python più recente.
- Pianificazione flessibile delle risorse (FlexRS): FlexRS riduce i costi di elaborazione batch del utilizzando tecniche di pianificazione avanzate, Dataflow Shuffle e da una combinazione di istanze VM prerilasciabile e VM normali.
Aggiorna pipeline di flusso in produzione
Consulta Eseguire l'upgrade di una pipeline di inserimento flussi.
Durata 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 seleziona il job da eseguire e tenta di avviarlo 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.
Una volta avviati, i worker Dataflow richiedono il lavoro il backend Dataflow. Il backend è responsabile della suddivisione il lavoro in blocchi parallelizzabili, chiamati set, distribuiti tra i worker. Se i worker non sono in grado di gestire lo stato e se la scalabilità automatica è abilitato, il backend avvia più worker per gestire il lavoro. Analogamente, se vengono avviati più worker del necessario, alcuni vengono chiusi verso il basso.
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 shuffle:
- Il piano dati viene eseguito sui worker Dataflow ed esegue lo shuffling i dati vengono archiviati su dischi permanenti.
- Il piano dati viene eseguito come servizio, esternamente alle VM worker. Questa implementazione ha due varianti, che specifichi quando crea il job: Dataflow Shuffle per le pipeline in modalità batch Motore di flussi di dati per le pipeline in modalità flusso. Lo shuffle basato su servizi migliora significativamente le prestazioni e la scalabilità delle operazioni di shuffling dei dati rispetto lo shuffling 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
dell'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 che ha una dipendenza critica dai servizi da più regioni, un errore in una qualsiasi di queste regioni può influire una pipeline o un blocco note personalizzato. Per evitare questo problema, esegui il deployment in più regioni per la ridondanza e il backup.
crea snapshot Dataflow
Dataflow offre una funzionalità di snapshot 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. Tu può quindi avviare la rielaborazione dei messaggi in Pub/Sub o Kafka a partire dal timestamp dello snapshot. Se configuri snapshot regolari delle pipeline, puoi ridurre al minimo i tempi di RTO (Recovery Time Objective).
Per ulteriori informazioni sugli snapshot Dataflow, consulta Usa gli snapshot Dataflow.
Gestire gli errori di invio del job
Invii job Dataflow non modello utilizzando l'SDK Apache Beam. Per inviare il job, devi esegui la pipeline utilizzando Dataflow Runner che viene specificato come parte del modello 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 API Modelli.
Potresti vedere errori diversi restituiti da Dataflow che indicano un errore per job modello 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 viene avviato a causa di un problema del servizio Dataflow, riprova il lavoro alcune volte. Un nuovo tentativo riduce il servizio temporaneo che le applicazioni presentino problemi di prestazioni.
Mitigazione degli errori a livello di zona specificando una regione 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
Dataflow per fornire un ulteriore livello di errore
per le tue pipeline scegliendo automaticamente la zona migliore possibile
per quel lavoro. 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 gli errori a livello di regione archiviando i dati in più regioni
Se un'intera regione non è disponibile, prova a eseguire il job in un'altra. È è importante considerare la disponibilità dei dati quando i job non vengono regioni. Per proteggerti da errori a livello di una singola regione senza copiare manualmente i dati in più regioni, usa le risorse Google Cloud che archiviano automaticamente in più regioni. Ad esempio, utilizza BigQuery località con più regioni per set di dati o Cloud Storage due regioni e più regioni bucket. 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 multiregionali con Dataflow, vedi Alta disponibilità e ridondanza geografica.
Gestire gli errori nelle pipeline in esecuzione
Dopo che un job è stato inviato e accettato, le uniche operazioni valide per sono i seguenti:
- annulla per job batch
- aggiornare, svuotare o annullare per i job di flussi di dati
Non puoi modificare la località 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 generato errori per 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 job non riusciti. Se un job non va a buon fine, ispeziona i log del job per identificare gli errori dei job causati da elementi di lavoro non riusciti che hanno superato le limite di nuovi tentativi.
Per i job di flussi, Dataflow tenta di nuovo gli elementi di lavoro non riusciti a tempo indeterminato. 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 il logging degli errori nel codice della pipeline per identificare più facilmente i blocchi 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 Dataflow, i backend vengono la migrazione automatica a una zona diversa dal servizio gestito, in modo che per continuare il job. Se il job utilizza Dataflow Shuffle, il backend non può essere spostato tra le zone. Se un backend Dataflow una migrazione, 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 potrebbero non riuscire o bloccarsi. Per i job batch, riavvia in un'altra regione, se possibile. È importante assicurarsi che i dati disponibili in diverse regioni.
Mitigare le interruzioni a livello di regione utilizzando l'alta disponibilità o il failover
Per i job di flussi di dati, a seconda della tolleranza di errore e del budget dell'applicazione, sono disponibili diverse opzioni per la mitigazione degli errori. Per una regione un'interruzione del servizio, l'opzione più semplice e conveniente è attendere l'interruzione termina il video. Tuttavia, se la tua applicazione sensibili alla latenza o se l'elaborazione dei dati non deve essere interrotta venga ripresa con un ritardo minimo, le sezioni seguenti illustrano le opzioni disponibili.
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. La le applicazioni downstream che dipendono dall'output di queste pipeline in grado di passare dall'output all'altro da queste due regioni. A causa della duplicazione di risorse, questa opzione comporta il costo più elevato rispetto ad altre opzioni. Per un esempio di deployment, consulta la sezione Alta disponibilità e ridondanza geografica.
Failover: sensibile alla latenza con una 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 e fare in modo che la pipeline utilizzi i dati della sottoscrizione di backup.
Guarda di nuovo l'abbonamento di backup a un periodo appropriato per ridurre al minimo la perdita di dati senza sacrificare la latenza. Le applicazioni downstream devono sapere come passare l'output della pipeline in esecuzione, in modo simile all'opzione ad alta disponibilità. Questo utilizza meno risorse rispetto all'esecuzione di pipeline duplicate perché solo duplicati.
Disponibilità elevata e ridondanza geografica
Puoi eseguire più pipeline di flusso in parallelo per dati ad alta disponibilità e l'elaborazione dei dati. Ad esempio, puoi eseguire due job di flussi di dati paralleli ridondanza geografica e tolleranza di errore per i dati. e 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 deployment di esempio.
Il diagramma mostra il seguente flusso:
Pub/Sub viene eseguito nella maggior parte delle regioni del mondo, il servizio offre un accesso rapido e globale ai dati, consentendoti di controllare in cui vengono archiviati i messaggi. Pub/Sub può archiviare automaticamente pubblicati nella regione Google Cloud più vicina a oppure puoi configurarlo in modo che utilizzi una regione o un insieme di regioni specifico utilizzando criteri di archiviazione dei messaggi.
Pub/Sub recapita quindi i messaggi ai sottoscrittori indipendentemente da dove sono archiviati i messaggi. Pub/Sub Non è necessario che i client siano a conoscenza delle posizioni dei server che si connettono poiché i meccanismi di bilanciamento del carico globale indirizzano il traffico all'unità più vicina Data center Google Cloud in cui sono archiviati i messaggi.
Dataflow viene eseguito in regioni di 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 un regione Google Cloud separata.
BigQuery fornisce località di set di dati a livello di una o più regioni. Quando scegli una località con più regioni, il set di dati si trova in almeno due regioni geografiche. Il diagramma mostra due pipeline separate, ciascuna scritta in un in un set di dati multiregionale.