Questo documento descrive i principi e le tecniche per implementare un flusso di lavoro ripetibile che ti aiuterà a integrare le modifiche ai dati nel tuo data warehouse (DWH) basato su BigQuery. Queste modifiche possono includere nuovi set di dati, nuove origini dati o aggiornamenti e modifiche ai set di dati esistenti. Il documento descrive anche un'architettura di riferimento per questa attività.
Il pubblico di questo documento è costituito da architetti di software e dati e da data engineer che utilizzano BigQuery come DWH. Il documento presuppone che tu abbia familiarità con i concetti di base di CI/CD o prassi di gestione del ciclo di vita delle applicazioni simili.
Introduzione
L'integrazione e la distribuzione continue (CI/CD) sono diventate una tecnica essenziale nel ciclo di vita dello sviluppo software. L'adozione dei principi di CI/CD consente ai team di fornire software migliore con meno problemi rispetto all'integrazione delle funzionalità e al loro deployment manuale. La CI/CD può anche far parte di una strategia per la gestione dei dati quando esegui la modernizzazione del data warehousing.
Tuttavia, quando utilizzi un DWH come BigQuery, esistono differenze nel modo in cui implementi CI/CD rispetto all'implementazione di CI/CD nel codice sorgente. Queste differenze sono dovute in parte al fatto che il data warehousing è un sistema intrinsecamente con stato per la gestione dei dati sottostanti.
Questo documento fornisce le seguenti informazioni:
- Tecniche per l'implementazione di una strategia di integrazione continua (CI) in BigQuery.
- Indicazioni e metodi che ti aiutano a evitare insidie.
- Suggerimenti per le funzionalità di BigQuery che aiutano con la CI in BigQuery.
Questo documento si concentra sull'integrazione continua perché l'integrazione richiede più considerazioni specifiche per i dati per un team di data warehousing rispetto alla distribuzione continua (CD).
Quando utilizzare l'integrazione continua per un DWH BigQuery
In questo documento, l'integrazione dei dati è un'attività che viene solitamente eseguita dal team del DWH, che include l'incorporazione di nuovi dati nel DWH. Questa attività potrebbe comportare l'integrazione di una nuova origine dati nel DWH o la modifica della struttura di una tabella già presente nel DWH.
L'integrazione di nuovi dati nel DWH è un'attività simile all'integrazione di una nuova funzionalità nel software esistente. Potrebbero essere introdotti bug e influire negativamente sull'esperienza dell'utente finale. Quando integri i dati in BigQuery, i consumatori downstream dei dati (ad esempio applicazioni, dashboard di Business Intelligence e singoli utenti) potrebbero riscontrare problemi a causa di mancate corrispondenze dello schema. In alternativa, i consumatori potrebbero utilizzare dati errati che non riflettono quelli dell'origine dati originale.
La CI per i DWH è utile se vuoi:
- Descrivi i punti chiave della CI per un sistema DWH.
- Progetta e implementa una strategia di CI per il tuo ambiente BigQuery.
- Scopri come utilizzare le funzionalità di BigQuery per implementare l'integrazione continua.
Questa guida non descrive come gestire l'integrità del codice per i prodotti non DWH, inclusi i prodotti di dati come Dataflow e Bigtable.
Scenario di esempio
La Società di esempio è una grande azienda di vendita al dettaglio che gestisce il proprio DWH in BigQuery. Nell'anno a venire, l'azienda vuole integrare nel proprio DWH nuove origini dati di società acquisite di recente dalla società di esempio. Le nuove origini dati da integrare hanno schemi diversi. Tuttavia, il DWH deve mantenere lo schema esistente e fornire una coerenza e una completezza dei dati molto elevate in modo che i consumatori di dati a valle non siano interessati negativamente.
Al momento, il team del data warehouse della Società di esempio esegue l'integrazione dei dati. L'integrazione si basa sull'esistenza di origini dati in uno schema predefinito. Questo flusso di lavoro prevede procedure di importazione dei dati precedenti, database acquisiti e servizi di applicazioni.
Per aggiornare le procedure di integrazione dei dati in modo da supportare le nuove origini dati, il team DWH deve riprogettare il proprio approccio all'integrazione dei dati in modo da rispettare i requisiti indicati in precedenza, ad esempio una forte coerenza dei dati. Il team deve implementare le modifiche in modo isolato in modo che le modifiche ai dati possano essere testate e misurate prima che i dati vengano resi disponibili per i consumatori a valle.
Dopo che il team DWH ha adottato il nuovo flusso di lavoro, ha a disposizione una procedura ripetibile. Ogni sviluppatore può creare un ambiente di sviluppo isolato basato sui dati di produzione. Utilizzando questi ambienti isolati, gli sviluppatori possono apportare modifiche, testarle, sottoporle a revisione e applicare le modifiche necessarie all'ambiente di produzione. Se le modifiche causano bug o problemi imprevisti, è possibile eseguire facilmente il rollback.
Che cosa significa l'integrazione continua per un DWH
L'integrazione continua (CI) è un insieme di pratiche che consente ai team di sviluppo di accorciare i cicli di sviluppo e di trovare i problemi nel codice più velocemente rispetto ai sistemi manuali. Il vantaggio principale dell'adozione di un approccio CI è la possibilità di sviluppare rapidamente, riducendo i rischi di interferenza tra gli sviluppatori. Questo obiettivo viene raggiunto assicurando che il processo sia ripetibile, consentendo al contempo a ogni sviluppatore di lavorare in isolamento dagli altri sviluppatori.
Questi principi si applicano anche quando un'organizzazione deve integrare i dati in un DWH, con alcune differenze. Nel contesto dello sviluppo software tipico, la CI isole le modifiche al codice sorgente, che è stateless. Nel contesto della CI in data, la CI integra i dati in un sistema DWH. Tuttavia, i dati sono stateful per definizione. Questa differenza ha implicazioni per il modo in cui l'IA si applica agli scenari DWH, come descritto in questo documento.
Scenari aggiuntivi non coperti da questo documento
Sebbene questo documento si concentri sull'isolamento delle modifiche di sviluppo dall'ambiente di produzione, non tratta i seguenti aspetti dell'integrazione dei dati:
- Test dei dati: sei in grado di verificare che i dati di tua proprietà siano conformi ai requisiti aziendali? I dati sono affidabili per fungere da fonte attendibile? Per aumentare il livello di affidabilità dei dati pubblicati dal tuo DWH, è importante testarli. Per eseguire il test, puoi eseguire un insieme di query, affermando che i dati non mancano di valori o che contengono valori "non validi".
- Rivalità dei dati:riesci a vedere una tabella nel suo contesto? Ad esempio, puoi vedere da dove sono stati raccolti i dati e quali set di dati sono stati precomputati per generare la tabella? Nelle moderne architetture DWH, i dati sono suddivisi in molti sistemi che utilizzano strutture di dati diverse e specializzate. Sono inclusi i database relazionali, i database NoSQL e le origini dati esterne. Per comprendere appieno i dati di cui disponi, devi tenerne traccia. Devi anche capire come sono stati generati i dati e da dove.
Questi argomenti non rientrano nell'ambito di questa guida. Tuttavia, la tua strategia relativa ai dati trarrà vantaggio dalla pianificazione di questi argomenti quando crei un flusso di lavoro per il tuo team.
Configurazione tipica di BigQuery come DWH
Il seguente diagramma mostra un tipico design del DWH per BigQuery. Mostra come vengono importati i dati provenienti da origini esterne nel DWH e come i consumatori li utilizzano.
I dati iniziano dalle origini dati, dove si trovano in database transactionali o a bassa latenza convenzionali, come i database SQL OLTP e NoSQL. Un processo pianificato copia i dati in un'area di staging.
I dati vengono archiviati temporaneamente nell'area di staging. Se necessario, i dati vengono trasformati in modo da adattarsi a un sistema di analisi prima di essere caricati nelle tabelle DWH. In questo diagramma, l'area di staging si trova all'interno di Google Cloud, ma non è obbligatoria. Le trasformazioni possono includere la denormalizzazione, l'arricchimento di determinati set di dati o la gestione di voci con formato non corretto (ad esempio voci con valori mancanti).
Dall'area di staging, i nuovi dati vengono caricati nelle tabelle DWH. Le tabelle possono essere organizzate in diversi modi a seconda del design del DWH e in genere sono chiamate tabelle principali. Alcuni esempi di paradigmi di progettazione delle tabelle includono il paradigma dello schema a stella, il paradigma denormalizzato e gli aggregati a più livelli.
Indipendentemente dal design della tabella, queste tabelle salvano i dati nel tempo. Le tabelle devono rispettare lo schema e si presume che contengano la fonte attendibile per tutte le finalità di analisi. Questo ruolo per le tabelle significa che i dati al loro interno devono essere completi, coerenti e rispettare gli schemi predefiniti.
Queste tabelle non forniscono dati direttamente ai consumatori. I dati vengono invece pubblicati tramite un livello di accesso, progettato per incapsulare la logica aziendale che deve essere applicata ai dati sottostanti. Esempi di questo tipo di logica aziendale sono il calcolo di una metrica per ogni record o il filtro e il raggruppamento dei dati.
I consumatori dei dati possono connettersi e leggere i dati dal livello di accesso DWH. Questi utenti dei dati potrebbero includere sistemi come:
- Dashboard di business intelligence (BI)
- Note sullo studio dei dati
- Sistemi operativi che si basano sui dati calcolati nel DWH
- Utenti umani per query ad hoc
I consumatori di dati si basano molto sul DWH per fornire schemi coerenti e sulla logica aziendale incapsulata dal DWH. Questi schemi e la logica di business possono essere considerati gli accordi sul livello del servizio (SLA) della piattaforma DWH. Qualsiasi modifica alla logica di business, allo schema o alla completezza dei dati potrebbe avere implicazioni significative a valle. Data la natura in continua evoluzione delle moderne piattaforme di dati, il team del DWH potrebbe dover apportare queste modifiche rispettando rigorosamente gli SLA. Affinché il team possa rispettare questi SLA e mantenere aggiornato il DWH, ha bisogno di un flusso di lavoro che consenta l'integrazione dei dati riducendo al minimo le difficoltà che queste modifiche potrebbero creare.
Asset per l'integrazione continua in un DWH
Come per qualsiasi altro team di sviluppo o IT, il team DWH deve gestire gli asset essenziali per le sue responsabilità. In genere, questi asset possono essere suddivisi nelle seguenti categorie:
La base di codice per le pipeline di dati: questi asset in genere consistono in codice sorgente in un linguaggio di programmazione di alto livello come Python o Java. Per questi tipi di asset, i processi CI/CD vengono creati utilizzando strumenti come Git e Jenkins oppure soluzioni come Cloud Source Repositories e Cloud Build.Google Cloud
Script SQL: questi asset descrivono la struttura e la logica di business incapsulata all'interno del DWH. All'interno di questa categoria, gli asset possono essere ulteriormente suddivisi nelle seguenti sottocategorie:
- Data Definition Language (DDL): questi asset vengono utilizzati per definire lo schema di tabelle e visualizzazioni.
- Data Manipulation Language (DML): questi asset vengono utilizzati per manipolare i dati all'interno di una tabella. I comandi DML vengono utilizzati anche per creare nuove tabelle in base a quelle esistenti.
- Data Control Language (DCL): questi asset vengono utilizzati per controllare le autorizzazioni e l'accesso alle tabelle. In BigQuery, puoi controllare l'accesso utilizzando SQL e lo strumento a riga di comando
bqo l'API REST BigQuery. Tuttavia, ti consigliamo di utilizzare IAM.
Questi asset e altri come gli script Terraform utilizzati per compilare i componenti vengono gestiti all'interno dei repository di codice. Strumenti come Dataform possono aiutarti a creare una pipeline CI/CD che convalida gli script SQL e controlla le regole di convalida predefinite nelle tabelle create dagli script DDL. Questi strumenti ti consentono di applicare processi di compilazione e test per SQL, che nella maggior parte dei contesti non ha un ambiente di test naturale.
Oltre alle risorse associate a strumenti e processi, la risorsa principale per un team di DWH sono i dati. I dati non sono monitorabili utilizzando sistemi di monitoraggio delle risorse come Git, progettato per monitorare il codice sorgente. Questo documento illustra i problemi associati al monitoraggio dei dati.
Problemi di integrazione dei dati
A causa della potenziale complessità delle relazioni tra tabelle all'interno di un DWH (ad esempio, in uno dei paradigmi di progettazione delle tabelle menzionati in precedenza), mantenere isolato lo stato dei dati di produzione da un ambiente di test è una sfida. Le pratiche standard nello sviluppo software non possono essere applicate allo scenario di integrazione dei dati.
La seguente tabella riassume le differenze tra le pratiche per integrare il codice e quelle per integrare i dati.
| Codice di integrazione | Integrazione dei dati | |
|---|---|---|
| Sviluppo locale | Il codice sorgente è facilmente clonabile grazie alle sue dimensioni relativamente ridotte. In genere, il codice è adatto alla maggior parte delle macchine degli utenti finali (esclusi i casi di monorepo, che hanno altre soluzioni). | La maggior parte delle tabelle in un DWH non può essere inserita in una macchina di sviluppo a causa delle dimensioni. |
| Test centralizzati | Diversi stati del codice sorgente vengono clonati in un sistema centrale (un server CI) per sottoporli a test automatici. Avere stati diversi del codice ti consente di confrontare i risultati tra una versione stabile e una versione di sviluppo. | La creazione di stati diversi dei dati in un ambiente isolato non è un processo semplice. Lo spostamento dei dati al di fuori del DWH è un'operazione che richiede molto tempo e risorse. Non è pratico eseguire questa operazione con la frequenza necessaria per i test. |
| Versioni precedenti | Durante il processo di rilascio di nuove versioni del software, puoi monitorare le versioni precedenti. Se rilevi un problema in una nuova release, puoi eseguire il rollback a una versione sicura. | Eseguire il backup delle tabelle all'interno del DWH è una prassi standard nel caso in cui debba eseguire il rollback. Tuttavia, devi assicurarti che per tutte le tabelle interessate venga eseguito il rollback allo stesso punto nel tempo. In questo modo, le tabelle correlate sono coerenti tra loro. |
Integrare i dati nelle tabelle BigQuery
BigQuery dispone di due funzionalità che possono aiutarti a progettare un flusso di lavoro per l'integrazione dei dati: gli snapshot delle tabelle e i cloni delle tabelle. Puoi combinare queste funzionalità per ottenere un flusso di lavoro che ti offra un ambiente di sviluppo economico. Gli sviluppatori possono manipolare i dati e la relativa struttura indipendentemente dall'ambiente di produzione e possono eseguire il rollback di una modifica, se necessario.
Uno snapshot della tabella BigQuery è una rappresentazione di sola lettura di una tabella (chiamata tabella di base) in un determinato momento. Analogamente, un clone di tabella BigQuery è una rappresentazione di lettura/scrittura di una tabella in un determinato momento. In entrambi i casi, i costi di archiviazione sono ridotti al minimo perché vengono archiviate solo le differenze rispetto alla tabella di base. I costi delle copie delle tabelle iniziano a essere applicati quando la tabella di base o le copie delle tabelle cambiano. Poiché gli snapshot delle tabelle sono di sola lettura, comportano costi solo quando la tabella di base cambia.
Per ulteriori informazioni sui prezzi degli snapshot delle tabelle e dei cloni delle tabelle, consulta Introduzione agli snapshot delle tabelle e Introduzione ai cloni delle tabelle.
Puoi acquisire snapshot e cloni delle tabelle utilizzando la funzionalità di spostamento nel tempo di BigQuery (fino a sette giorni prima). Questa funzionalità ti consente di acquisire istantanee e cloni di più tabelle nello stesso istante, rendendo l'ambiente di lavoro e le istantanee coerenti tra loro. L'utilizzo di questa funzionalità può essere utile per le tabelle aggiornate di frequente.
Come utilizzare i cloni e gli snapshot delle tabelle per consentire l'isolamento
Per illustrare il flusso di lavoro di integrazione per l'IA in un DWH, immagina il seguente scenario. Ti viene chiesto di integrare un nuovo set di dati nel DWH. L'attività potrebbe consistere nella creazione di nuove tabelle DWH, nell'aggiornamento di tabelle esistenti, nella modifica della struttura delle tabelle o in qualsiasi combinazione di queste attività. Il flusso di lavoro potrebbe essere simile alla seguente sequenza:
- Identifica le tabelle che potrebbero essere interessate dalle modifiche e altre tabelle che potresti voler controllare.
- Crea un nuovo set di dati BigQuery per contenere gli asset per questa modifica. Questo set di dati consente di isolare le modifiche e separare questa attività dalle altre su cui lavorano gli altri membri del team. Il set di dati deve trovarsi nella stessa regione del set di dati di origine. Tuttavia, il progetto può essere separato dal progetto di produzione per contribuire a soddisfare i requisiti di sicurezza e fatturazione della tua organizzazione.
Per ogni tabella, crei sia un clone che un snapshot nel nuovo set di dati, potenzialmente per lo stesso istante. Questo approccio offre i seguenti vantaggi:
- La copia della tabella può fungere da copia di lavoro in cui puoi apportare modifiche liberamente senza influire sulla tabella di produzione. Puoi creare più cloni di tabelle della stessa tabella di base per testare contemporaneamente diversi percorsi di integrazione con un overhead minimo.
- Lo snapshot può fungere da punto di ripristino e di riferimento, un punto in cui è noto che i dati hanno funzionato prima di qualsiasi modifica. Avere questo snapshot ti consente di eseguire un rollback nel caso in cui venga rilevato un problema più avanti nel processo.
Utilizza i cloni delle tabelle per implementare le modifiche necessarie per le tabelle. Questa azione genera una versione aggiornata dei cloni delle tabelle, che puoi testare in un set di dati isolato.
Se vuoi, al termine della fase di implementazione puoi presentare un set di dati che può essere utilizzato per le seguenti attività:
- Test di unità con uno strumento di convalida come Dataform. I test di unità sono autocontenuti, il che significa che l'asset viene testato in isolamento. In questo caso, la risorsa è la tabella in BigQuery. I test di unità possono verificare la presenza di valori null, verificare che tutte le stringhe soddisfino i requisiti di lunghezza e assicurarsi che determinati aggregati producano risultati utili. I test di unità possono includere qualsiasi test di affidabilità che garantisca che la tabella mantenga le regole aziendali dell'organizzazione.
- Test di integrazione con i consumatori a valle.
- Revisione tra pari.
Questo flusso di lavoro ti consente di eseguire test con i dati di produzione, senza influire sui consumatori a valle.
Prima di unire i nuovi dati a BigQuery, puoi creare un altro snapshot. Questo snapshot è utile come un'altra opzione di rollback nel caso in cui i dati nella tabella di base siano stati modificati.
La procedura di unione delle modifiche dipende dalla procedura che la tua organizzazione vuole adottare e dalle modifiche richieste. Ad esempio, per una modifica degli script SQL, il nuovo set di dati potrebbe essere accompagnato da una pull request al codice di base standard. Se la modifica è limitata ai dati all'interno di una determinata tabella, puoi semplicemente copiare i dati utilizzando i metodi standard di BigQuery.
Puoi utilizzare uno script di procedure archiviate per incapsulare e automatizzare i passaggi per la creazione di un set di dati e dei cloni e degli snapshot. L'automazione di queste attività riduce il rischio di errori umani. Per un esempio di script che può aiutarti a automatizzare i processi, consulta il repository GitHub dell'utilità CI for Data in BigQuery CLI.
Vantaggi dell'utilizzo di cloni e istantanee delle tabelle
Quando utilizzi il flusso di lavoro descritto nella sezione precedente, gli sviluppatori possono lavorare in isolamento e in parallelo, senza interferire con i colleghi. Gli sviluppatori possono testare e rivedere le modifiche e, in caso di problemi, eseguire il rollback delle modifiche. Poiché utilizzi gli snapshot delle tabelle e non le tabelle complete, puoi ridurre al minimo i costi e lo spazio di archiviazione rispetto all'utilizzo delle tabelle complete.
Questa sezione fornisce ulteriori dettagli su come gli snapshot e i cloni delle tabelle consentono agli sviluppatori di realizzare questo flusso di lavoro. Il seguente diagramma mostra in che modo gli snapshot e i cloni delle tabelle sono correlati ai dati nel set di dati di produzione.
Nel diagramma, il set di dati di produzione contiene tutte le tabelle in uso in produzione. Ogni sviluppatore può creare un set di dati per il proprio ambiente di sviluppo. Il diagramma mostra due set di dati per sviluppatori, etichettati come Set di dati per sviluppatori 1 e Set di dati per sviluppatori 2. Utilizzando questi set di dati per sviluppatori, gli sviluppatori possono lavorare contemporaneamente sulle stesse tabelle senza interferire tra loro.
Dopo aver creato un set di dati, gli sviluppatori possono creare cloni e snapshot delle tabelle su cui stanno lavorando. I cloni e gli snapshot rappresentano i dati in un determinato momento. A questo punto, gli sviluppatori sono liberi di modificare i cloni della tabella, perché le modifiche non sono visibili nella tabella di base.
Uno sviluppatore può esaminare i cloni delle tabelle, confrontarli con lo snapshot e verificarne la compatibilità con i consumatori a valle. Gli altri sviluppatori possono lavorare con altri cloni e snapshot, senza interferenze e senza creare troppe copie della tabella di base che richiedono molte risorse.
Gli sviluppatori possono unire le modifiche alla tabella di base mantenendo al sicuro l'istantanea come opzione di rollback, se necessario. Questa procedura può essere ripetuta anche per ambienti diversi, come sviluppo, test e produzione.
Alternative ai cloni e agli snapshot delle tabelle
Esistono alternative all'utilizzo di cloni di tabelle e istantanee di tabelle che consentono di ottenere un risultato simile. Questi metodi alternativi vengono in genere utilizzati diversamente rispetto ai cloni e agli snapshot. È importante comprendere le differenze tra questi metodi e in quali casi è preferibile utilizzare uno rispetto all'altro.
Copiare intere tabelle in un altro set di dati
Un metodo alternativo è utilizzare un set di dati diverso e copiare le tabelle in quel set di dati. L'utilizzo di questo metodo è simile all'utilizzo di cloni e snapshot delle tabelle, ma viene copiato l'intero insieme di tabelle. A seconda delle dimensioni dei dati da copiare, i costi di archiviazione potrebbero essere elevati. Alcune organizzazioni hanno utilizzato questo metodo prima che i cloni delle tabelle diventassero disponibili in BigQuery. Tuttavia, questo metodo non presenta alcun vantaggio rispetto all'utilizzo di cloni e snapshot.
Esportare e importare tabelle in Cloud Storage
Un altro metodo alternativo è spostare i dati tramite Cloud Storage. Questo metodo è simile anche all'utilizzo di cloni e snapshot delle tabelle. Tuttavia, include il passaggio aggiuntivo di esportazione dei dati in un bucket Cloud Storage. Un vantaggio di questo metodo è che ti offre un backup aggiuntivo dei tuoi dati. Potresti scegliere questo metodo se vuoi un backup per il ripristino di emergenza o soluzioni ibride.
Utilizzare Analytics Hub
Analytics Hub ti consente di condividere set di dati sia all'esterno che all'interno dell'organizzazione in modo sicuro. Offre molte funzionalità che ti consentono di pubblicare set di dati per fornire agli abbonati un accesso controllato e di sola lettura a questi set di dati. Tuttavia, anche se puoi utilizzare Analytics Hub per esporre i set di dati per implementare le modifiche, uno sviluppatore deve comunque creare cloni di tabelle per poter lavorare con le tabelle.
Riepilogo delle opzioni di integrazione continua del DWH
La seguente tabella riassume le differenze, i vantaggi e i potenziali svantaggi tra le opzioni per l'integrazione continua del DWH. Analytics Hub offre un insieme di funzionalità diverso e pertanto non è misurabile utilizzando i parametri elencati nella tabella.
| Costi | Rollback | Rischi | |
|---|---|---|---|
| Istantanee e cloni delle tabelle | Minima. Paghi solo per la differenza tra lo snapshot o la tabella clone e la tabella di base. | Lo snapshot funge da backup da cui eseguire il rollback, se necessario. | Sei tu a decidere il livello di rischio. Gli snapshot possono essere acquisiti in un determinato momento per tutte le tabelle, il che riduce le incoerenze anche in caso di rollback. |
| Copia tabella | Costi più elevati rispetto all'utilizzo di istantanee e cloni di tabelle. L'intera raccolta di dati viene duplicata. Per supportare i rollback, sono necessarie più copie della stessa tabella. | Possibile, ma richiede due copie della tabella: una da utilizzare come backup e una da utilizzare e modificare. | La clonazione è più difficile da eseguire per un determinato momento. Se è necessario un rollback, non tutte le tabelle vengono prese dallo stesso punto nel tempo. |
| Esportazione e importazione | Costi più elevati rispetto all'utilizzo di istantanee e cloni di tabelle. I dati sono duplicati. Per supportare il rollback, sono necessarie più copie della stessa tabella. | I dati esportati fungono da backup. | I dati esportati non sono un'esportazione in un determinato momento per più tabelle. |
Passaggi successivi
- Scopri di più sugli snapshot delle tabelle BigQuery in Introduzione agli snapshot delle tabelle.
- Scopri di più sull'integrazione continua per lo sviluppo software in Tecnologia DevOps: integrazione continua.
- Per altre architetture di riferimento, diagrammi e best practice, visita il Centro architetture di Google Cloud.