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

Last reviewed 2022-01-07 UTC

Questo documento fa parte di una serie che illustra il ripristino di emergenza (RE) in Google Cloud. Questo documento descrive come applicare le limitazioni relative alle località contenute nel documento Architecting ripristino di emergenza di lavoro con limitazioni a livello di località alle applicazioni di analisi dei dati. Nello specifico, questo documento descrive in che modo i componenti utilizzati in una piattaforma di analisi dei dati si inseriscono in un'architettura di RE che soddisfa le limitazioni relative alle località a cui potrebbero essere soggetti applicazioni o dati.

La serie è costituita dai seguenti componenti:

Questo documento è rivolto agli architetti di sistemi e ai responsabili IT. Si presuppone che tu abbia 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. Queste applicazioni producono eventi che vengono elaborati e archiviati nel tuo sistema di analisi. Sia l'applicazione stessa sia i dati archiviati nel sistema potrebbero essere soggetti alle normative locali. Queste normative variano non solo nei vari paesi, ma anche nei verticali di settore. Pertanto, dovresti avere una chiara comprensione dei requisiti per le località dei dati prima di iniziare a progettare l'architettura di RE.

Per determinare se la tua piattaforma di analisi dei dati ha requisiti di località rispondendo alle seguenti 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 rispondi "no" a entrambe le domande, la tua piattaforma di analisi dei dati non ha requisiti specifici per le località. Poiché la tua piattaforma non ha requisiti di località, segui le indicazioni di RE per servizi e prodotti conformi descritte nella Guida alla pianificazione del ripristino di emergenza.

Tuttavia, se rispondi "sì" a una delle domande, la tua applicazione sarà limitata alla località. Poiché la tua piattaforma di analisi è limitata per località, devi porre la seguente domanda: Puoi utilizzare tecniche di crittografia per mitigare i requisiti relativi ai dati at-rest?

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

Se non sei in grado di utilizzare le tecniche di crittografia, devi usare soluzioni personalizzate o offerte dei partner per la pianificazione del RE. Per ulteriori informazioni sulle tecniche per gestire le limitazioni relative alle 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 i componenti utilizzati dalla tua piattaforma di analisi dei dati. Alcuni componenti comuni di una piattaforma di analisi dei dati sono database, data lake, pipeline di elaborazione e data warehouse, come descritto nell'elenco seguente:

  • Google Cloud offre un insieme di servizi di database adatti 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 fanno riferimento ai servizi Google Cloud:
    • Un data lake è una piattaforma scalabile e sicura per l'importazione e l'archiviazione di dati da più sistemi. Un tipico data lake potrebbe usare Cloud Storage come repository di archiviazione centrale.
    • Una pipeline di elaborazione è un processo end-to-end che prende i dati o gli eventi di uno o più sistemi, li trasforma e li carica in un altro sistema. La pipeline potrebbe seguire un processo ETL (Extract, Transform, Load) o ELT (Extract, Load, Transform). In genere, il sistema in cui vengono caricati i dati elaborati è un data warehouse. Pub/Sub, Dataflow e Dataproc sono componenti di uso comune di una pipeline di elaborazione.
    • Un data warehouse è un sistema aziendale utilizzato per l'analisi e il reporting dei dati, che in genere proviene da un database operativo. BigQuery è un sistema di data warehouse di uso comune in esecuzione su Google Cloud.

L'implementazione effettiva di RE varia a seconda dei requisiti della località e dei componenti di analisi dei dati utilizzati. Le seguenti sezioni mostrano 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 retail raccoglie periodicamente gli eventi di vendita come file da vari negozi e quindi scrive i file in un bucket Cloud Storage. Il seguente diagramma illustra l'architettura di analisi dei dati per il job batch di questo retailer.

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 consiste nell'invio dei dati dei punti vendita (POS) dei negozi a Cloud Storage. I dati importati sono in attesa di elaborazione.
  • La fase di orchestrazione utilizza Cloud Composer per l'orchestrazione della 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. 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 formati a colonne di Cloud Storage come 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) vengono archiviati nel servizio metastore Hive fornito da Dataproc Metastore.

In scenari con limitazioni a livello di località, potrebbe essere difficile fornire una capacità di elaborazione e orchestrazione ridondante per mantenere la disponibilità. Poiché i dati vengono elaborati in batch, le pipeline di elaborazione e orchestrazione possono essere create di nuovo e i job batch possono essere riavviati dopo la risoluzione di uno scenario di emergenza. Pertanto, per il ripristino di emergenza, l'attenzione si concentra principalmente sul recupero dei dati effettivi: i dati POS importati, i dati elaborati archiviati nel data lake e i metadati archiviati nel data lake.

Importazione in Cloud Storage

La prima considerazione riguarda i requisiti di località per il bucket Cloud Storage utilizzato per importare i dati dal sistema POS. Utilizza queste informazioni sulla località per valutare le seguenti opzioni:

  • Se i requisiti di località consentono ai dati at-rest di risiedere in una delle località con più o due regioni, scegli il tipo di località corrispondente quando crei il bucket Cloud Storage. Il tipo di località che scegli definisce le regioni Google Cloud utilizzate per replicare i dati at-rest. Se si verifica un'interruzione in una delle regioni, i dati che risiedono in bucket multiregionali o a due regioni sono comunque accessibili.
  • Cloud Storage supporta anche le chiavi di crittografia gestite dal cliente (CMEK) e le chiavi di crittografia fornite dal cliente (CSEK). Alcune regole a livello di località consentono di archiviare i dati at-rest in più località quando utilizzi CMEK o CSEK per la gestione delle chiavi. Se le regole per le località consentono l'utilizzo di CMEK o CSEK, puoi progettare l'architettura di RE per utilizzare le regioni di Cloud Storage.
  • I requisiti relativi alla località potrebbero non consentirti di utilizzare i tipi di località o la gestione delle chiavi di crittografia. Se non puoi utilizzare i tipi di località o la gestione delle chiavi di crittografia, puoi utilizzare il comando gsutil rsync per sincronizzare i dati in un'altra posizione, ad esempio in soluzioni di archiviazione on-premise o di archiviazione di un altro cloud provider.

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

  • 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 un algoritmo di backoff esponenziale troncato per consentire al sistema POS di ritentare l'operazione di importazione dati. Poiché Cloud Storage offre una durabilità di undici e nove, l'importazione dati e la successiva pipeline di elaborazione 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à multiregionali e a due regioni. A seconda dei requisiti per le località dei dati, potresti essere in grado di configurare un bucket Cloud Storage multiregionale o a due regioni 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 per il caso d'uso batch, Cloud Composer esegue i seguenti passaggi:

  • Verifica che i nuovi file siano stati caricati nel bucket di importazione di Cloud Storage.
  • 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 file di grafi diretti aciclici (DAG) che definiscono queste serie di passaggi. Questi file DAG sono archiviati in un bucket Cloud Storage che non è mostrato nel diagramma dell'architettura. In termini di località a due e più regioni, le considerazioni di RE per il bucket dei file DAG sono le stesse di quelle discusse per il bucket di importazione.

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

Archiviazione nei 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 e più regioni, l'uso della crittografia e l'uso di gsutil rsync.

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

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

    Nel caso d'uso attuale in modalità batch, per la posizione del data lake si impiega Cloud Storage e offre una durabilità di 11 nove. Tuttavia, gli attacchi ransomware sono in aumento. Per garantire che tu abbia la possibilità di recuperare da tali attacchi, sarebbe prudente seguire le best practice descritte in In che modo Cloud Storage offre 11 nove di durabilità.

  • Dipendenza dai dati. I dati nei data lake vengono solitamente utilizzati da altri componenti di un sistema di analisi dei dati, ad esempio una pipeline di elaborazione. In uno scenario di RE, la pipeline di elaborazione e i dati da cui dipende devono condividere lo stesso RTO. In questo contesto, concentrati sul per quanto tempo il sistema può non 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 dei dati e potrebbe essere stato mantenuto in un altro componente con proprie strategie di RE. Ad esempio, i dati sulle vendite esportati in Cloud Storage vengono importati giornalmente in BigQuery per l'analisi. Con strategie di RE adeguate per BigQuery, i record delle vendite storiche che sono stati importati in BigQuery potrebbero avere obiettivi di recupero più bassi rispetto a quelli che non sono stati importati.

Archiviazione dei metadati dei data lake con Dataproc Metastore

Dataproc Metastore è un metastore Apache Hive completamente gestito, ad alta disponibilità, con riparazione automatica e serverless. Il metastore fornisce funzionalità di astrazione e individuazione dei dati. È possibile eseguire il backup e il ripristino del metastore in caso di emergenza. Il servizio Dataproc Metastore consente inoltre di esportare e import i metadati. Puoi aggiungere un'attività per esportare il metastore e mantenere un backup esterno insieme al job ETL.

Se riscontri una situazione di mancata corrispondenza dei metadati, puoi ricreare il metastore dai dati stessi utilizzando il comando 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 Change Data Capture (CDC) per aggiornare i sistemi di inventario backend e monitorare le metriche sulle vendite in tempo reale. Il seguente diagramma mostra un'architettura in cui gli eventi di un database transazionale, come Cloud SQL, 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 entrata inviati a Pub/Sub. Come servizio di consegna 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 essere scalabile e serverless.
  • La fase di elaborazione prevede l'uso di Dataflow per eseguire un processo ELT sugli eventi importati.
  • La fase di 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 mantenersi aggiornate con il database transazionale.

Sebbene questa architettura CDC non si basi su Cloud Composer, alcune architetture CDC richiedono a Cloud Composer di orchestrare l'integrazione del flusso nei carichi di lavoro 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 discusso in precedenza nel documento.

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

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

Importazione in Pub/Sub

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

Se i requisiti delle località consentono l'uso della crittografia, è possibile configurare Pub/Sub in modo da ottenere un livello di alta disponibilità simile a quello degli endpoint globali. Anche se i messaggi Pub/Sub sono criptati con chiavi di proprietà di Google e gestite da Google per impostazione predefinita, puoi configurare Pub/Sub per l'utilizzo di CMEK. Utilizzando Pub/Sub con CMEK, puoi soddisfare le regole di località relative alla crittografia mantenendo al contempo una disponibilità elevata.

Alcune regole relative alla località richiedono che i messaggi rimangano in una località specifica anche dopo la crittografia. Se le regole per le località hanno questa limitazione, puoi specificare il criterio di archiviazione dei messaggi di un argomento Pub/Sub e limitarlo a una regione. Se utilizzi questo approccio all'archiviazione dei messaggi, i messaggi pubblicati in un argomento non sono mai permanenti al di fuori del set di regioni Google Cloud che hai specificato. Se le tue regole per le località consentono di utilizzare più di una regione Google Cloud, puoi aumentare la disponibilità del servizio abilitando queste regioni nell'argomento Pub/Sub. Tieni presente che l'implementazione di un criterio di archiviazione dei messaggi per limitare le località delle risorse Pub/Sub prevede pro e contro la disponibilità.

Una sottoscrizione Pub/Sub consente di archiviare i messaggi non confermati per un massimo di sette giorni senza alcuna limitazione sul numero di messaggi. Se l'accordo sul livello del servizio consente i dati in ritardo, puoi eseguirne il buffering nella sottoscrizione Pub/Sub in caso di interruzione dell'esecuzione delle pipeline. Quando le pipeline vengono di nuovo in esecuzione, puoi elaborare gli eventi di cui è stato eseguito il backup. Questa progettazione ha il vantaggio di avere un RPO basso. Per ulteriori informazioni sui limiti delle risorse per Pub/Sub, consulta Limiti delle risorse per le quote di Pub/Sub.

Elaborazione degli 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 in modalità batch e flusso. Crei le tue pipeline con un programma Apache Beam ed le esegui sul servizio Dataflow.

Quando progetti per le limitazioni relative alle località, devi considerare la posizione delle origini, dei sink e dei file temporanei. Se queste posizioni dei file si trovano al di fuori della regione del job, i tuoi dati potrebbero essere inviati tra regioni. Se le regole di località consentono l'elaborazione dei dati in una località diversa, progetta la tua architettura di RE per eseguire il deployment dei worker in altre regioni di Google Cloud e garantire l'alta disponibilità.

Se le limitazioni in base alla località limitano l'elaborazione a una singola località, puoi creare un job Dataflow limitato a una regione o a una zona specifica. Quando invii un job Dataflow, puoi specificare i parametri per endpoint regionale, regione worker e zona worker. Questi parametri controllano dove viene eseguito il deployment dei worker e dove sono archiviati i metadati del job.

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

Se la crittografia ti consente di mitigare le limitazioni della località, puoi utilizzare CMEK in Dataflow sia per criptare gli artefatti dello stato della pipeline, sia per accedere a origini e sink protetti con chiavi Cloud KMS. Utilizzando la crittografia, puoi progettare un'architettura di RE che utilizzi regioni che altrimenti non sarebbero disponibili a causa delle limitazioni della località.

Data warehouse basato su BigQuery

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

Quando progetti il piano di RE per il tuo data warehouse, considera le seguenti caratteristiche:

  • Dimensioni. I data warehouse sono molto più grandi dei sistemi di elaborazione delle transazioni online (OLTP). Non è raro che i data warehouse abbiano da terabyte a petabyte di dati. Devi considerare quanto tempo occorrerà per ripristinare questi dati per raggiungere i valori RPO e RTO. Quando pianifichi la tua 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 informazioni su 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, selezioni una località in cui archiviare i dati: regionale o multiregionale. Una regione regionale è un'unica località geografica specifica, ad esempio l'Iowa (us-central1) o Montréal (northamerica-northeast1). Una località multiregionale è una grande area geografica, ad esempio gli Stati Uniti (USA) o l'Europa (UE), che contiene due o più luoghi geografici.

    Durante la progettazione del piano di RE per soddisfare le limitazioni delle località, il dominio in errore (ovvero se l'errore si verifica a livello di macchina, zona o regione) avrà 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 è statica. Molti data warehouse sono progettati per essere solo append. Se il data warehouse è di sola aggiunta, potresti riuscire a raggiungere il tuo RTO ripristinando solo i dati che vengono aggiunti. Con questo approccio, esegui il backup solo dei dati aggiunti. In caso di emergenza, potrai ripristinare i dati aggiunti e utilizzare il data warehouse, ma con un sottoinsieme di dati.

  • Pattern di aggiunta e aggiornamento dei dati. I data warehouse vengono generalmente aggiornati utilizzando pattern ETL o ELT. Una volta controllati i percorsi di aggiornamento, puoi riprodurre gli eventi di aggiornamento recenti da origini alternative.

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

Se puoi utilizzare una sola regione, valuta la possibilità di eseguire il backup delle tabelle BigQuery. La soluzione più economica per le tabelle di backup è utilizzare le esportazioni di BigQuery. Utilizza Cloud Scheduler o Cloud Composer per pianificare periodicamente un job di esportazione in modo che scriva in Cloud Storage. Puoi utilizzare formati come Avro con compressione SNAPPY o JSON con compressione GZIP. Durante la progettazione delle strategie di esportazione, prendi nota dei limiti delle esportazioni.

Puoi anche archiviare i backup di BigQuery in formati a colonne come Parquet e ORC. Forniscono un'elevata compressione e consentono inoltre l'interoperabilità con molti motori open source, come Hive e Presto, che potresti avere nei tuoi sistemi on-premise. Il seguente diagramma illustra il 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.

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

  • I dati di 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, questi vengono scritti in Cloud Storage e trasferiti in una posizione di RE on-premise.
  • Cloud Interconnect viene utilizzato per connettere la rete Virtual Private Cloud alla tua rete on-premise.
  • Il trasferimento alla località di ripristino di emergenza on-premise può avvenire mediante il job Spark.

Se il progetto del warehouse è di sola aggiunta ed è partizionato per data, devi creare una copia delle partizioni richieste in una nuova tabella prima di eseguire un job di esportazione BigQuery nella nuova tabella. Puoi quindi utilizzare uno strumento come gsutil per trasferire i file aggiornati nella località di backup on-premise o in un altro cloud. (Potrebbero essere applicati costi per il traffico in uscita quando trasferisci dati al di fuori di Google Cloud.)

Ad esempio, hai un data warehouse delle vendite composto da una tabella orders di sola aggiunta in cui i nuovi ordini vengono aggiunti alla partizione che rappresenta la data corrente. Tuttavia, in base alle norme sui resi, gli articoli potrebbero essere restituiti entro sette giorni. Pertanto, i record nella tabella orders degli ultimi 7 giorni potrebbero essere aggiornati. Le tue strategie di esportazione devono tenere conto delle norme sui resi. In questo esempio, qualsiasi job di esportazione per 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