Casi d'uso di ripristino di emergenza: applicazioni di analisi dei dati limitate alla località

Questo documento fa parte di una serie che parla del ripristino di emergenza in Google Cloud. Questo documento descrive come applicare le limitazioni di località del documento, Architecting recovery recovery for restricted-restricted workloads, alle applicazioni di analisi dei dati. In particolare, in questo documento viene spiegato come i componenti che utilizzi in una piattaforma di analisi dei dati si inseriscono in un'architettura DR che soddisfa le restrizioni di località a cui potrebbero essere applicati i tuoi dati o le tue applicazioni.

La serie è composta dalle seguenti parti:

Questo documento è destinato agli architetti e ai responsabili IT. Si presume che tu abbia le seguenti conoscenze e competenze:

Requisiti di 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 inattivi. Queste applicazioni producono eventi che vengono elaborati e archiviati nel sistema di analisi. Sia l'applicazione sia i dati archiviati nel sistema potrebbero essere soggetti alle normative sulla località. Queste normative variano non solo in tutti i paesi, ma anche nei verticali di settore. Di conseguenza, dovresti avere una comprensione chiara dei requisiti relativi alla posizione dei dati prima di iniziare a progettare l'architettura di richiesta di proposta.

Puoi determinare se la tua piattaforma di analisi dei dati ha requisiti relativi alla località rispondendo alle due domande seguenti:

  • Il deployment della tua applicazione deve essere eseguito in un'area geografica specifica?
  • I dati at-rest sono limitati a un'area geografica specifica?

Se rispondi "No" a entrambe le domande, la tua piattaforma di analisi dei dati non ha requisiti specifici in base alla località. La tua piattaforma non ha requisiti di località, segui le indicazioni relative alla RE per i servizi e i prodotti conformi descritti nella guida alla pianificazione del ripristino di emergenza.

Tuttavia, se rispondi "Sì" a una delle domande, la tua domanda verrà limitata. Poiché la tua piattaforma di analisi è limitata dalla località, devi porre la seguente domanda: Puoi utilizzare tecniche di crittografia per mitigare i requisiti dei dati inattivi?

Se puoi utilizzare le tecniche di crittografia, puoi utilizzare i servizi a più aree geografiche e due aree geografiche di Cloud External Key Manager e Cloud Key Management Service. Puoi anche seguire le tecniche standard ad alta disponibilità e di ripristino di emergenza descritte in Scenari di ripristino di emergenza per i dati.

Se non riesci a utilizzare le tecniche di crittografia, devi utilizzare soluzioni personalizzate o offerte di partner per la pianificazione DR. Per ulteriori informazioni sulle tecniche per risolvere le limitazioni di località per gli scenari DR, vedi Architettura di ripristino di emergenza per i carichi di lavoro con limitazioni di località.

Componenti in una piattaforma di analisi dei dati

Per comprendere i requisiti relativi alle località, il passaggio successivo è comprendere i componenti utilizzati dalla piattaforma di analisi dei dati. Alcuni componenti comuni della piattaforma di analisi dei dati sono database, data lake, pipeline di elaborazione e data warehouse, come descritto nel seguente elenco:

  • Google Cloud offre un set di servizi di database che si adattano a diversi casi d'uso.
  • I data lake, i data warehouse e le pipeline di elaborazione possono avere definizioni leggermente diverse. Questo documento utilizza un insieme di definizioni che fa riferimento ai servizi Google Cloud:
    • Un data lake è una piattaforma scalabile e sicura per importare e archiviare dati da più sistemi. Un tipico data lake potrebbe utilizzare Cloud Storage come repository di archiviazione centrale.
    • Una pipeline di elaborazione è un processo end-to-end che prende dati o eventi da uno o più sistemi, li trasforma e li carica in un altro sistema. La pipeline potrebbe seguire un processo di estrazione, trasformazione e caricamento (ETL) oppure estrazione, caricamento e trasformazione (ELT). In genere, il sistema in cui vengono caricati i dati elaborati è un data warehouse. Pub/Sub, Dataflow e Dataproc sono componenti comunemente utilizzati di una pipeline di elaborazione.
    • Un data warehouse è un sistema aziendale utilizzato per l'analisi e il reporting dei dati, che di solito proviene da un database operativo. BigQuery è un sistema di data warehouse di uso comune in esecuzione su Google Cloud.

