Migrazione tra regioni Google Cloud: prepara i dati e i carichi di lavoro in batch per la migrazione tra regioni

Last reviewed 2023-12-08 UTC

Questo documento descrive come progettare una piattaforma dati su Google Cloud per Ridurre al minimo l'impatto di un'espansione futura ad altre regioni o di migrazione tra regioni diverse. Questo documento fa parte di una serie che ti aiuta a Comprendere l'impatto dell'espansione della tua piattaforma dati in un'altra regione. it ti aiuta a svolgere le seguenti attività:

  • Preparati allo spostamento di dati e pipeline di dati.
  • Configura i controlli durante le fasi di migrazione.
  • Crea una strategia di migrazione flessibile separando l'archiviazione dei dati e i dati calcolo.

Le indicazioni di questa serie sono utili anche se non hai pianificato una migrazione in più regioni o per un'espansione in più regioni in anticipo. In questo caso, potresti dover dedicare del tempo alla preparazione dell'infrastruttura carichi di lavoro e dati per la migrazione tra regioni e per l'espansione in più regioni.

Questo documento fa parte di una serie:

Questa serie presuppone che tu abbia letto e abbia familiarità con i seguenti argomenti documenti:

Il seguente diagramma illustra il percorso del tuo percorso di migrazione.

Percorso di migrazione diviso in quattro fasi.

Durante ogni fase della migrazione, segui le fasi definite nella Migrazione a Google Cloud: inizia:

  1. Valuta e scopri i tuoi carichi di lavoro.
  2. Pianifica e costruisci le basi.
  3. Esegui il deployment dei carichi di lavoro.
  4. Ottimizza il tuo ambiente.

La moderna piattaforma di dati su Google Cloud

Questa sezione descrive le diverse parti di una moderna piattaforma di dati e come di solito sono creati in Google Cloud. Piattaforme di dati in generale può essere suddiviso in due sezioni:

  • Il livello di archiviazione dei dati è la posizione in cui vengono salvati i dati. I dati che stai il salvataggio potrebbe essere sotto forma di file in cui gestisci byte effettivi su file system come Hadoop Distributed File System (HDFS) o Cloud Storage, o una lingua specifica del dominio (DSL) per gestire i dati in un di gestione dei database.
  • Il livello di computing dei dati è qualsiasi elaborazione dati che potresti attivare in cima al sistema di archiviazione. Come per il livello di archiviazione, possibili implementazioni e alcuni strumenti di archiviazione dei dati gestiscono anche calcolo. Il ruolo del livello di calcolo dei dati nella piattaforma è quello di caricare i dati dal livello di archiviazione, elaborarli e salvare a un sistema target. Il sistema di destinazione può essere l'archiviazione di origine livello di sicurezza.

Alcune piattaforme di dati utilizzano più sistemi di archiviazione per il livello di archiviazione dei dati. e più sistemi di calcolo dei dati per il loro livello di elaborazione dei dati. Nella maggior parte dei casi, casi, il livello di archiviazione dei dati e il livello di calcolo dei dati sono separati. Per Ad esempio, potresti aver implementato il livello di archiviazione dei dati utilizzando Servizi Google Cloud:

Potresti aver implementato il livello di calcolo dei dati utilizzando altre Servizi Google Cloud come questi:

Per ridurre i tempi e la latenza di comunicazione, il costo dei dati in uscita trasferimento e il numero di operazioni di I/O tra il livello di archiviazione e di computing, consigliamo di archiviare i dati nella stessa zona con cui elabori i dati.

Ti consigliamo inoltre di mantenere il livello di archiviazione dati separato dai dati il livello di computing. Mantenere questi strati separati migliora la tua flessibilità la modifica dei livelli di calcolo e la migrazione dei dati. Anche mantenere i livelli separati riduce l'uso delle risorse perché non è necessario mantenere il livello contemporaneamente in esecuzione. Ti consigliamo quindi di eseguire il deployment del tuo spazio di archiviazione e il calcolo dei dati su piattaforme separate nella stessa zona e nella stessa regione. Per Ad esempio, puoi spostare l'archiviazione dei dati da HDFS a Cloud Storage e usare un cluster Dataproc per il calcolo.

Valuta il tuo ambiente

Nella fase di valutazione, stabilisci i requisiti e le dipendenze esegui la migrazione delle pipeline di dati in batch di cui hai eseguito il deployment:

  1. Crea un inventario completo delle pipeline di dati.
  2. Cataloga le pipeline in base alle loro proprietà e dipendenze.
  3. Addestra e forma i tuoi team su Google Cloud.
  4. Crea un esperimento e una proof of concept su Google Cloud.
  5. Calcola il costo totale di proprietà (TCO) dell'ambiente di destinazione.
  6. Scegli per primi i carichi di lavoro di cui vuoi eseguire la migrazione.

