Casi d'uso di disaster recovery: applicazioni di analisi dei dati con limitazioni a livello di località

Last reviewed 2024-07-20 UTC

Questo documento fa parte di una serie che illustra il disaster recovery (RE) in Google Cloud. Questo documento descrive come applicare le limitazioni a livello di località del documento Progettazione ripristino di emergenza per i workload con limitazioni a livello di località alle applicazioni di analisi dei dati. Nello specifico, questo documento descrive in che modo i componenti che utilizzi in una piattaforma di analisi dei dati si inseriscono in un'architettura dREDR che soddisfa le limitazioni di località a cui potrebbero essere soggetti le tue applicazioni o i tuoi dati.

La serie è composta dalle seguenti parti:

Questo documento è rivolto ad architetti di sistemi e 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 tuo sistema di analisi. Sia l'applicazione stessa che i dati memorizzati nel sistema potrebbero essere soggetti a normative locali. Questi regolamenti variano non solo da paese a paese, ma anche da settore a settore. Pertanto, prima di iniziare a progettare l'architettura di RE, devi avere una comprensione chiara dei requisiti di località dei dati.

Per determinare se la tua piattaforma di analisi dei dati ha requisiti di località, rispondi alle seguenti due domande:

  • La tua applicazione deve essere sottoposta a deployment 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 località. Poiché la tua piattaforma non ha requisiti di località, segui le indicazioni per il RE per servizi e prodotti conformi descritte nella Guida alla pianificazione del disaster recovery.

Tuttavia, se rispondi "sì" a una delle due domande, la tua richiesta è limitata a una località. Poiché la tua piattaforma di analisi è soggetta a limitazioni locali, devi porre la seguente domanda: Puoi utilizzare tecniche di crittografia per mitigare i requisiti relativi ai dati archiviati?

Se puoi utilizzare tecniche di crittografia, puoi utilizzare i servizi multiregionali e dual-region 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 dei dati.

Se non riesci a utilizzare tecniche di crittografia, devi utilizzare soluzioni personalizzate o offerte dei partner per la pianificazione delRER. Per saperne di più sulle tecniche per risolvere le limitazioni a livello di località per gli scenari di RE, consulta Progettazione ripristino di emergenza per i workload con limitazioni a livello di località.

Componenti di una piattaforma di analisi dei dati

Una volta compresi i requisiti di località, il passaggio successivo consiste nel comprendere i componenti utilizzati dalla 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 nel seguente elenco:

  • Google Cloud dispone di un insieme di servizi di database adatti a diversi casi d'uso.

  • Data lake, data warehouse e 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 dei dati provenienti 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 acquisisce 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) o 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 provengono da un database operativo. BigQuery è un sistema di data warehouse di uso comune in esecuzione su Google Cloud.

A seconda dei requisiti di località e dei componenti di analisi dei dati che utilizzi, l'implementazioneRER effettivo varia. Le sezioni seguenti mostrano questa variazione 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 come file da vari negozi e poi scrive i file in un bucket Cloud Storage. Il seguente diagramma illustra l'architettura di analisi dei dati per il job batch di questo rivenditore.

Diagramma dell'architettura di un caso d'uso batch che coinvolge i dati dei punti vendita.

L'architettura include le seguenti fasi e i seguenti componenti:

  • La fase di importazione consiste nell'invio dei dati del point of sale (POS) a Cloud Storage da parte dei negozi. 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 l'esecuzione di un job Apache Spark su un cluster Dataproc. Il job Apache Spark esegue un processo ETL sui dati importati. Questo processo ETL fornisce metriche aziendali.
  • La fase del data lake prende i dati elaborati e archivia le informazioni nei seguenti componenti:
    • I dati elaborati vengono generalmente archiviati in formati colonnari di Cloud Storage come Parquet e ORC perché questi formati consentono un'archiviazione efficiente e un accesso più rapido per i 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 di località, potrebbe essere difficile fornire capacità di elaborazione e orchestrazione ridondanti per mantenere la disponibilità. Poiché i dati vengono elaborati in batch, le pipeline di elaborazione e orchestrazione possono essere ricreate e i job batch possono essere riavviati dopo la risoluzione di uno scenario di emergenza. Pertanto, per il ripristino di emergenza, l'obiettivo principale è il 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 da fare riguarda i requisiti di località per il bucket Cloud Storage utilizzato per l'importazione dei 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à multiregionali o dual-region, 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 si trovano nei 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 di località consentono di archiviare i dati inattivi in più località quando utilizzi CMEK o CSEK per la gestione delle chiavi. Se le regole locali consentono l'utilizzo di CMEK o CSEK, puoi progettare l'architettura di RE in modo che utilizzi le regioni Cloud Storage.
  • I requisiti di località potrebbero non consentirti di utilizzare i tipi di località o la gestione delle chiavi di crittografia. Quando non puoi utilizzare i tipi di località o la gestione delle chiavi di crittografia, puoi utilizzare il comando gcloud storage rsync per sincronizzare i dati con un'altra località, ad esempio l'archiviazione on-premise o le soluzioni di archiviazione di un altro fornitore di servizi cloud.

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

  • Consenti al sistema POS di riprovare. Se il sistema non è in grado di scrivere i dati POS in Cloud Storage, il processo di importazione dati non va a buon fine. Per risolvere questo problema, puoi implementare una strategia di ripetizione per consentire al sistema POS di riprovare l'operazione di importazione dati. Poiché Cloud Storage offre un'elevata durabilità, l'importazione dati e la pipeline di elaborazione successiva riprenderanno con una perdita di dati minima o nulla dopo la ripresa del servizio Cloud Storage.

  • Crea copie dei dati importati. Cloud Storage supporta i tipi di località sia multiregionali che dual-region. A seconda dei requisiti di località dei dati, potresti essere in grado di configurare un bucket Cloud Storage multiregionale o dual-region per aumentare la disponibilità dei dati. Puoi anche utilizzare strumenti come il comando gcloud storage Google Cloud CLI per sincronizzare i dati tra Cloud Storage e un'altra posizione.

Orchestrazione ed elaborazione dei dati POS importati

Nel diagramma dell'architettura per lo scenario d'uso batch, Cloud Composer esegue i seguenti passaggi:

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

Cloud Composer utilizza file grafo aciclico diretto (DAG) che definiscono queste serie di passaggi. Questi file DAG vengono archiviati in un bucket Cloud Storage non mostrato nel diagramma dell'architettura. In termini di località a doppia regione e multiregionale, le considerazioni sul RE per il bucket dei file DAG sono le stesse discusse per il bucket di importazione.

I cluster Dataproc sono temporanei. ovvero i cluster esistono solo per la durata della fase di elaborazione. Questa natura effimera significa che non devi fare nulla di esplicito per RE in relazione ai cluster Dataproc.

Archiviazione del data lake con Cloud Storage

Il bucket Cloud Storage che utilizzi per il data lake presenta le stesse considerazioni sulla località di quelle discusse per il bucket di importazione: considerazioni relative a due regioni e a più regioni, l'utilizzo della crittografia e l'utilizzo del comando gcloud CLI gcloud storage rsync.

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

  • Dimensioni 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 di RE, devi considerare l'impatto del volume del data lake sulla quantità di tempo necessaria per ripristinare i dati a un punto che soddisfi i seguenti criteri:

    Per il caso d'uso del batch corrente, Cloud Storage viene utilizzato per la posizione del data lake e offre un'elevata durabilità. Tuttavia, gli attacchi ransomware sono in aumento. Per assicurarti di avere la possibilità di ripristinare i dati in seguito a questi attacchi, ti consigliamo di seguire le best practice descritte in Come Cloud Storage offre una durabilità del 99,999999999%.

  • Dipendenza dai dati. I dati nei data lake vengono in genere utilizzati da altri componenti di un sistema di analisi dei dati, ad esempio una pipeline di elaborazione. In uno scenario RE, la pipeline di elaborazione e i dati da cui dipende devono condividere lo stesso RTO. In questo contesto, concentrati sul periodo di tempo in cui 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 reso persistente in un altro componente con proprie strategREnza. Ad esempio, i record di vendita esportati in Cloud Storage vengono importati quotidianamente in BigQuery per l'analisi. Con strategie di RE appropriate per BigQuery, i record di vendita storici importati in BigQuery potrebbero avere obiettivi di ripristino inferiori rispetto a quelli non importati.

Archiviazione dei metadati del 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. Il metastore può essere eseguito il backup e ripristinato in caso di emergenza. Il servizio Dataproc Metastore ti consente anche di esportare e importare i metadati. Puoi aggiungere un'attività per esportare il metastore e mantenere un backup esterno insieme al job ETL.

Se si verifica una situazione in cui i metadati non corrispondono, puoi ricreare il metastore dai dati stessi utilizzando il comando MSCK.

Caso d'uso dello streaming: acquisizione dei dati di modifica utilizzando 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 di backend e monitorare le metriche di vendita in tempo reale. Il seguente diagramma mostra un'architettura in cui gli eventi di 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 prevede l'acquisizione di dati di vendita al dettaglio.

L'architettura include le seguenti fasi e i seguenti componenti:

  • La fase di importazione consiste nell'invio degli eventi di modifica in entrata a Pub/Sub. In qualità di servizio di distribuzione dei messaggi, Pub/Sub viene utilizzato per importare e distribuire in modo affidabile i dati di analisi dei flussi. Pub/Sub offre i vantaggi aggiuntivi di essere scalabile 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 di mantenere aggiornate le informazioni archiviate in BigQuery con il database transazionale.

Sebbene questa architettura CDC non si basi su Cloud Composer, alcune architetture CDC richiedono Cloud Composer per orchestrare l'integrazione dello stream 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 nello scenario di utilizzo dell'elaborazione batch illustrato in precedenza nel documento.

Per una pipeline di dati di streaming, devi considerare quanto segue quando pianifichi l'architettura di RE:

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

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 Google Cloud posizione.

Se i requisiti della tua località consentono l'utilizzo della crittografia, è possibile configurare Pub/Sub per ottenere un livello di alta disponibilità simile a quello degli endpoint globali. Anche se i messaggi Pub/Sub sono criptati con Google-owned and Google-managed encryption keys per impostazione predefinita, puoi configurare Pub/Sub per utilizzare CMEK in alternativa. Utilizzando Pub/Sub con CMEK, puoi rispettare le regole di località relative alla crittografia mantenendo comunque un'elevata disponibilità.

Alcune regole di località richiedono che i messaggi rimangano in una posizione specifica anche dopo la crittografia. Se le regole di località prevedono questa limitazione, puoi specificare il criterio di archiviazione dei messaggi di un argomento Pub/Sub e limitarlo a una regione. Se utilizzi questo approccio di archiviazione dei messaggi, i messaggi pubblicati in un argomento non vengono mai archiviati al di fuori dell'insieme di regioni Google Cloud che specifichi. Se le regole di località consentono l'utilizzo di più di una Google Cloud regione, puoi aumentare la disponibilità del servizio attivando queste regioni nell'argomento Pub/Sub. Devi tenere presente che l'implementazione di una policy di archiviazione dei messaggi per limitare le località delle risorse Pub/Sub comporta compromessi in termini di disponibilità.

Una sottoscrizione Pub/Sub ti consente di archiviare i messaggi non confermati per un massimo di 7 giorni senza alcuna limitazione al numero di messaggi. Se il tuo contratto di livello di servizio consente dati ritardati, puoi memorizzare i dati nel buffer dell'abbonamento Pub/Sub se le pipeline smettono di essere eseguite. Quando le pipeline sono di nuovo 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 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 ti consente di sviluppare pipeline sia in batch sia in streaming. Crea le pipeline con un programma Apache Beam e poi le esegui nel servizio Dataflow.

Quando progetti in base alle limitazioni locali, devi considerare la posizione di origini, sink e file temporanei. Se queste posizioni dei file si trovano al di fuori della regione del tuo job, i tuoi dati potrebbero essere inviati tra regioni diverse. Se le tue regole di località consentono l'elaborazione dei dati in una posizione diversa, progetta la tua architettura REza per distribuire i worker in altre Google Cloud regioni per garantire un'elevata disponibilità.

Se le limitazioni di località limitano il trattamento a una singola posizione, puoi creare un job Dataflow limitato a una regione o zona specifica. Quando invii un job Dataflow, puoi specificare i parametri endpoint regionale, regione worker e zona worker. Questi parametri controllano dove vengono implementati i worker e dove vengono memorizzati i metadati del job.

Apache Beam fornisce un framework che consente l'esecuzione delle pipeline su vari runner. Puoi progettare la tua architettura di RE in modo da sfruttare questa funzionalità. Ad esempio, potresti progettare un'architettura di RE in modo che abbia una pipeline di backup che viene eseguita 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 la matrice delle funzionalità di Beam.

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

Data warehouse creato 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 analitiche.

Quando progetti il piano di RE per il tuo data warehouse, pensa alle seguenti caratteristiche:

  • Dimensioni. I data warehouse sono molto più grandi dei sistemi di elaborazione delle transazioni online (OLTP). Non è raro che i data warehouse contengano terabyte o petabyte di dati. Devi considerare il tempo necessario per ripristinare questi dati per raggiungere i valori RPO e RTO. Quando pianifichi la tua strategia di RE, devi anche tenere conto dei costi associati al recupero di terabyte di dati. Per saperne di più sulle tecniche di mitigazione RE per BigQuery, consulta le informazioni su BigQuery nella sezione relativa ai 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 località a singola regione è una singola località geografica specifica, ad esempio l'Iowa (us-central1). Una località a più regioni è una grande area geografica, ad esempio gli Stati Uniti (US) o l'Europa (EU), che contiene due o più luoghi geografici.

    Quando progetti il tuo piano di RE per soddisfare le limitazioni di località, il dominio in errore (ovvero se l'errore si verifica a livello di macchina, di zona o di regione) influirà direttamente sul rispetto del RTO definito. Per ulteriori informazioni su questi domini di errore e su come 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 sono progettati per essere solo accodamento. Se il tuo data warehouse è di sola aggiunta, potresti riuscire a raggiungere l'RTO ripristinando solo i dati che vengono aggiunti. Con questo approccio, esegui il backup solo di questi dati aggiunti. In caso di disastro, potrai ripristinare i dati aggiunti e utilizzare il tuo data warehouse, ma con un sottoinsieme dei dati.

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

I requisiti di località potrebbero limitare la possibilità di utilizzare una singola regione o più regioni per il data warehouse. Sebbene i set di dati BigQuery possano essere regionali, l'archiviazione multiregionale è il modo più semplice ed economico per garantire la disponibilità dei dati in caso di disastro. Se l'archiviazione multiregionale non è disponibile nella tua regione, ma puoi utilizzare un'altra regione, utilizza BigQuery Data Transfer Service per copiare il set di dati in un'altra regione. Se puoi utilizzare la crittografia per attenuare 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 il backup delle tabelle BigQuery. La soluzione più conveniente per il backup delle tabelle è l'utilizzo delle esportazioni BigQuery. Utilizza Cloud Scheduler o Cloud Composer per programmare periodicamente un job di esportazione da scrivere in Cloud Storage. Puoi utilizzare formati come Avro con compressione SNAPPY o JSON con compressione GZIP. Mentre progetti le tue strategie di esportazione, tieni presente i limiti alle esportazioni.

Potresti anche voler archiviare i backup BigQuery in formati colonnari come Parquet e ORC. Questi forniscono un'elevata compressione e consentono anche 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 BigQuery in un formato colonnare per l'archiviazione in una posizione on-premise.

Diagramma dell'architettura che mostra l'esportazione dei dati BigQuery in un'unità di archiviazione colonnare per il ripristino di emergenza.

Nello specifico, 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.
  • Una volta che il job Dataproc ha elaborato i file BigQuery, questi vengono scritti in Cloud Storage e poi trasferiti in una posizione di RE on-premise.
  • Cloud Interconnect viene utilizzato per connettere la tua rete Virtual Private Cloud alla tua rete on-premise.
  • Il trasferimento alla posizione di RE on-premise può avvenire tramite il job Spark.

Se la progettazione del tuo data warehouse è di sola aggiunta e partizionata 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 il comando gcloud storage gcloud CLI per trasferire i file aggiornati nella posizione di backup on-premise o in un altro cloud. Potrebbero essere applicati costi per il traffico in uscita quando trasferisci dati da Google Cloud.

Ad esempio, hai un data warehouse delle vendite costituito da una 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. 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 di perdere gli aggiornamenti a causa dei resi.

Passaggi successivi

Collaboratori

Autori: