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 potrebbero 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 ingegneri dei dati che utilizzano BigQuery come DWH. Il documento presuppone che tu conosca i concetti di base di CI/CD o pratiche simili di gestione del ciclo di vita delle applicazioni.
Introduzione
L'integrazione continua e la distribuzione continua (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 migliori con meno problemi rispetto all'integrazione delle funzionalità e alla loro implementazione manuale. CI/CD può anche far parte di una strategia per la gestione dei dati quando modernizzi il data warehousing.
Tuttavia, quando lavori con un DWH come BigQuery, ci sono 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 stateful 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 le insidie.
- Suggerimenti per le funzionalità di BigQuery che aiutano con CI;integrazione continua in BigQuery.
Questo documento si concentra sullCI;integrazione continua, perché l'integrazione presenta considerazioni più specifiche per i dati per un team di data warehousing rispetto alla distribuzione continua.
Quando utilizzare CI;integrazione continua per un DWH BigQuery
In questo documento, l'integrazione dei dati è un'attività solitamente eseguita dal team DWH, che include l'incorporamento di nuovi dati nel DWH. Questa attività potrebbe comportare l'incorporamento 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à in un software esistente. Potrebbe introdurre bug e influire negativamente sull'esperienza dell'utente finale. Quando integri i dati in BigQuery, i consumatori downstream dei dati (ad esempio applicazioni, dashboard BI e singoli utenti) potrebbero riscontrare problemi a causa di mancata corrispondenza dello schema. Oppure i consumatori potrebbero utilizzare dati errati che non riflettono i dati dell'origine dati originale.
L'CI per DWH è utile quando vuoi:
- Descrivi i punti chiave dellCI;integrazione continua 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 CI;integrazione continua.
Questa guida non descrive come gestire l'CI per i prodotti non DWH, inclusi i prodotti di dati come Dataflow e Bigtable.
Scenario di esempio
Example Company è una grande azienda retail che gestisce il proprio DWH in BigQuery. Nel prossimo anno, l'azienda vuole integrare nuove origini dati nel proprio DWH provenienti da società recentemente acquisite da Example Company. Le nuove origini dati da integrare hanno schemi diversi. Tuttavia, il DWH deve mantenere lo schema esistente e fornire una forte coerenza e completezza dei dati in modo che i consumatori downstream dei dati non vengano influenzati negativamente.
Attualmente, il team DWH di Example Company esegue l'integrazione dei dati. L'integrazione si basa sulla presenza delle origini dati esistenti in uno schema predefinito. Questo flusso di lavoro include processi di importazione dei dati legacy, database acquisiti e servizi applicativi.
Per aggiornare i processi di integrazione dei dati in modo da adattarli alle nuove origini dati, il team DWH deve riprogettare il proprio approccio all'integrazione dei dati per rispettare i requisiti indicati in precedenza, come 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 ai consumatori downstream.
Dopo che il team DWH adotta il nuovo flusso di lavoro, il team dispone di 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, farle esaminare e distribuire le modifiche richieste nell'ambiente di produzione. Se le modifiche causano bug o problemi imprevisti, possono essere facilmente annullate.
Che cosa significa l'integrazione continua per un DWH
L'integrazione continua (CI) è un insieme di pratiche che consentono ai team di sviluppo di abbreviare i cicli di sviluppo e trovare i problemi nel codice più rapidamente rispetto ai sistemi manuali. Il vantaggio principale dell'adozione di un approccio CI è la capacità di sviluppare rapidamente, riducendo i rischi di interferenza tra gli sviluppatori. Questo obiettivo viene raggiunto assicurando che il processo sia ripetibile, consentendo 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 del tipico sviluppo di software, CI;integrazione continua isola le modifiche al codice sorgente, che è senza stato. Nel contesto dell'integrità dei dati, CI;integrità dei dati integra i dati in un sistema DWH. Tuttavia, i dati sono stateful per definizione. Questa differenza ha implicazioni sul modo in cui CI si applica agli scenari DWH, come descritto in questo documento.
Scenari aggiuntivi non trattati in 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:riesci a verificare che i dati in tuo possesso siano conformi ai requisiti aziendali? I dati sono affidabili e possono essere utilizzati come fonte attendibile? Per aumentare il livello di affidabilità dei dati che pubblichi dal tuo DWH, è importante testarli. Per eseguire il test, puoi eseguire un insieme di query, verificando che i dati non contengano valori mancanti o che contengano valori "errati".
- Lignaggio 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 precalcolati per generare la tabella? Nelle moderne architetture DWH, i dati vengono suddivisi in molti sistemi che utilizzano strutture di dati diverse e specializzate. Questi includono database relazionali, database NoSQL e origini dati esterne. Per comprendere appieno i dati in tuo possesso, 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, è utile pianificare questi argomenti quando progetti un workflow per il tuo team.
Configurazione tipica di BigQuery come DWH
Il seguente diagramma illustra una tipica progettazione di DWH per BigQuery. Mostra come vengono inseriti i dati da origini esterne nel DWH e come i consumatori utilizzano i dati del DWH.
I dati iniziano dalle origini dati, dove si trovano in database transazionali o a bassa latenza convenzionali, come i database SQL OLTP e NoSQL. Un processo pianificato copia i dati in un'area di gestione temporanea.
I dati vengono archiviati temporaneamente nell'area di gestione temporanea. Se necessario, i dati vengono trasformati per adattarsi a un sistema di analisi prima di essere caricati nelle tabelle del DWH. In questo diagramma, l'area di staging si trova all'interno di Google Cloud, ma non è obbligatorio. Le trasformazioni potrebbero includere la denormalizzazione, l'arricchimento di determinati set di dati o la gestione di voci non valide (ad esempio, voci con valori mancanti).
Dall'area di gestione temporanea, i nuovi dati vengono caricati nelle tabelle del DWH. Le tabelle potrebbero essere organizzate in modi diversi a seconda della progettazione del DWH e sono solitamente denominate 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 dalla progettazione 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à analitiche. Questo ruolo per le tabelle significa che i dati in queste tabelle devono essere completi, coerenti e conformi agli schemi predefiniti.
Queste tabelle non forniscono dati direttamente ai consumatori. I dati vengono invece forniti tramite un livello di accesso, progettato per incapsulare la logica di business 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 filtraggio e il raggruppamento dei dati.
I consumatori dei dati possono connettersi e leggere i dati dal livello di accesso al DWH. Questi consumatori di dati potrebbero includere sistemi come i seguenti:
- 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 affidano molto al DWH per fornire schemi coerenti e alla logica di business che il DWH incapsula. Questi schemi e la logica aziendale possono essere considerati come 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 grandi implicazioni a valle. Data la natura in continua evoluzione delle moderne piattaforme di dati, il team DWH potrebbe dover apportare queste modifiche rispettando rigorosamente gli SLA. Affinché il team rispetti questi SLA e mantenga aggiornato il DWH, ha bisogno di un flusso di lavoro che consenta l'integrazione dei dati riducendo al minimo l'attrito che queste modifiche potrebbero creare.
Asset per l'integrazione continua in un DWH
Come qualsiasi altro team di sviluppo o IT, il team DWH deve gestire asset essenziali per le proprie responsabilità. Questi asset possono in genere essere divisi nelle seguenti categorie:
Il codebase per le pipeline di dati: questi asset di solito sono costituiti da 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 utilizzando Google Cloud soluzioni come Cloud Source Repositories e Cloud Build.
Script SQL: questi asset descrivono la struttura e la logica di business incapsulate 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 viste.
- 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 basate su tabelle 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 creare componenti, vengono gestiti all'interno dei repository di codice. Strumenti come Dataform possono aiutarti a creare una pipeline CI/CD che convalidi gli script SQL e controlli 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 dispone di un ambiente di test naturale.
Oltre agli asset associati a strumenti e processi, l'asset principale per un team DWH sono i dati. I dati non sono monitorabili utilizzando sistemi di monitoraggio degli asset come Git, progettato per monitorare il codice sorgente. Questo documento tratta i problemi associati ai dati di monitoraggio.
Problemi con l'integrazione dei dati
A causa della potenziale complessità delle relazioni tra le tabelle all'interno di un DWH (ad esempio, in uno dei paradigmi di progettazione delle tabelle menzionati in precedenza), mantenere lo stato dei dati di produzione isolato da un ambiente di test è una sfida. Le pratiche standard di sviluppo software non possono essere applicate allo scenario di integrazione dei dati.
La seguente tabella riassume le differenze tra le pratiche per l'integrazione del codice e quelle per l'integrazione dei 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, per i quali esistono altre soluzioni). | La maggior parte delle tabelle in un DWH non può essere inserita in una macchina di sviluppo a causa delle dimensioni. |
| Test centralizzato | Diversi stati del codice sorgente vengono clonati in un sistema centrale (un server CI) per essere sottoposti a test automatizzati. Avere diversi stati 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 è semplice. Lo spostamento dei dati al di fuori del DWH è un'operazione che richiede molte risorse e molto tempo. Non è pratico eseguirlo 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. | L'esecuzione di backup delle tabelle all'interno del DWH è una pratica standard in caso di rollback. Tuttavia, devi assicurarti che tutte le tabelle interessate vengano ripristinate allo stesso momento. In questo modo, le tabelle correlate sono coerenti tra loro. |
Integrare i dati nelle tabelle BigQuery
BigQuery offre due funzionalità che possono aiutarti a progettare un workflow 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 conveniente. Gli sviluppatori possono manipolare i dati e la loro struttura in isolamento dall'ambiente di produzione e possonorollbacke una modifica, se necessario.
Uno snapshot di una tabella BigQuery è una rappresentazione di sola lettura di una tabella (chiamata tabella di base) in un determinato momento. Allo stesso modo, un clone di una tabella BigQuery è una rappresentazione in lettura/scrittura di una tabella in un determinato momento. In entrambi i casi, i costi di archiviazione vengono ridotti al minimo perché vengono archiviate solo le differenze rispetto alla tabella di base. I cloni della tabella iniziano a generare costi quando la tabella di base cambia o quando cambiano i cloni della tabella. Poiché gli snapshot delle tabelle sono di sola lettura, comportano costi solo quando la tabella di base cambia.
Per saperne di più sui prezzi degli snapshot e dei cloni delle tabelle, consulta Introduzione agli snapshot delle tabelle e Introduzione ai cloni delle tabelle.
Puoi creare snapshot e cloni delle tabelle utilizzando la funzionalità di spostamento cronologico di BigQuery (fino a sette giorni prima). Questa funzionalità ti consente di acquisire snapshot e cloni di più tabelle nello stesso momento, il che rende l'ambiente di lavoro e gli snapshot coerenti tra loro. L'utilizzo di questa funzionalità può essere utile per le tabelle che vengono 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 CI in un DWH, immagina lo scenario seguente. Ti viene assegnato il compito di integrare un nuovo set di dati nel DWH. L'attività potrebbe consistere nel creare nuove tabelle DWH, aggiornare quelle esistenti, modificare la struttura delle tabelle o qualsiasi combinazione di queste attività. Il workflow potrebbe essere simile alla seguente sequenza:
- Identifica le tabelle che potrebbero essere interessate dalle modifiche e le tabelle aggiuntive 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 separa 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 ciascuna tabella, crei sia un clone che uno snapshot nel nuovo set di dati, potenzialmente per lo stesso punto nel tempo. Questo approccio offre i seguenti vantaggi:
- Il clone della tabella può fungere da copia di lavoro in cui puoi apportare modifiche liberamente senza influire sulla tabella di produzione. Puoi creare più cloni della stessa tabella di base per testare diversi percorsi di integrazione contemporaneamente, con un overhead minimo.
- Lo snapshot può fungere da punto di riferimento e ripristino, un punto in cui è noto che i dati funzionavano prima di qualsiasi modifica. Questo snapshot ti consente di eseguire un rollback nel caso in cui venga rilevato un problema in un secondo momento.
Utilizzi i cloni delle tabelle per implementare le modifiche necessarie per le tabelle. Questa azione genera una versione aggiornata dei cloni della tabella, che puoi testare in un dataset isolato.
(Facoltativo) Al termine della fase di implementazione, puoi presentare un set di dati che può essere utilizzato per le seguenti attività:
- Test unitari con uno strumento di convalida come Dataform. I test delle unità sono autonomi, il che significa che l'asset viene testato in isolamento. In questo caso, l'asset è la tabella in BigQuery. I test delle unità possono verificare la presenza di valori nulli, possono verificare che tutte le stringhe soddisfino i requisiti di lunghezza e possono assicurarsi che determinati aggregati producano risultati utili. I test unitari possono includere qualsiasi test di affidabilità che garantisca che la tabella mantenga le regole aziendali dell'organizzazione.
- Test di integrazione con i consumatori downstream.
- Revisione dei compagni.
Questo flusso di lavoro ti consente di eseguire test con i dati di produzione senza influire sui consumer downstream.
Prima di unire i nuovi dati in BigQuery, puoi creare un altro snapshot. Questo snapshot è utile come 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 agli script SQL, il nuovo set di dati potrebbe essere accompagnato da una richiesta di pull al codebase standard. Se la modifica è limitata a una modifica dei dati all'interno di una determinata tabella, puoi semplicemente copiare i dati utilizzando i metodi standard di BigQuery.
Puoi utilizzare uno script di stored procedure per incapsulare e automatizzare i passaggi per creare un set di dati e creare i cloni e gli snapshot. L'automazione di queste attività riduce il rischio di errore umano. Per un esempio di script che può aiutarti ad automatizzare i processi, consulta il repository GitHub dell'utilità CLI CI for Data in BigQuery.
Vantaggi dell'utilizzo di cloni e snapshot 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, rollbacke le modifiche. Poiché lavori con snapshot delle tabelle e non con tabelle complete, puoi ridurre al minimo i costi e l'archiviazione rispetto all'utilizzo di tabelle complete.
Questa sezione fornisce maggiori dettagli su come gli snapshot e i cloni delle tabelle consentono agli sviluppatori di ottenere questo workflow. Il seguente diagramma mostra la relazione tra gli snapshot delle tabelle e i cloni delle tabelle e i dati nel set di dati di produzione.
Nel diagramma, il set di dati di produzione contiene tutte le tabelle utilizzate 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 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 momento specifico. 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 della tabella, confrontarli con lo snapshot e testarli per verificare la compatibilità con i consumatori downstream. Altri sviluppatori possono lavorare con altri cloni e snapshot, senza interferenze e senza creare troppe copie della tabella di base che consumano risorse.
Gli sviluppatori possono unire le modifiche alla tabella di base mantenendo lo snapshot sicuro da utilizzare come opzione di rollback, se necessario. Questo processo può essere ripetuto per ambienti diversi, come sviluppo, test e produzione.
Alternative ai cloni e agli snapshot delle tabelle
Esistono alternative all'utilizzo di cloni e snapshot di tabelle che consentono di ottenere un risultato simile. Questi metodi alternativi vengono in genere utilizzati in modo diverso rispetto a cloni e snapshot. È importante comprendere le differenze tra questi metodi e in quali casi potresti preferirne uno all'altro.
Copiare intere tabelle in un altro set di dati
Un metodo alternativo consiste nell'utilizzare un set di dati diverso e copiare le tabelle in questo set di dati. L'utilizzo di questo metodo è simile all'utilizzo di cloni e snapshot di tabelle, ma copi l'intero insieme di tabelle. A seconda delle dimensioni dei dati copiati, i costi di archiviazione potrebbero essere elevati. Alcune organizzazioni utilizzavano questo metodo prima che i cloni di 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. Uno dei vantaggi di questo metodo è che ti offre un backup aggiuntivo dei tuoi dati. Puoi scegliere questo metodo se vuoi un backup per il ripristino di emergenza o soluzioni ibride.
Utilizzare BigQuery sharing
La condivisione BigQuery (precedentemente Analytics Hub) consente di condividere i set di dati sia all'esterno che all'interno dell'organizzazione in modo progettato per essere sicuro. Offre molte funzionalità che 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 la condivisione di BigQuery per esporre i set di dati per implementare le modifiche, uno sviluppatore deve comunque creare cloni delle 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. La condivisione offre un insieme di funzionalità diverso e pertanto non è misurabile utilizzando i parametri elencati nella tabella.
| Costi | Rollback | Rischi | |
|---|---|---|---|
| Snapshot e cloni delle tabelle | Minima. Paghi solo la differenza tra lo snapshot o il clone e la tabella di base. | Lo snapshot funge da backup a cui eseguire il rollback, se necessario. | Sei tu a controllare 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 della tabella | Costi più elevati rispetto all'utilizzo di snapshot e cloni delle tabelle. L'intero set di dati viene duplicato. Per supportare i rollback, devi avere più copie della stessa tabella. | Possibile, ma richiede due copie della tabella: una copia da utilizzare come backup e una copia da utilizzare per apportare modifiche. | La clonazione è più difficile da eseguire per un momento specifico. Se è necessario un rollback, non tutte le tabelle vengono prese dallo stesso momento. |
| Esportazione e importazione | Costi più elevati rispetto all'utilizzo di snapshot e cloni delle 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 puntuale 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 di software in DevOps tech: Continuous integration.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora Cloud Architecture Center.