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 ripristino di emergenza (RE) in Google Cloud. Questo documento descrive come applicare le limitazioni di località del documento Architecting ripristino di emergenza for locality-restricted workloads 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 di località a cui potrebbero essere soggette le applicazioni o i dati.

La serie è composta dai seguenti componenti:

Questo documento è rivolto ad architetti di sistema e amministratori IT. Si presume che tu abbia le seguenti conoscenze e competenze:

Requisiti relativi alla 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 a riposo. Queste applicazioni producono eventi che vengono elaborati e archiviati nel sistema di analisi. Sia l'applicazione stessa sia i dati archiviati nel sistema potrebbero essere soggetti alle normative locali. Queste normative variano non solo in base ai paesi, ma anche ai verticali di settore. Pertanto, devi avere una conoscenza chiara dei requisiti di località dei dati prima di iniziare a progettare l'architettura di RE.

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

  • L'applicazione deve essere dispiattata 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 la località. Poiché la tua piattaforma non ha requisiti relativi alla località, segui le indicazioni per il piano di ripristino dei disastri per i servizi e i prodotti conformi riportate nella guida alla pianificazione del ripristino dei disastri.

Tuttavia, se rispondi "sì" a una delle domande, la tua applicazione è limitata alla località. Poiché la tua piattaforma di analisi è limitata a una località, devi rispondere alla seguente domanda: Puoi utilizzare tecniche di crittografia per mitigare i requisiti dei dati a riposo?

Se sei in grado di utilizzare tecniche di crittografia, puoi utilizzare i servizi multiregionali e dual-regionali 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 puoi utilizzare tecniche di crittografia, devi utilizzare soluzioni personalizzate o offerte di partner per la pianificazione RE. Per ulteriori informazioni sulle tecniche per gestire 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 relativi alla località, il passaggio successivo consiste nel 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 nel seguente elenco:

  • Google Cloud dispone di 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 dei dati provenienti da diversi sistemi. Un data lake tipico 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 ETL (estrazione, trasformazione e caricamento) o ELT (estrazione, caricamento e trasformazione). In genere, il sistema in cui vengono caricati i dati elaborati è un data warehouse. Pub/Sub, Dataflow e Dataproc sono componenti di una pipeline di elaborazione comunemente usati.
    • Un data warehouse è un sistema aziendale utilizzato per l'analisi e la generazione di report dei dati, solitamente provenienti 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'implementazione effettiva del RE varia. Le sezioni seguenti illustrano 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 sotto forma di file da vari magazzini e poi li scrive 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 di vendita.

L'architettura include le seguenti fasi e componenti:

  • La fase di importazione consiste nell'invio da parte dei negozi dei 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. Questo processo ETL fornisce metriche aziendali.
  • La fase del data lake prende i dati elaborati e memorizza le informazioni nei seguenti componenti:
    • I dati elaborati vengono in genere archiviati in Cloud Storage in formati a colonne come Parquet e ORC perché questi formati consentono un'archiviazione efficiente e un accesso più rapido per i carichi di lavoro di analisi.
    • I metadati relativi ai dati di processo (ad esempio 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 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 ricreate e i job batch possono essere riavviati dopo la risoluzione di uno scenario di disastro. Pertanto, per il ripristino di emergenza, l'obiettivo principale è recuperare i 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 deve riguardare 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 che i dati at-rest si trovino in una delle località con più regioni o regioni doppie, scegli il tipo di località corrispondente quando crei il bucket Cloud Storage. Il tipo di posizione scelto definisce le regioni Google Cloud utilizzate per replicare i dati at-rest. Se si verifica un'interruzione in una delle regioni, i dati memorizzati nei bucket multiregione o a due regioni rimangono 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 at-rest in più posizioni quando utilizzi CMEK o CSEK per la gestione delle chiavi. Se le regole della località consentono l'utilizzo di CMEK o CSEK, puoi progettare l'architettura di RE in modo da utilizzare le regioni Cloud Storage.
  • I requisiti relativi alla località potrebbero non consentire l'utilizzo di tipi di località o della 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 posizione, ad esempio lo spazio di archiviazione on-premise o soluzioni di archiviazione di un altro provider cloud.

In caso di incidente, i dati POS importati nel bucket Cloud Storage potrebbero contenere dati che non sono stati 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 calamitoso:

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

  • Crea copie dei dati importati. Cloud Storage supporta sia i tipi di località con più regioni sia quelli con due regioni. A seconda dei requisiti della 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 il gcloud storage comando Google Cloud CLI per sincronizzare i dati tra Cloud Storage e un'altra posizione.

Orchestrazione ed elaborazione dei dati POS importati

Nel diagramma di 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 questa 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 regioni e multiregione, le considerazioni di RE per il bucket dei file DAG sono le stesse discusse per il bucket di importazione.

I cluster Dataproc sono temporanei. In altre parole, i cluster esistono solo per la durata della fase di elaborazione. Questa natura effimera significa che non devi fare nulla in modo esplicito per il RE in merito 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 su regioni doppie e multiregioni, utilizzo della crittografia e utilizzo del comando gcloud storage rsync gcloud CLI.

Quando progetti il piano di RE per il tuo data lake, tieni in considerazione i seguenti aspetti:

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

    Per il caso d'uso 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 recuperare da questi attacchi, ti consigliamo di seguire le best practice descritte in In che modo 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 di RE, la pipeline di elaborazione e i dati su cui si basa devono condividere lo stesso RTO. In questo contesto, concentrati sul periodo di tempo per il quale puoi consentire il malfunzionamento del sistema.

  • 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 che ha le sue proprie strategie di RE. Ad esempio, i record di vendita esportati in Cloud Storage vengono importati quotidianamente in BigQuery per l'analisi. Con strategie di RE adeguate per BigQuery, i record di vendita storici che sono stati 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 che è completamente gestito, ad alta disponibilità, con riparazione automatica e serverless. Il metastore fornisce funzionalità di astrazione e scoperta dei dati. Il metastore può essere sottoposto a backup e ripristinato 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 gestire un backup esterno insieme al tuo job ETL.

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

Caso d'uso di streaming: acquisizione dei dati di modifica utilizzando 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 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 il rilevamento dei dati modificati dei dati di vendita al dettaglio.

L'architettura include le seguenti fasi e componenti:

  • La fase di importazione consiste nell'invio degli eventi di modifica in arrivo a Pub/Sub. In qualità di servizio di invio di 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'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 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 di elaborazione batch descritto in precedenza nel documento.

Per una pipeline di dati in streaming, devi considerare quanto segue quando pianifichi la tua architettura di RE:

  • Dipendenze della pipeline. Le pipeline di elaborazione ricevono input da uno o più sistemi (le origini). Le pipeline poi elaborano, trasformano e memorizzano questi input in altri sistemi (i sink). È importante progettare la tua architettura di RE in modo da raggiungere il tuo RTO end-to-end. Devi assicurarti che l'RPO delle origini dati e delle destinazioni ti consenta di soddisfare l'RTO. Oltre a progettare l'architettura cloud in modo da soddisfare i requisiti di località, dovrai anche progettare le origini CDC di origine per consentire il rispetto del 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.
    • Implementare i servizi in regioni che altrimenti non sarebbero disponibili per l'uso a causa di limitazioni locali.
  • Regole di località per i dati in movimento. Alcune regole di località potrebbero essere applicate solo ai dati at-rest, ma non ai dati in movimento. Se le regole di località non si applicano ai dati in movimento, progetta l'architettura di RE in modo da utilizzare risorse in altre regioni per migliorare gli obiettivi di recupero. Puoi integrare l'approccio regionale integrando tecniche di crittografia.

Importazione in Pub/Sub

Se non hai limitazioni 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 per ottenere un livello di alta disponibilità simile agli endpoint globali. Sebbene i messaggi Pub/Sub siano criptati con chiavi di proprietà e gestite da Google per impostazione predefinita, puoi configurare Pub/Sub in modo da utilizzare CMEK. Utilizzando Pub/Sub con CMEK, puoi soddisfare le regole di località relative alla crittografia, mantenendo al contempo un'alta 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 memorizzati al di fuori dell'insieme di regioni Google Cloud specificate. Se le regole di località consentono l'utilizzo di più regioni Google Cloud, puoi aumentare la disponibilità del servizio attivando 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 trade-off in termini di disponibilità.

Una sottoscrizione Pub/Sub ti consente di archiviare i messaggi non confermati per un massimo di 7 giorni senza limitazioni sul numero di messaggi. Se il tuo contratto a livello di servizio consente i dati in ritardo, puoi mettere in buffer i dati nell'abbonamento Pub/Sub se le pipeline smettono di funzionare. 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 di risorse per Pub/Sub, consulta Limiti di 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 batch sia in streaming. Creerai le pipeline con un programma Apache Beam e poi le eseguirai nel servizio Dataflow.

Quando progetti in base alle limitazioni di località, devi considerare dove si trovano le sorgenti, gli sink e i file temporanei. Se queste posizioni dei file si trovano al di fuori della regione del tuo job, i dati potrebbero essere inviati tra regioni. Se le tue regole di località consentono l'elaborazione dei dati in una località diversa, progetta l'architettura di RE per eseguire il deployment dei worker in altre regioni Google Cloud in modo da garantire un'alta disponibilità.

Se le limitazioni relative alla località limitano l'elaborazione a una singola località, puoi creare un job Dataflow limitato a una regione o una zona specifica. Quando invii un job Dataflow, puoi specificare i parametri endpoint a livello di regione, regione dei worker e zona dei worker. Questi parametri controllano dove vengono implementati i worker e dove vengono memorizzati i metadati dei job.

Apache Beam fornisce un framework che consente di eseguire le pipeline su diversi runner. Puoi progettare l'architettura di RE in modo da sfruttare questa funzionalità. Ad esempio, puoi progettare un'architettura di RE per avere una pipeline di backup che venga eseguita sul tuo cluster Spark on-premise locale utilizzando Apache Spark Runner. Per informazioni su se un runner specifico è in grado 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 elementi dello stato della pipeline e accedere a origini e destinazioni protette con le chiavi Cloud KMS. Utilizzando la crittografia, puoi progettare un'architettura di RE che utilizzi 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 di analisi.

Quando progetti il piano di RE per il tuo data warehouse, tieni presente 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 contengano da terabyte a petabyte di dati. Devi considerare il tempo necessario per ripristinare questi dati in modo da 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 del 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, devi selezionare una posizione in cui archiviare i dati: regionale o multiregionale. 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 è una vasta area geografica, ad esempio gli Stati Uniti (US) o l'Europa (UE), che contiene due o più località geografiche.

    Quando progetti il piano di RE per soddisfare le limitazioni di località, il dominio in errore (ovvero se l'errore si verifica a livello di macchina, zonale o regionale) avrà un impatto diretto sul raggiungimento 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 più vecchi è spesso statica. Molti data warehouse sono progettati per essere solo di accodamento. Se il tuo data warehouse è di sola aggiunta, potresti essere in grado di raggiungere il tuo RTO ripristinando solo i dati che vengono aggiunti. In questo approccio, esegui il backup solo di questi dati aggiunti. In caso di calamità, 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 in genere aggiornati utilizzando pattern ETL o ELT. Quando hai percorsi di aggiornamento controllati, puoi riprodurre gli eventi di aggiornamento recenti da fonti alternative.

I requisiti relativi alla 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 regionali, lo spazio di archiviazione multiregionale è il modo più semplice e conveniente per garantire la disponibilità dei dati in caso di disastro. Se lo spazio di archiviazione multiregione 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 attenuare i requisiti di località, puoi gestire le tue chiavi di crittografia con Cloud KMS e BigQuery.

Se puoi utilizzare una sola regione, ti consigliamo di eseguire il backup delle tabelle BigQuery. La soluzione più economica per eseguire il backup delle tabelle è utilizzare BigQuery Export. Utilizza Cloud Scheduler o Cloud Composer per pianificare periodicamente un job di esportazione per scrivere in Cloud Storage. Puoi utilizzare formats come Avro con compressione SNAPPY o JSON con compressione GZIP. Mentre stai elaborando le tue strategie di esportazione, tieni presente i limiti previsti per le esportazioni.

Ti consigliamo inoltre di archiviare i backup di BigQuery in formati colonnari come Parquet e ORC. Questi 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 lo stoccaggio in una posizione on-premise.

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

Nello specifico, questa procedura di esportazione dei dati di BigQuery in un luogo 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 la evoluzione dello schema.
  • Dopo 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 collegare la rete Virtual Private Cloud alla rete on-premise.
  • Il trasferimento alla posizione di RE on-premise può avvenire tramite il job Spark.

Se il design del tuo data warehouse è di tipo append-only 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 il gcloud storage comando gcloud CLI per trasferire i file aggiornati alla posizione di backup on-premise o in un altro cloud. Quando trasferisci i dati da Google Cloud, potrebbero essere applicati costi di uscita.

Ad esempio, hai 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 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 anche esportare le partizioni che rappresentano gli ordini negli ultimi 7 giorni per evitare aggiornamenti mancanti a causa dei resi.

Passaggi successivi

Collaboratori

Autori: