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

Last reviewed 2024-12-02 UTC

Questo documento descrive come progettare una piattaforma di dati su Google Cloud per ridurre al minimo l'impatto di una futura espansione ad altre regioni o di una migrazione da regione a regione. Questo documento fa parte di una serie che ti aiuta a comprendere l'impatto dell'espansione della tua piattaforma di dati in un'altra regione. Ti aiuta a imparare a:

  • 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 e l'elaborazione dei dati.

Le indicazioni di questa serie sono utili anche se non hai pianificato in anticipo una migrazione tra regioni o un'espansione in più regioni. In questo caso, potrebbe essere necessario dedicare ulteriore impegno alla preparazione dell'infrastruttura, dei workload e dei 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 conosca i seguenti documenti:

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

Percorso di migrazione con quattro fasi.

Durante ogni passaggio della migrazione, segui le fasi definite in Migrazione a Google Cloud: Guida introduttiva:

  1. Valuta e individua i tuoi carichi di lavoro.
  2. Pianificare e costruire una base.
  3. Esegui il deployment dei carichi di lavoro.
  4. Ottimizza l'ambiente.

La piattaforma dati moderna su Google Cloud

Questa sezione descrive le diverse parti di una moderna piattaforma di dati 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 è quello in cui vengono salvati i dati. I dati che stai salvando potrebbero 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 potresti utilizzare un linguaggio specifico del dominio (DSL) per gestire i dati in un sistema di gestione dei database.
  • Il livello di calcolo dei dati è qualsiasi elaborazione dei dati che potresti attivare sopra il 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 poi salvare i risultati in un sistema di destinazione. Il sistema di destinazione può essere il livello di archiviazione di origine.

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 livello di elaborazione dei dati. Nella maggior parte dei 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 altri serviziGoogle Cloud come questi:

Per ridurre il tempo e la latenza della comunicazione, il costo del trasferimento dei 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 separati questi livelli migliora la flessibilità nella modifica dei livelli di calcolo e nella migrazione dei dati. Mantenere i livelli separati riduce anche l'utilizzo delle risorse perché non devi mantenere il livello di calcolo sempre in esecuzione. Pertanto, ti consigliamo di eseguire il deployment dell'archiviazione e dell'elaborazione dei dati su piattaforme separate nella stessa zona e regione. Ad esempio, puoi spostare l'archiviazione dei dati da HDFS a Cloud Storage e utilizzare un cluster Dataproc per il calcolo.

Valutare l'ambiente

Nella fase di valutazione, determini i requisiti e le dipendenze per migrare le pipeline di dati batch che hai implementato:

  1. Crea un inventario completo delle tue pipeline di dati.
  2. Cataloga le pipeline in base alle loro proprietà e dipendenze.
  3. Forma e istruisci 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 workload di cui vuoi eseguire la migrazione per primi.

Per ulteriori informazioni sulla fase di valutazione e su queste attività, vedi Migrazione a Google Cloud: valutazione e individuazione dei carichi di lavoro. Le sezioni seguenti si basano sulle informazioni contenute in questo documento.

Creare gli inventari

Per definire l'ambito della migrazione, devi comprendere l'ambiente della piattaforma dati in cui vengono implementate le pipeline di dati:

  1. Crea un inventario della tua infrastruttura di dati, ovvero i diversi livelli di archiviazione e i diversi livelli di calcolo che utilizzi per l'archiviazione dei dati e l'elaborazione batch dei dati.
  2. Crea un inventario delle pipeline di dati la cui migrazione è pianificata.
  3. Crea un inventario dei set di dati letti dalle pipeline di dati e che devono essere migrati.

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

  • Livelli di archiviazione. Oltre 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 dispone di servizi di migrazione dei dati e un database potrebbe avere uno strumento di migrazione integrato. Assicurati che ogni prodotto che utilizzi per l'archiviazione dei dati sia disponibile nell'ambiente di destinazione o che tu disponga di una sostituzione compatibile. Esercitati e verifica la procedura tecnica di trasferimento dei dati per ciascuna delle piattaforme di archiviazione coinvolte.
  • Livelli di calcolo. Per ogni piattaforma di calcolo, verifica il piano di deployment e le modifiche alla configurazione che potresti aver apportato alle diverse piattaforme.
  • Latenza di rete. Testa e verifica la latenza di rete tra l'ambiente di origine e quello di destinazione. È importante che tu comprenda quanto tempo ci vorrà per copiare i dati. Devi anche testare la latenza di 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 i propri metodi di configurazione. Fai l'inventario delle configurazioni personalizzate che hai apportato per ogni componente e di quali componenti utilizzi le versioni predefinite per ogni piattaforma (ad esempio, quale versione di Dataproc o Apache Kafka stai utilizzando). Assicurati che queste configurazioni siano implementabili nell'ambito del processo di deployment automatizzato.

    Devi sapere come è configurato ogni componente perché i motori di calcolo potrebbero comportarsi in modo diverso se configurati in modo diverso, in particolare se il framework del livello di elaborazione cambia durante la migrazione. Ad esempio, se l'ambiente di destinazione esegue una versione diversa di Apache Spark, alcune configurazioni del framework Spark potrebbero essere cambiate tra le versioni. Questo tipo di modifica della configurazione può causare cambiamenti negli output, nelle serializzazioni e nel calcolo.

    Durante la migrazione, ti consigliamo di utilizzare le implementazioni automatiche per assicurarti che le versioni e le configurazioni rimangano invariate. Se non riesci a mantenere le versioni e le configurazioni uguali, assicurati di eseguire test che convalidino gli output di dati calcolati dal framework.

  • Dimensioni dei cluster. Per i cluster autogestiti, come un cluster Dataproc a lunga durata o un cluster Apache Kafka in esecuzione su Compute Engine, annota il numero di nodi e CPU e la memoria per ogni nodo nei cluster. La migrazione a un'altra regione potrebbe comportare una modifica del processore utilizzato dal deployment. Pertanto, ti consigliamo di profilare e ottimizzare i 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), il dimensionamento farà 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 origini e dei sink che ogni pipeline di dati utilizza per leggere e scrivere i dati.
  • Accordi sul livello del servizio (SLA) e obiettivi del livello del servizio (SLO). Gli SLA e gli SLO delle pipeline di dati batch vengono in genere misurati in base al tempo di completamento, ma possono essere misurati anche in altri modi, ad esempio in base alla potenza di calcolo utilizzata. Questi metadati aziendali sono importanti per guidare i processi del piano di continuità aziendale e ripristino di emergenza (BCDR), ad esempio il failover di un sottoinsieme delle pipeline più critiche in un'altra regione in caso di errore zonale o regionale.
  • Dipendenze delle pipeline di dati. Alcune pipeline di dati si basano su dati generati da un'altra pipeline di dati. Quando dividi le pipeline in sprint di migrazione, assicurati di considerare le dipendenze dei dati.
  • Set di dati generati e utilizzati. Per ogni pipeline di dati, identifica i set di dati che la pipeline utilizza e quelli che genera. In questo modo, puoi identificare le dipendenze tra le pipeline e tra altri sistemi o componenti dell'architettura complessiva.

I seguenti elementi che valuti nel tuo inventario si concentrano sui set di dati da migrare:

  • Set di dati. Identifica i set di dati di cui è necessario eseguire la migrazione all'ambiente di destinazione. Potresti considerare alcuni dati storici non necessari per la migrazione o da migrare in un secondo momento, se i dati sono archiviati e non vengono utilizzati attivamente. Definendo l'ambito del processo di migrazione e gli sprint di migrazione, puoi ridurre i rischi nella migrazione.
  • Dimensioni dei dati. Se prevedi di comprimere i file prima di trasferirli, assicurati di annotare le dimensioni del file prima e dopo la compressione. Le dimensioni dei dati influiranno sul tempo e sui costi necessari per copiare i dati dall'origine alla destinazione. Tenere in considerazione questi fattori ti aiuterà a scegliere tra le strategie di downtime, come descritto più avanti in questo documento.
  • Struttura dei dati. Classifica ogni set di dati da migrare e assicurati di capire se i dati sono strutturati, semistrutturati o non strutturati. Comprendere la struttura dei dati può aiutarti a definire la strategia per verificare che i dati vengano migrati correttamente e completamente.

Completa la valutazione

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

Pianificare e creare le basi

La fase di pianificazione e creazione della migrazione a Google Cloud consiste nelle seguenti attività:

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

Per maggiori informazioni su ciascuna di queste attività, consulta la pagina Eseguire la migrazione a Google Cloud: pianificare e creare le basi.

Eseguire la migrazione di dati e pipeline di dati

Le sezioni seguenti descrivono alcuni aspetti del piano di migrazione dei dati e delle pipeline di dati batch. Definisce alcuni concetti relativi alle caratteristiche delle pipeline di dati che è importante comprendere quando crei il piano di migrazione. Vengono inoltre illustrati alcuni concetti di test dei dati che possono aiutarti ad aumentare la tua fiducia nella migrazione dei dati.

Piano di migrazione

Nel piano di migrazione, devi includere il tempo necessario per completare il trasferimento dei dati. Il piano deve tenere conto della latenza di rete, del tempo necessario per verificare la completezza dei dati e recuperare i dati di cui non è stata eseguita la migrazione, nonché di eventuali costi di rete. Poiché i dati verranno copiati da una regione all'altra, il tuo piano per i costi di rete deve includere i costi di rete interregionale.

Ti consigliamo di dividere le diverse pipeline e i diversi set di dati in sprint e di eseguirne la migrazione separatamente. Questo approccio contribuisce a ridurre i rischi per ogni sprint di migrazione e consente di apportare miglioramenti in ogni sprint. Per migliorare la tua strategia di migrazione e scoprire 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 è la descrizione della strategia, delle dipendenze e della natura delle diverse pipeline di dati dal livello di calcolo. Se il livello di archiviazione e il livello di calcolo dei dati sono basati sullo stesso sistema, ti consigliamo di monitorare le prestazioni del sistema durante la copia dei dati. In genere, l'operazione di copia di grandi quantità di dati può causare un sovraccarico di I/O sul sistema e ridurre le prestazioni nel livello di calcolo. Ad esempio, se esegui un carico di lavoro per estrarre dati da un cluster Kafka in modalità batch, le operazioni di I/O aggiuntive per leggere grandi quantità di dati possono causare un calo delle prestazioni di qualsiasi pipeline di dati attiva ancora in esecuzione nell'ambiente di origine. In questo tipo di scenario, devi monitorare le prestazioni del sistema utilizzando metriche integrate o personalizzate. Per evitare di sovraccaricare il sistema, ti consigliamo di pianificare il ritiro di alcuni carichi di lavoro durante la procedura di copia dei dati o di limitare la fase di copia.

Poiché la copia dei dati rende la migrazione un processo di lunga durata, ti consigliamo di avere piani di emergenza per affrontare qualsiasi problema che potrebbe verificarsi durante la migrazione. Ad esempio, se lo spostamento dei dati richiede più tempo del previsto o se i test di integrità non riescono prima di mettere online il nuovo sistema, valuta se vuoi eseguire il rollback o provare a correggere e ripetere le operazioni non riuscite. Sebbene un rollback possa essere una soluzione più pulita, copiare più volte set di dati di grandi dimensioni può richiedere molto tempo e denaro. Ti consigliamo di avere una chiara comprensione e test predefiniti per determinare quale azione intraprendere in quali condizioni, quanto tempo concedere per tentare di creare patch e quando eseguire un rollback completo.

È importante distinguere tra gli strumenti e gli script che utilizzi per la migrazione e i dati che copi. Il rollback dello spostamento dei dati significa che devi ricopiare i dati e sovrascrivere 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, potresti dover 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 copiare nuovamente i dati, crea script che consentano la ripresa e l'idempotenza.

Caratteristiche della pipeline di dati

Per creare un piano di migrazione ottimale, devi comprendere le caratteristiche delle diverse pipeline di dati. È importante ricordare che le pipeline batch che scrivono dati sono diverse da quelle che li leggono:

  • Pipeline di dati che scrivono dati: poiché modifica lo stato del sistema di origine, può essere difficile scrivere dati nell'ambiente di origine contemporaneamente alla copia dei dati nell'ambiente di destinazione. Considera i runtime delle pipeline che scrivono dati e prova a dare la priorità alla loro migrazione all'inizio del processo complessivo. In questo modo, i dati saranno 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 vengono interrotte nel sistema di origine, le pipeline che leggono i dati potrebbero essere in grado di essere eseguite durante la copia dei dati nell'ambiente di destinazione.

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

È anche importante distinguere i sistemi nel piano di migrazione. I tuoi sistemi potrebbero avere requisiti funzionali e non funzionali diversi (ad esempio, un sistema per il batch e un altro per lo streaming). Pertanto, il tuo piano deve includere strategie diverse per migrare ogni sistema. Assicurati di specificare le dipendenze tra i sistemi e come ridurre i tempi di inattività per ogni 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 strategie comuni, vedi Esegui il deployment dei 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 nell'ambiente di destinazione. Questo elenco deve includere script personalizzati utilizzati per copiare asset Cloud Storage, strumenti standard come lGoogle Cloud CLI e strumenti come i servizi di migrazione. Google Cloud
  • Elenco delle risorse da eseguire il deployment nell'ambiente di destinazione. Elenca tutte le risorse che devono essere implementate nell'ambiente di destinazione. Questo elenco deve includere tutti i componenti dell'infrastruttura dati, come bucket Cloud Storage, set di dati BigQuery e cluster Dataproc. In alcuni casi, gli sprint di migrazione iniziali includeranno il deployment di un cluster dimensionato (ad esempio un cluster Dataproc) con una capacità inferiore, mentre gli sprint successivi includeranno il ridimensionamento per adattarsi ai nuovi carichi di lavoro. Assicurati che il tuo piano includa il potenziale ridimensionamento.
  • Elenco dei set di dati da copiare. Per ogni set di dati, assicurati di specificare le seguenti informazioni:
    • Ordine di copia (se applicabile): per la maggior parte delle strategie, l'ordine di operazione potrebbe essere importante. Un'eccezione è la strategia di manutenzione pianificata descritta più avanti in questo documento.
    • Dimensioni
    • Statistiche chiave: mostra le statistiche chiave del grafico, ad esempio il numero di righe, 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 esplicitamente i test che prevedi di completare per verificare che i dati siano stati copiati integralmente.
    • Piano di emergenza: descrivi cosa fare se uno dei test di verifica non va a buon fine. Il piano di emergenza deve specificare quando riprovare e riprendere la copia o colmare la lacuna e quando eseguire un rollback completo e ricopiare l'intero set di dati.

Test

Questa sezione descrive alcuni tipi tipici di test che puoi pianificare. I test possono aiutarti a garantire l'integrità e la completezza dei dati. Possono anche aiutarti a verificare che il livello di calcolo funzioni come previsto e sia pronto per eseguire le pipeline di dati.

  • Confronto di riepilogo o hashing: per convalidare la completezza dei dati dopo la copia, devi confrontare il set di dati originale con la nuova copia nell'ambiente di destinazione. Se i dati sono strutturati all'interno delle tabelle BigQuery, non puoi unire le due tabelle in una query per verificare se esistono tutti i dati, perché le tabelle si trovano in regioni diverse. A causa del costo e della latenza, BigQuery non consente alle query di unire i dati tra le regioni. Il metodo di confronto deve riepilogare ogni set di dati e confrontare i risultati. A seconda della struttura del set di dati, il metodo di riepilogo potrebbe essere diverso. Ad esempio, una tabella BigQuery potrebbe utilizzare una query di aggregazione, mentre un insieme di file su Cloud Storage potrebbe utilizzare una pipeline Spark per calcolare un hash di ogni 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 assicurarsi che i dati di input rispettino un insieme di prerequisiti. Puoi implementare 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 ci siano 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 riepiloghi o altre aggregazioni di una colonna o di un sottoinsieme dei dati. Puoi quindi utilizzare il flusso canary per confrontare i dati con un riepilogo o un'aggregazione simili estratti dalla copia dei dati.

    I metodi di flusso canary sono utili quando devi valutare l'accuratezza dei dati archiviati e copiati in formati di file, come i file Avro in Cloud Storage. I flussi canary normalmente non generano nuovi dati, ma non riescono se un insieme di regole non viene rispettato nei dati di input.

  • Ambiente di test: dopo aver completato il piano di migrazione, devi testarlo in un ambiente di test. L'ambiente di test deve includere la copia di dati campionati o di staging 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 verificare che i dati possano essere migrati correttamente. I test devono includere test funzionali e non funzionali. I test funzionali verificano che i dati vengano migrati correttamente. Il test non funzionale verifica che la migrazione soddisfi i requisiti non funzionali relativi a prestazioni, sicurezza e altro. Ogni passaggio della migrazione nel tuo piano deve includere un criterio di convalida che specifichi quando il passaggio può essere considerato completato.

Per facilitare la convalida dei dati, puoi utilizzare lo strumento di convalida dei dati (DVT). Lo strumento esegue funzioni di convalida dei dati a più livelli, dal livello di tabella al livello di riga, e ti aiuta a confrontare i risultati dei sistemi di origine e di destinazione.

I test devono verificare il deployment del livello computazionale e testare i set di dati che sono stati copiati. Un approccio consiste nel creare una pipeline di test che possa calcolare alcune aggregazioni dei set di dati copiati e assicurarsi che i set di dati di origine e di destinazione corrispondano. Una mancata corrispondenza tra i set di dati di origine e di destinazione è più comune quando i file che copi tra le regioni non sono rappresentazioni esatte della copia byte tra i sistemi di origine e di destinazione (ad esempio quando modifichi i formati o le compressioni dei file).

Ad esempio, considera un set di dati composto da file JSON delimitati da una nuova riga. I file sono archiviati in un bucket Cloud Storage e vengono montati come tabella esterna in BigQuery. Per ridurre la quantità di dati spostati sulla rete, puoi eseguire la compressione Avro nell'ambito della migrazione, prima di copiare i file nell'ambiente di destinazione. Questa conversione presenta molti vantaggi, ma anche alcuni rischi, perché i file scritti nell'ambiente di destinazione non sono una rappresentazione byte per byte dei file nell'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 controllo del set di dati (ad esempio calcolando somme, medie o quantili per ogni colonna numerica). Per le colonne di stringhe, puoi calcolare le aggregazioni in base alla lunghezza della stringa o al codice hash della stringa. Per ogni riga, puoi calcolare un hash aggregato da una combinazione di tutte le altre colonne, che può verificare con elevata precisione che una riga è uguale alla sua origine. Questi calcoli vengono eseguiti sia nell'ambiente di origine che in quello di destinazione e poi vengono 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 l'ambiente di origine con quelli calcolati per l'ambiente di destinazione. Questo approccio può aiutarti ad assicurarti che i dati siano completi e accurati.

Un altro aspetto importante del test del livello di calcolo è l'esecuzione di pipeline che includono tutte le varietà di motori di elaborazione e metodi di calcolo. Il test della pipeline è meno importante per i motori di calcolo gestiti come BigQuery o Dataflow. Tuttavia, è importante testare la 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 workload siano pronti per essere trasferiti.

Strategie di migrazione

Dopo aver verificato il piano di migrazione con test adeguati, puoi eseguire la migrazione dei dati. Quando esegui la migrazione dei dati, puoi utilizzare strategie diverse per workload diversi. Di seguito sono riportati alcuni esempi di strategie di migrazione che puoi utilizzare così come sono o personalizzare in base alle tue esigenze:

  • Manutenzione pianificata: pianifichi quando si verifica la finestra di cutover. Questa strategia è adatta quando i dati vengono modificati di frequente, ma gli SLO e gli SLA possono resistere a un certo tempo di inattività. Questa strategia offre un'elevata affidabilità dei dati trasferiti perché i dati sono completamente obsoleti durante la copia. Per saperne di più, vedi Manutenzione pianificata in "Migrazione a Google Cloud: trasferimento di set di dati di grandi dimensioni".
  • Cutover di sola lettura: una leggera variazione della strategia di manutenzione pianificata, in cui la piattaforma di dati del sistema di origine consente alle pipeline di dati di sola lettura di continuare a leggere i dati durante la copia. Questa strategia è utile perché alcune pipeline di dati possono continuare a funzionare e fornire approfondimenti ai sistemi finali. Lo svantaggio di questa strategia è che i dati prodotti sono obsoleti durante la migrazione, perché i dati di origine non vengono aggiornati. Pertanto, dopo la migrazione potrebbe essere necessario utilizzare una strategia di recupero per tenere conto dei dati obsoleti 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 ed eseguito il passaggio al nuovo deployment, esegui una fase di copia delta per ottenere i dati generati dopo il timestamp della migrazione nell'ambiente di origine. Questo approccio richiede maggiore 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 nell'ambiente di origine sia in quello di destinazione durante la copia dei dati. Questa strategia evita la fase di copia delta necessaria per il backfill dei dati se utilizzi le strategie completamente attiva o di sola lettura. Tuttavia, per contribuire a garantire che le pipeline di dati producano risultati identici, una strategia di doppia scrittura richiede più test prima della migrazione. Se non esegui test avanzati, si verificheranno problemi durante il tentativo di consolidare uno scenario di split-brain. La strategia di doppia scrittura introduce anche potenziali costi di esecuzione degli stessi carichi di lavoro due volte in regioni diverse. Questa strategia ha il potenziale per eseguire la migrazione della piattaforma senza tempi di inattività, ma richiede molta più coordinazione per essere eseguita correttamente.

Test post-migrazione

Una volta completata la migrazione, devi testare la completezza dei dati e la validità delle pipeline di dati. Se completi la migrazione in sprint, devi eseguire questi test dopo ogni sprint. I test che esegui in questa fase sono simili ai test di integrazione: verifichi la validità di una pipeline di dati che esegue casi d'uso aziendali con dati di livello di produzione completi come input e poi esamini l'output per verificarne la validità. 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 in quello 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 sufficientemente simili) ai dati nell'ambiente di destinazione. A seconda della strategia utilizzata nella sezione precedente, i dati potrebbero non corrispondere uno a uno. Pertanto, 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 è più di cinque minuti indietro 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'inizio di questa fase significa che i clienti potrebbero dover modificare la configurazione per fare riferimento ai nuovi sistemi. In alcuni casi, la configurazione non può essere la stessa di quella che rimanda al sistema di origine. Ad esempio, se un servizio deve leggere i dati da un bucket Cloud Storage, i client devono modificare la configurazione per specificare il bucket da utilizzare. I nomi dei bucket Cloud Storage sono univoci a livello globale, quindi il bucket Cloud Storage dell'ambiente di destinazione sarà diverso da quello dell'ambiente di origine.

Durante la fase di cutover, devi ritirare e annullare la pianificazione dei workload 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 l'esecuzione di produzione di una pipeline di dati. Pertanto, una volta completato il cutover 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 potrebbero essere sfuggiti durante la fase di test e a garantire la riuscita della migrazione.

Ottimizzare l'ambiente

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

  1. Valuta l'ambiente, i team e il ciclo di ottimizzazione attuali.
  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 ulteriori informazioni su come ottimizzare il tuo Google Cloud ambiente, vedi Migrazione a Google Cloud: ottimizza il tuo ambiente.

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

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

BigQuery

Poiché BigQuery è un data warehouse SQL serverless, non devi eseguire il deployment del livello di calcolo. Se alcuni dei tuoi client BigQuery specificano le regioni per il trattamento, dovrai modificarli. In caso contrario, BigQuery è lo stesso nell'ambiente di origine e in quello di destinazione. I dati BigQuery vengono archiviati in due tipi di tabelle:

  • Tabelle BigQuery: tabelle nel formato BigQuery. BigQuery gestisce i file di dati per te. Per ulteriori informazioni sulla migrazione dei dati nel formato BigQuery, consulta Gestire i set di dati.
  • Tabelle esterne BigQuery: tabelle per le quali i dati sono archiviati al di fuori di BigQuery. Dopo lo spostamento dei dati, dovrai ricreare le tabelle esterne nella nuova destinazione. Per ulteriori informazioni sulla migrazione delle tabelle esterne, consulta Introduzione alle tabelle esterne.

Cloud Storage

Cloud Storage offre un Storage Transfer Service che può aiutarti a eseguire la migrazione dei dati.

Dataflow (batch)

Dataflow è un motore di trattamento dati gestito da Google. Per semplificare la migrazione di Dataflow e assicurarti che i job possano essere sottoposti a deployment in qualsiasi regione, devi inserire tutti gli input e gli output come parametri del job. Anziché scrivere le posizioni dei dati di input e 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 in grado di eseguire qualsiasi carico di lavoro 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 devi eseguire la migrazione dell'ambiente Dataproc tra le regioni:

  • Cluster effimeri con dati su Cloud Storage: i cluster vengono creati per eseguire job specifici e vengono eliminati al termine dei job. Ciò significa che anche il livello HDFS o qualsiasi altro stato del cluster viene eliminato. Se la tua configurazione soddisfa i seguenti criteri, questo tipo di utilizzo è più facile da migrare rispetto ad altri tipi di utilizzo:
    • Gli input e gli output dei job non sono codificati nel codice sorgente. I job ricevono input e output come argomenti.
    • Il provisioning dell'ambiente Dataproc è automatizzato, incluse le configurazioni per i singoli framework utilizzati dall'ambiente.
  • Cluster a lunga durata con dati esterni: hai uno o più cluster, ma sono cluster a lunga durata. Anche se non sono presenti job in esecuzione sul cluster, il cluster è comunque attivo e in esecuzione. I dati e il calcolo sono separati perché i dati vengono salvati al di fuori del cluster su soluzioniGoogle Cloud come Cloud Storage o BigQuery. Questo modello è in genere efficace quando ci sono sempre job in esecuzione sul cluster, quindi non ha senso smantellare e configurare i cluster come nel modello temporaneo. Poiché i dati e il calcolo sono separati, la migrazione è simile a quella del modello effimero.
  • Cluster di lunga durata con dati nel cluster: il cluster è di lunga durata, ma mantiene anche lo stato, i dati o entrambi all'interno del cluster, più comunemente come dati su HDFS. Questo tipo di utilizzo complica gli sforzi di migrazione perché dati e calcolo non sono separati; se esegui la migrazione di uno senza l'altro, esiste un alto rischio di creare incoerenze. In questo scenario, valuta la possibilità di spostare i dati e lo stato al di fuori del cluster prima della migrazione, per separarli. Se non è possibile, ti consigliamo di utilizzare la strategia di manutenzione pianificata per ridurre il rischio di creare incoerenze nei tuoi dati.

Poiché esistono molti framework potenziali 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 Airflow di Google Cloud, per l'orchestrazione e la pianificazione dei flussi. DAG, configurazioni e log vengono gestiti in un bucket Cloud Storage che deve essere migrato con il deployment di Cloud Composer. Per eseguire la migrazione dello stato della tua implementazione di Cloud Composer, puoi salvare e caricare 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 framework e piattaforme di elaborazione dei dati. Pertanto, la migrazione di Cloud Composer può essere completamente isolata dai dati. Inoltre, Cloud Composer non elabora i dati, quindi il deployment non deve trovarsi nella stessa regione dei dati. Pertanto, puoi creare un deployment di Cloud Composer nell'ambiente di destinazione ed eseguire comunque le pipeline nell'ambiente di origine. In alcuni casi, questa operazione può essere utile per gestire pipeline diverse in regioni diverse durante la migrazione dell'intera piattaforma.

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 direttamente, ma attiva altri framework e piattaforme di elaborazione dei dati. Le pipeline di Cloud Data Fusion devono essere esportate dall'ambiente di origine e importate nell'ambiente di destinazione in uno dei seguenti modi:

A seconda della quantità di flussi di cui devi eseguire la migrazione, potresti preferire un metodo rispetto a un 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 i flussi cambiano con una frequenza relativamente elevata, 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