Integrazione continua dei dati in BigQuery

Questo documento descrive i principi e le tecniche per implementare un flusso di lavoro ripetibile che ti aiuterà a integrare le modifiche dei 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 è composto da architetti di dati e software e data engineer che utilizzano BigQuery come DWH. Il documento presuppone che tu abbia familiarità con 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 del software. L'adozione dei principi di CI/CD consente ai team di offrire software migliore con meno problemi rispetto all'integrazione delle funzionalità e al deployment manuale. CI/CD può anche essere 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 in parte perché il data warehousing è un sistema intrinsecamente stateful per la gestione dei dati sottostanti.

Il presente documento fornisce le seguenti informazioni:

  • Tecniche per implementare una strategia di integrazione continua (CI) in BigQuery.
  • Consigli e metodi che ti aiutino a evitare le insidie.
  • Suggerimenti per le funzionalità di BigQuery che aiutano con CI in BigQuery.

Questo documento è incentrato sulla CI, perché per un team di data warehousing l'integrazione prevede considerazioni più specifiche dei dati rispetto alla distribuzione continua (CD).

Quando utilizzare CI per un DWH BigQuery

In questo documento, l'integrazione dei dati è un'attività generalmente eseguita dal team DWH, che include l'integrazione di nuovi dati nel datastore. Questa attività potrebbe comportare l'integrazione di una nuova origine dati nel datastore o la modifica della struttura di una tabella già all'interno del database.

L'integrazione di nuovi dati nel DWH è un'attività simile all'integrazione di una nuova funzionalità nel 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 mancate corrispondenze dello schema. Oppure i consumatori potrebbero utilizzare dati errati che non riflettono i dati dell'origine dati originale.

CI per DWH è utile quando vuoi:

  • Descrivere i punti chiave in CI per un sistema DWH.
  • Progettare e implementare una strategia CI per il tuo ambiente BigQuery.
  • Scopri come utilizzare le funzionalità di BigQuery per implementare la CI.

Questa guida non descrive come gestire CI per prodotti non DWH, inclusi prodotti di dati come Dataflow e Bigtable.

Scenario di esempio

Example Company è una grande azienda di vendita al dettaglio che gestisce il proprio DWH in BigQuery. L'anno prossimo, l'azienda vuole integrare nuove origini dati nel suo DWH dalle aziende recentemente acquisite dall'azienda di esempio. Le nuove origini dati da integrare hanno schemi diversi. Tuttavia, il DWH deve mantenere lo schema esistente e garantire una elevata coerenza e completezza dei dati in modo che i consumatori a valle dei dati non subiscano un impatto negativo.

Attualmente il team DWH di Example Company esegue l'integrazione dei dati. L'integrazione si basa sull'avere le origini dati esistenti in uno schema predefinito. Questo flusso di lavoro prevede processi di importazione dati legacy, database acquisiti e servizi per le applicazioni.

Per aggiornare i propri processi di integrazione dei dati in modo da renderli compatibili con le nuove origini dati, il team DWH deve riprogettare il proprio approccio all'integrazione dei dati per soddisfare i requisiti indicati in precedenza, come l'elevata 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 siano resi disponibili ai consumatori downstream.

Dopo che il team DWH ha adottato il nuovo flusso di lavoro, deve seguire un processo 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 applicare le modifiche necessarie all'ambiente di produzione. Se le modifiche causano bug o problemi imprevisti, possono essere facilmente ripristinate.

Che cosa significa l'integrazione continua per un sistema di riscaldamento centralizzato

L'integrazione continua (CI) è un insieme di pratiche che consente ai team di sviluppo di abbreviare i cicli di sviluppo e rilevare problemi nel codice più velocemente rispetto ai sistemi manuali. Il principale vantaggio dell'adozione di un approccio CI è la capacità di sviluppare rapidamente, riducendo i rischi di interferenze tra gli sviluppatori. Questo obiettivo viene raggiunto assicurando che il processo sia ripetibile, consentendo allo stesso tempo a ogni sviluppatore di lavorare in modo isolato dagli altri sviluppatori.

Questi principi si applicano anche quando un'organizzazione deve integrare i dati in un datastore, con alcune differenze. Nel contesto dello sviluppo software tipico, CI isola le modifiche al codice sorgente, che è stateless. Nel contesto dellCI;integrazione dei dati nei dati, CI integrazione 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 sia incentrato 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 in tuo possesso siano conformi ai requisiti aziendali? I dati sono affidabili per fungere da fonte attendibile? È importante testare i dati per aumentare il livello di confidenza nei dati che pubblichi da DWH. Per verificare, puoi eseguire un insieme di query, affermando che nei dati non mancano valori o affermando che contengono valori "errati".
  • Dance dei dati: riesci a visualizzare qualsiasi 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 sono suddivisi in molti sistemi che utilizzano strutture di dati diverse e specializzate. che includono database relazionali, database NoSQL e origini dati esterne. Per comprendere appieno i dati a disposizione, è necessario tenerne traccia. Devi anche capire come sono stati generati i dati e da dove sono stati generati.

Questi argomenti non rientrano nell'ambito di questa guida. Tuttavia, la tua strategia sui dati sarà utile per pianificare questi argomenti quando progetti un flusso di lavoro per il tuo team.

Configurazione tipica di BigQuery come DWH

Il seguente diagramma illustra una tipica progettazione di DWH per BigQuery. Mostra come i dati da fonti esterne vengono importati nel DWH e in che modo i consumatori consumano i dati dal datastore.

Tre database esterni a Google Cloud sono origini dati. I dati vengono spostati nello spazio di archiviazione in un'area temporanea. I dati vengono quindi spostati nelle tabelle BigQuery, che sono l'origine delle viste BigQuery. I consumer come Looker, App Engine, Vertex AI Notebooks e gli utenti umani utilizzano le viste.

I dati iniziano dalle origini dati, dove si trovano in database convenzionali transazionali o a bassa latenza come database SQL OLTP e NoSQL. Un processo pianificato copia i dati in un'area temporanea.

I dati vengono memorizzati temporaneamente nell'area temporanea. Se necessario, i dati vengono trasformati per adattarsi a un sistema analitico prima di essere caricati nelle tabelle DWH. In questo diagramma, l'area temporanea si trova all'interno di Google Cloud, ma non deve esserlo. Le trasformazioni possono includere la denormalizzazione, l'arricchimento di determinati set di dati o la gestione di voci non corrette (ad esempio, voci con valori mancanti).

Dall'area temporanea, i nuovi dati vengono caricati nelle tabelle DWH. Le tabelle potrebbero essere organizzate in modi diversi a seconda della struttura del DWH e sono generalmente definite tabelle con core. Alcuni esempi di paradigmi di progettazione delle tabelle includono il paradigma dello schema a stella, il paradigma denormalizzato e i dati aggregati multilivello.

Indipendentemente dalla loro struttura, queste tabelle consentono di risparmiare dati nel tempo. Le tabelle devono aderire allo schema e si presume che contengano la fonte attendibile per tutti gli scopi analitici. Questo ruolo per le tabelle indica che i dati in queste tabelle devono essere completi, coerenti e rispettare gli schemi predefiniti.

Queste tabelle non forniscono i dati direttamente ai consumatori. I dati vengono invece pubblicati attraverso un livello di accesso progettato per incapsulare la logica di business che deve essere applicata ai dati sottostanti. Esempi di questo tipo di logica di business sono il calcolo di una metrica per ogni record o il filtraggio e il raggruppamento dei dati.

I consumer dei dati possono connettersi e leggere i dati dal livello di accesso 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 su dati calcolati nel DWH
  • Utenti umani per query ad hoc

I consumatori dei dati fanno molto affidamento sul DWH per fornire schemi coerenti e sulla logica di business che il DWH incapsula. Questi schemi e logica di business possono essere considerati come 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 piattaforme dati moderne, al team DWH potrebbe essere richiesto di apportare queste modifiche, pur rispettando rigorosamente gli SLA. Per soddisfare questi SLA e mantenere aggiornato il DWH, il team ha bisogno di un flusso di lavoro che consenta l'integrazione dei dati e al contempo riduca al minimo l'attrito che potrebbero creare queste modifiche.

Asset per l'integrazione continua in un sistema DWH

Come per qualsiasi altro team IT o di sviluppo, il team DWH deve mantenere asset essenziali per le sue responsabilità. Questi asset possono essere in genere suddivisi nelle seguenti categorie:

  • Codebase per 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 o utilizzando soluzioni Google Cloud come Cloud Source Repositories e Cloud Build.

  • Script SQL: questi asset descrivono la struttura e la logica di business incapsulata all'interno del DWH. In 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 Manipolion Language (DML): questi asset vengono utilizzati per manipolare i dati all'interno di una tabella. I comandi DML servono anche per creare nuove tabelle basate su tabelle esistenti.
    • Linguaggio di controllo dei dati (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 bq oppure l'API REST di 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 convalida gli script SQL e verifica le regole di convalida predefinite nelle tabelle create dagli script DDL. Questi strumenti 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 agli strumenti e ai processi, l'asset principale per un team di DWH sono i dati. I dati non sono tracciabili usando sistemi di monitoraggio degli asset come Git, progettato per tenere traccia del codice sorgente. Questo documento risolve 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. Non è possibile applicare pratiche standard nello sviluppo software allo scenario di integrazione dei dati.

La seguente tabella riassume le differenze tra le pratiche per l'integrazione del codice e le pratiche per l'integrazione dei dati.

  Integrazione del codice Integrazione dei dati
Sviluppo locale Il codice sorgente è facilmente clonato a causa delle sue dimensioni relativamente ridotte. In genere il codice si adatta alla maggior parte delle macchine degli utenti finali (esclusi i casi di monoorepos, che hanno altre soluzioni). La maggior parte delle tabelle in un file DWH non può essere adattata a una macchina di sviluppo a causa delle dimensioni.
Test centrali diversi stati del codice sorgente vengono clonati in un sistema centrale (un server CI) per essere sottoposti a test automatici. Avere stati diversi del codice consente di confrontare i risultati tra una versione stabile e una versione di sviluppo. Creare stati diversi dei dati in un ambiente isolato non è facile. Lo spostamento dei dati al di fuori del datastore richiede molte risorse e molto tempo. Non è pratico eseguire la stessa frequenza necessaria per i test.
Versioni precedenti Durante il processo di rilascio delle nuove versioni del software, puoi tenere traccia delle 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 nel caso in cui sia necessario eseguire il rollback. Tuttavia, devi assicurarti che venga eseguito il rollback di tutte le tabelle interessate allo stesso momento. In questo modo, le tabelle correlate sono coerenti tra loro.

Integra i dati nelle tabelle BigQuery

BigQuery offre due funzionalità che possono aiutarti a progettare un flusso di lavoro per l'integrazione dei dati: snapshot di tabelle e cloni di tabelle. Puoi combinare queste funzionalità per ottenere un flusso di lavoro che offra un ambiente di sviluppo a costi contenuti. Gli sviluppatori possono manipolare i dati e la loro struttura in modo isolato dall'ambiente di produzione e, se necessario, possono eseguire il rollback di una modifica.

Uno snapshot di una 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 in lettura e 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 cloni delle tabelle iniziano a generare costi quando la tabella di base viene modificata o quando cambiano i cloni della tabella. Poiché gli snapshot della tabella 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 creare snapshot delle tabelle e cloni di tabelle utilizzando la funzionalità di viaggio nel tempo di BigQuery (fino a sette giorni prima). Questa funzionalità consente di acquisire snapshot e cloni di più tabelle nello stesso momento, rendendo l'ambiente di lavoro e gli snapshot coerenti tra loro. L'uso di questa funzionalità può essere utile per le tabelle che vengono aggiornate di frequente.

Come utilizzare cloni e snapshot delle tabelle per consentire l'isolamento

Per illustrare il flusso di lavoro di integrazione per CI in un DWH, immagina lo scenario riportato di seguito. Ti viene assegnata l'attività di integrare un nuovo set di dati nel DWH. L'attività potrebbe essere creare nuove tabelle DWH, aggiornare le tabelle esistenti, modificare la struttura delle tabelle o qualsiasi combinazione di queste attività. Il flusso di lavoro potrebbe essere come la seguente sequenza:

  1. Identifica le tabelle che potrebbero essere interessate dalle modifiche e le tabelle aggiuntive che potresti voler controllare.
  2. Devi creare un nuovo set di dati BigQuery che contenga gli asset per questa modifica. Questo set di dati aiuta a isolare le modifiche e separa questa attività dalle altre su cui lavorano 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 soddisfare i requisiti di sicurezza e fatturazione della tua organizzazione.

  3. Per ogni tabella, crei sia un clone che uno snapshot nel nuovo set di dati, potenzialmente per lo stesso momento. Questo approccio offre i seguenti vantaggi:

    • Il clone della tabella può fungere da copia funzionante in cui puoi apportare modifiche liberamente senza influire sulla tabella di produzione. Puoi creare più cloni di tabella della stessa tabella di base per testare diversi percorsi di integrazione contemporaneamente, con un overhead minimo.
    • Lo snapshot può fungere da punto di ripristino e di riferimento, un punto in cui è noto il funzionamento dei dati prima che venisse apportata qualsiasi modifica. Questo snapshot ti consente di eseguire un rollback nel caso in cui un problema venga rilevato in un secondo momento durante il processo.

  4. Puoi utilizzare 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.

  5. Facoltativamente, alla fine della fase di implementazione, puoi presentare un set di dati da utilizzare per le attività seguenti:

    • Test delle unità con uno strumento di convalida come Dataform. I test delle unità sono autonomi, il che significa che l'asset viene testato in modo isolato. In questo caso, l'asset è la tabella in BigQuery. I test delle unità possono verificare la presenza di valori nulli, verificare che tutte le stringhe soddisfino i requisiti di lunghezza e garantire che determinati dati aggregati producano risultati utili. I test delle unità possono includere qualsiasi test di affidabilità che garantisce che la tabella conservi le regole aziendali dell'organizzazione.
    • Test di integrazione con i consumatori downstream.
    • Revisione dei compagni.

    Questo flusso di lavoro consente di eseguire test con i dati di produzione, senza influire sui consumatori downstream.

  6. Prima di unire i nuovi dati a BigQuery, puoi creare un altro snapshot. Questo snapshot è utile come altra opzione di rollback in caso di modifica dei dati della tabella di base.

    Il processo di unione delle modifiche dipende dalla procedura che l'organizzazione intende adottare e dalle modifiche richieste. Ad esempio, per una modifica negli 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 copiare i dati utilizzando i metodi standard di BigQuery.

Puoi utilizzare uno script di stored procedure per incapsulare e automatizzare i passaggi per la creazione di un set di dati e per la creazione di cloni e snapshot. L'automazione di queste attività riduce il rischio di errori umani. Per un esempio di uno script che può aiutare ad automatizzare i processi, consulta il repository GitHub CI per dati nell'utilità dell'interfaccia a riga di comando di BigQuery.

Vantaggi dell'utilizzo di cloni di tabelle e snapshot delle tabelle

Quando utilizzi il flusso di lavoro descritto nella sezione precedente, i tuoi sviluppatori possono lavorare in modo isolato e in parallelo senza interferire con i colleghi. Gli sviluppatori possono testare e rivedere le modifiche e, in caso di problemi, eseguirne il rollback. Poiché lavori con gli snapshot delle tabelle e non con le tabelle complete, puoi ridurre al minimo i costi e lo spazio di archiviazione rispetto all'uso di tabelle complete.

Questa sezione fornisce ulteriori dettagli su come gli snapshot delle tabelle e i cloni delle tabelle consentono agli sviluppatori di raggiungere questo flusso di lavoro. Il seguente diagramma mostra la correlazione tra gli snapshot e i cloni delle tabelle con i dati nel set di dati di produzione.

Un set di dati di produzione contiene nove tabelle. Un secondo set di dati denominato "Dev Dataset 1" contiene snapshot delle tabelle 2 e 3 e cloni delle tabelle 2 e 3. Un terzo set di dati denominato "Dev Dataset 2" contiene snapshot delle tabelle 3 e 4 e cloni delle tabelle 3 e 4.

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 di sviluppatori, etichettati Set di dati per sviluppatori 1 e Set di dati per sviluppatori 2. Grazie a questi set di dati, gli sviluppatori possono lavorare contemporaneamente sulle stesse tabelle senza interferire tra loro.

Dopo che gli sviluppatori hanno creato un set di dati, possono creare cloni e snapshot delle tabelle su cui stanno lavorando. cloni e snapshot rappresentano i dati in un determinato momento. A questo punto, gli sviluppatori possono cambiare 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 testarli per verificarne 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 troppe risorse.

Gli sviluppatori possono unire le modifiche nella tabella di base mantenendo sicuro lo snapshot come opzione di rollback, se necessario. Questo processo può anche essere ripetuto 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 snapshot che consentono di ottenere un risultato simile. Questi metodi alternativi vengono generalmente usati in modo diverso rispetto a cloni e snapshot. È importante comprendere le differenze tra questi metodi e capire dove potresti preferire un metodo rispetto all'altro.

Copia intere tabelle in un set di dati diverso

Un metodo alternativo è utilizzare un set di dati diverso e copiare le tabelle in quel set di dati. Questo metodo è simile all'uso di cloni e snapshot di 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'uso di cloni e snapshot.

Esporta e importa tabelle in Cloud Storage

Un altro metodo alternativo è spostare i dati tramite Cloud Storage. Questo metodo è simile anche all'utilizzo di cloni di tabelle 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 offre un ulteriore backup dei dati. Scegli questo metodo se vuoi un backup per il ripristino di emergenza o per soluzioni ibride.

Utilizza Analytics Hub

Analytics Hub consente di condividere i set di dati sia all'esterno che all'interno dell'organizzazione con modalità progettate per la sicurezza. Offre molte funzionalità che consentono di pubblicare set di dati per fornire agli abbonati un accesso controllato e di sola lettura a tali 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 DWH

La seguente tabella riassume le differenze, i vantaggi e i potenziali svantaggi tra le opzioni per l'integrazione continua di DWH. Analytics Hub offre un set di funzionalità diverso, pertanto non è misurabile con i parametri elencati nella tabella.

  Costi Rollback Rischi
Snapshot e cloni di tabelle Minimo. Paghi solo per 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 la quantità di rischi. 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 di tabelle. L'intero insieme dei dati viene duplicato. Per supportare i rollback, hai bisogno di più copie della stessa tabella. Possibile, ma richiede due copie della tabella: una copia da utilizzare come backup e una da utilizzare e da modificare. La clonazione è più difficile da eseguire per un determinato momento. Se è necessario un rollback, non tutte le tabelle vengono acquisite dallo stesso momento.
Esporta e importa Costi più elevati rispetto all'utilizzo di snapshot e cloni di tabelle. I dati vengono 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 point-in-time per più tabelle.

Passaggi successivi