Per ulteriori informazioni sulla fase di valutazione e su queste attività, consulta: Migrazione a Google Cloud: valuta e individua i tuoi carichi di lavoro. Le sezioni seguenti si basano sulle informazioni contenute nel documento.

Creare gli inventari

Per definire l'ambito della migrazione, devi conoscere l'ambiente della piattaforma dati in cui viene eseguito il deployment delle pipeline di dati:

  1. Crea un inventario della tua infrastruttura di dati, ovvero i diversi tipi di archiviazione e i vari livelli di calcolo utilizzati per l'archiviazione dei dati e l'elaborazione dei dati in batch.
  2. Creare un inventario delle pipeline di dati pianificate per essere di cui è stata eseguita la migrazione.
  3. Crea un inventario dei set di dati letti dai dati pipeline di dati e di cui è necessario eseguire la migrazione.

Per creare un inventario della tua piattaforma dati, considera quanto segue per ogni parte dell'infrastruttura dati:

  • Livelli di archiviazione. Insieme alle piattaforme di archiviazione standard come Cloud Storage, prendi in considerazione altri livelli di archiviazione come i database come Firebase, BigQuery, Bigtable e Postgres o altri cluster come Apache Kafka. Ogni piattaforma di archiviazione ha una propria strategia e un proprio metodo per completare la migrazione. Ad esempio: Cloud Storage include servizi di migrazione dei dati e un database dispongono di uno strumento di migrazione integrato. Assicurati che ogni prodotto che stai per l'archiviazione dei dati è disponibile nel tuo ambiente di destinazione, oppure che disponi di un dispositivo sostitutivo compatibile. Esercitati e verifica i requisiti tecnici trasferimento dei dati per ciascuna delle piattaforme di archiviazione interessate.
  • Livelli di calcolo. Per ogni piattaforma di calcolo, verifica di deployment e verificare le eventuali modifiche su diverse piattaforme.
  • Latenza di rete. Testa e verifica la latenza di rete tra tra l'ambiente di origine e l'ambiente di destinazione. Per te è importante per capire quanto tempo occorre per la copia dei dati. Devi inoltre avere per testare la latenza di rete da client e ambienti esterni (come un ambiente on-premise) all'ambiente di destinazione rispetto nell'ambiente di origine.

  • Configurazioni e deployment. Ogni prodotto di infrastruttura dei dati ha ha dei propri metodi di configurazione. Fai un inventario delle configurazioni personalizzate che hai creato per ogni componente e quali componenti stai utilizzando le versioni predefinite di ciascuna piattaforma (ad esempio, la versione Dataproc o Apache Kafka in uso). Marca che sia possibile eseguire il deployment di queste configurazioni nell'ambito di deployment.

    Devi sapere come è configurato ogni componente, poiché e motori potrebbero comportarsi in modo diverso a seconda della configurazione in modo diverso, soprattutto se il framework del livello di elaborazione cambia durante la migrazione. Ad esempio, se nell'ambiente di destinazione è in esecuzione un diversa di Apache Spark, alcune configurazioni potrebbe essere cambiato da una versione all'altra. Questo tipo di configurazione può causare cambiamenti in output, serializzazioni e calcoli.

    Durante la migrazione, ti consigliamo di utilizzare i deployment automatici per assicurare che le versioni e le configurazioni rimangano invariate. Se non puoi conservare le stesse versioni e configurazioni, quindi assicurati di avere e convalidare gli output di dati calcolati dal framework.

  • Dimensioni dei cluster. Per cluster autogestiti, ad esempio un cluster di lunga durata un cluster Dataproc o un cluster Apache Kafka in esecuzione su in Compute Engine, prendi nota del numero di nodi e CPU e della memoria per ciascun nodo nei cluster. La migrazione a un'altra regione potrebbe causare un al processore usato dal deployment. Pertanto, consigliamo profili e ottimizzare i carichi di lavoro dopo aver eseguito il deployment dell'infrastruttura alla produzione. Se un componente è completamente gestito o serverless (ad esempio Dataflow), le dimensioni faranno parte di ogni un singolo job e non fa parte del cluster stesso.

I seguenti elementi valutati nel tuo inventario si concentrano sui dati pipeline:

  • Origini dati e sink. Assicurati di tenere conto delle fonti e sink utilizzati da ogni pipeline di dati per la lettura e la scrittura dei dati.
  • Accordi sul livello del servizio (SLA) e obiettivi del livello di servizio (SLO). Gli SLA e gli SLO per le pipeline di dati in batch vengono solitamente misurati per il completamento, ma possono essere misurati anche in altri modi, come ad esempio potenza di calcolo utilizzata. I metadati aziendali sono importanti per promuovere la tua attività di continuità e del piano di ripristino di emergenza (BCDR), come l'errore su un sottoinsieme delle tue pipeline più critiche in un'altra regione del di un errore a livello di zona o di regione.
  • Dipendenze delle pipeline di dati. Alcune pipeline di dati si basano su dati viene generato da un'altra pipeline di dati. Quando suddividi le pipeline in degli sprint di migrazione, assicurati di considerare le dipendenze dei dati.
  • Set di dati generati e consumati. Per ogni pipeline di dati, identifica i set di dati utilizzati dalla pipeline e quelli generati. Attività può aiutarti a identificare le dipendenze tra le pipeline e sistemi o componenti presenti nell'architettura complessiva.

I seguenti elementi valutati nel tuo inventario si concentrano sui set di dati per eseguire la migrazione:

  • Set di dati. Identifica i set di dati di cui eseguire la migrazione nell'ambiente di destinazione. Potresti considerare alcuni dati storici come non necessari per la migrazione o da migrare in un momento diverso, se i dati vengono archiviati e non utilizzati attivamente. definendo l'ambito della migrazione del processo e gli sprint della migrazione, puoi ridurre i rischi associati.
  • Dimensioni dei dati. Se prevedi di comprimere i file prima di trasferirli, prendi nota delle dimensioni del file prima e dopo la compressione. Le dimensioni i tuoi dati incideranno sul tempo e sul costo necessari per copiare i dati dall'origine alla destinazione. Considerare questi fattori ti aiuterà scegliere tra le strategie di inattività, come descritto più avanti in questo documento.
  • Struttura dei dati. Classificare ogni set di dati di cui eseguire la migrazione e assicurarsi che a capire se i dati sono strutturati, semistrutturati o non strutturati. Comprendere la struttura dei dati può aiutarti a definire la strategia per verificare che la migrazione dei dati sia corretta e completa.

Completa la valutazione

Dopo aver creato gli inventari relativi ai tuoi cluster Kubernetes carichi di lavoro, completa le altre attività della fase Migrazione a Google Cloud: valuta e individua i tuoi carichi di lavoro.

Pianifica e costruisci le tue basi

La fase di pianificazione e creazione della migrazione a Google Cloud è composta da le seguenti attività:

  1. Creare una gerarchia di risorse.
  2. Configurare Identity and Access Management (IAM).
  3. Configura la fatturazione.
  4. Configura la connettività di rete.
  5. Rafforza la tua sicurezza.
  6. Configura il logging, il monitoraggio e gli avvisi.

Per ulteriori informazioni su ciascuna di queste attività, vedi Eseguire la migrazione a Google Cloud: creare le basi.

Migrazione di pipeline di dati e dati

Le sezioni seguenti descrivono alcuni aspetti del piano per la migrazione e pipeline di dati in batch. Definisce alcuni concetti relativi caratteristiche delle pipeline di dati che è importante capire quando per creare il piano di migrazione. Illustra inoltre alcuni concetti di test dei dati che possono per aumentare l'affidabilità della migrazione dei dati.

Piano di migrazione

Nel piano di migrazione, devi includere il tempo necessario per completare il trasferimento dei dati. Il tuo piano deve tenere conto della latenza di rete e del tempo necessario per testare la completezza dei dati e recuperare i dati di cui non è stato possibile eseguire la migrazione, oltre agli eventuali costi di rete. Poiché i dati verrà copiato da una regione all'altra, il piano per i costi di rete dovrebbe includono i costi di rete tra regioni.

Ti consigliamo di dividere le diverse pipeline e i diversi set di dati in sprint e migrarli separatamente. Questo approccio aiuta a ridurre i rischi per ogni sprint di migrazione e consente miglioramenti a ogni sprint. Per migliorare di migrazione e rilevare tempestivamente i problemi, ti consigliamo di dare la priorità carichi di lavoro non critici, più piccoli, prima di eseguire la migrazione carichi di lavoro con scale out impegnativi.

Un'altra parte importante di un piano di migrazione è descrivere la strategia, delle dipendenze e la natura delle diverse pipeline di dati livello di sicurezza. Se il livello di archiviazione dei dati e il livello di calcolo dei dati si basano stesso sistema, ti consigliamo di monitorare le prestazioni del sistema è in corso la copia dei dati. In genere, la copia di grandi quantità di dati può causa un overhead di I/O sul sistema e una riduzione delle prestazioni livello di sicurezza. Ad esempio, se esegui un carico di lavoro per estrarre dati da un cluster Kafka in modalità batch, le operazioni I/O aggiuntive per la lettura di grandi quantità di dati causare un peggioramento delle prestazioni su qualsiasi pipeline di dati attiva che è ancora in esecuzione nell'ambiente di origine. In questo tipo di scenario, è necessario monitorare le prestazioni del sistema utilizzando metriche integrate o personalizzate. Da evitare che sovraccarica il sistema, ti consigliamo di elaborare un piano per durante il processo di copia dei dati o per limitare la fase di copia.

Poiché la copia dei dati rende la migrazione un processo a lunga esecuzione, ti consigliamo che hai dei piani di emergenza per affrontare qualsiasi problema che possa andare storto durante la migrazione. Ad esempio, se lo spostamento dei dati sta richiedendo più tempo del previsto se i test di integrità hanno esito negativo prima di mettere online il nuovo sistema, valuta se vuoi eseguire il rollback o provare a risolvere il problema e riprovare a eseguire le operazioni non riuscite. Sebbene un il rollback può essere una soluzione più pulita, può essere dispendioso in termini di tempo e denaro e copiare più volte grandi set di dati. Ti consigliamo di avere una panoramica e test predefiniti per stabilire quale azione intraprendere e condizioni, quanto tempo consentire per provare a creare patch e quando eseguire un rollback completo.

È importante distinguere gli strumenti e gli script utilizzare per la migrazione e i dati che copi. Rollback dei dati in corso il movimento significa che devi ricopiare i dati e sostituirli o eliminarli che hai già copiato. Il rollback delle modifiche a strumenti e script potenzialmente più facile e meno costoso, ma le modifiche agli strumenti potrebbero costringere e ricopiare i dati. Ad esempio, potrebbe essere necessario copiare nuovamente i dati se crei un nuovo percorso di destinazione in uno script che genera una posizione di Cloud Storage in modo dinamico. Per evitare di ripetere la copia dei dati, crea script che consentano ripristinabilità e idempotenza.

Caratteristiche della pipeline di dati

Per creare un piano di migrazione ottimale, è necessario conoscere le caratteristiche di diverse pipeline di dati. È importante ricordare che Le pipeline batch che scrivono dati sono diverse da quelle che leggono dati:

  • Pipeline di dati che scrivono dati: poiché modificano lo stato del sistema di origine, può essere difficile scrivere dati nell'ambiente di origine nello stesso momento in cui i dati vengono copiati nell'ambiente di destinazione. Considera i runtime delle pipeline che scrivono dati e prova a dare la priorità e quindi di effettuare la migrazione nelle fasi iniziali del processo generale. In questo modo avrai i dati pronti nell'ambiente di destinazione prima di eseguire la migrazione delle pipeline per leggere i dati.
  • Pipeline di dati che leggono dati: le pipeline che leggono i dati potrebbero avere requisiti diversi per l'aggiornamento dei dati. Se le pipeline che generano vengono arrestati sul sistema di origine, poi le pipeline che leggono i dati potrebbero essere eseguiti durante la copia dei dati nell'ambiente di destinazione.

I dati sono stati e la loro copia tra regioni non è un'operazione atomica. Pertanto, è necessario prestare attenzione alle modifiche di stato durante la copia dei dati.

Inoltre, è importante nel piano di migrazione fare distinzione tra i diversi sistemi. Il tuo potrebbero avere requisiti funzionali e non funzionali (ad ad esempio un sistema per il batch e un altro per lo streaming). Di conseguenza, il tuo piano devono includere diverse strategie per la migrazione di ciascun sistema. Assicurati di specificare le dipendenze tra i sistemi e specificare come ridurre tempo di inattività per ciascun sistema durante ogni fase della migrazione.

Un piano tipico per uno sprint di migrazione dovrebbe includere quanto segue:

  • Strategia generale. Descrivere la strategia per la gestione della migrazione in questo sprint. Per le strategie comuni, consulta Esegui il deployment dei tuoi carichi di lavoro.
  • Elenco di strumenti e metodi per la copia dei dati e il deployment delle risorse. Specifica qualsiasi strumento che prevedi di utilizzare per copiare i dati o eseguire il deployment delle risorse per l'ambiente di destinazione. Questo elenco deve includere script personalizzati utilizzati per copiare gli asset di Cloud Storage, strumenti standard come Google Cloud CLI e strumenti di Google Cloud come Migration Service.
  • Elenco di risorse di cui eseguire il deployment nell'ambiente di destinazione. Elenca tutti risorse di cui è necessario eseguire il deployment nell'ambiente di destinazione. Questo elenco dovrebbe includere tutti i componenti dell'infrastruttura dati, bucket Cloud Storage, set di dati BigQuery di cluster Dataproc. In alcuni casi, la migrazione anticipata includerà il deployment di un cluster di dimensioni (come cluster Dataproc) con una capacità minore, per poi eseguire scatti includerà il ridimensionamento per adattarlo ai nuovi carichi di lavoro. Assicurati che il tuo piano può includere il potenziale ridimensionamento.
  • Elenco di set di dati da copiare. Per ogni set di dati, assicurati specificare le seguenti informazioni:
    • Ordine di copia (se applicabile): per la maggior parte delle strategie, il valore l'ordine delle operazioni potrebbe essere importante. Un'eccezione è la regola prevista di manutenzione descritta più avanti in questo documento.
    • Dimensioni
    • Statistiche principali: inserisci statistiche chiave su un grafico, ad esempio numero di riga, che può aiutarti a verificare che il set di dati sia stato copiato correttamente.
    • Tempo stimato per la copia: il tempo necessario per completare i dati. in base al piano di migrazione.
    • Metodo di copia: consulta l'elenco di strumenti e metodi descritti in precedenza in questo documento.
    • Test di verifica: elenca in modo esplicito i test che prevedi per verificare che i dati siano stati copiati per intero.
    • Piano di contingenza: descrivi cosa fare in caso di verifica che non hanno esito positivo. Il piano di emergenza deve specificare quando riprovare riprendi la copia o colma il vuoto e quando eseguire un rollback completo e ricopiare l'intero set di dati.

Test

In questa sezione vengono descritti alcuni tipi tipici di test che puoi pianificare. La possono aiutarti a garantire l'integrità e la completezza dei dati. Possono anche aiutarti per assicurarti che il livello computazionale funzioni come previsto e sia pronto per eseguire le pipeline di dati.

  • Riepilogo o confronto con l'hashing: per convalidare i dati. completezza dopo aver copiato i dati, è necessario confrontare l'originale rispetto alla nuova copia nell'ambiente di destinazione. Se i dati vengono strutturati all'interno di tabelle BigQuery, non puoi tabelle in una query per vedere se tutti i dati esistono, perché le tabelle risiedono regioni diverse. Per via dei costi e della latenza, BigQuery non consente alle query di unire i dati tra regioni. Al contrario, il metodo il confronto deve riassumere ogni set di dati e confrontare i risultati. A seconda sulla struttura del set di dati, il metodo per il riepilogo potrebbe essere diverso. Ad esempio, una tabella BigQuery potrebbe utilizzare un'aggregazione ma un insieme di file su Cloud Storage potrebbe utilizzare una query una pipeline per calcolare un hash di ogni file e poi aggregarli.

  • Flussi canary: i flussi canary attivano job creati per la convalida l'integrità e la completezza dei dati. Prima di continuare con i casi d'uso aziendali come l'analisi dei dati, può essere utile eseguire job canary per assicurarsi che i dati di input siano conformi a una serie di prerequisiti. Puoi implementare flussi canary come pipeline di dati personalizzate o come flussi in DAG basate su Cloud Composer. I flussi canary possono aiutarti a completare attività come verificando che non manchino valori per alcuni campi oppure che il conteggio delle righe di set di dati specifici corrisponda al conteggio previsto.

    Puoi anche utilizzare i flussi canary per creare digest o altre aggregazioni di un colonna o un sottoinsieme di dati. Puoi quindi utilizzare il flusso canary per confrontare i dati in un digest o aggregazione simile preso dalla copia i dati.

    I metodi di flusso canary sono utili quando è necessario valutare l'accuratezza di dati archiviati e copiati in formati file, come i file Avro in aggiunta a Cloud Storage. I flussi canary di solito non generano nuovi dei dati, ma non funzionano se non viene soddisfatto un insieme di regole all'interno dell'input e i dati di Google Cloud.

  • Ambiente di test: dopo aver completato il piano di migrazione, deve testare il piano in un ambiente di test. L'ambiente di test deve includere la copia dei dati campionati o di dati temporanei in un'altra regione, per stimare il tempo necessario per copiare i dati sulla rete. Questo test ti aiuta a identificare eventuali problemi con il piano di migrazione e a per verificare che sia possibile eseguire la migrazione dei dati. Il test dovrebbe che includano sia i test funzionali che quelli non funzionali. Test funzionali consente di verificare che la migrazione dei dati venga eseguita correttamente. Test non funzionali verifica che la migrazione soddisfi le esigenze di prestazioni, sicurezza e altri requisiti non funzionali. Ogni passaggio della migrazione nel piano includi un criterio di convalida che indichi quando il passaggio può essere preso in considerazione completato.

Per facilitare la convalida dei dati, puoi utilizzare Strumento di convalida dei dati (DVT, Data Validation Tool, DVT). Lo strumento esegue funzioni di convalida dei dati a più livelli a livello di tabella a livello di riga per consentirti di confrontare i risultati sistemi presi di mira.

I test devono verificare il deployment del livello computazionale e testare il e i set di dati copiati. Un approccio per farlo è creare un test pipeline in grado di calcolare alcune aggregazioni dei set di dati copiati e per verificare che i set di dati di origine e quelli di destinazione corrispondano. Una mancata corrispondenza tra i set di dati di origine e di destinazione sono più comuni quando i file copiati tra non sono rappresentazioni esatte in byte tra l'origine e la destinazione sistemi operativi (come quando modifichi i formati o la compressione dei file).

Ad esempio, considera un set di dati composto da file JSON delimitati da nuova riga. I file sono archiviati in un bucket Cloud Storage e sono montati come in BigQuery. Per ridurre la quantità di dati trasferiti sulla rete, puoi eseguire la compressione Avro durante la migrazione, prima di copiare i file nell'ambiente di destinazione. Questa conversione ha molti ma presenta anche alcuni rischi, perché i file che vengono scritti dell'ambiente di destinazione non sono una rappresentazione byte-copia dei file nell'ambiente di origine.

Per mitigare i rischi derivanti dallo scenario di conversione, puoi creare una nel job Dataflow o usare BigQuery per calcolare aggregazioni e hash di checksum del set di dati (ad esempio calcolando somme, medie o quantili per ciascuna colonna numerica). Per le colonne stringa, puoi calcolano le aggregazioni oltre alla lunghezza della stringa o sul relativo codice hash stringa. Per ogni riga, puoi calcolare un hash aggregato da una combinazione di tutte le altre colonne, il che può verificare con elevata precisione che una riga la stessa origine. Questi calcoli vengono eseguiti sia sull'origine che sulla destinazione ambienti per poi essere confrontati. In alcuni casi, ad esempio se il tuo set di dati è archiviato in BigQuery, non puoi unire le tabelle dall'origine ambienti di destinazione perché si trovano in regioni diverse, quindi devi usare in grado di connettersi a entrambi gli ambienti.

Puoi implementare i metodi di test precedenti in BigQuery o come job batch (ad esempio in Dataflow). Puoi quindi eseguire i job di aggregazione e confrontare i risultati calcolati per dell'ambiente di origine ai risultati calcolati per l'ambiente di destinazione. Questo può aiutarti a verificare che i dati siano completi e accurati.

Un altro aspetto importante del test del livello computazionale è l'esecuzione delle pipeline che includono tutti i tipi di motori di elaborazione e metodi di calcolo. Testare la pipeline è meno importante per i motori di calcolo gestiti come BigQuery o Dataflow. Tuttavia, è importante testare la pipeline per motori di calcolo non gestiti come Dataproc. Ad esempio, se disponi di Dataproc in un cluster che gestisce vari tipi di calcolo, come Apache Spark, Apache Hive, Apache Flink o Apache MapReduce, devi testare ogni per assicurarti che i diversi tipi di carichi di lavoro siano pronti trasferito.

Strategie di migrazione

Dopo aver verificato il piano di migrazione con test adeguati, puoi eseguire la migrazione e i dati di Google Cloud. Quando esegui la migrazione dei dati, puoi utilizzare strategie diverse per carichi di lavoro con scale out impegnativi. Ecco alcuni esempi di strategie di migrazione che puoi utilizzare così come sono o personalizzarli in base alle tue esigenze:

  • Manutenzione programmata: stai programmando quando si verifica la finestra di cutover. Questa strategia è utile quando i dati vengono modificati di frequente, ma gli SLO e gli SLA (accordi sul livello del servizio) possono resistere ad alcuni tempi di inattività. Questo strategia offre un'elevata affidabilità dei dati trasferiti perché sono completamente inattivi durante la copia. Per ulteriori informazioni, vedi Manutenzione pianificata in "Migrazione a Google Cloud: trasferimento di set di dati di grandi dimensioni".
  • Cutover in sola lettura: una leggera variazione della manutenzione pianificata. in cui la piattaforma dati del sistema di origine consente dati di sola lettura pipeline di dati per continuare a leggere i dati durante la loro copia. Questo è utile perché alcune pipeline di dati possono continuare a funzionare fornire insight ai sistemi finali. Lo svantaggio di questa strategia è che i dati prodotti non sono aggiornati durante la migrazione, poiché l'origine non vengono aggiornati. Pertanto, potresti dover adottare un sistema di recupero dopo la migrazione, per tenere conto dei dati inattivi nei sistemi finali.
  • Completamente attivo: copi i dati in un timestamp specifico, mentre l'ambiente di origine è ancora attivo per le pipeline di dati di lettura e scrittura. Dopo aver copiato i dati e aver effettuato il passaggio al nuovo deployment, una fase di copia delta per ottenere i dati generati dopo la migrazione il timestamp nell'ambiente di origine. Questo approccio richiede coordinamento e considerazione rispetto ad altre strategie. Pertanto, il piano di migrazione deve includere le modalità di gestione dell'aggiornamento e dell'eliminazione operazioni sui dati di origine.
  • Doppie scritture: le pipeline di dati possono essere eseguite sia sull'origine che ambienti di destinazione mentre i dati vengono copiati. Questa strategia evita fase di copia delta necessaria per il backfill dei dati se utilizzi strategie attive o di sola lettura. Tuttavia, per fare in modo che i dati le pipeline producano risultati identici, una strategia di doppia scrittura richiede ulteriori test prima della migrazione. Se non esegui test avanzati, incontreranno problemi nel tentativo di consolidare cervello diviso in questo scenario. La strategia delle doppie scritture introduce anche potenziali costi che esegue gli stessi carichi di lavoro due volte in regioni diverse. Questa strategia ha la possibilità di migrare la piattaforma senza tempi di inattività, ma richiede molto più coordinamento per eseguirlo correttamente.

Test post-migrazione

Al termine della migrazione, è necessario verificare la completezza dei dati e pipeline di dati per garantire la validità. Se completi la migrazione in tempi rapidi, hai bisogno per eseguire questi test dopo ogni sprint. I test che esegui in questo sono simili ai test di integrazione: verifichi la validità di una pipeline di dati che esegue casi d'uso aziendali con dati di produzione completi come input e e poi controlli la validità dell'output. Puoi confrontare l'output di integrazione nell'output dell'ambiente di origine eseguendo lo stesso la pipeline di dati sia nell'ambiente di origine che nell'ambiente di destinazione. Questo tipo di test funziona solo se la pipeline di dati è deterministica e se puoi assicurano che l'input in entrambi gli ambienti sia identico.

Puoi confermare che i dati sono completi quando soddisfano un insieme di valori predefiniti in cui i dati nell'ambiente di origine sono uguali (o sufficientemente simili) ai dati nell'ambiente di destinazione. In base alla strategia utilizzata della sezione precedente, i dati potrebbero non corrispondere a uno a uno. Pertanto, devi predefinire i criteri per descrivere la completezza dei dati per il tuo caso d'uso. Per Ad esempio, per i dati delle serie temporali, potresti considerare i dati completi quando il record più aggiornato non è indietro di più di cinque minuti rispetto all'attuale timestamp.

Cutover

Dopo aver verificato e testato i dati e le pipeline di dati sulla destinazione puoi avviare la fase di cutover. Iniziare questa fase significa che i clienti potrebbero dover cambiare la configurazione per fare riferimento ai nuovi sistemi. In alcuni casi, la configurazione non può essere uguale a quella che rimanda al sistema di origine. Ad esempio, se un servizio deve leggere i dati in un bucket Cloud Storage, i client devono modificare la configurazione e quale bucket utilizzare. I nomi dei bucket Cloud Storage sono univoci a livello globale, il bucket Cloud Storage dell'ambiente di destinazione sarà diverso nell'ambiente di origine.

Durante la fase di cutover, devi ritirare e annullare la pianificazione dell'origine carichi di lavoro dell'ambiente di lavoro. Ti consigliamo di conservare i dati dell'ambiente di origine per un po' di tempo, nel caso in cui sia necessario eseguire il rollback.

La fase di test di pre-migrazione non è completa quanto un'esecuzione di produzione di un dato una pipeline o un blocco note personalizzato. Pertanto, una volta completato il cutover e il sistema di destinazione operativo, devi monitorare le metriche, i runtime e gli output semantici delle tue pipeline di dati. Questo monitoraggio ti aiuterà a individuare gli errori che i tuoi di test non è stata completata, questo ci aiuterà a garantire il successo della migrazione.

Ottimizza il tuo ambiente

L'ottimizzazione è l'ultima fase della migrazione. In questa fase, devi rendere più efficiente eseguendo più iterazioni di un loop ripetibile finché l'ambiente non soddisfa i requisiti di ottimizzazione:

  1. Valuta l'ambiente attuale, i team e il ciclo di ottimizzazione.
  2. Definisci i requisiti e gli obiettivi di ottimizzazione.
  3. Ottimizza il tuo ambiente e i tuoi team.
  4. Ottimizza il loop di ottimizzazione.

Per saperne di più su come ottimizzare il tuo ambiente Google Cloud, vedi Migrazione a Google Cloud: ottimizza l'ambiente.

Prepara i dati e le risorse di calcolo di Google Cloud per una migrazione tra regioni

Questa sezione fornisce una panoramica delle risorse di calcolo e di dati Google Cloud e dei principi di progettazione per prepararsi alla migrazione tra regioni diverse.

BigQuery

Poiché BigQuery è un data warehouse SQL serverless, per il deployment del livello di computing. Se alcuni dei tuoi dati BigQuery che specificano le regioni per l'elaborazione, dovrai modificare questi client. In caso contrario, BigQuery è lo stesso nell'ambiente di origine e nell'ambiente di destinazione. I dati BigQuery vengono archiviati in due tipi tabelle:

  • Tabelle BigQuery: tabelle in BigQuery formato. BigQuery gestisce i file di dati per te. Per maggiori informazioni informazioni sulla migrazione dei dati in formato BigQuery, consulta Gestisci i set di dati.
  • Tabelle esterne BigQuery: tabelle per le quali vengono visualizzati i dati. archiviati al di fuori di BigQuery. Dopo lo spostamento dei dati, ricreare le tabelle esterne nella nuova destinazione. Per maggiori informazioni informazioni sulla migrazione delle tabelle esterne, consulta Introduzione alle tabelle esterne.

Cloud Storage

Cloud Storage offre Storage Transfer Service che possono aiutarti a eseguire la migrazione dei tuoi dati.

Dataflow (batch)

Dataflow è un motore di elaborazione dei dati gestito da Google. Per aiutare semplificare la migrazione di Dataflow e garantire che i tuoi job in qualsiasi regione, occorre inserire tutti gli input e gli output parametri al tuo job. Invece di scrivere le posizioni dei dati di input e output in codice sorgente, ti consigliamo di trasmettere i percorsi e stringhe di connessione al database come argomenti o parametri.

Dataproc

Dataproc è un ambiente Apache Hadoop gestito che può eseguire compatibile con il framework Apache Hadoop. È compatibile con framework come Apache Spark, Apache Flink e Apache Hive.

Puoi utilizzare Dataproc nei seguenti modi, che incidono sul modo in cui devi eseguire la migrazione del tuo ambiente Dataproc tra regioni:

  • Cluster temporanei con dati su Cloud Storage: i cluster vengono creati per eseguire job specifici e questi vengono eliminati al termine dei job. Questo significa che anche il livello HDFS o qualsiasi altro stato del cluster distrutte. Se la configurazione soddisfa i seguenti criteri, tipo di utilizzo è più facile da migrare rispetto ad altri tipi di utilizzo:
    • Gli input e gli output dei job non sono impostati come hardcoded nel codice di origine le API nel tuo codice. I job ricevono invece input e output come argomenti.
    • Il provisioning dell'ambiente Dataproc automatica, comprese le configurazioni dei singoli framework utilizzati dal tuo ambiente.
  • Cluster di lunga durata con dati esterni: hai uno o più ma sono cluster di lunga durata, anche se non sono in esecuzione i job sul cluster, il cluster è ancora in esecuzione. I dati e le risorse sono separate perché i dati vengono salvati all'esterno del cluster Soluzioni Google Cloud come Cloud Storage in BigQuery. Questo modello è solitamente efficace quando ci sono sempre i job in esecuzione sul cluster, quindi non ha senso e configurare cluster come nel modello temporaneo. Poiché i dati e le sono separate, la migrazione è simile alla migrazione un modello temporaneo.
  • Cluster di lunga durata con dati nel cluster: il cluster è lungo ma il cluster mantiene anche lo stato, i dati o entrambi all'interno più comunemente come dati su HDFS. Questo tipo di utilizzo complica operazioni di migrazione perché dati e computing non sono separati; se esegui la migrazione l'uno senza l'altro, c'è un rischio elevato di creare incoerenze. Nella valuta la possibilità di spostare dati e stato al di fuori del cluster prima migrazione, per separare i due. Se questo è impossibile, ti consigliamo di utilizzare manutenzione pianificata per ridurre il rischio di creare incoerenze nei e i dati di Google Cloud.

Poiché esistono molti framework potenziali, molte versioni di questi framework, dovrai eseguire test approfonditi prima di di eseguire il piano di migrazione.

Cloud Composer

Cloud Composer è la versione gestita di Apache di Google Cloud Airflow, per l'orchestrazione e la pianificazione dei flussi. i DAG, le configurazioni i log vengono gestiti in un bucket Cloud Storage di cui deve essere eseguita la migrazione del deployment di Cloud Composer. Per eseguire la migrazione dello stato il deployment di Cloud Composer, salva e carica gli snapshot dell'ambiente.

Se hai eseguito il deployment di plug-in personalizzati in Cloud Composer Ad esempio, consigliamo di applicare una metodologia Infrastructure as Code di ricreare l'ambiente in modo completamente automatizzato.

Cloud Composer non gestisce i dati, ma attiva altri dati framework e piattaforme di elaborazione. Pertanto, la migrazione Cloud Composer può essere completamente isolato dai dati. Inoltre, Cloud Composer non elabora i dati, pertanto il deployment devono trovarsi nella stessa regione dei dati. Pertanto, puoi creare un il deployment di Cloud Composer nell'ambiente di destinazione ed è ancora in esecuzione di pipeline di origine nell'ambiente di origine. In alcuni casi, questa operazione può essere utile per gestire pipeline diverse in regioni diverse mentre l'intera piattaforma di cui viene eseguita la migrazione.

Cloud Data Fusion

Cloud Data Fusion è uno strumento di integrazione visiva che ti aiuta a creare pipeline di dati con un editor visivo. Cloud Data Fusion si basa sul progetto open source CDAP. Come Cloud Composer, Cloud Data Fusion non gestisce i dati stessa, ma attiva altri framework e piattaforme di elaborazione dei dati. Il tuo Le pipeline di Cloud Data Fusion devono essere esportate dall'origine e importati nell'ambiente di destinazione in uno dei modi seguenti:

A seconda della quantità di flussi da migrare, potresti preferire una il metodo precedente rispetto all'altro. L'utilizzo dell'API CDAP per creare uno script di migrazione potrebbe difficile e richiede più competenze di software engineering. Tuttavia, se o se i flussi cambiano con una frequenza relativamente elevata, viene potrebbe essere l'approccio migliore.

Passaggi successivi

Collaboratori

Autore: Eyal Ben Ivri | Cloud Solutions Architect

Altro collaboratore: Marco Ferrari | Cloud Solutions Architect