Automatizzazione dei backup di BigQuery scalabile

Last reviewed 2024-09-17 UTC

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.
  • Recuperare i dati persi a causa di errori umani.
  • Rispettare le normative.
  • Migliorare l'efficienza operativa.

L'ambito dei dati 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 BigQuery ed esportazioni BigQuery in Cloud Storage.

Questo documento è destinato ad architetti, ingegneri e responsabili della governance dei dati cloud che vogliono definire e automatizzare i criteri per i dati nelle loro organizzazioni.

Architettura

Il seguente diagramma mostra l'architettura del backup automatico:

Architettura della soluzione di backup automatizzato.

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

  1. Cloud Scheduler attiva un'esecuzione del servizio dispatcher 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 distribuzione, basato su Cloud Run, utilizza l'API BigQuery per elencare le tabelle che rientrano nell'ambito di BigQuery.
  3. Il servizio dispatcher invia una richiesta per ogni tabella al servizio configuratore tramite un messaggio Pub/Sub.

  4. Il servizio di configurazione di Cloud Run calcola la norma 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 riserva, definito dal responsabile della governance dei dati, per le tabelle per cui non sono stati definiti criteri.

    Per informazioni dettagliate sulle policy di backup, consulta Policy di backup.

  5. Il servizio di configurazione invia una richiesta per ogni tabella al servizio successivo, in base alla policy di backup calcolata.

  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 BigQuery esegue il backup della tabella come snapshot.
    2. Il servizio per le esportazioni di dati esegue il backup della tabella come esportazione di dati in Cloud Storage.

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

  8. Una volta completate le operazioni dei servizi di backup, Pub/Sub attiva il servizio di tagging.

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

Prodotti utilizzati

Questa architettura di riferimento utilizza i seguenti prodotti Google Cloud :

  • BigQuery: un data warehouse aziendale che ti aiuta a gestire e analizzare i dati con funzionalità integrate come machine learning, analisi geospaziale e 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 da quelli che li elaborano.
  • Cloud Run: una piattaforma di computing serverless che ti consente di eseguire container direttamente sull'infrastruttura scalabile di Google.
  • Cloud Storage: uno spazio di archiviazione di oggetti a basso costo e senza limiti per diversi tipi di dati. I dati sono accessibili dall'interno e dall'esterno di Google Cloude vengono replicati in più località per la ridondanza.
  • Cloud Scheduler: un servizio 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 del backup

Ad esempio, la tua azienda potrebbe operare in un settore regolamentato e utilizzare BigQuery come data warehouse principale. Anche quando la tua azienda segue le best practice nello sviluppo di software, nella revisione del codice e nell'ingegneria di rilascio, esiste comunque il rischio di perdita o danneggiamento dei dati a causa di errori umani. In un settore regolamentato, devi ridurre al minimo questo rischio il più possibile.

Ecco alcuni esempi di questi errori umani:

  • Eliminazione accidentale delle tabelle.
  • Danneggiamento dei dati dovuto a una logica errata della pipeline di dati.

Questi tipi di errori umani possono in genere essere risolti con la funzionalità Time Travel, che consente di recuperare i dati di un massimo di sette giorni prima. Inoltre, BigQuery offre anche un periodo di sicurezza, durante il quale i dati eliminati vengono conservati in uno spazio di archiviazione di sicurezza per altri sette giorni dopo il periodo di time travel. Questi dati sono disponibili per il ripristino di emergenza tramite l'assistenza clienti Google Cloud. Tuttavia, se la tua azienda non rileva e 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 dai dati di origine (ad esempio, record storici o KPI con logica di business in 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 limiti dell'API Google Cloud .
  • Fornire un framework standardizzato per definire le policy di backup.
  • Fornire funzionalità di trasparenza e monitoraggio per le operazioni di backup.

Policy di backup

La tua azienda potrebbe anche richiedere che le norme di backup siano definite dai seguenti gruppi di persone:

  • I proprietari dei dati, che conoscono meglio le tabelle e possono impostare le norme di backup a livello di tabella appropriate.
  • Il team di governance dei dati, che si assicura che sia in vigore un criterio di riserva per coprire tutte le tabelle che non hanno un criterio a livello di tabella. Il criterio di fallback garantisce il backup di determinati set di dati, progetti e cartelle per rispettare le normative di conservazione dei dati della tua azienda.

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

  • Configurazione del proprietario dei dati (decentralizzata): una norma di backup a livello di tabella, che viene allegata manualmente a una tabella.

    • Il proprietario dei dati definisce un file JSON a livello di tabella archiviato in un bucket comune.
    • Le policy manuali hanno la precedenza sulle policy di riserva quando la soluzione determina la policy di backup di una tabella.
    • Per i dettagli sull'implementazione, vedi Impostare criteri di backup a livello di tabella.

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

    • 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 i dettagli sul deployment, vedi Definisci le policy di backup di fallback.

Backup e replica

Un processo di backup crea una copia dei dati della tabella da un determinato momento, in modo che possa essere ripristinata in caso di perdita o danneggiamento dei dati. I backup possono essere eseguiti una sola volta o in modo ricorrente (tramite una query o un flusso di lavoro pianificato). In BigQuery, i backup point-in-time possono essere eseguiti con gli snapshot. Puoi utilizzare gli snapshot per conservare copie dei dati oltre il periodo di sette giorni di Time Travel nella stessa posizione di archiviazione dei dati di origine. Gli snapshot BigQuery sono particolarmente utili per il recupero dei dati in seguito a errori umani che causano perdita o danneggiamento dei dati, anziché per il ripristino da errori regionali. BigQuery offre un obiettivo del livello di servizio (SLO) compreso tra il 99,9% e il 99,99%, a seconda della versione.

Al contrario, la replica è il processo continuo di copia delle modifiche al 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 nelle regioni Google Cloud secondarie, diverse dalla regione di origine dei dati. Tuttavia, la replica tra regioni di BigQuery non è pensata per essere utilizzata come piano di ripristino di emergenza per scenari di interruzione totale della regione. Per la resilienza ai disastri regionali, valuta la possibilità di utilizzare il recupero 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 consumatori di dati. Queste copie dei dati consentono unioni collocate ed evitano traffico e costi interregionali. Tuttavia, in caso di danneggiamento dei dati dovuto a errore umano, la sola replica non può aiutare il recupero, 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 di backup e replica:

Metodo Frequenza Località di archiviazione Casi d'uso Costi
Backup

(snapshot o esportazione di Cloud Storage)		 Una tantum o in modo ricorrente Uguale ai dati della tabella di origine Ripristinare i dati originali oltre il periodo di spostamento nel tempo Gli snapshot comportano costi di archiviazione solo per le modifiche ai dati nello snapshot

Le esportazioni possono comportare costi di archiviazione standard

Consulta Ottimizzazione dei costi
Replica tra regioni Continuamente Remoto Crea una replica in un'altra regione

Migrazioni una tantum tra regioni		 Comporta costi per l'archiviazione dei dati nella replica

Comporta costi di replica dei dati

Considerazioni sulla progettazione

Questa sezione fornisce indicazioni da prendere in considerazione 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à

L'implementazione incorpora le seguenti misure di sicurezza nella sua progettazione e implementazione:

  • L'impostazione Ingress di rete per Cloud Run accetta solo il traffico interno, per limitare l'accesso da internet. Consente inoltre solo a utenti autenticati e service account 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. In questo modo si riducono i rischi associati all'utilizzo di un account di servizio per il sistema e si segue il principio del privilegio minimo.

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

In quanto soluzione generica, il deployment di riferimento non soddisfa necessariamente i requisiti specifici di un determinato settore.

Affidabilità

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

Mitigazione degli errori con granularità

Per eseguire backup di migliaia di tabelle, è probabile che tu raggiunga i limiti API per i prodotti Google Cloud sottostanti (ad esempio, i limiti delle operazioni di snapshot e di esportazione per ogni 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 possibilità di eseguire il backup di altre tabelle.

Per ridurre i potenziali errori, il deployment di riferimento disaccoppia i passaggi di elaborazione utilizzando servizi Cloud Run granulari e collegandoli tramite Pub/Sub. Se una richiesta di backup della tabella non riesce nell'ultimo passaggio del servizio di tagging, Pub/Sub riprova solo questo passaggio e non l'intera procedura.

La suddivisione del flusso in più servizi Cloud Run, anziché in più endpoint ospitati in un unico servizio Cloud Run, consente di fornire un controllo granulare della configurazione di ogni servizio. Il livello di configurazione dipende dalle funzionalità del servizio e dalle API con cui comunica. Ad esempio, il servizio dispatcher viene eseguito una volta per esecuzione, ma richiede molto tempo per elencare tutte le tabelle nell'ambito del backup BigQuery. Pertanto, il servizio di distribuzione richiede impostazioni di timeout e memoria più elevate. Tuttavia, il servizio Cloud Run per gli snapshot BigQuery viene eseguito una volta per tabella in una singola esecuzione e viene completato in meno tempo rispetto al servizio dispatcher. Pertanto, il servizio Cloud Run richiede un insieme diverso di configurazioni 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 continuamente aggiornati e modificati, 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 a un punto nel tempo diverso dalla tabella dell'inventario corrispondente potrebbe creare una mancata corrispondenza delle scorte disponibili. Allo stesso modo, le viste del database che aggregare i dati di più tabelle possono essere particolarmente sensibili alle incoerenze. Il ripristino di queste viste senza assicurarsi che le tabelle sottostanti si trovino in uno stato coerente potrebbe portare a risultati imprecisi o fuorvianti. Pertanto, quando progetti le politiche e le frequenze di backup di BigQuery, è fondamentale considerare questa coerenza e assicurarti che i dati ripristinati riflettano accuratamente lo stato reale del tuo set di dati in un determinato momento.

Ad esempio, nel deployment di questa architettura di riferimento, la coerenza dei dati è controllata tramite le seguenti due configurazioni nelle norme di backup. Queste configurazioni calcolano l'ora esatta dello snapshot della tabella tramite time travel, 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 time travel per tutte le tabelle di cui viene eseguito il backup in questa esecuzione.
  • backup_time_travel_offset_days: controlla quanti giorni nel passato devono essere sottratti dal punto di riferimento nel tempo (ora di inizio della corsa) per calcolare la versione esatta della tabella nel tempo.

Ripristino automatico del backup

Sebbene questa architettura di riferimento si concentri sull'automazione del backup su larga scala, puoi anche prendere in considerazione il ripristino di questi backup in modo automatico. Questa automazione aggiuntiva può fornire vantaggi simili a quelli dell'automazione di backup, tra cui una maggiore efficienza e velocità di ripristino, con meno tempi di inattività. Poiché la soluzione tiene traccia di tutti i parametri e i risultati del backup tramite il servizio di tagging, 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 dispatcher, che invia una richiesta per tabella a un servizio di configurazione. Il servizio di configurazione potrebbe recuperare la cronologia dei backup che ti interessa per una determinata tabella. Il servizio di configurazione potrebbe quindi trasmetterlo a un servizio di ripristino degli snapshot BigQuery o a un servizio di ripristino di Cloud Storage per applicare l'operazione di ripristino di conseguenza. Infine, un servizio di tagging potrebbe archiviare i risultati di queste operazioni in uno store di stato. In questo modo, il framework di ripristino automatico può trarre vantaggio dagli stessi obiettivi di progettazione del framework di backup descritti 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 BigQuery, che comportano costi di archiviazione in base ai dati aggiornati ed eliminati rispetto alla tabella di base. Pertanto, gli snapshot sono più convenienti per le tabelle di sola aggiunta o con aggiornamenti limitati.
    • Esportazioni BigQuery in Cloud Storage, che comportano addebiti standard per l'archiviazione. Tuttavia, per le tabelle di grandi dimensioni che seguono un approccio di troncamento e caricamento, è più conveniente eseguire il backup come esportazioni in classi di archiviazione meno costose.
  • Scadenza snapshot: la durata (TTL) è impostata per un singolo snapshot della tabella, per evitare di sostenere costi di archiviazione per lo snapshot a tempo indeterminato. I costi di archiviazione possono aumentare nel tempo se le tabelle non hanno una scadenza.

Efficienza operativa

Questa sezione descrive le funzionalità e le considerazioni per l'efficienza operativa.

Policy di backup granulari e scalabili

Uno degli obiettivi di questo framework è l'efficienza operativa, aumentando l'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 configurazioni e policy di backup gestite.

Oltre a consentire le norme di backup a livello di tabella, il framework consente anche le norme a livello di set di dati, progetto, cartella e globale. Ciò significa che con poche 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 gli stati dei processi. Ad esempio, dovresti essere in grado di trovare le informazioni per le seguenti query comuni:

  • La policy di backup utilizzata dal sistema per ogni tabella.
  • La cronologia dei backup e le posizioni di backup di ogni tabella.
  • Lo stato generale 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, oltre ad altri checkpoint 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 i 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 invio elenca tutte le tabelle incluse nell'ambito del backup 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 andare a buon fine per motivi temporanei, ad esempio raggiungimento dei limiti delle API Google Cloud sottostanti o problemi di rete. Finché le richieste non vengono completate, Pub/Sub ritenta automaticamente le richieste con il criterio di ripetizione con backoff esponenziale. Se si verificano errori irreversibili come destinazioni di backup non valide o autorizzazioni mancanti, gli errori vengono registrati e l'esecuzione della richiesta di tabella specifica viene interrotta 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 di operazione di backup che specifichi:

  • Un progetto può eseguire fino a 100 job di snapshot di tabelle simultanei.
  • 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 di tabelle per tabella al giorno.

Per informazioni dettagliate, vedi 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 riserva slot.

Per saperne di più sull'estensione di questi limiti, consulta Job di esportazione.

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

Deployment

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

Passaggi successivi

Collaboratori

Autore: Karim Wadie | Strategic Cloud Engineer

Altri collaboratori: