Casi d'uso per il ripristino di emergenza: applicazioni di analisi dei dati con limitazioni 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 alle applicazioni di analisi dei dati le limitazioni per le località riportate nel documento Architettura del ripristino di emergenza per carichi di lavoro con limitazioni a livello di località. In particolare, 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 di località a cui potrebbero essere soggetti le tue applicazioni o i tuoi dati.

La serie è costituita dai seguenti componenti:

Questo documento è destinato ai System Architect 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 at-rest. Queste applicazioni generano eventi elaborati e archiviati nel tuo sistema di analisi. Sia l'applicazione stessa sia i dati archiviati nel sistema potrebbero essere soggetti alle normative sulle località. Queste normative variano non solo in base al paese, ma anche ai vari settori verticali. Pertanto, dovresti aver compreso chiaramente i requisiti di località dei dati prima di iniziare a progettare l'architettura di RE.

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

  • Il deployment della tua applicazione deve essere eseguito in una regione specifica?
  • I 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 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 applicazione è soggetta a limitazioni di località. Poiché la tua piattaforma di analisi è soggetta a limitazioni per località, devi porre la seguente domanda: È possibile utilizzare tecniche di crittografia per mitigare i requisiti dei dati at-rest?

Se sei in grado di utilizzare le tecniche di crittografia, puoi utilizzare i servizi multiregionali e biregionali 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 riesci a utilizzare le tecniche di crittografia, devi utilizzare soluzioni personalizzate o offerte dei partner per la pianificazione del RE. Per maggiori 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 in una piattaforma di analisi dei dati

Una volta compresi i requisiti per le località, il passaggio successivo è comprendere i componenti utilizzati dalla tua 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 nell'elenco seguente:

  • Google Cloud dispone di una serie 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 importare e archiviare i dati di più sistemi. Un 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, trasforma questi dati o eventi e li carica in un altro sistema. La pipeline potrebbe seguire un processo di estrazione, trasformazione e caricamento (ETL) o di 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 di uso comune di una pipeline di elaborazione.
    • Un data warehouse è un sistema aziendale utilizzato per l'analisi e il reporting sui dati, che in genere provengono da un database operativo. BigQuery è un sistema di data warehouse di uso comune in esecuzione su Google Cloud.

L'effettiva implementazione di RE varia a seconda dei requisiti per le località e dei componenti di analisi dei dati che utilizzi. Le sezioni seguenti mostrano questa variante con due casi d'uso.

Caso d'uso in batch: un job ETL periodico

Il primo caso d'uso descrive un processo batch in cui una piattaforma retail raccoglie periodicamente eventi di vendita come file da vari archivi 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 rivenditore.

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

L'architettura comprende le fasi e i componenti seguenti:

  • La fase di importazione consiste nell'invio dei dati dei punti vendita (POS) da parte dei negozi a Cloud Storage. I 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. 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 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 per i carichi di lavoro analitici.
    • I metadati relativi ai dati di processo (ad esempio database, tabelle, colonne e partizioni) vengono archiviati nel servizio di metastore Hive fornito da Dataproc Metastore.

In scenari limitati a 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 potrebbero essere riavviati dopo la risoluzione di uno scenario di emergenza. Di conseguenza, per il ripristino di emergenza, l'attenzione 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 cosa da fare è considerare i requisiti di 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 la localizzazione dei dati at-rest in una delle località a due o più regioni, scegli il tipo di località corrispondente quando crei il bucket Cloud Storage. Il tipo di località scelto 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 inoltre sia chiavi di crittografia gestite dal cliente (CMEK) sia chiavi di crittografia fornite dal cliente (CSEK). Alcune regole di località consentono l'archiviazione dei dati at-rest 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 la tua architettura di RE in modo da utilizzare le regioni di Cloud Storage.
  • I requisiti di 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 località, ad esempio con soluzioni di archiviazione on-premise di 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, 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 il sistema POS riprovi. Nel caso in cui il sistema non sia in grado di scrivere i dati del POS in Cloud Storage, il processo di importazione dati non va a buon fine. Per attenuare questa situazione, puoi implementare un algoritmo backoff esponenziale troncato per consentire al sistema POS di ritentare l'operazione di importazione dati. Poiché Cloud Storage offre una durabilità di 11 9, l'importazione dati e la successiva pipeline di elaborazione riprenderanno con una perdita di dati minima o nulla una volta ripristinato il servizio Cloud Storage.

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

Orchestrazione ed elaborazione dei dati POS importati

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

  • Convalida che i nuovi file sono 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 grafo diretto aciclico (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à a due o più regioni, le considerazioni di RE per il bucket di file DAG sono le stesse di quelle discusse per il bucket di importazione.

I cluster Dataproc sono temporanei. I cluster esistono solo finché è in esecuzione la fase di elaborazione. Questa natura temporanea significa che non devi fare nulla per 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 di località di quelle discusse per il bucket di importazione: considerazioni relative a due regioni e più regioni, uso della crittografia e uso di gsutil rsync.

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

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

    Per il caso d'uso batch attuale, Cloud Storage viene utilizzato per la località del data lake e fornisce una durabilità di 11 nove. Tuttavia, gli attacchi ransomware sono in aumento. Per assicurarti di avere la possibilità di recuperare da questi attacchi, sarebbe 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 vengono in genere consumati da altri componenti di un sistema di analisi dei dati, come 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 periodo di tempo in cui il sistema può rimanere non 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 dell'analisi dei dati e potrebbe essere stato mantenuto invariate in un altro componente con strategie di RE proprie. Ad esempio, i record delle vendite esportati in Cloud Storage vengono importati ogni giorno in BigQuery per l'analisi. Con strategie di RE adeguate per BigQuery, i record di vendita storici 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 rilevamento dei dati. È possibile eseguire il backup e ripristinare del metastore in caso di emergenza. Il servizio Dataproc Metastore ti consente inoltre di esportare e import i metadati. Puoi aggiungere un'attività per esportare il metastore e gestire un backup esterno insieme al job ETL.

In caso di mancata corrispondenza dei metadati, puoi ricreare il metastore dai dati stessi utilizzando il comando MSCK.

Caso d'uso relativo ai flussi di dati: Change Data Capture (CDC) utilizzando ELT

Il secondo caso d'uso identifica una piattaforma retail 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 poi archiviati in un data warehouse.

Diagramma dell'architettura di un caso d'uso in modalità flusso che comporta l'acquisizione di dati di Change Data per la vendita al dettaglio.

L'architettura comprende le fasi e i componenti seguenti:

  • La fase di importazione è composta dagli eventi di modifica in entrata che vengono inviati a Pub/Sub. Essendo un 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 il vantaggio aggiuntivo 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 rimanere aggiornate con il database transazionale.

Anche se questa architettura CDC non si basa 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 trattate nel caso d'uso dell'elaborazione batch discusso in precedenza nel documento.

Per una pipeline di dati in modalità flusso, devi prendere in considerazione quanto segue durante la pianificazione dell'architettura di RE:

  • Dipendenze della pipeline. Le pipeline di elaborazione ricevono input da uno o più sistemi (le origini). Le pipeline elaborano, trasformano e archiviano questi input in altri sistemi (i sink). Progettare la tua architettura di RE per ottenere l'RTO end-to-end è importante. Devi assicurarti che l'RPO delle origini dati e dei sink ti consenta di soddisfare l'RTO. Oltre a progettare l'architettura cloud per soddisfare i requisiti di località, dovrai anche progettare le origini CDC di origine per consentire il raggiungimento del 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.
    • Sfrutta le funzionalità di crittografia dei singoli servizi.
    • Esegui il deployment dei servizi in regioni che altrimenti non sarebbero disponibili a causa delle limitazioni relative alle località.
  • Regole di località per i dati in movimento. Alcune regole di località si applicano solo ai dati at-rest, ma non a quelli in movimento. Se le regole di località non si applicano ai dati in movimento, progetta l'architettura di RE in modo da sfruttare le risorse in altre regioni per migliorare gli obiettivi di ripristino. Puoi integrare l'approccio a livello di regione 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à Google Cloud.

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

Alcune regole di 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 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 conservati al di fuori dell'insieme di regioni di Google Cloud specificato. Se le regole di località consentono l'utilizzo di più regioni 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 comporta compromissioni relative alla 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 accordo sul livello del servizio consente dati in ritardo, puoi eseguire il buffering dei dati nella tua sottoscrizione Pub/Sub se l'esecuzione delle pipeline si interrompe. 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 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 in modalità batch e flusso. Puoi creare le pipeline con un programma Apache Beam e quindi eseguirle sul servizio Dataflow.

Quando progetti per le limitazioni di località, devi considerare dove si trovano le fonti, i sink e i file temporanei. Se le posizioni dei file sono al di fuori della regione del job, i 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 una disponibilità elevata.

Se le limitazioni per le località limitano l'elaborazione a una singola località, puoi creare un job Dataflow limitato a una regione o zona specifica. Quando invii un job Dataflow, puoi specificare i parametri endpoint a livello di regione, 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 l'esecuzione di pipeline su vari runner. Puoi progettare l'architettura di RE per sfruttare questa funzionalità. Ad esempio, potresti progettare un'architettura di RE in modo che abbia una pipeline di backup in esecuzione sul cluster Spark on-premise locale utilizzando Apache Spark Runner. Per informazioni su se un determinato runner è in grado di eseguire una determinata operazione della pipeline, consulta la matrice delle capacità dei raggi.

Se la crittografia ti consente di ridurre le limitazioni relative alle località, puoi utilizzare CMEK in Dataflow per criptare gli artefatti dello stato della pipeline e per accedere a origini e sink protetti con chiavi Cloud KMS. Utilizzando la crittografia, puoi progettare un'architettura di RE che utilizza regioni che altrimenti non sarebbero disponibili a causa di restrizioni di 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 molteplici componenti analitici e procedure.

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 terabyte o petabyte di dati. Devi considerare quanto tempo ci vuole per ripristinare questi dati e 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, 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, seleziona una località in cui archiviare i dati: Una regione o Più regioni. Una località regionale è una località geografica specifica, come Iowa (us-central1) o Montréal (northamerica-northeast1). Una località con più regioni è una grande area geografica, ad esempio gli Stati Uniti (US) o l'Europa (UE), che contiene due o più luoghi geografici.

    Quando progetti il tuo piano di RE in modo da rispettare le limitazioni di località, il dominio in errore in cui l'errore si verifica (ovvero a livello di macchina, di zona o di regione) avrà un impatto diretto sul raggiungimento dell'RTO definito. Per saperne di più 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 sono progettati per essere solo append. Se il tuo data warehouse è di sola aggiunta, potresti riuscire a ottenere l'RTO ripristinando solo i dati aggiunti. Con questo approccio, esegui il backup di questi dati aggiunti. In caso di emergenza, potrai ripristinare i dati aggiunti e rendere il data warehouse disponibile per l'uso, ma con un sottoinsieme di dati.

  • Aggiunta di dati e pattern di aggiornamento. I data warehouse vengono in genere aggiornati utilizzando pattern ETL o ELT. Se disponi di percorsi di aggiornamento controllati, puoi riprodurre gli eventi di aggiornamento recenti da origini alternative.

I tuoi requisiti di località potrebbero limitare la possibilità di utilizzare una singola regione o più regioni per il tuo data warehouse. Sebbene i set di dati BigQuery possano essere a livello di regione, l'archiviazione in più regioni è il modo più semplice ed economico per garantire la disponibilità dei dati in caso di emergenza. Se l'archiviazione in più regioni non è disponibile nella 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 ridurre 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ù economica per il backup delle tabelle è utilizzare le esportazioni di BigQuery. Utilizza Cloud Scheduler o Cloud Composer per pianificare periodicamente un job di esportazione per la scrittura in Cloud Storage. Puoi utilizzare formati come Avro con compressione SNAPPY o JSON con compressione GZIP. Durante la progettazione delle strategie di esportazione, tieni presente i limiti previsti per le esportazioni.

Inoltre, puoi archiviare i backup di BigQuery in formati a colonna, come Parquet e ORC. Questi motori 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 località on-premise.

Diagramma dell'architettura che mostra l'esportazione dei dati di BigQuery nell'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'uso del job Apache Spark consente l'evoluzione dello schema.
  • Una volta che il job di Dataproc ha elaborato i file di BigQuery, i file elaborati 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 rete on-premise.
  • Il trasferimento alla località di RE on-premise può avvenire tramite il job Spark.

Se il design del tuo 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 posizione di backup on-premise o su un altro cloud. Quando trasferisci dati all'esterno di Google Cloud, potrebbero essere applicati costi per il traffico in uscita.

Ad esempio, supponiamo che tu abbia un data warehouse delle vendite costituito da una tabella orders di sola aggiunta 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 della tabella orders degli 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