Casi d'uso per il ripristino di emergenza: applicazioni di analisi dei dati limitate a livello di località

Last reviewed 2024-07-20 UTC

Questo documento fa parte di una serie che tratta Ripristino di emergenza (RE) in Google Cloud. Questo documento descrive come applicare le limitazioni per le località indicate nel documento. Architettura del ripristino di emergenza per carichi di lavoro con limitazioni a livello di località alle applicazioni di analisi dei dati. Nello specifico, questo documento descrive come i componenti utilizzati in una piattaforma di analisi dei dati si adattano in un'architettura di RE che soddisfi le limitazioni relative alle località che le tue applicazioni o dati.

La serie è costituita dai seguenti componenti:

Questo documento è rivolto agli architetti di sistemi e ai responsabili IT. Presuppone di possedere le seguenti conoscenze e competenze:

Requisiti della località per una piattaforma di analisi dei dati

Le piattaforme di analisi dei dati sono in genere applicazioni complesse a più livelli che archiviano i dati at-rest. Questi le applicazioni producono eventi che vengono elaborati e archiviati di un sistema operativo completo. Sia l'applicazione stessa sia i dati archiviati nel sistema soggetti alle normative locali. Queste normative variano non solo paesi, ma anche nei verticali di settore. Pertanto, devi avere una è chiara la comprensione i requisiti per le località dei dati prima di iniziare a progettare la tua architettura di RE.

Puoi determinare se la tua piattaforma di analisi dei dati ha una località di sicurezza rispondendo a queste due domande:

  • Il deployment dell'applicazione deve essere eseguito in una regione specifica?
  • I tuoi dati at-rest sono limitati a una regione specifica?

Se la tua risposta è "no" a entrambe le domande, la piattaforma di analisi dei dati hai requisiti specifici per la località. Poiché la tua piattaforma non dispone di requisiti locali, segui le indicazioni di RE per servizi conformi e descritti in Guida alla pianificazione del ripristino di emergenza.

Tuttavia, se rispondi "sì", a una delle domande, la tua applicazione limitato a una località. Poiché la tua piattaforma di analisi è soggetta a limitazioni per località, devi porre la seguente domanda: È possibile utilizzare tecniche di crittografia per attenuare i requisiti relativi ai dati at-rest?

Se puoi utilizzare le tecniche di crittografia, puoi usare la crittografia multiregionale e i servizi a due regioni di Cloud External Key Manager e Cloud Key Management Service. Puoi anche seguire le tecniche standard di alta disponibilità e ripristino di emergenza (HA/RE) descritte in Scenari di ripristino di emergenza per i dati.

Se non riesci a utilizzare le tecniche di crittografia, devi usare soluzioni personalizzate. per la pianificazione del RE. Per ulteriori informazioni sulle tecniche di gestire le limitazioni delle località per gli scenari di RE, consulta Architettura del ripristino di emergenza per carichi di lavoro con limitazioni a livello di località.

Componenti di una piattaforma di analisi dei dati

Una volta compresi i requisiti per le località, il passaggio successivo consiste nel comprendere utilizzati dalla tua piattaforma di analisi dei dati. Alcuni componenti comuni di analisi dei dati sono database, data lake, pipeline di elaborazione data warehouse, come descritto nell'elenco seguente:

  • Google Cloud offre servizi di database per diversi casi d'uso.

  • I data lake, i data warehouse e le pipeline di elaborazione possono avere definizioni diverse. Questo documento utilizza un insieme di definizioni fare riferimento ai servizi Google Cloud:

    • R data lake è una piattaforma scalabile e sicura per l'importazione e l'archiviazione di dati sistemi diversi. Un tipico data lake potrebbe utilizzare Cloud Storage il repository centrale di archiviazione.
    • Una pipeline di elaborazione è un processo end-to-end che prende i dati o eventi da uno o più sistemi, trasforma i dati o gli eventi e li carica in un altro sistema. La pipeline può seguire processo ETL (Extract, Transform, Load) o ELT (Extract, Load, Transform). Di solito, il sistema in cui vengono caricati i dati elaborati è un warehouse. Pub/Sub, Dataflow e Dataproc sono componenti comunemente utilizzati di una pipeline di elaborazione.
    • R data warehouse è un sistema aziendale usato per l'analisi e il reporting di dati, che di solito proviene da un database operativo. BigQuery è un sistema di data warehouse di uso comune in esecuzione su Google Cloud.

A seconda dei requisiti della località e dei componenti di analisi dei dati che l'effettiva implementazione di RE varia. Le seguenti sezioni di dimostrare questa variante con due casi d'uso.

Caso d'uso batch: un job ETL periodico

Il primo caso d'uso descrive un processo batch in cui una piattaforma di vendita al dettaglio raccoglie periodicamente gli eventi di vendita sotto forma di file da varie archivia e scrive i file in un bucket Cloud Storage. La il seguente diagramma illustra l'architettura di analisi dei dati per questo il job batch del rivenditore.

Diagramma dell'architettura di un caso d'uso in batch che riguarda i dati dei point of sale.

L'architettura include le fasi e i componenti seguenti:

  • La fase di importazione è composta dai negozi che inviano i loro i dati dei point of sale (POS) in Cloud Storage. Questi dati hanno importato è in attesa di elaborazione.
  • La fase di orchestrazione utilizza Cloud Composer per l'orchestrazione la pipeline batch end-to-end.
  • La fase di elaborazione prevede l'esecuzione di un job Apache Spark su di un cluster Dataproc. Il job Apache Spark esegue un ETL sui dati importati. Questo processo ETL fornisce metriche aziendali.
  • La fase di data lake prende i dati elaborati e archivia le informazioni nei seguenti componenti:
      .
    • I dati elaborati vengono comunemente archiviati in Cloud Storage formati a colonne come Parquet e ORC perché questi formati consentono un'archiviazione efficiente e un accesso più rapido carichi di lavoro analitici.
    • I metadati relativi ai dati di processo (ad esempio database, tabelle, colonne e partizioni) vengono archiviate nel servizio metastore Hive fornito da Dataproc Metastore.

In scenari con limitazioni per le località, potrebbe essere difficile fornire servizi ridondanti di elaborazione e orchestrazione per mantenere la disponibilità. Poiché i dati vengono elaborati in batch, le pipeline di elaborazione e orchestrazione possono e i job batch potrebbero essere riavviati dopo che uno scenario di emergenza risolto. Pertanto, per il ripristino di emergenza, l'attenzione si concentra principalmente sul ripristino dati effettivi: i dati POS importati, i dati elaborati archiviati nel data lake e i metadati archiviati nel data lake.

Importazione in Cloud Storage

Devi considerare innanzitutto i requisiti di località per il Bucket Cloud Storage utilizzato per importare i dati dal POS di un sistema operativo completo. Utilizza queste informazioni sulla località per valutare le seguenti opzioni:

  • Se i requisiti relativi alle località consentono che i dati at-rest si trovino in uno dei località a più regioni o a due regioni, scegli la località corrispondente quando crei il bucket Cloud Storage. Il tipo di località che scegli definisce le regioni Google Cloud utilizzate di replicare i dati at-rest. Se si verifica un'interruzione in una delle regioni, i dati che risiede in bucket a più regioni o a due regioni è ancora accessibile.
  • Cloud Storage supporta anche chiavi di crittografia gestite dal cliente (CMEK) e chiavi di crittografia fornite dal cliente (CSEK). Alcune regole per le località consentono l'archiviazione dei dati at-rest in più località quando utilizzi CMEK o CSEK per la gestione delle chiavi. Se le regole per le località consentono l'uso di CMEK o CSEK, puoi progettare l'architettura di RE da utilizzare regioni di Cloud Storage.
  • I requisiti relativi alle località potrebbero non consentirti di utilizzare nessuna delle due località o la gestione delle chiavi di crittografia. Se non puoi usare i tipi di località o la gestione delle chiavi di crittografia, puoi utilizzare gcloud storage rsync per sincronizzare i dati in un'altra posizione, ad esempio on-premise di archiviazione o archiviazione di un altro cloud provider.

In caso di emergenza, i dati POS importati in Cloud Storage del bucket potrebbe contenere dati che non sono stati ancora elaborati e importati data lake. In alternativa, i dati dei POS potrebbero non essere importati nel bucket Cloud Storage. In questi casi, si verifica la seguente calamità opzioni di recupero:

  • Lascia che sia il sistema POS a riprovare. Nel caso in cui il sistema non sia in grado di scrivere i dati POS in Cloud Storage, il processo di importazione dati non va a buon fine. Per mitigare questa situazione, puoi implementare una strategia di nuovo tentativo per consentire al sistema POS di riprovare a eseguire l'operazione di importazione dati. Poiché Cloud Storage offre alta durabilità, l'importazione dati e la successiva pipeline di elaborazione riprendi con una perdita di dati minima o nulla dopo il servizio Cloud Storage .

  • Crea copie dei dati importati. Cloud Storage supporta più regioni e due regioni tipi di località. A seconda dei requisiti per le località dei dati, potresti essere in grado di configurare bucket Cloud Storage a più regioni o a due regioni per aumentare i dati la disponibilità del servizio. Puoi anche usare strumenti come gcloud storage Comando Google Cloud CLI per sincronizzare dati tra Cloud Storage e in un'altra posizione.

Orchestrazione ed elaborazione dei dati POS importati

Nel diagramma dell'architettura per il caso d'uso batch, Cloud Composer esegue questi passaggi:

  • Verifica che i nuovi file siano stati caricati nel Bucket Cloud Storage di importazione.
  • Avvia un cluster Dataproc temporaneo.
  • Avvia un job Apache Spark per elaborare i dati.
  • Elimina il cluster Dataproc al termine del job.

Cloud Composer utilizza grafo diretto aciclico (DAG) che definiscono questa serie di passaggi. Questi file DAG sono archiviati in Bucket Cloud Storage non mostrato nel diagramma dell'architettura. Nella termini di località a due e più regioni, le considerazioni di RE per I bucket dei file DAG sono gli stessi di quelli discussi per il bucket di importazione.

I cluster Dataproc sono temporanei. In altre parole, i cluster finché è in esecuzione la fase di elaborazione. Questa natura temporanea implica che non devi fare nulla in modo esplicito per il RE in relazione di cluster Dataproc.

Archiviazione nei data lake con Cloud Storage

Il bucket Cloud Storage che utilizzi per il data lake ha lo stesso considerazioni sulle località come quelle discusse per il bucket di importazione: considerazioni relative a due e più regioni, l'uso della crittografia e l'utilizzo del comando gcloud CLI di gcloud storage rsync.

Quando progetti il piano di RE per il tuo data lake, considera quanto segue: aspetti:

  • Dimensione dei dati. Il volume dei dati in un data lake può essere grande. Ripristino di un un grande volume di dati richiede tempo. In uno scenario di RE, è necessario considerare l'impatto che il volume del data lake ha sul tempo richiesto
    per ripristinare i dati in un punto che soddisfa i seguenti criteri:

    Per il caso d'uso attuale in modalità batch, Cloud Storage è utilizzato della località del data lake e offre un'elevata durabilità. Tuttavia, gli attacchi ransomware sono in aumento. Per assicurarti di avere la possibilità per riprendersi da tali attacchi, sarebbe prudente seguire le best practice descritte in questo articolo: In che modo Cloud Storage offre 11 nove di durabilità.

  • Dipendenza dai dati. I dati nei data lake vengono solitamente utilizzati da altri i componenti di un sistema di analisi dei dati, ad esempio una pipeline di elaborazione. In un RE, la pipeline di elaborazione e i dati da cui dipende deve condividere lo stesso RTO. In questo contesto, concentrati su quanto tempo puoi avere il sistema non sarà disponibile.

  • Età dei dati. I dati storici potrebbero consentire un RPO più elevato. Questo tipo di I dati potrebbero essere già stati analizzati o elaborati da altre analisi di dati e potrebbe essere stata persistente in un altro componente che ha strategie di RE. Ad esempio, i dati sulle vendite esportati in vengono importati giornalmente in BigQuery per e analisi. Con le giuste strategie di RE per BigQuery, i record delle vendite importati in BigQuery potrebbero con obiettivi di recupero inferiori rispetto a quelli che non sono stati importati.

Archiviazione dei metadati dei data lake con Dataproc Metastore

Dataproc Metastore è un servizio Metastore Apache Hive completamente gestito, ad alta disponibilità, con riparazione automatica e serverless. La Il metastore fornisce funzionalità di astrazione e individuazione dei dati. Il metastore può essere con backup e ripristinato in caso di emergenza. Anche il servizio Dataproc Metastore consente di esportare e importazione metadati. Puoi aggiungere un'attività per esportare il metastore e mantenere un il backup insieme al job ETL.

Se ti imbatti in una situazione di mancata corrispondenza dei metadati, puoi ricreare il metastore dai dati stessi utilizzando MSCK .

Caso d'uso per i flussi di dati: cambiare l'acquisizione dei dati con ELT

Il secondo caso d'uso descrive una piattaforma di vendita al dettaglio che utilizza la tecnologia CDC (Change Data Capture) per aggiornare l'inventario di backend e monitorare le metriche sulle vendite in tempo reale. Il seguente diagramma mostra un in cui gli eventi provenienti da un database transazionale, come vengono elaborati e quindi archiviati in un data warehouse.

Diagramma dell'architettura di un caso d'uso di flussi di dati che prevede l'acquisizione dei dati di variazione dei dati di vendita al dettaglio.

L'architettura include le fasi e i componenti seguenti:

  • La fase di importazione è composta dagli eventi di modifica in arrivo tramite push in Pub/Sub. Come servizio di consegna dei messaggi, Pub/Sub viene utilizzato per importare e distribuire in modo affidabile e analisi dei dati. Pub/Sub offre i vantaggi aggiuntivi di essere scalabili e serverless.
  • La fase di elaborazione prevede l'utilizzo di Dataflow eseguire un processo ELT sugli eventi importati.
  • La fase di data warehouse utilizza BigQuery per archiviare elaborati. L'operazione di unione inserisce o aggiorna un record in BigQuery. Questa operazione consente alle informazioni BigQuery per restare al passo con il database transazionale.

Sebbene questa architettura CDC non si basi su Cloud Composer, alcuni CDC richiedono Cloud Composer di orchestrare l'integrazione il flusso in carichi di lavoro batch. In questi casi, Cloud Composer il flusso di lavoro implementa controlli di integrità, backfill e proiezioni in tempo reale a causa di vincoli di latenza. tecniche di RE per Cloud Composer è discusso nella caso d'uso dell'elaborazione batch di cui abbiamo parlato in precedenza.

Per una pipeline di dati in modalità flusso, dovresti considerare quanto segue quando pianifichi dell'architettura di RE:

  • Dipendenze della pipeline. Le pipeline di elaborazione ricevono input da uno più sistemi (le sorgenti). Le pipeline poi elaborano, trasformano e archiviano questi input in altri sistemi (i sink). È importante progettare l'architettura di RE per raggiungere il tuo RTO end-to-end. Devi assicurarti che l'RPO dei sink e delle origini dati ti consenta di rispettare l'RTO. Nella oltre a progettare l'architettura cloud in modo da soddisfare le esigenze della tua località dovrai anche progettare le origini CDC di origine per il tuo RTO end-to-end sarà soddisfatto.
  • Crittografia e località. Se la crittografia ti consente di mitigare limitazioni in base alle località, puoi utilizzare Cloud KMS, per raggiungere i seguenti obiettivi:
      .
    • Gestisci le tue chiavi di crittografia.
    • Sfruttare le funzionalità di crittografia dei singoli servizi.
    • Esegui il deployment di servizi in regioni che altrimenti non sarebbero disponibili da utilizzare a causa delle limitazioni relative alle località.
  • Regole di località sui dati in movimento. Potrebbero essere applicate alcune regole per le località solo ai dati at-rest, ma non ai dati in movimento. Se la tua località regola non si applicano ai dati in movimento, progetta l'architettura di RE da utilizzare in altre regioni per migliorare gli obiettivi di recupero. Puoi integrare l'approccio regionale integrando tecniche di crittografia.

Importazione in Pub/Sub

Se non hai limitazioni per le località, puoi pubblicare messaggi nel endpoint Pub/Sub globale. Gli endpoint Pub/Sub globali sono visibili e accessibili da qualsiasi località di Google Cloud.

Se i requisiti per le località consentono l'uso della crittografia, è possibile: configurare Pub/Sub per ottenere un livello simile di alta disponibilità come endpoint globali. Sebbene i messaggi Pub/Sub siano criptati le chiavi di proprietà di Google e gestite da Google per impostazione predefinita, configurare Pub/Sub per utilizzare CMEK . Utilizzando Pub/Sub con CMEK, puoi conoscere la località sulla crittografia, mantenendo al contempo una disponibilità elevata.

Alcune regole per le località richiedono che i messaggi rimangano in una località specifica anche dopo la crittografia. Se le regole per le località hanno questa restrizione, puoi specificare il criteri di archiviazione dei messaggi di un argomento Pub/Sub e limitarlo a una regione. Se utilizzi questo di archiviazione dei messaggi, i messaggi pubblicati in un argomento non vengono mai al di fuori del set di regioni Google Cloud da te specificate. Se le regole per le località consentono di utilizzare più di una regione Google Cloud, puoi aumentare la disponibilità del servizio abilitando queste regioni nel Pub/Sub. Tieni presente che l'implementazione di un messaggio per limitare le località delle risorse Pub/Sub, con pro e contro la disponibilità.

Una sottoscrizione Pub/Sub consente di archiviare i messaggi non confermati fino a 7 giorni senza alcuna limitazione sul numero di messaggi. Se il tuo servizio di accordo di livello consente dati ritardati, puoi eseguirne il buffering Sottoscrizione Pub/Sub in caso di interruzione dell'esecuzione delle pipeline. Quando le pipeline vengano nuovamente in esecuzione, puoi elaborare gli eventi di cui è stato eseguito il backup. Questo design ha il vantaggio di avere un RPO basso. Per ulteriori informazioni sulla risorsa limiti per Pub/Sub, consulta limiti delle risorse per le quote Pub/Sub.

Elaborazione degli eventi con Dataflow

Dataflow è un servizio gestito per l'esecuzione di un'ampia gamma pattern di elaborazione dei dati. L'SDK Apache Beam è un modello di programmazione open source che consente di sviluppare sia in batch pipeline di flusso. Crei le tue pipeline con un programma Apache Beam quindi eseguirle sul servizio Dataflow.

Quando progetti per i limiti di località, devi considerare si trovano origini, sink e file temporanei. Se queste posizioni dei file sono all'esterno della regione del job, i tuoi dati potrebbero essere inviati tra regioni diverse. Se le tue consentono di elaborare i dati in una località diversa, quindi progetta di RE per il deployment di worker in altre regioni Google Cloud al fine di fornire l'alta disponibilità.

Se le limitazioni per le tue località limitano l'elaborazione a una sola località, puoi: crea un job Dataflow limitati a una regione o zona specifica. Quando invii un nel job Dataflow, puoi specificare endpoint regionale, regione worker e zona worker parametri. Questi parametri controllano dove viene eseguito il deployment dei worker e dove viene eseguito di archiviazione dei metadati.

Apache Beam fornisce un framework che consente l'esecuzione di pipeline vari runner. Puoi progettare la tua architettura di RE per sfruttare funzionalità. Ad esempio, potresti progettare un'architettura di RE per avere un backup in esecuzione sul tuo cluster Spark on-premise locale utilizzando Apache Spark Runner. Per informazioni sulla capacità di un runner specifico di eseguire un una determinata operazione della pipeline, Matrice della capacità di trasmissione.

Se la crittografia consente di mitigare le limitazioni relative alla località, puoi utilizzare CMEK in Dataflow sia per criptare gli artefatti dello stato della pipeline sia per accedere a origini e sink che sono con chiavi Cloud KMS. Utilizzando la crittografia, puoi progettare un RE che utilizza regioni che altrimenti non sarebbero disponibili a causa limitazioni in base alle località.

Data warehouse basato su BigQuery

I data warehouse supportano l'analisi e il processo decisionale. Oltre a contenere un analitico, i data warehouse contengono più componenti analitici e le procedure del caso.

Quando progetti il piano di RE per il tuo data warehouse, considera quanto segue: caratteristiche:

  • Dimensioni. I data warehouse sono molto più grandi delle transazioni online per l'elaborazione dei dati (OLTP). Non è raro che i data warehouse abbiano da terabyte a petabyte di dati. Devi considerare quanto tempo ci vorrà per ripristinare questi dati e raggiungere i valori RPO e RTO. Quando pianifichi strategia di RE, devi anche tenere conto del costo associato al recupero di terabyte di dati. Per ulteriori informazioni sulle tecniche di mitigazione di RE per BigQuery, vedi le relative informazioni nel attiva meccanismi di backup e ripristino per i servizi di database gestiti su Google Cloud.

  • Disponibilità. Quando crei un set di dati BigQuery, seleziona una posizione in cui archiviare i dati: regionale o più regioni. Per località regionale si intende una singola località geografica specifica, ad esempio Iowa (us-central1) o Montréal (northamerica-northeast1). Una località con più regioni località è una vasta area geografica, come gli Stati Uniti (USA) o Europa (UE), che contiene due o più luoghi geografici.

    Quando si progetta il piano di RE per soddisfare le limitazioni relative alle località, il dominio in errore (ovvero a livello di macchina, di zona o di regione) avere un impatto diretto sul raggiungimento dell'RTO definito. Per ulteriori informazioni su questi domini in errore e sul modo in cui influiscono sulla disponibilità, consulta Disponibilità e durabilità di BigQuery.

  • Natura dei dati. I data warehouse contengono informazioni storiche, e la maggior parte dei dati meno recenti è spesso statica. Molti data warehouse progettati per essere solo append. Se il data warehouse è in modalità di sola aggiunta, puoi raggiungere il tuo RTO ripristinando solo i dati aggiunto. Con questo approccio, esegui il backup solo dei dati aggiunti. Se esiste un sarai in grado di ripristinare i dati aggiunti e di avere data warehouse disponibile per l'uso, ma con un sottoinsieme di dati.

  • Pattern di aggiunta e aggiornamento dei dati. I data warehouse sono in genere aggiornato utilizzando i pattern ETL o ELT. Se hai controllato i percorsi di aggiornamento, puoi riprodurre gli eventi di aggiornamento recenti da fonti alternative.

I requisiti per le località potrebbero limitare la possibilità di utilizzare una sola regione o più regioni per il tuo data warehouse. Sebbene BigQuery l'archiviazione in più regioni è la soluzione più semplice un modo conveniente per garantire la disponibilità dei dati in caso di emergenza. Se l'archiviazione multiregionale non è disponibile in la tua regione, ma puoi utilizzarne un'altra, utilizza BigQuery Data Transfer Service per copiare il set di dati in un'altra regione. Se puoi utilizzare la crittografia per mitigare i requisiti di località, puoi gestire le tue chiavi di crittografia con Cloud KMS e BigQuery.

Se puoi utilizzare una sola regione, valuta la possibilità di eseguire BigQuery tabelle. La soluzione più conveniente per le tabelle di backup è utilizzare Esportazioni BigQuery. Utilizza le funzionalità di Cloud Scheduler o Cloud Composer per pianificare periodicamente un job di esportazione in modo che scriva in Cloud Storage. Tu è possibile usare formati come Avro con compressione SNAPPY o JSON con compressione GZIP. Mentre stai progettando le tue strategie di esportazione, prendi nota limiti sulle esportazioni.

Potresti anche voler archiviare i backup di BigQuery in una colonna come Parquet e ORC. Forniscono un'elevata compressione e consentono all'interoperabilità con molti motori open source, come Hive e Presto, che che potresti avere nei tuoi sistemi on-premise. Il seguente diagramma illustra le processo di esportazione dei dati di BigQuery in un formato a colonne per l'archiviazione in una posizione on-premise.

Diagramma dell'architettura che mostra l'esportazione dei dati di BigQuery in uno spazio di archiviazione a colonne per il ripristino di emergenza.

Nello specifico, questo processo di esportazione dei dati di BigQuery una località di archiviazione on-premise prevede i seguenti passaggi:

  • I dati BigQuery vengono inviati a un job Apache Spark su Dataproc. L'uso del job Apache Spark consente dell'evoluzione dello schema.
  • Una volta che il job Dataproc ha elaborato nei file BigQuery, i file elaborati vengono scritti Cloud Storage e quindi trasferito in una località di RE on-premise.
  • Cloud Interconnect viene utilizzato per connettere la tua rete Virtual Private Cloud alla rete on-premise.
  • Il trasferimento alla località di ripristino di emergenza on-premise può avvenire mediante il job Spark.

Se la progettazione del warehouse è di sola aggiunta ed è partizionata per data, devi crea una copia delle partizioni richieste in una nuova tabella prima di esegui un job di esportazione BigQuery nella nuova tabella. Dopodiché puoi usare uno strumento come gcloud storage Comando gcloud CLI per trasferire i file aggiornati al backup una località on-premise o in un altro cloud. Potrebbero essere applicati costi per il traffico in uscita da Google Cloud.

Ad esempio, hai un data warehouse delle vendite composto da un'istruzione Tabella orders in cui i nuovi ordini vengono aggiunti alla partizione che rappresenta la data corrente. Tuttavia, le norme sui resi potrebbero consentire la restituzione degli articoli entro 7 giorni. Di conseguenza, i record nella tabella orders degli ultimi 7 giorni. Le tue strategie di esportazione devono rispettare le norme sui resi in considerazione. In questo esempio, qualsiasi job di esportazione per eseguire il backup della tabella orders deve per esportare anche le partizioni che rappresentano gli ordini degli ultimi 7 giorni in evitare di perdere aggiornamenti a causa dei resi.

Passaggi successivi

Collaboratori

Autori: