Automatizzazione dei backup di BigQuery scalabile

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

Questa architettura fornisce un framework e un deployment di riferimento per aiutarti a sviluppare la tua strategia di backup di BigQuery. Questo framework consigliato e la sua automazione possono aiutare la tua organizzazione a:

• Rispetta gli obiettivi di ripristino di emergenza della tua organizzazione.
• Recupera i dati persi a causa di errori umani.
• Rispettare le normative.
• Migliorare l'efficienza operativa.

L'ambito dei dati di BigQuery può includere (o escludere) cartelle, progetti, set di dati e tabelle. Questa architettura consigliata mostra come automatizzare le operazioni di backup ricorrenti su larga scala. Puoi utilizzare due metodi di backup per ogni tabella: Snapshot di BigQuery ed Esportazioni di BigQuery in Cloud Storage.

Questo documento è destinato a cloud architect, engineer e responsabili della governance dei dati che vogliono definire e automatizzare i criteri dei dati nelle loro organizzazioni.

Architettura

Il seguente diagramma mostra l'architettura del backup automatico:

Il flusso di lavoro mostrato nel diagramma precedente include le seguenti fasi:

1. Cloud Scheduler attiva un'esecuzione al servizio di supervisore tramite un messaggio Pub/Sub, che contiene l'ambito dei dati BigQuery inclusi ed esclusi. Le esecuzioni vengono pianificate utilizzando un'espressione cron.
2. Il servizio di supervisore, basato su Cloud Run, utilizza l'API BigQuery per elencare le tabelle che rientrano nell'ambito di BigQuery.
3. Il servizio di supervisore invia una richiesta per ogni tabella al servizio configuratore tramite un messaggio Pub/Sub.

4. Il servizio di configurazione di Cloud Run calcola il criterio di backup della tabella da una delle seguenti opzioni definite:

   1. Il criterio a livello di tabella definito dai proprietari dei dati.
   2. Il criterio di fallback, definito dal responsabile della governance dei dati, per le tabelle che non hanno criteri definiti.

   Per maggiori dettagli sui criteri di backup, vedi Criteri di backup.

5. Il servizio di configurazione invia una richiesta per ogni tabella al servizio successivo, in base al criterio di backup calcolato.

6. A seconda del metodo di backup, uno dei seguenti servizi Cloud Run personalizzati invia una richiesta all'API BigQuery ed esegue il processo di backup:

   1. Il servizio per gli snapshot di BigQuery esegue il backup della tabella come snapshot.
   2. Il servizio per le esportazioni dei dati esegue il backup della tabella come esportazione dei dati in Cloud Storage.

7. Se il metodo di backup è un'esportazione di dati di tabelle, un sink di log di Cloud Logging ascolta gli eventi di completamento dei job di esportazione per abilitare l'esecuzione asincrona del passaggio successivo.

8. al termine delle operazioni, Pub/Sub attiva il servizio tagger.

9. Per ogni tabella, il servizio di tagger registra i risultati dei servizi di backup e aggiorna lo stato del backup nel livello dei metadati di Cloud Storage.

Prodotti utilizzati

Questa architettura di riferimento utilizza i seguenti Google Cloud prodotti:

• BigQuery: un data warehouse aziendale che ti aiuta a gestire e analizzare i tuoi dati con funzionalità integrate come l'analisi geospaziale di machine learning e la business intelligence.
• Cloud Logging: un sistema di gestione dei log in tempo reale con archiviazione, ricerca, analisi e avvisi.
• Pub/Sub: un servizio di messaggistica asincrono e scalabile che disaccoppia i servizi che producono messaggi dai servizi che li elaborano.
• Cloud Run: una piattaforma di computing serverless che consente di eseguire i container direttamente sull'infrastruttura scalabile di Google.
• Cloud Storage: un archivio di oggetti economico e senza limiti per diversi tipi di dati. È possibile accedere ai dati dall'interno e dall'esterno di Google Cloude sono replicati in più località per la ridondanza.
• Cloud Scheduler: uno scheduler di livello enterprise completamente gestito per la pianificazione di cron job, che consente di configurare unità di lavoro pianificate da eseguire a orari definiti o a intervalli regolari.
• Datastore: un database NoSQL a scalabilità elevata per le applicazioni web e mobile.

Casi d'uso

Questa sezione fornisce esempi di casi d'uso per i quali puoi utilizzare questa architettura.

Automazione backup

Ad esempio, la tua azienda potrebbe operare in un settore regolamentato e utilizzare BigQuery come data warehouse principale. Anche se la tua azienda segue le best practice nello sviluppo del software, nella revisione del codice e nella release engineering, sussiste comunque il rischio di perdita o danneggiamento dei dati a causa di errori umani. In un settore regolamentato, è necessario minimizzare questo rischio il più possibile.

Ecco alcuni esempi di questi errori umani:

• Eliminazione accidentale delle tabelle.
• I dati sono danneggiati a causa di un'errata logica della pipeline di dati.

Questi tipi di errori umani possono essere risolti in genere con la funzionalità viaggio nel tempo, che consente di recuperare i dati degli ultimi sette giorni. Inoltre, BigQuery offre anche un periodo di fail-safe, durante il quale i dati eliminati vengono conservati in uno spazio di archiviazione sicuro per altri sette giorni dopo la finestra di spostamento cronologico. Questi dati sono disponibili per il recupero di emergenza tramite l'assistenza clienti Google Cloud. Tuttavia, se la tua azienda non rileva e non corregge questi errori entro questo periodo di tempo combinato, i dati eliminati non sono più recuperabili dal loro ultimo stato stabile.

Per mitigare questo problema, ti consigliamo di eseguire backup regolari per tutte le tabelle BigQuery che non possono essere ricostruite a partire dai dati di origine, ad esempio record storici o KPI con una logica di business in continua evoluzione.

La tua azienda potrebbe utilizzare script di base per eseguire il backup di decine di tabelle. Tuttavia, se devi eseguire regolarmente il backup di centinaia o migliaia di tabelle in tutta l'organizzazione, hai bisogno di una soluzione di automazione scalabile in grado di:

• Gestisci diversi Google Cloud limiti delle API.
• Fornisci un framework standardizzato per la definizione dei criteri di backup.
• Offrono funzionalità di trasparenza e monitoraggio per le operazioni di backup.

Policy di backup

La tua azienda potrebbe anche richiedere che i criteri di backup siano definiti dai seguenti gruppi di persone:

• I proprietari dei dati, che hanno più familiarità con le tabelle e possono impostare i criteri di backup a livello di tabella appropriati.
• Team di governance dei dati, che si assicura che sia applicato un criterio di riserva per coprire le tabelle che non dispongono di un criterio a livello di tabella. Il criterio di fallback garantisce che venga eseguito il backup di alcuni set di dati, progetti e cartelle in modo da rispettare le normative sulla conservazione dei dati della tua azienda.

Nel deployment di questa architettura di riferimento, esistono due modi per definire i criteri di backup per le tabelle e possono essere utilizzati insieme:

• Configurazione del proprietario dei dati (decentralizzata): un criterio di backup a livello di tabella collegato manualmente a una tabella.

  • Il proprietario dei dati definisce un file JSON a livello di tabella archiviato in un bucket comune.
  • I criteri manuali hanno la precedenza sui criteri di riserva quando la soluzione determina il criterio di backup di una tabella.
  • Per maggiori dettagli sul deployment, vedi Impostare i criteri di backup a livello di tabella.

• Configurazione predefinita dell'organizzazione (centralizzata): un criterio di riserva, che si applica solo alle tabelle che non hanno criteri collegati manualmente.

  • Un team di governance dei dati definisce un file JSON centrale in Terraform, come parte della soluzione.
  • Il criterio di fallback offre strategie di backup predefinite a livello di cartella, progetto, set di dati e tabella.
  • Per maggiori dettagli sul deployment, consulta Definire i criteri per il backup di riserva.

Backup e replica

Un processo di backup crea una copia dei dati della tabella da un determinato momento in modo che possano essere ripristinati in caso di perdita o danneggiamento dei dati. I backup possono essere eseguiti come occorrenza una tantum o in modo ricorrente (tramite una query o un flusso di lavoro pianificati). In BigQuery, i backup point-in-time possono essere realizzati con snapshot. Puoi utilizzare gli snapshot per conservare copie dei dati oltre il periodo di viaggio cronologico di sette giorni all'interno della stessa località di archiviazione dei dati di origine. Gli snapshot BigQuery sono particolarmente utili per recuperare i dati in seguito a errori umani che causano la perdita o il danneggiamento dei dati, anziché recuperare in caso di errori a livello di regione. BigQuery offre un obiettivo del livello di servizio (SLO) compreso tra 99,9% e 99,99%, a seconda della versione.

Al contrario, la replica è il processo continuo di copia delle modifiche del database in un database secondario (o di replica) in una località diversa. In BigQuery, la replica tra regioni può contribuire a fornire la ridondanza geografica creando copie di sola lettura dei dati in Google Cloud regioni secondarie, diverse da quella dei dati di origine. Tuttavia, la replica tra regioni di BigQuery non è destinata a essere utilizzata come piano di ripristino di emergenza per gli scenari di interruzione totali a livello di regioni. Per la resilienza contro i disastri regionali, valuta l'utilizzo del ripristino di emergenza gestito da BigQuery.

La replica tra regioni di BigQuery fornisce una copia sincronizzata di sola lettura dei dati in una regione vicina ai consumer dei dati. Queste copie di dati consentono i join collocati ed evitano costi e traffico tra regioni. Tuttavia, in caso di dati danneggiati a causa di un errore umano, la replica da sola non è utile per il ripristino, perché i dati danneggiati vengono copiati automaticamente nella replica. In questi casi, i backup point-in-time (snapshot) sono una scelta migliore.

La tabella seguente mostra un confronto riepilogativo dei metodi e della replica di backup:

Metodo	Frequenza	Località di archiviazione	Casi d'uso	Costi
Backup (esportazione di snapshot o Cloud Storage)	Una volta o periodicamente	Uguale ai dati della tabella di origine	Ripristinare i dati originali, oltre il periodo di spostamento cronologico	Gli snapshot sono soggetti a costi di archiviazione solo per le modifiche dei dati nello snapshot Le esportazioni possono essere soggette a costi di archiviazione standard Consulta Ottimizzazione dei costi
Replica tra regioni	In modo continuativo	Remoto	Crea una replica in un'altra regione Migrazioni una tantum tra regioni	Comporta addebiti per l'archiviazione dei dati nella replica Prevede costi di replica dei dati

Note sul layout

Questa sezione fornisce indicazioni da considerare quando utilizzi questa architettura di riferimento per sviluppare una topologia che soddisfi i tuoi requisiti specifici di sicurezza, affidabilità, ottimizzazione dei costi, efficienza operativa e prestazioni.

Sicurezza, privacy e conformità

Nella progettazione e nell'implementazione del deployment sono incluse le seguenti misure di sicurezza:

• L'impostazione In entrata nella rete per Cloud Run accetta solo traffico interno per limitare l'accesso da internet. Inoltre, consente solo agli utenti e agli account di servizio autenticati di chiamare i servizi.
• Ogni servizio Cloud Run e abbonamento Pub/Sub utilizza un account di servizio separato a cui sono assegnate solo le autorizzazioni richieste. Ciò riduce i rischi associati all'utilizzo di un account di servizio per il sistema e segue il principio del privilegio minimo.

Per considerazioni sulla privacy, la soluzione non raccoglie né elabora informazioni che consentono l'identificazione personale (PII). Tuttavia, se le tabelle di origine contengono PII esposte, i backup eseguiti per queste tabelle includono anche questi dati esposti. Il proprietario dei dati di origine è responsabile della protezione di tutte le PII nelle tabelle di origine (ad esempio, applicando la sicurezza a livello di colonna, il mascheramento dei dati o l'oscuramento). I backup sono sicuri solo quando i dati di origine sono protetti. Un altro approccio consiste nell'assicurarsi che i progetti, i set di dati o i bucket contenenti dati di backup con PII esposte dispongano dei criteri IAM (Identity and Access Management) richiesti che limitano l'accesso solo agli utenti autorizzati.

Essendo una soluzione per uso generico, il deployment di riferimento non è necessariamente conforme ai requisiti specifici di un determinato settore.

Affidabilità

Questa sezione descrive le funzionalità e le considerazioni sulla progettazione per l'affidabilità.

Mitigazione degli errori con granularità

Per eseguire backup di migliaia di tabelle, è probabile che tu possa raggiungere i limiti delle API per i prodotti Google Cloud sottostanti (ad esempio, limiti operativi di snapshot ed esportazione per ciascun progetto). Tuttavia, se il backup di una tabella non va a buon fine a causa di una configurazione errata o di altri problemi temporanei, ciò non dovrebbe influire sull'esecuzione complessiva e sulla capacità di eseguire il backup di altre tabelle.

Per ridurre i potenziali errori, il deployment di riferimento disaccoppia le fasi di elaborazione mediante l'uso di servizi granulari di Cloud Run e la connessione tramite Pub/Sub. Se una richiesta di backup della tabella non va a buon fine durante il passaggio di servizio del tagger finale, Pub/Sub riprova solo a questo passaggio senza ripetere l'intero processo.

La suddivisione del flusso in più servizi Cloud Run, invece che in più endpoint ospitati in un unico servizio Cloud Run, consente di fornire un controllo granulare di ciascuna configurazione del servizio. Il livello di configurazione dipende dalle funzionalità del servizio e dalle API con cui comunica. Ad esempio, il servizio di supervisore viene eseguito una volta per ogni esecuzione, ma richiede molto tempo per elencare tutte le tabelle all'interno dell'ambito del backup di BigQuery. Di conseguenza, il servizio di supervisore richiede impostazioni di timeout e di memoria maggiori. Tuttavia, il servizio Cloud Run per gli snapshot BigQuery viene eseguito una volta per tabella in un'unica esecuzione e viene completato in meno tempo rispetto al servizio di supervisore. Pertanto, il servizio Cloud Run richiede un set di configurazioni diverso a livello di servizio.

Coerenza dei dati

La coerenza dei dati tra tabelle e viste è fondamentale per mantenere una strategia di backup affidabile. Poiché i dati vengono aggiornati e modificati continuamente, i backup eseguiti in momenti diversi potrebbero acquisire stati diversi del set di dati. Questi backup in stati diversi possono causare incoerenze durante il ripristino dei dati, in particolare per le tabelle che appartengono allo stesso set di dati funzionale. Ad esempio, il ripristino di una tabella delle vendite in un momento diverso da quella della corrispondente tabella dell'inventario potrebbe creare una mancata corrispondenza delle scorte disponibili. Allo stesso modo, le viste del database che aggregano i dati di più tabelle possono essere particolarmente sensibili alle incoerenze. Il ripristino di queste viste senza garantire che le tabelle sottostanti siano in uno stato coerente potrebbe portare a risultati imprecisi o fuorvianti. Pertanto, quando progetti le frequenze e i criteri di backup di BigQuery, è fondamentale considerare questa coerenza e garantire che i dati ripristinati riflettano accuratamente lo stato reale del set di dati in un determinato momento.

Ad esempio, nel deployment di questa architettura di riferimento, la coerenza dei dati viene controllata attraverso le due configurazioni seguenti nei criteri di backup. Queste configurazioni calcolano il tempo esatto di snapshot delle tabelle attraverso i viaggi cronologici, senza necessariamente eseguire il backup di tutte le tabelle contemporaneamente.

• backup_cron: controlla la frequenza con cui viene eseguito il backup di una tabella. Il timestamp di inizio di un'esecuzione viene utilizzato come punto di riferimento per il calcolo del viaggio nel tempo per tutte le tabelle di cui è stato eseguito il backup in questa esecuzione.
• backup_time_travel_offset_days: controlla quanti giorni nel passato devono essere sottratti dal punto di riferimento temporale (ora di inizio dell'esecuzione), per calcolare la versione esatta dello spostamento cronologico della tabella.

Ripristino del backup automatico

Sebbene questa architettura di riferimento si concentri sull'automazione dei backup su larga scala, puoi valutare di ripristinare anche questi backup in modo automatico. Questa automazione aggiuntiva può fornire vantaggi simili a quelli dell'automazione del backup, tra cui una migliore efficienza e velocità del ripristino, con meno tempi di inattività. Poiché la soluzione tiene traccia di tutti i parametri e i risultati di backup tramite il servizio di tagger, potresti sviluppare un'architettura simile per applicare le operazioni di ripristino su larga scala.

Ad esempio, potresti creare una soluzione basata su un trigger on demand che invia un ambito di dati BigQuery a un servizio di supervisore, che invia una richiesta per tabella a un servizio di configurazione. Il servizio di configurazione potrebbe recuperare la cronologia del backup che vuoi ottenere per una determinata tabella. Il servizio di configurazione potrebbe quindi passarlo a un servizio di ripristino di snapshot BigQuery o a un servizio di ripristino di Cloud Storage per applicare l'operazione di ripristino di conseguenza. Infine, un servizio tagger potrebbe archiviare i risultati di queste operazioni in un archivio di stato. In questo modo, il framework di ripristino automatico può trarre vantaggio dagli stessi obiettivi di progettazione del framework di backup descritto in questo documento.

Ottimizzazione dei costi

Il framework di questa architettura fornisce criteri di backup che impostano i seguenti parametri per l'ottimizzazione complessiva dei costi:

• Metodo di backup: il framework offre i seguenti due metodi di backup:
  • Snapshot di BigQuery, che comportano costi di archiviazione in base ai dati aggiornati ed eliminati rispetto alla tabella di base. Di conseguenza, gli snapshot sono più convenienti per le tabelle di sola aggiunta o con aggiornamenti limitati.
  • BigQuery esegue le esportazioni in Cloud Storage, che prevede i costi di archiviazione standard. Tuttavia, per le tabelle di grandi dimensioni che seguono un approccio di troncamento e caricamento, è più conveniente eseguirle come esportazioni in classi di archiviazione meno costose.
• Scadenza dello snapshot: la durata (TTL) è impostata per un singolo snapshot di tabella, per evitare di incorrere in costi di archiviazione per lo snapshot a tempo indeterminato. Se le tabelle non hanno scadenza, i costi di archiviazione possono aumentare nel tempo.

Efficienza operativa

Questa sezione descrive le funzionalità e le considerazioni relative all'efficienza operativa.

Criteri di backup granulari e scalabili

Uno degli obiettivi di questo framework è l'efficienza operativa attraverso lo scale up dell'output aziendale, mantenendo l'input aziendale relativamente basso e gestibile. Ad esempio, l'output è un numero elevato di tabelle di cui viene eseguito regolarmente il backup, mentre l'input è un numero ridotto di criteri e configurazioni di backup mantenuti.

Oltre a consentire i criteri di backup a livello di tabella, il framework consente anche criteri a livello di set di dati, progetto, cartella e globale. Ciò significa che con alcune configurazioni a livelli superiori (ad esempio, a livello di cartella o progetto), è possibile eseguire regolarmente il backup di centinaia o migliaia di tabelle su larga scala.

Osservabilità

Con un framework di automazione, è fondamentale comprendere lo stato dei processi. Ad esempio, dovresti essere in grado di trovare le informazioni per le seguenti query comuni:

• Il criterio di backup utilizzato dal sistema per ogni tabella.
• La cronologia dei backup e le località di backup di ogni tabella.
• Lo stato complessivo di una singola esecuzione (il numero di tabelle elaborate e non riuscite).
• Gli errori irreversibili che si sono verificati in una singola esecuzione e i componenti o i passaggi del processo in cui si sono verificati.

Per fornire queste informazioni, il deployment scrive log strutturati in Cloud Logging a ogni passaggio di esecuzione che utilizza un servizio Cloud Run. I log includono input, output ed errori, insieme ad altri punti di controllo di avanzamento. Un sink di log instrada questi log a una tabella BigQuery. Puoi eseguire una serie di query per monitorare le esecuzioni e ottenere report per casi d'uso comuni di osservabilità. Per ulteriori informazioni su log e query in BigQuery, consulta Visualizzare i log indirizzati a BigQuery.

Ottimizzazione delle prestazioni

Per gestire migliaia di tabelle a ogni esecuzione, la soluzione elabora le richieste di backup in parallelo. Il servizio di supervisore elenca tutte le tabelle incluse nell'ambito del backup di BigQuery e genera una richiesta di backup per tabella a ogni esecuzione. Ciò consente all'applicazione di elaborare migliaia di richieste e tabelle in parallelo, non in sequenza.

Alcune di queste richieste potrebbero inizialmente non riuscire per motivi temporanei come il raggiungimento dei limiti delle API Google Cloud sottostante o si stanno verificando problemi di rete. Finché non vengono completate, Pub/Sub ritenta automaticamente le richieste con il criterio per i nuovi tentativi con backoff esponenziale. Se si verificano errori irreversibili, come destinazioni di backup non valide o autorizzazioni mancanti, gli errori vengono registrati e l'esecuzione di quella specifica richiesta di tabella viene terminata senza influire sull'esecuzione complessiva.

Limiti

A questa architettura si applicano le quote e i limiti seguenti.

Per gli snapshot delle tabelle, quanto segue si applica a ogni progetto delle operazioni di backup specificato:

• Un progetto può eseguire fino a 100 job simultanei di snapshot delle tabelle.
• Un progetto può eseguire fino a 50.000 job di snapshot delle tabelle al giorno.
• Un progetto può eseguire fino a 50 job di snapshot della tabella per tabella al giorno.

Per maggiori dettagli, consulta Snapshot delle tabelle.

Per i job di esportazione (esportazioni in Cloud Storage), si applica quanto segue:

• Puoi esportare gratuitamente fino a 50 TiB di dati al giorno da un progetto utilizzando il pool di slot condiviso.
• Un progetto può eseguire fino a 100.000 esportazioni al giorno. Per estendere questo limite, crea una prenotazione di slot.

Per ulteriori informazioni sull'estensione di questi limiti, consulta Job di esportazione.

Per quanto riguarda i limiti di contemporaneità, questa architettura utilizza Pub/Sub per riprovare automaticamente le richieste non riuscite a causa di questi limiti, finché non vengono gestite dall'API. Tuttavia, per altri limiti sul numero di operazioni per progetto al giorno, questi potrebbero essere mitigati da una richiesta di aumento delle quote o dalla distribuzione delle operazioni di backup (snapshot o esportazioni) su più progetti. Per distribuire le operazioni tra i progetti, configura i criteri di backup come descritto nelle seguenti sezioni sul deployment:

• Definisci i criteri di backup di riserva
• Configura progetti aggiuntivi per le operazioni di backup
• Imposta i criteri di backup a livello di tabella

Deployment

Per eseguire il deployment di questa architettura, consulta Eseguire il deployment dell'automazione scalabile del backup di BigQuery.

Passaggi successivi

• Scopri di più su BigQuery:
  • Snapshot delle tabelle BigQuery
  • Esportazioni delle tabelle BigQuery in Cloud Storage
• Per altre architetture di riferimento, diagrammi e best practice, visita il Centro architetture di Google Cloud.

Collaboratori

Autore: Karim Wadie | Strategic Cloud Engineer

Altri collaboratori:

• Chris DeForeest | Site Reliability Engineer
• Eyal Ben Ivri | Cloud Solutions Architect
• Jason Davenport | Consulente per gli sviluppatori
• Jaliya Ekanayake | Engineering Manager
• Muhammad Zain | Strategic Cloud Engineer