L'implementazione effettiva del RE varia in base ai requisiti di località e ai componenti di analisi dei dati utilizzati. Le sezioni seguenti illustrano questa variante con due casi d'uso.

Caso d'uso collettivo: 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 come file di vari store e quindi scrive i file in un bucket Cloud Storage. Il seguente diagramma illustra l'architettura di analisi dei dati per questo job batch per il rivenditore.

Diagramma dell'architettura di un caso d'uso in batch che prevede dati sui point of sale.

L'architettura include le seguenti fasi e componenti:

  • La fase di importazione consiste nei negozi che inviano i propri dati point of sale (POS) a Cloud Storage. Questi dati importati sono in attesa di elaborazione.
  • La fase di orchestrazione utilizza Cloud Composer per orchestrare la pipeline batch end-to-end.
  • La fase di elaborazione prevede un job Apache Spark in esecuzione su un cluster Dataproc. Il job Apache Spark esegue un processo ETL sui dati importati. Questa procedura ETL fornisce metriche aziendali.
  • Nella fase data lake, i dati elaborati vengono archiviati e archiviati nei seguenti componenti:
    • I dati elaborati sono generalmente archiviati nei formati a colonna di Cloud Storage, ad esempio Parquet e ORC, perché questi formati consentono un'archiviazione efficiente e un accesso più rapido ai carichi di lavoro analitici.
    • I metadati sui dati di processo (come database, tabelle, colonne e partizioni) sono archiviati nel servizio metastore Hive fornito da Dataproc Metastore.

Negli scenari con limitazioni di località, potrebbe essere difficile fornire capacità di elaborazione e orchestrazione ridondanti per mantenere la disponibilità. Poiché i dati vengono elaborati in batch, è possibile ricreare le pipeline di elaborazione e orchestrazione e riavviare i job batch dopo la risoluzione di uno scenario di emergenza. Pertanto, per il ripristino di emergenza, l'obiettivo è recuperare i dati effettivi: i dati POS importati, i dati elaborati memorizzati nel data lake e i metadati archiviati nel data lake.

Importazione in Cloud Storage

La prima considerazione deve essere costituita dai requisiti della località per il bucket Cloud Storage utilizzato per importare i dati dal sistema POS. Utilizza queste informazioni sulla località quando valuti le seguenti opzioni:

  • Se i requisiti di località consentono ai dati at-rest di risiedere in una delle località a più aree geografiche o a due aree geografiche, scegli il tipo di località corrispondente quando crei il bucket Cloud Storage. Il tipo di località che scegli definisce le aree geografiche Google Cloud utilizzate per replicare i dati inattivi. Se si verifica un'interruzione del servizio in una delle aree geografiche, i dati che risiedono nei bucket a più aree geografiche o in due aree geografiche sono ancora accessibili.
  • Cloud Storage supporta anche le chiavi di crittografia gestite dal cliente (CMEK) e le chiavi di crittografia fornite dal cliente (CSEK). Alcune regole di località consentono di archiviare i dati inattivi in più località quando utilizzi CMEK o CSEK per la gestione delle chiavi. Se le regole di località consentono l'utilizzo di CMEK o CSEK, puoi progettare l'architettura DR in modo che utilizzi le aree geografiche di Cloud Storage.
  • I requisiti in base alla località potrebbero non consentire l'utilizzo dei tipi di località o della gestione delle chiavi di crittografia. Quando non puoi utilizzare i tipi di posizione o la gestione delle chiavi di crittografia, puoi utilizzare il comando gsutil rsync per sincronizzare i dati in un'altra posizione, ad esempio spazio di archiviazione on-premise o soluzioni di archiviazione da un altro cloud provider.

In caso di emergenza, i dati POS importati nel bucket Cloud Storage potrebbero contenere dati non ancora elaborati e importati nel data lake. In alternativa, potrebbe non essere possibile importare i dati POS nel bucket Cloud Storage. In questi casi, hai le seguenti opzioni di ripristino di emergenza:

  • Riprova il sistema POS. Nel caso in cui il sistema non sia in grado di scrivere i dati POS in Cloud Storage, il processo di importazione dei dati non riesce. Per mitigare questa situazione, puoi implementare un algoritmo di backoff esponenziale troncato per consentire al sistema POS di riprovare l'operazione di importazione dati. Poiché Cloud Storage offre una durabilità di 11 9, l'importazione dati e la pipeline di elaborazione successiva riprenderanno con una perdita di dati minima o nulla dopo il ripristino del servizio Cloud Storage.

  • Crea copie dei dati importati. Cloud Storage supporta i tipi di località sia a più aree geografiche che a due aree geografiche. A seconda dei requisiti relativi alla località dei dati, potresti essere in grado di configurare un bucket Cloud Storage a più aree geografiche o doppia area geografica per aumentare la disponibilità dei dati. Puoi anche utilizzare strumenti come gsutil per sincronizzare i dati tra Cloud Storage e un'altra posizione.

Orchestrazione ed elaborazione dei dati POS importati

Nel diagramma dell'architettura del caso d'uso in batch, Cloud Composer esegue i seguenti passaggi:

  • Convalida che sono stati caricati nuovi file nel bucket di importazione Cloud Storage.
  • Avvia un cluster Dataproc temporaneo.
  • Avvia un job Apache Spark per elaborare i dati.
  • Elimina il cluster Dataproc alla fine del job.

Cloud Composer utilizza file grafico aciclico diretto (DAG) che definiscono questa serie di passaggi. Questi file DAG sono archiviati in un bucket Cloud Storage non mostrato nel diagramma dell'architettura. In termini di località con due o più aree geografiche, le considerazioni sulla risposta diretta per il bucket dei file DAI sono le stesse discusse per il bucket di importazione.

I cluster Dataproc sono temporanei. Questo significa che i cluster esistono solo finché è in esecuzione la fase di elaborazione. Questa natura temporanea implica che non devi fare esplicitamente nulla per il RE relativamente ai cluster Dataproc.

Archiviazione dei data lake con Cloud Storage

Il bucket Cloud Storage che utilizzi per il data lake ha le stesse considerazioni sulla località di quelle discusse per il bucket di importazione: considerazioni su due aree geografiche e più aree geografiche, l'uso della crittografia e l'uso di gsutil rsync.

Quando progetti il piano DR per il tuo data lake, pensa ai seguenti aspetti:

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

    Per l'attuale caso d'uso in batch, Cloud Storage è utilizzato per la località del data lake e fornisce una durabilità di 11 nove. Tuttavia, gli attacchi di tipo ransomware sono in aumento. Per assicurarti di avere la possibilità di recuperare da tali attacchi, è prudente seguire le best practice descritte in In che modo Cloud Storage offre 11 Nove di durabilità.

  • Dipendenza dei dati. I dati nei data lake sono generalmente consumati da altri componenti di un sistema di analisi dei dati, come una pipeline di elaborazione. In uno scenario DR, la pipeline di elaborazione e i dati da cui dipende devono condividere lo stesso RTO. In questo contesto, concentrati sul periodo di tempo per cui il sistema non può essere disponibile.

  • Età dei dati. I dati storici potrebbero consentire un RPO più elevato. Questo tipo di dati potrebbe essere già stato analizzato o elaborato da altri componenti di analisi di dati e potrebbe essere stato mantenuto in un altro componente che ha le proprie strategie DR. Ad esempio, i record di vendita esportati in Cloud Storage vengono importati quotidianamente in BigQuery per l'analisi. Con strategie DR corrette per BigQuery, i record di vendita storici importati in BigQuery potrebbero avere obiettivi di recupero inferiori rispetto a quelli che non sono stati importati.

Archiviazione dei metadati del data lake con Dataproc Metastore

Dataproc Metastore è un metastore Apache Hive completamente gestito, a disponibilità elevata, con riparazione automatica e serverless. Il metastore offre funzionalità di astrazione e rilevamento dei dati, Il metastore può essere effettuato il backup e ripristinato in caso di disastro. Il servizio Dataproc Metastore ti consente anche di esportare e importare i metadati. Puoi aggiungere un'attività per esportare il metastore e gestire un backup esterno insieme al tuo job ETL.

Se si verifica una situazione di mancata corrispondenza dei metadati, puoi ricreare il metastore dai dati stessi utilizzando il comando MSCK.

Caso d'uso di streaming: modifica acquisizione 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 i sistemi di inventario di backend e monitorare le metriche relative alle vendite in tempo reale. Il seguente diagramma mostra un'architettura in cui gli eventi da un database transazionale, come Cloud SQL, vengono elaborati e poi archiviati in un data warehouse.

Diagramma dell'architettura di un caso d'uso di streaming che comporta l'acquisizione dei dati di modifica dei dati relativi alla vendita al dettaglio.

L'architettura include le seguenti fasi e componenti:

  • La fase di importazione consiste nel push degli eventi di modifica in Pub/Sub. Come servizio di recapito dei messaggi, Pub/Sub viene utilizzato per importare e distribuire in modo affidabile i dati di analisi dei flussi di dati. Pub/Sub offre i vantaggi aggiuntivi di scalabilità e serverless.
  • La fase di elaborazione prevede l'utilizzo di Dataflow per eseguire un processo ELT sugli eventi importati.
  • La fase del data warehouse utilizza BigQuery per archiviare gli eventi elaborati. L'operazione di unione inserisce o aggiorna un record in BigQuery. Questa operazione consente alle informazioni archiviate in BigQuery di tenersi aggiornate sul database transazionale.

Sebbene questa architettura CDC non si basi su Cloud Composer, alcune architetture di CDC richiedono che Cloud Composer orchestra l'integrazione del flusso in carichi di lavoro in batch. In questi casi, il flusso di lavoro di Cloud Composer implementa controlli di integrità, backfill e proiezioni che non possono essere eseguiti in tempo reale a causa di vincoli di latenza. Le tecniche di RE per Cloud Composer sono descritte nel caso d'uso dell'elaborazione batch descritto in precedenza nel documento.

Per una pipeline di dati in modalità flusso, devi prendere in considerazione quanto segue al momento di pianificare la tua architettura DR:

  • Dipendenze pipeline. Le pipeline di elaborazione prendono l'input da uno o più sistemi (le origini). Successivamente, le pipeline elaborano, trasformano e archiviano gli input in altri sistemi (i sink). È importante progettare l'architettura DR in modo che raggiunga il RTO end-to-end. Devi assicurarti che l'RPO delle origini dati e dei sink ti consenta di soddisfare l'RTO. Oltre a progettare la tua architettura cloud per soddisfare i requisiti della tua località, devi anche progettare le origini CDC di origine per consentire il raggiungimento del tuo RTO end-to-end.
  • Crittografia e località. Se la crittografia consente di mitigare le restrizioni di 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 aree geografiche che non sarebbero disponibili per l'uso a causa di limitazioni di località.
  • Regole di località sui dati in movimento. Alcune regole di località potrebbero essere applicate solo ai dati inattivi, ma non ai dati in movimento. Se le regole di località non si applicano ai dati in movimento, progetta la tua architettura DR per sfruttare le risorse in altre aree geografiche e migliorare gli obiettivi di recupero. Puoi integrare l'approccio regionale integrando tecniche di crittografia.

Importazione in Pub/Sub

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

Se i requisiti di località consentono l'utilizzo della crittografia, è possibile configurare Pub/Sub in modo che raggiunga un livello simile di alta disponibilità come endpoint globali. Anche se i messaggi Pub/Sub sono criptati con chiavi gestite da Google per impostazione predefinita, puoi invece configurare Pub/Sub in modo che utilizzi CMEK. Se utilizzi Pub/Sub con CMEK, puoi soddisfare le regole di località relative alla crittografia, mantenendo al contempo l'alta disponibilità.

Alcune regole di località richiedono che i messaggi rimangano in una posizione specifica anche dopo la crittografia. Se le regole di località hanno questa restrizione, puoi specificare il criterio di archiviazione dei messaggi di un argomento Pub/Sub e limitarlo a un'area geografica. Se utilizzi questo approccio per l'archiviazione dei messaggi, i messaggi pubblicati in un argomento non vengono conservati al di fuori del set di aree geografiche Google Cloud specificato. Se le regole di località consentono di utilizzare più di un'area geografica di Google Cloud, puoi aumentare la disponibilità dei servizi attivando tali aree geografiche nell'argomento Pub/Sub. Tieni presente che l'implementazione di un criterio di archiviazione dei messaggi per limitare le località delle risorse Pub/Sub comporta vantaggi compromessi sulla disponibilità.

Una sottoscrizione Pub/Sub consente di archiviare i messaggi non confermati per un massimo di 7 giorni senza alcuna limitazione al numero di messaggi. Se il tuo accordo sul livello del servizio consente dati ritardati, puoi memorizzare nel buffer i dati nella tua sottoscrizione Pub/Sub se la pipeline viene interrotta. Quando le pipeline sono di nuovo in esecuzione, puoi elaborare gli eventi di cui è stato effettuato il backup. Questo progetto ha il vantaggio di avere un RPO basso. Per ulteriori informazioni sui limiti delle risorse per Pub/Sub, consulta i limiti delle risorse per le quote Pub/Sub.

Elaborazione di eventi con Dataflow

Dataflow è un servizio gestito per l'esecuzione di un'ampia varietà di pattern di elaborazione dati. L'SDK Apache Beam è un modello di programmazione open source che consente di sviluppare pipeline sia in modalità flusso che batch. Puoi creare le pipeline con un programma Apache Beam, quindi eseguirle nel servizio Dataflow.

Quando progetti per restrizioni relative alla località, devi considerare dove si trovano le origini, i sink e i file temporanei. Se queste località dei file si trovano al di fuori dell'area geografica del job, i dati potrebbero essere inviati in più aree geografiche. Se le regole della tua località consentono di elaborare i dati in una località diversa, progetta la tua architettura DR per eseguire il deployment dei worker in altre aree geografiche Google Cloud per fornire alta disponibilità.

Se le limitazioni della tua località limitano l'elaborazione a una singola località, puoi creare un job Dataflow limitato a una determinata area geografica o zona. Quando invii un job Dataflow, puoi specificare i parametri endpoint dell'area geografica, area geografica worker e zona worker. Questi parametri controllano dove viene eseguito il deployment dei worker e dove vengono archiviati i metadati dei job.

Apache Beam fornisce un framework che consente di eseguire le pipeline su vari runner. Puoi progettare la tua architettura DR per sfruttare questa funzionalità. Ad esempio, potresti progettare un'architettura DR per avere una pipeline di backup eseguita sul cluster Spark locale on-premise utilizzando Apache Spark Runner. Per informazioni sulla capacità di un runner specifico di eseguire una determinata operazione della pipeline, consulta la sezione Beam Capability Matrix.

Se la crittografia consente di mitigare le restrizioni di località, puoi utilizzare CMEK in Dataflow per criptare gli artefatti dello stato della pipeline e accedere alle origini e ai sink protetti con le chiavi Cloud KMS. Utilizzando la crittografia, puoi progettare un'architettura DR che utilizzi aree geografiche che altrimenti non sarebbero disponibili a causa di limitazioni sulle località.

Data warehouse creato su BigQuery

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

Quando progetti il piano DR per il tuo data warehouse, prendi in considerazione le seguenti caratteristiche:

  • Dimensioni. I data warehouse sono molto più grandi dei sistemi di elaborazione di transazioni online (OLTP). Non è raro che i data warehouse abbiano da byte a petabyte di dati. Devi considerare quanto tempo impiegherebbe per ripristinare questi dati prima di raggiungere i valori RPO e RTO. Quando pianifichi la tua strategia di RE, devi anche tenere conto del costo associato al recupero dei byte di dati. Per ulteriori informazioni sulle tecniche di mitigazione DR per BigQuery, consulta le informazioni BigQuery nella sezione sui meccanismi di backup e ripristino per i servizi di database gestiti su Google Cloud.

  • Disponibilità. Quando crei un set di dati BigQuery, devi selezionare una località in cui archiviare i tuoi dati: regional o multi-regional. Una località a singola area geografica è una singola località geografica specifica, ad esempio Iowa (us-central1) o Montréal (northamerica-northeast1). Una località a più aree geografiche è un'ampia area geografica, ad esempio gli Stati Uniti (Stati Uniti) o l'Europa (UE), che contiene due o più località geografiche. Quando progetti il tuo piano di RE per rispettare le restrizioni sulla località, il dominio in cui si è verificato l'errore (ovvero, se l'errore si verifica a livello di macchina, a livello di zona o a livello di area geografica) avrà un impatto diretto sul raggiungimento dell'RTO definito. Per ulteriori informazioni su questi domini in errore e sul loro impatto 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 sono progettati per essere solo aggiunti. Se il tuo data warehouse è solo per l'aggiunta, puoi raggiungere il tuo RTO ripristinando solo i dati aggiunti. In questo approccio, esegui il backup solo di questi dati aggiunti. In caso di emergenza, potrai ripristinare i dati aggiunti e rendere disponibile il tuo data warehouse, ma con un sottoinsieme di dati.

  • Pattern di aggiunta e aggiornamento dei dati. I data warehouse vengono in genere aggiornati utilizzando i modelli ETL o ELT. Se hai controllato i percorsi di aggiornamento, puoi riprodurre gli eventi di aggiornamento recenti di origini alternative.

I requisiti relativi alla località potrebbero limitare la tua possibilità di utilizzare una singola area geografica o più aree geografiche per il data warehouse. Anche se i set di dati BigQuery possono essere configurati a livello di area geografica, l'archiviazione in più aree geografiche è il modo più semplice ed economico per garantire la disponibilità dei dati in caso di emergenza. Se l'archiviazione a più aree geografiche non è disponibile nell'area geografica, ma puoi utilizzarne un'altra, utilizza BigQuery Data Transfer Service per copiare il set di dati in un'altra area geografica. 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 area geografica, ti consigliamo di eseguire il backup delle tabelle BigQuery. La soluzione più conveniente per creare tabelle di backup è l'uso delle esportazioni di BigQuery. Utilizza Cloud Scheduler o Cloud Composer per pianificare periodicamente un job di esportazione da scrivere in Cloud Storage. Puoi utilizzare formati come Avro con compressione SNAPPY o JSON con compressione GZIP. Quando progetti le strategie di esportazione, tieni presente i limiti previsti per le esportazioni.

Puoi anche archiviare i backup di BigQuery in formati a colonne come Parquet e ORC. Forniscono un'elevata compressione e consentono anche l'interoperabilità con molti motori open source, come Hive e Presto, che potrebbero essere presenti nei tuoi sistemi on-premise. Il seguente diagramma illustra il processo di esportazione dei dati BigQuery in un formato a colonne per l'archiviazione in una località on-premise.

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

In particolare, questo processo di esportazione dei dati BigQuery in una posizione di archiviazione on-premise prevede i seguenti passaggi:

  • I dati BigQuery vengono inviati a un job Apache Spark su Dataproc. L'utilizzo del job Apache Spark consente l'evoluzione dello schema.
  • Dopo che il job Dataproc ha elaborato i file BigQuery, i file elaborati vengono scritti in Cloud Storage e poi trasferiti in una posizione DR on-premise.
  • Cloud Interconnect viene utilizzato per connettere la tua rete Virtual Private Cloud alla tua rete on-premise.
  • Il trasferimento alla località DR on-premise può avvenire tramite il job Spark.

Se il tuo design di warehouse è di tipo append-only e viene partizionato per data, devi creare una copia delle partizioni necessarie in una nuova tabella prima di eseguire un job di esportazione di BigQuery nella nuova tabella. Puoi quindi utilizzare uno strumento come gsutil per trasferire i file aggiornati nella tua posizione di backup on-premise o in un altro cloud. (In caso di trasferimento di dati da Google Cloud, potrebbero essere applicati dei costi per il traffico in uscita).

Ad esempio, hai un data warehouse per le vendite costituito da una tabella orders di tipo append-only in cui vengono aggiunti nuovi ordini alla partizione che rappresenta la data corrente. Tuttavia, una norma sui resi potrebbe consentire la restituzione degli articoli entro 7 giorni. Pertanto, i record nella tabella orders risalenti agli ultimi 7 giorni potrebbero essere aggiornati. Le strategie di esportazione devono tenere conto delle norme sui resi. In questo esempio, qualsiasi job di esportazione per eseguire il backup della tabella orders deve esportare anche le partizioni che rappresentano gli ordini negli ultimi 7 giorni per evitare aggiornamenti mancanti a causa di resi.

Passaggi successivi