Esegui la migrazione tra regioni Google Cloud: prepara i dati e i carichi di lavoro 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 un 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 a spostare i dati e le 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 in anticipo una migrazione tra regioni o un'espansione a più regioni. In questo caso, potrebbe essere necessario un impegno aggiuntivo per preparare l'infrastruttura, i carichi di lavoro e i dati per la migrazione tra regioni e per l'espansione a più regioni.

Questo documento fa parte di una serie:

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

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

Percorso di migrazione con 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 crea una base.
  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 piattaforma di dati moderna e come vengono solitamente costruite in Google Cloud. Le piattaforme di dati come concetto generale possono essere suddivise in due sezioni:

  • Il livello di archiviazione dei dati è il luogo in cui vengono salvati i dati. I dati che salvi possono essere sotto forma di file in cui gestisci i byte effettivi su un file system come Hadoop Distributed File System (HDFS) o Cloud Storage oppure puoi utilizzare un linguaggio DSL (domain-specific language) per gestire i dati in un sistema di gestione del database.
  • Il livello di calcolo dei dati è qualsiasi elaborazione dei dati che potresti attivare sul sistema di archiviazione. Come per il livello di archiviazione, esistono molte implementazioni possibili e alcuni strumenti di archiviazione dei dati gestiscono anche il calcolo dei dati. 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. Ad esempio, potresti aver implementato il livello di archiviazione dei dati utilizzando questi servizi Google Cloud:

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

Per ridurre il tempo e la latenza della comunicazione, il costo del trasferimento di dati in uscita e il numero di operazioni di I/O tra il livello di archiviazione e il livello di calcolo, ti consigliamo di archiviare i dati nella stessa zona in cui li elabori.

Ti consigliamo inoltre di mantenere separato il livello di archiviazione dei dati dal livello di calcolo dei dati. Mantenere questi strati separati migliora la tua flessibilità la modifica dei livelli di calcolo e la migrazione dei dati. Mantenere separati i livelli consente inoltre di ridurre l'utilizzo delle risorse perché non è necessario mantenere in esecuzione il livello di calcolo. 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 tue 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 i carichi di lavoro di cui vuoi eseguire prima la migrazione.

Per ulteriori informazioni sulla fase di valutazione e su queste attività, consulta Migrazione a Google Cloud: valuta e scopri 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 comprendere l'ambiente della piattaforma dati in cui sono implementate le pipeline di dati:

  1. Crea un inventario della tua infrastruttura dati: i diversi livelli di archiviazione e di calcolo che utilizzi per l'archiviazione dei dati e l'elaborazione batch dei dati.
  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 la propria strategia e il proprio metodo per completare la migrazione. Ad esempio, Cloud Storage offre servizi di migrazione dei dati e un database potrebbe avere 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 il piano di implementazione e eventuali modifiche alla configurazione apportate alle diverse piattaforme.
  • Latenza di rete. Testa e verifica la latenza della rete tra l'ambiente di origine e quello di destinazione. È importante capire quanto tempo occorre per la copia dei dati. Devi anche verificare la latenza della rete dai client e dagli ambienti esterni (ad esempio un ambiente on-premise) all'ambiente di destinazione rispetto all'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). Assicurati che queste configurazioni siano diponibili per il deployment nell'ambito del processo di deployment automatico.

    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 una versione diversa di Apache Spark, alcune configurazioni del framework Spark potrebbero essere cambiate tra le versioni. Questo tipo di configurazione può causare cambiamenti in output, serializzazioni e calcoli.

    Durante la migrazione, ti consigliamo di utilizzare i deployment automatici garantire che le versioni e le configurazioni rimangano invariate. Se non puoi mantenere invariate le versioni e le configurazioni, assicurati di disporre di test che convalidino le uscite di dati calcolate dal framework.

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

I seguenti elementi che valuti nel tuo inventario si concentrano sulle pipeline di dati:

  • 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 gli 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 i set di dati 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 è necessaria la migrazione nell'ambiente di destinazione. Potresti considerare alcuni dati storici non necessari per la migrazione o da migrare in un secondo momento, se sono archiviati e non vengono 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 e ai tuoi carichi di lavoro Kubernetes, completa le restanti attività della fase di valutazione in Migrazione a Google Cloud: valuta e scopri i tuoi carichi di lavoro.

Pianifica e costruisci le tue basi

La fase di pianificazione e creazione della migrazione a Google Cloud è costituita dalle 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 Esegui la migrazione a Google Cloud: pianifica e costruisci le tue basi.

Esegui la migrazione dei dati e delle pipeline di dati

Le sezioni seguenti descrivono alcuni aspetti del piano per la migrazione delle pipeline di dati e dei dati batch. Definisce alcuni concetti relativi alle caratteristiche delle pipeline di dati che è importante comprendere quando crei 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 verranno copiati da una regione all'altra, il piano per i costi di rete deve includere i costi di rete interregionali.

Ti consigliamo di dividere le diverse pipeline e i diversi set di dati in sprint e migrarli separatamente. Questo approccio consente di ridurre i rischi per ogni sprint di migrazione e di apportare miglioramenti in ogni sprint. Per migliorare la strategia di migrazione e rilevare i problemi in anticipo, ti consigliamo di dare la priorità ai carichi di lavoro più piccoli e non critici prima di eseguire la migrazione di quelli più grandi e critici.

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 i dati da un cluster Kafka in batch, le operazioni I/O aggiuntive per leggere grandi quantità di dati possono causare un calo delle prestazioni di eventuali pipeline di dati attive ancora in funzione nell'ambiente di origine. In questo tipo di scenario, devi monitorare il rendimento del sistema utilizzando le 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 lungo, ti consigliamo di predisporre piani di emergenza per risolvere eventuali problemi 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 rollback possa essere una soluzione più chiara, può essere dispendioso in termini di tempo e denaro copiare set di dati di grandi dimensioni più volte. Ti consigliamo di avere una conoscenza chiara e test predefiniti per determinare quali azioni intraprendere in quali condizioni, quanto tempo concedere 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. Il rollback del movimento dei dati significa che devi copiare di nuovo i dati e sostituire o eliminare i dati che hai già copiato. Il rollback delle modifiche agli strumenti e agli script è potenzialmente più semplice e meno costoso, ma le modifiche agli strumenti potrebbero costringerti a ricopiare i dati. Ad esempio, potrebbe essere necessario copiare di nuovo i dati se crei un nuovo percorso di destinazione in uno script che genera dinamicamente una posizione Cloud Storage. 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. Prendi in considerazione i runtime delle pipeline che scrivono dati e cerca di dare la priorità alla loro migrazione all'inizio del processo complessivo. In questo modo, avrai i dati pronti nell'ambiente di destinazione prima di eseguire la migrazione delle pipeline che li leggono.
  • Pipeline di dati che leggono i dati: le pipeline che leggono i dati potrebbero avere requisiti diversi per l'aggiornamento dei dati. Se le pipeline che generano dati sono interrotte sul sistema di origine, le pipeline che leggono i dati potrebbero essere in grado di funzionare durante la copia dei dati nell'ambiente di destinazione.

I dati sono uno stato e la loro copia tra regioni non è un'operazione atomica. Pertanto, devi essere consapevole delle modifiche dello stato durante la copia dei dati.

Inoltre, è importante nel piano di migrazione distinguere 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). Pertanto, il tuo piano deve includere strategie diverse per la migrazione di ciascun sistema. Assicurati di specificare le dipendenze tra i sistemi e specificare come ridurre tempi di inattività per ciascun sistema durante ogni fase della migrazione.

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

  • Strategia generale. Descrivi la strategia per gestire la 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 l'interfaccia a riga di comando Google Cloud e strumenti Google Cloud come Migration Services.
  • Elenco delle risorse da eseguire nell'ambiente di destinazione. Elenca tutti risorse di cui è necessario eseguire il deployment nell'ambiente di destinazione. Questo elenco deve includere tutti i componenti dell'infrastruttura dati, come i bucket Cloud Storage, i set di dati BigQuery e i cluster Dataproc. In alcuni casi, gli sprint iniziali di migrazione includeranno il deployment di un cluster di dimensioni (ad esempio un cluster Dataproc) in una capacità inferiore, mentre gli sprint successivi includeranno il ridimensionamento in base ai nuovi carichi di lavoro. Assicurati che il piano includa 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 potrebbe essere importante l'ordine delle operazioni. Un'eccezione è la strategia di manutenzione programmata descritta più avanti in questo documento.
    • Dimensioni
    • Statistiche chiave: le statistiche chiave del grafico, ad esempio il numero di riga, che possono aiutarti a verificare che l'insieme di dati sia stato copiato correttamente.
    • Tempo stimato per la copia: il tempo necessario per completare il trasferimento dei dati, in base al piano di migrazione.
    • Metodo di copia: consulta l'elenco di strumenti e metodi descritto 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 emergenza: descrivi cosa fare in caso di fallimento dei test di verifica. 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

Questa sezione descrive alcuni tipi di test tipici che puoi pianificare. La possono aiutarti a garantire l'integrità e la completezza dei dati. Inoltre, possono aiutarti a verificare che il livello di calcolo funzioni come previsto ed è 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 con la 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. A causa del costo e della latenza, BigQuery non consente di eseguire query per unire i dati tra regioni. Il metodo di confronto deve invece riepilogare ogni set di dati e confrontare i risultati. A seconda della struttura del set di dati, il metodo di sintesi potrebbe essere diverso. Ad esempio, una tabella BigQuery potrebbe utilizzare una query di aggregazione, ma un insieme di file su Cloud Storage potrebbe utilizzare una pipeline Spark per calcolare un hash di ciascun file e poi aggregare gli hash.

  • Flussi canary: i flussi canary attivano job creati per convalidare l'integrità e la completezza dei dati. Prima di passare ai casi d'uso aziendali come l'analisi dei dati, può essere utile eseguire job di flusso canary per assicurarti che i dati di input siano conformi a un insieme di prerequisiti. Puoi implementare i flussi Canary come pipeline di dati personalizzate o come flussi in un DAG basato su Cloud Composer. I flussi Canary possono aiutarti a completare attività come verificare che non siano presenti valori mancanti per determinati campi o convalidare 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 una colonna o di 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 devi valutare l'accuratezza degli dati archiviati e copiati in formati di file, come i file Avro, su Cloud Storage. In genere, i flussi Canary non generano nuovi dati, ma non vanno a buon fine se un insieme di regole non viene soddisfatto all'interno dei dati di input.

  • 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 di dati campionati o di dati di staging in un'altra regione per stimare il tempo necessario per copiare i dati sulla rete. Questi test ti aiutano a identificare eventuali problemi con il piano di migrazione e a verificare che sia possibile eseguire la migrazione dei dati. I test devono includere sia i test funzionali che quelli non funzionali. I test di funzionalità verificano che la migrazione dei dati sia avvenuta correttamente. I test non funzionali verificano che la migrazione soddisfi i requisiti di prestazioni, sicurezza e altri requisiti non funzionali. Ogni passaggio di migrazione nel piano deve includere criteri di convalida che descrivono quando il passaggio può essere considerato 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, dal livello della tabella al livello della riga, e ti aiuta a confrontare i risultati dei sistemi di origine e di destinazione.

I test devono verificare il deployment del livello di calcolo e testare i set di dati che sono stati 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. Un mancato accoppiamento tra i set di dati di origine e di destinazione è più comune quando i file che copi tra le regioni non sono rappresentazioni esatte di copie di byte tra i sistemi di origine e di destinazione (ad esempio quando modifichi i formati dei file o le compressioni dei file).

Ad esempio, prendi in considerazione un set di dati composto da file JSON delimitati da una 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 dell'ambiente di origine.

Per ridurre i rischi dello scenario di conversione, puoi creare un job Dataflow o utilizzare BigQuery per calcolare alcune aggregazioni e hash di checksum del set di dati (ad esempio calcolando somme, medie o quantili per ogni 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 set di dati è archiviato in BigQuery, non puoi unire le tabelle degli ambienti di origine e di destinazione perché si trovano in regioni diverse, quindi devi utilizzare un client che possa 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 eseguire il test della pipeline per i motori di calcolo non gestiti come Dataproc. Ad esempio, se hai un cluster Dataproc che gestisce diversi tipi di calcolo, come Apache Spark, Apache Hive, Apache Flink o Apache MapReduce, devi testare ogni runtime per assicurarti che i diversi tipi di carico di lavoro siano pronti per essere trasferiti.

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 diversi. Ecco alcuni esempi di strategie di migrazione che puoi utilizzare così come sono o personalizzarli in base alle tue esigenze:

  • Manutenzione pianificata: puoi pianificare il periodo di transizione. 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, consulta la sezione Manutenzione pianificata in "Migrazione a Google Cloud: trasferimento dei tuoi 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. Questa strategia è utile perché alcune pipeline di dati possono continuare a funzionare e fornire approfondimenti ai sistemi di destinazione. 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: i dati vengono copiati in un timestamp specifico, mentre l'ambiente di origine è ancora attivo sia per le pipeline di dati di lettura sia per quelle di 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 la modalità di gestione delle operazioni di aggiornamento ed eliminazione 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 la fase di copia delta necessaria per il completamento dei dati se utilizzi le strategie completamente 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 di scrittura doppia introduce anche potenziali costi per l'esecuzione degli stessi carichi di lavoro due volte in regioni diverse. Questa strategia ha il potenziale di eseguire la migrazione della piattaforma senza tempi di riposo, ma richiede molto più coordinamento per essere eseguita correttamente.

Test post-migrazione

Al termine della migrazione, è necessario verificare la completezza dei dati e il test per una maggiore validità. Se completi la migrazione in sprint, devi eseguire questi test dopo ogni sprint. I test che esegui in questo sono simili ai test di integrazione, ovvero 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 del test di integrazione con l'output dell'ambiente di origine eseguendo la stessa pipeline di dati sia nell'ambiente di origine sia nell'ambiente di destinazione. Questo tipo di test funziona solo se la pipeline di dati è deterministica e se puoi assicurarti che l'input in entrambi gli ambienti sia identico.

Puoi confermare che i dati sono completi quando soddisfano un insieme di criteri predefiniti, in cui i dati nell'ambiente di origine sono uguali (o abbastanza simili) ai dati nell'ambiente di destinazione. A seconda della strategia utilizzata nella sezione precedente, i dati potrebbero non corrispondere uno a uno. Di conseguenza, devi predefinire i criteri per descrivere la completezza dei dati per il tuo caso d'uso. Ad esempio, per i dati delle serie temporali, potresti considerare i dati completi quando il record più aggiornato non è in ritardo di più di cinque minuti rispetto al timestamp corrente.

Cutover

Dopo aver verificato e testato i dati e le pipeline di dati nell'ambiente di destinazione, puoi iniziare la fase di transizione. L'avvio di questa fase comporta che i clienti potrebbero dover modificare la propria 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, pertanto il bucket Cloud Storage dell'ambiente di destinazione sarà diverso da quello dell'ambiente di origine.

Durante la fase di passaggio, devi ritirare e annullare la pianificazione dei carichi di lavoro dell'ambiente di origine. 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 pre-migrazione non è completa come un'esecuzione di produzione di una pipeline di dati. Pertanto, una volta completato il passaggio e il sistema di destinazione è operativo, devi monitorare le metriche, i runtime e gli output semantici delle pipeline di dati. Questo monitoraggio ti aiuterà a rilevare gli errori che potresti aver perso durante la fase di test e a garantire il buon esito della migrazione.

Ottimizza l'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. Stabilisci i requisiti e gli obiettivi di ottimizzazione.
  3. Ottimizza il tuo ambiente e i tuoi team.
  4. Ottimizza il ciclo di ottimizzazione.

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

Preparare 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, non devi eseguire il deployment del livello di calcolo. 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 di BigQuery vengono archiviati in due tipi di tabella:

  • 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 i dati sono memorizzati al di fuori di BigQuery. Dopo aver spostato i dati, dovrai 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 contribuire a semplificare la migrazione di Dataflow e assicurarti che i job possano essere facilmente dipiazzati in qualsiasi regione, devi inserire tutti gli input e le uscite come parametri nel job. Anziché scrivere le posizioni dei dati di input e di output nel codice sorgente, ti consigliamo di passare i percorsi Cloud Storage e le 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 influiscono sul modo in cui eseguire la migrazione dell'ambiente Dataproc tra le regioni:

  • Cluster temporanei con dati su Cloud Storage: i cluster vengono creati per eseguire job specifici e questi vengono eliminati al termine dei job. Ciò significa che anche il livello HDFS o qualsiasi altro stato del cluster viene distrutto. Se la tua configurazione soddisfa i seguenti criteri, la migrazione di questo tipo di utilizzo è più semplice 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 il calcolo sono separati perché i dati vengono salvati al di fuori del cluster su soluzioni Google Cloud come Cloud Storage o BigQuery. Questo modello è solitamente efficace quando sul cluster sono sempre in esecuzione job, quindi non ha senso smontare e configurare i cluster come nel modello temporaneo. Poiché i dati e le sono separate, la migrazione è simile alla migrazione un modello temporaneo.
  • Cluster a vita lunga con dati al loro interno: il cluster è a vita lunga, ma mantiene anche stato, dati o entrambi al suo 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 non è possibile, ti consigliamo di utilizzare la strategia di manutenzione pianificata per ridurre il rischio di creare incoerenze nei dati.

Poiché esistono molti potenziali framework e molte versioni e configurazioni di questi framework, devi eseguire test approfonditi prima 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 e i log vengono gestiti in un bucket Cloud Storage di cui deve essere eseguita la migrazione con il 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 nell'istanza Cloud Composer, ti consigliamo di applicare una metodologia di infrastruttura come codice per ricreare l'ambiente in modo completamente automatico.

Cloud Composer non gestisce i dati, ma attiva altri dati framework e piattaforme di elaborazione. Pertanto, la migrazione di Cloud Composer può essere completamente isolata dai dati. Anche Cloud Composer non elabora i dati, pertanto il deployment non deve necessariamente 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 utilizzando 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 essere difficile e richiede maggiori competenze di ingegneria del software. Tuttavia, se hai molti flussi o se questi cambiano relativamente di frequente, un processo automatizzato potrebbe essere l'approccio migliore.

Passaggi successivi

Collaboratori

Autore: Eyal Ben Ivri | Cloud Solutions Architect

Altro collaboratore: Marco Ferrari | Cloud Solutions Architect