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 relativa 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.
  • Migliora 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 eseguire automaticamente le operazioni di backup ricorrenti su larga scala. Puoi utilizzare due metodi di backup per ogni tabella: gli snapshot di BigQuery e le esportazioni di BigQuery in Cloud Storage.

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

Architettura

Il seguente diagramma mostra l'architettura del backup automatico:

Architettura della soluzione di backup automatico.

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

  1. Cloud Scheduler attiva un'esecuzione del servizio di accodamento tramite un messaggio Pub/Sub, che contiene l'ambito dei dati BigQuery inclusi e esclusi. Le esecuzioni vengono pianificate utilizzando un'espressione CRON.
  2. Il servizio di smistamento, basato su Cloud Run, utilizza l'API BigQuery per elencare le tabelle che rientrano nell'ambito di BigQuery.
  3. Il servizio di invio invia una richiesta per ogni tabella al servizio di configurazione 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 riserva, definito dall'ufficiale di gestione dei dati, per le tabelle che non hanno criteri definiti.

    Per informazioni dettagliate sui criteri di backup, consulta 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. Quando il metodo di backup è un'esportazione dei dati di una tabella, un destinatario log Cloud Logging ascolta gli eventi di completamento dei job di esportazione per abilitare 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 consente di disaccoppiare i servizi che producono messaggi da quelli che li elaborano.
  • Cloud Run: una piattaforma di calcolo 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 Cloud e vengono replicati in più località per garantire la ridondanza.
  • Cloud Scheduler: un programmatore di cron job di livello enterprise completamente gestito 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.

Automatizzazione del 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 per lo sviluppo software, la revisione del codice e l'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.

Ecco alcuni esempi di errori umani:

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

Questi tipi di errori umani in genere possono essere risolti con la funzionalità di viaggio nel tempo, che consente di recuperare i dati fino a sette giorni prima. Inoltre, BigQuery offre anche un periodo di sicurezza, durante il quale i dati eliminati vengono conservati nello spazio di archiviazione di sicurezza per altri sette giorni dopo la finestra di viaggio nel tempo. Questi dati sono disponibili per il recupero di emergenza tramite l'assistenza clienti Google Cloud. Tuttavia, se la tua azienda non scopre 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 regolarmente i backup di tutte le tabelle BigQuery che non possono essere ricostruite dai dati di origine (ad esempio, record storici o KPI con logica aziendale 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 nell'organizzazione, hai bisogno di una soluzione di automazione scalabile in grado di:

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

Criteri di backup

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

  • I proprietari dei dati, che hanno maggiore familiarità con le tabelle e possono impostare i criteri di backup a livello di tabella appropriati.
  • Il team di governance dei dati, che si assicura che sia stato implementato un criterio di riserva per coprire tutte le tabelle che non dispongono di un criterio a livello di tabella. Il criterio di riserva garantisce che venga eseguito il backup di determinati set di dati, progetti e cartelle per 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, che possono essere utilizzati insieme:

  • Configurazione del proprietario dei dati (decentralizzata): un criterio di backup a livello di tabella, che viene 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 informazioni dettagliate sul deployment, consulta 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 riserva offre strategie di backup predefinite a livello di cartella, progetto, set di dati e tabella.
    • Per informazioni dettagliate sul deployment, consulta Definire i criteri di backup di riserva.

Backup e replica

Un processo di backup crea una copia dei dati della tabella da un determinato punto in tempo, in modo che possano essere ripristinati se i dati vengono persi o danneggiati. I backup possono essere eseguiti come evento una tantum 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 le copie dei dati oltre il periodo di sette giorni del viaggio nel tempo all'interno della stessa posizione di archiviazione dei dati di origine. Gli snapshot di BigQuery sono particolarmente utili per recuperare i dati dopo errori umani che causano perdita o danneggiamento dei dati, piuttosto che ripristinare i dati dopo errori regionali. BigQuery offre un obiettivo di livello del 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 replica) in una posizione diversa. In BigQuery, la replica tra regioni può contribuire a fornire ridondanza geografica creando copie di sola lettura dei dati nelle regioni Google Cloud secondarie, diverse dalla regione dei dati di origine. Tuttavia, la replica tra regioni di BigQuery non è prevista per l'utilizzo come piano di ripristino di emergenza per scenari di interruzione della regione totale. Per la resilienza contro i disastri regionali, ti consigliamo di utilizzare il disaster recovery gestito da BigQuery.

La replica tra regioni di BigQuery fornisce una copia di sola lettura sincronizzata dei dati in una regione vicina ai consumatori di dati. Queste copie dei dati consentono le unioni collocate ed evitano costi e traffico tra regioni. Tuttavia, in caso di danneggiamento dei dati a causa di errori umani, la sola replica non può contribuire al recupero, perché i dati danneggiati vengono copiati automaticamente nella replica. In questi casi, i backup in un determinato momento (snapshot) sono una scelta migliore.

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

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

(snapshot o esportazione in Cloud Storage)		 Una tantum o periodicamente Identico ai dati della tabella di origine Ripristinare i dati originali oltre il periodo di viaggio nel tempo Gli snapshot comportano addebiti di archiviazione solo per le modifiche ai dati nello snapshot

Le esportazioni possono comportare addebiti 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

Note sul layout

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à

Il deployment incorpora le seguenti misure di sicurezza nella progettazione e nell'implementazione:

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

Per motivi di privacy, la soluzione non raccoglie né elabora informazioni che consentono l'identificazione personale (PII). Tuttavia, se le tabelle di origine hanno PII esposte, i backup eseguiti di 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 se i dati di origine sono protetti. Un altro approccio è assicurarsi che i progetti, i set di dati o i bucket che contengono i dati di backup con PII esposte siano dotati dei criteri IAM (Identity and Access Management) richiesti che limitano l'accesso solo agli utenti autorizzati.

In quanto soluzione generica, l'implementazione di riferimento non è necessariamente conforme ai 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 il backup di migliaia di tabelle, è probabile che tu raggiunga i limiti dell'API per i prodotti Google Cloud sottostanti (ad esempio, i limiti di operazione di snapshot e 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, questo 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 scinde i passaggi di elaborazione utilizzando servizi Cloud Run granulari e collegandoli tramite Pub/Sub. Se una richiesta di backup della tabella non va a buon fine nell'ultimo passaggio del servizio di tagging, Pub/Sub riprova solo questo passaggio e non l'intera procedura.

Suddividere il flusso in più servizi Cloud Run, anziché in più endpoint ospitati in un unico servizio Cloud Run, consente di fornire un controllo granulare di ogni configurazione del servizio. Il livello di configurazione dipende dalle funzionalità del servizio e dalle API con cui comunica. Ad esempio, il servizio di invio viene eseguito una volta per esecuzione, ma richiede molto tempo per elencare tutte le tabelle nell'ambito del backup di BigQuery. Pertanto, il servizio di smistamento richiede impostazioni di timeout e memoria superiori. Tuttavia, il servizio Cloud Run per gli snapshot di BigQuery viene eseguito una volta per tabella in una singola esecuzione e si completa in meno tempo rispetto al servizio di invio. 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 visualizzazioni è 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 portare a 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 vendite a un punto in tempo diverso dalla tabella dell'inventario corrispondente potrebbe creare una mancata corrispondenza dello stock disponibile. Analogamente, le visualizzazioni di database che aggregano i dati di più tabelle possono essere particolarmente sensibili alle incoerenze. Il ripristino di queste visualizzazioni senza assicurarsi che le tabelle sottostanti siano in uno stato coerente potrebbe portare a risultati imprecisi o fuorvianti. Pertanto, quando progetti i criteri e le frequenze di backup di BigQuery, è fondamentale tenere conto di questa coerenza e assicurarti che i dati ripristinati riflettano con precisione 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 viene controllata tramite le due configurazioni riportate di seguito nei criteri di backup. Queste configurazioni calcolano l'ora esatta dello snapshot della tabella tramite il viaggio nel tempo, senza necessariamente eseguire il backup di tutte le tabelle contemporaneamente.

  • backup_cron: consente di controllare 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 movimento nel tempo 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 dell'esecuzione) per calcolare la versione esatta del viaggio nel tempo della tabella.

Ripristino del backup automatico

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

Ad esempio, puoi creare una soluzione basata su un attivatore on demand che invia un ambito di dati BigQuery a un servizio di invio, che invia una richiesta per tabella a un servizio di configurazione. Il servizio di configuratore potrebbe recuperare la cronologia dei backup che ti interessa per una determinata tabella. Il servizio di configurazione potrebbe poi trasmetterlo a un servizio di ripristino degli snapshot di BigQuery o a un servizio di ripristino di Cloud Storage per applicare l'operazione di ripristino di conseguenza. Infine, un servizio di tagging potrebbe memorizzare i risultati di queste operazioni in un archivio dello 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:
    • Istantanee BigQuery, che comportano costi di archiviazione basati su 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 di BigQuery in Cloud Storage, che comportano addebiti standard per lo spazio di archiviazione. Tuttavia, per le tabelle di grandi dimensioni cheseguono un approccio di troncamento e caricamento, è più conveniente eseguire il backup come esportazioni in classi di archiviazione meno costose.
  • Scadenza dello 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 scadenza.

Efficienza operativa

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

Criteri di backup granulari e scalabili

Uno degli obiettivi di questo framework è l'efficienza operativa tramite l'aumento dell'output aziendale mantenendo al contempo 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 criteri di backup gestiti.

Oltre a consentire i criteri di backup a livello di tabella, il framework consente anche i 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 gli stati dei processi. Ad esempio, dovresti riuscire a trovare le informazioni per le seguenti query comuni:

  • Il criterio di backup utilizzato dal sistema per ogni tabella.
  • La cronologia dei backup e le posizioni dei backup di ogni tabella.
  • Lo stato complessivo di una singola esecuzione (il numero di tabelle elaborate e tabelle con errori).
  • Gli errori fatali 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 in ogni passaggio di esecuzione che utilizza un servizio Cloud Run. I log includono input, output ed errori, oltre ad altri punti di controllo dell'avanzamento. Un sink di log instrada questi log a una tabella BigQuery. Puoi eseguire una serie di query per monitorare le esecuzioni e generare report per i casi d'uso comuni di osservabilità. Per ulteriori informazioni su log e query in BigQuery, consulta Visualizzare i log inviati 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 accodamento elenca tutte le tabelle incluse nell'ambito del backup di BigQuery e genera una richiesta di backup per tabella a ogni esecuzione. In questo modo l'applicazione può elaborare migliaia di richieste e tabelle in parallelo, non in sequenza.

Inizialmente alcune di queste richieste potrebbero non andare a buon fine per motivi temporanei, ad esempio per il raggiungimento dei limiti delle API Google Cloud sottostanti o per problemi di rete. Fino al completamento delle richieste, Pub/Sub ritenta automaticamente le richieste con il criterio di ripetizione con tempo di attesa esponenziale. Se si verificano errori fatali come destinazioni di backup non valide o autorizzazioni mancanti, gli errori vengono registrati e l'esecuzione della richiesta della tabella in questione viene interrotta senza influire sull'esecuzione complessiva.

Limiti

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

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

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

Per informazioni dettagliate, 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 concorrenza, questa architettura utilizza Pub/Sub per ritentare automaticamente le richieste che non vanno a buon fine a causa di questi limiti, finché non vengono eseguite dall'API. Tuttavia, per altri limiti sul numero di operazioni per progetto al giorno, questi potrebbero essere attenuati da una richiesta di aumento della quota 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 di implementazione:

Deployment

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

Passaggi successivi

Collaboratori

Autore: Karim Wadie | Strategic Cloud Engineer

Altri collaboratori: