Esegui la migrazione tra regioni Google Cloud: prepara i carichi di lavoro di dati e 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 una futura espansione ad altre regioni o di una migrazione da una regione all'altra. Questo documento fa parte di una serie che ti aiuta a comprendere l'impatto dell'espansione della tua piattaforma dati in un'altra regione. Ti aiuta a imparare a fare quanto segue:

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

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

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

Percorso di migrazione con quattro fasi.

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

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

La moderna piattaforma dati su Google Cloud

Questa sezione descrive le diverse parti di una piattaforma dati moderna e come vengono solitamente create in Google Cloud. Il concetto generale di piattaforme dati può essere suddiviso in due sezioni:

  • Il livello di archiviazione dei dati è il luogo 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 di database.
  • Il livello di calcolo dei dati è qualsiasi elaborazione di dati che potresti attivare sul sistema di archiviazione. Come per il livello di archiviazione, ci sono molte possibili implementazioni e alcuni strumenti di archiviazione dati gestiscono anche il calcolo dei dati. Il ruolo del livello di calcolo dati nella piattaforma è caricare i dati dal livello di archiviazione, elaborarli e quindi salvare i risultati in un sistema di destinazione. Il sistema di destinazione può essere il livello di archiviazione di origine.

Alcune piattaforme 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 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 dati utilizzando questi servizi Google Cloud:

Potresti aver implementato il livello di calcolo dei dati utilizzando altri servizi Google Cloud come questi:

Per ridurre i tempi e la latenza delle comunicazioni, 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 elabori i dati.

Ti consigliamo inoltre di mantenere il livello di archiviazione dei dati separato dal livello di calcolo dei dati. Mantenere questi livelli separati aumenta la flessibilità nel modificare i livelli di calcolo e nella migrazione dei dati. Mantenere i livelli separati riduce anche l'utilizzo delle risorse, in quanto non è necessario mantenere sempre in esecuzione il livello di calcolo. Ti consigliamo quindi di eseguire il deployment dell'archiviazione e del calcolo dei dati su piattaforme separate nella stessa zona e nella stessa regione. Ad esempio, puoi spostare l'archiviazione dei dati da HDFS a Cloud Storage e utilizzare un cluster Dataproc per il calcolo.

Valuta il tuo ambiente

Nella fase di valutazione, determini i requisiti e le dipendenze per la migrazione delle pipeline di dati 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 istruisci i tuoi team su Google Cloud.
  4. Crea un esperimento e un proof of concept su Google Cloud.
  5. Calcolare 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: valutazione e scoperta dei carichi di lavoro. Le sezioni seguenti si basano sulle informazioni contenute nel documento.

Crea i tuoi inventari

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

  1. Crea un inventario dell'infrastruttura dei dati: i diversi livelli di archiviazione e di calcolo che utilizzi per l'archiviazione dei dati e l'elaborazione batch dei dati.
  2. Crea un inventario delle pipeline di dati di cui è pianificata la migrazione.
  3. Creare un inventario dei set di dati letti dalle 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 dei dati:

  • Livelli di archiviazione: Oltre alle piattaforme di archiviazione standard come Cloud Storage, prendi in considerazione altri livelli di archiviazione 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 offre 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 nel tuo ambiente di destinazione oppure di disporre di un dispositivo sostitutivo compatibile. Esercitati e verifica la procedura tecnica di trasferimento dei dati per ciascuna delle piattaforme di archiviazione interessate.
  • Livelli di calcolo. Per ogni piattaforma di calcolo, verifica il piano di deployment e le eventuali 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 l'ambiente di destinazione. È importante che tu capisca quanto tempo occorre per la copia dei dati. Devi inoltre testare la latenza di rete da client e ambienti esterni (ad esempio un ambiente on-premise) all'ambiente di destinazione rispetto all'ambiente di origine.

  • Configurazioni e deployment. Ogni prodotto di infrastruttura dati ha i propri metodi di configurazione. Fai un inventario delle configurazioni personalizzate che hai effettuato per ogni componente e dei componenti che utilizzi le versioni predefinite per ogni piattaforma (ad esempio, quale versione di Dataproc o di Apache Kafka stai utilizzando). Assicurati che sia possibile eseguire il deployment di queste configurazioni nell'ambito del processo di deployment automatizzato.

    Devi sapere come è configurato ogni componente, perché i motori di calcolo potrebbero comportarsi in modo diverso a seconda della configurazione, 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 da una versione all'altra. Questo tipo di modifica della configurazione può causare variazioni negli output, nelle serializzazioni e nel calcolo.

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

  • Dimensioni del cluster. Per i cluster autogestiti, ad esempio un cluster Dataproc a 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 comportare una modifica al processore utilizzato dal deployment. Pertanto, ti consigliamo di profilare e ottimizzare i carichi di lavoro dopo aver eseguito il deployment dell'infrastruttura migrata 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 sono incentrati sulle pipeline di dati:

  • Origini dati e sink. Assicurati di tenere conto delle origini e dei sink utilizzati da ogni pipeline di dati per leggere e scrivere i dati.
  • Accordo sul livello del servizio (SLA) e obiettivi del livello di servizio (SLO). Gli SLA e gli SLO delle pipeline di dati in batch vengono generalmente misurati nel tempo di completamento, ma possono anche essere misurati in altri modi, ad esempio in termini di potenza di calcolo utilizzata. Questi metadati aziendali sono importanti per promuovere processi di continuità aziendale e piano di ripristino di emergenza (BCDR), come il fallimento di un sottoinsieme delle tue pipeline più critiche in un'altra regione in caso di errore a livello di zona o di regione.
  • Dipendenze delle pipeline di dati. Alcune pipeline di dati si basano su dati generati da un'altra pipeline. Quando suddividi le pipeline in sprint di migrazione, assicurati di prendere in considerazione le dipendenze dei dati.
  • Set di dati generati e utilizzati. Per ogni pipeline di dati, identifica i set di dati utilizzati dalla pipeline e quelli che genera. Questo può aiutarti a identificare le dipendenze tra le pipeline e tra altri sistemi o componenti dell'architettura complessiva.

I seguenti elementi che valuti nel tuo inventario sono incentrati sui set di dati di cui eseguire la migrazione:

  • Set di dati. Identificare i set di dati di cui è necessario eseguire la migrazione nell'ambiente di destinazione. Potresti considerare alcuni dati storici come non necessari per la migrazione, oppure essere migrati in un momento diverso, se i dati sono archiviati e non vengono utilizzati attivamente. Se definisci l'ambito del processo di migrazione e gli sprint di migrazione, puoi ridurre i rischi durante la migrazione.
  • Dimensioni dei dati. Se prevedi di comprimere i file prima di trasferirli, assicurati di notare le dimensioni dei file prima e dopo la compressione. La dimensione dei dati influirà sul tempo e sul costo necessari per copiare i dati dall'origine alla destinazione. Questi fattori ti aiuteranno a scegliere tra le strategie per il tempo di riposo, come descritto più avanti in questo documento.
  • Struttura dei dati. Classifica ogni set di dati di cui eseguire la migrazione e assicurati di capire se i dati sono strutturati, semistrutturati o non strutturati. La comprensione della struttura dei dati può aiutarti a stabilire la corretta migrazione dei dati.

Completa la valutazione

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

Pianifica e getta le basi

La fase di pianificazione e creazione della migrazione a Google Cloud è composta 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 logging, monitoraggio e avvisi.

Per saperne di più su ciascuna di queste attività, consulta Eseguire la migrazione a Google Cloud: creare le basi.

Esegui la migrazione di pipeline di dati e dati

Le seguenti sezioni descrivono alcuni aspetti del piano per la migrazione di pipeline di dati e dati in batch. Definisce alcuni concetti relativi alle caratteristiche delle pipeline di dati che è importante comprendere quando si crea il piano di migrazione. Descrive inoltre alcuni concetti di test dei dati che aiuta ad aumentare l'affidabilità della migrazione dei dati.

Piano di migrazione

Nel tuo piano di migrazione, devi includere il tempo necessario per completare il trasferimento dei dati. Il tuo piano deve tenere conto della latenza di rete, del tempo necessario per testare la completezza dei dati e recuperare i dati di cui non è stata eseguita la migrazione, nonché gli 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 tra regioni.

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

Un'altra parte importante di un piano di migrazione è descrivere la strategia, le dipendenze e la natura delle diverse pipeline di dati dal livello di calcolo. Se il livello di archiviazione dati 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, la copia di grandi quantità di dati può causare l'overhead di I/O sul sistema e ridurre le prestazioni nel livello di calcolo. Ad esempio, se esegui un carico di lavoro per estrarre i dati da un cluster Kafka in modalità batch, le operazioni di I/O aggiuntive per leggere grandi quantità di dati possono causare un peggioramento 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 qualsiasi metrica integrata o personalizzata. Per evitare di sovraccaricare il sistema, ti consigliamo di elaborare un piano per ritirare alcuni carichi di lavoro durante il processo di copia dei dati o limitare la fase di copia.

Poiché la copia dei dati rende la migrazione un processo a lunga esecuzione, ti consigliamo di disporre di piani di emergenza per risolvere eventuali problemi durante la migrazione. Ad esempio, se lo spostamento dei dati richiede più tempo del previsto o se i test di integrità non vanno a buon fine prima di mettere online il nuovo sistema, valuta se vuoi eseguire il rollback o provare a risolvere il problema e riprovare le operazioni non riuscite. Sebbene un rollback possa essere una soluzione più pulita, copiare più volte set di dati di grandi dimensioni può essere dispendioso in termini di tempo e denaro. Ti consigliamo di disporre di test predefiniti e di una chiara comprensione per determinare quale azione 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 che utilizzi per la migrazione dai dati che stai copiando. Il rollback dello spostamento dei dati significa che devi ripetere la copia dei dati e sostituire o eliminare quelli già copiati. Il rollback delle modifiche agli strumenti e agli script è potenzialmente più semplice e meno costoso, ma le modifiche agli strumenti potrebbero costringerti a ripetere 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 località di Cloud Storage. Per evitare di ricopiare i dati, crea gli script in modo da consentire 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 dalle pipeline batch che leggono i dati:

  • pipeline di dati che scrivono dati: poiché cambia 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à alla migrazione nelle prime fasi del processo complessivo. In questo modo avrai i dati pronti nell'ambiente di destinazione prima di eseguire la migrazione delle pipeline che leggono i dati.
  • Pipeline di dati che leggono i dati: le pipeline che leggono i dati potrebbero avere requisiti diversi in termini di aggiornamento dei dati. Se le pipeline che generano dati vengono arrestate nel sistema di origine, quelle che leggono i dati potrebbero essere eseguite durante la copia dei dati nell'ambiente di destinazione.

I dati sono di stato e la copia dei dati tra regioni non è un'operazione atomica. Pertanto, è necessario essere consapevoli dei cambiamenti di stato durante la copia dei dati.

Inoltre, è importante differenziare 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 i flussi). Pertanto, il tuo piano dovrebbe includere diverse strategie per la migrazione di ciascun sistema. Assicurati di specificare le dipendenze tra i sistemi e di specificare in che modo 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 la gestione della migrazione in questo sprint. Per le strategie comuni, consulta Eseguire il deployment dei carichi di lavoro.
  • Elenco di strumenti e metodi per la copia dei dati e il deployment delle risorse. Specifica lo strumento che intendi utilizzare per copiare i dati o eseguire il deployment delle risorse nell'ambiente di destinazione. Questo elenco deve includere script personalizzati che vengono utilizzati per copiare gli asset di Cloud Storage, strumenti standard come gsutil e strumenti Google Cloud come i servizi di migrazione.
  • Elenco di risorse di cui eseguire il deployment nell'ambiente di destinazione. Elenca tutte le risorse di cui deve essere eseguito 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 di migrazione iniziali includeranno il deployment di un cluster di dimensioni ridotte (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 piano includa un potenziale ridimensionamento.
  • Elenco dei set di dati da copiare. Per ogni set di dati, assicurati di specificare le seguenti informazioni:
    • Ordine in fase 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: tracciare statistiche chiave, come il numero di riga, che possono aiutarti a verificare che il set 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: fai riferimento all'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 per intero.
    • Piano di contingenza: descrivi cosa fare se i test di verifica non vanno a buon fine. Il tuo piano di contingenza deve specificare quando riprovare e riprendere la copia o colmare il vuoto e quando eseguire un rollback completo e copiare di nuovo l'intero set di dati.

Test

Questa sezione descrive alcuni tipi 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 tue pipeline di dati.

  • Confronto di riepilogo o di hashing: per verificare la completezza dei dati dopo averli copiati, devi confrontare il set di dati originale con la nuova copia nell'ambiente di destinazione. Se i dati sono strutturati all'interno di tabelle BigQuery, non puoi unire le due tabelle in una query per vedere se tutti i dati esistono, perché le tabelle risiedono in regioni diverse. A causa dei costi e della latenza, BigQuery non consente alle query di unire i dati tra regioni. Il metodo di confronto deve invece riassumere ogni set di dati e confrontare i risultati. Il metodo di riepilogo potrebbe essere diverso a seconda della struttura del set di dati. Ad esempio, una tabella BigQuery potrebbe utilizzare una query di aggregazione, ma un insieme di file in Cloud Storage potrebbe utilizzare una pipeline Spark per calcolare un hash di ogni file e poi aggregarli.

  • Flussi canary: i flussi canary attivano job creati per convalidare l'integrità e la completezza dei dati. Prima di continuare con 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 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 la verifica dell'assenza di valori per determinati campi o la convalida 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 con un digest o un'aggregazione simile estratto dalla copia dei dati.

    I metodi di flusso canary sono preziosi quando è necessario valutare l'accuratezza dei dati archiviati e copiati nei formati file, come i file Avro in Cloud Storage. I flussi canary non generano nuovi dati, ma non riescono se un insieme di regole non viene soddisfatto 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 dei dati campionati o i dati temporanei in un'altra regione, per stimare il tempo necessario per copiare i dati sulla rete. Questo test consente di identificare eventuali problemi del piano di migrazione e di verificare che la migrazione dei dati possa essere eseguita correttamente. I test devono includere sia test funzionali che non funzionali. I test funzionali verificano che la migrazione dei dati venga eseguita correttamente. I test non funzionali verificano che la migrazione soddisfi i requisiti di prestazioni, sicurezza e altri requisiti non funzionali. Ogni passaggio della migrazione nel tuo piano deve includere un criterio di convalida che indichi quando il passaggio può essere considerato completato.

Per facilitare la convalida dei dati, puoi utilizzare lo strumento di convalida dei dati. Lo strumento esegue funzioni di convalida dei dati su più livelli, dal livello di tabella a quello di riga, e consente di 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 copiati. Un approccio per farlo è costruire una pipeline di test in grado di calcolare alcune aggregazioni dei set di dati copiati e di assicurarsi 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 è più comune quando i file copiati tra regioni non sono rappresentazioni esatte di copia in byte tra i sistemi di origine e di destinazione (ad esempio quando modifichi i formati di file o le compresse di 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 montati come tabella esterna in BigQuery. Per ridurre la quantità di dati trasferiti sulla rete, puoi eseguire la compressione Avro nell'ambito della migrazione, prima di copiare i file nell'ambiente di destinazione. Questa conversione ha molti svantaggi, ma presenta anche alcuni rischi, perché i file che vengono scritti nell'ambiente di destinazione non sono una rappresentazione di copia in byte dei file nell'ambiente di origine.

Per ridurre i rischi legati allo scenario di conversione, puoi creare un job Dataflow oppure 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 di tipo stringa, puoi calcolare le aggregazioni in base alla lunghezza della stringa o al relativo codice hash. Per ogni riga, puoi calcolare un hash aggregato da una combinazione di tutte le altre colonne, in modo da verificare con precisione che una riga sia uguale alla sua origine. Questi calcoli vengono effettuati sia sull'ambiente di origine che su 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 dagli ambienti di origine e di destinazione perché si trovano in regioni diverse, quindi devi utilizzare un client 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 l'ambiente di origine con quelli calcolati per l'ambiente di destinazione. Questo approccio può aiutarti a garantire che i dati siano completi e accurati.

Un altro aspetto importante dei test del livello computazionale è l'esecuzione di 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 i motori di calcolo non gestiti come Dataproc. Ad esempio, se hai un cluster Dataproc che gestisce diversi tipi di calcolo, come ApacheSpark, Apache Hive, Apache Flink o Apache MapReduce, devi testare ogni runtime per assicurarti che i diversi tipi di carichi di lavoro 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 carichi di lavoro 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 il periodo del cutover. Questa strategia è ideale quando i dati vengono modificati di frequente, ma SLO e SLA sono in grado di tollerare alcuni tempi di inattività. Questa strategia offre un'elevata affidabilità dei dati trasferiti perché i dati sono completamente inattivi durante la copia. Per maggiori informazioni, consulta la pagina Manutenzione pianificata in "Migrazione a Google Cloud: trasferimento dei tuoi set di dati di grandi dimensioni".
  • Cuscinetto di sola lettura: una leggera variazione della strategia di manutenzione pianificata, in cui la piattaforma 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 insight ai sistemi finali. Lo svantaggio di questa strategia è che i dati prodotti sono inattivi durante la migrazione, perché i dati di origine non vengono aggiornati. Pertanto, potrebbe essere necessario utilizzare una strategia 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 per le pipeline di dati di lettura e scrittura. Dopo aver copiato i dati e passato al nuovo deployment, esegui una fase di copia delta per recuperare i dati generati dopo il timestamp di migrazione nell'ambiente di origine. Questo approccio richiede più coordinamento e considerazione rispetto ad altre strategie. Pertanto, il tuo piano di migrazione deve includere il modo in cui gestirai le operazioni di aggiornamento ed eliminazione sui dati di origine.
  • Doppia scrittura: le pipeline di dati possono essere eseguite sia nell'ambiente di origine che in quello di destinazione, durante la copia dei dati. Questa strategia evita la fase di copia delta necessaria per eseguire il backfill dei dati se utilizzi le strategie completamente attive o di sola lettura. Tuttavia, per garantire che le pipeline di dati producano risultati identici, una strategia di doppia scrittura richiede più test prima della migrazione. Se non esegui i test avanzati, riscontrerai problemi durante il tentativo di consolidare uno scenario split-brain. La strategia di scrittura doppia introduce anche i potenziali costi dell'esecuzione due volte degli stessi carichi di lavoro in regioni diverse. Questa strategia ha il potenziale per eseguire la migrazione della tua piattaforma senza tempi di inattività, ma richiede molto più coordinamento per essere eseguita correttamente.

Test post-migrazione

Al termine della migrazione, devi testare la completezza dei dati e testare la validità delle pipeline di dati. Se completi la migrazione in velocità, devi eseguire questi test dopo ogni sprint. I test eseguiti in questa fase sono simili a quelli di integrazione: verifichi la validità di una pipeline di dati che esegue casi d'uso aziendali con dati completi di livello produzione come input, quindi 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 dei dati è deterministica e se puoi assicurarti che l'input per 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 a 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, puoi considerare completi i dati quando il record più aggiornato è in ritardo di più di cinque minuti rispetto al timestamp attuale.

Cutover

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

Durante la fase del cutover, devi ritirare e annullare la programmazione 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 di pre-migrazione non è completa come un'esecuzione di produzione di una pipeline di dati. Di conseguenza, una volta completata il cutover e che il sistema di destinazione è operativo, devi monitorare le metriche, i runtime e gli output semantici delle pipeline di dati. Questo monitoraggio ti aiuterà a individuare gli errori che la fase di test potrebbe aver perso e a garantire il successo della migrazione.

Ottimizza il tuo ambiente

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

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

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

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

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

BigQuery

Poiché BigQuery è un data warehouse SQL serverless, non è necessario eseguire il deployment del livello di calcolo. Se alcuni dei client BigQuery specificano le regioni per l'elaborazione, dovrai modificare i client. Altrimenti, BigQuery è lo stesso nell'ambiente di origine e nell'ambiente di destinazione. I dati BigQuery sono archiviati in due tipi di tabelle:

  • Tabelle BigQuery: tabelle in formato BigQuery. BigQuery gestisce i file di dati per conto tuo. Per saperne di più sulla migrazione dei dati in formato BigQuery, consulta Gestione dei set di dati.
  • Tabelle BigQuery esterne: tabelle per le quali i dati vengono archiviati al di fuori di BigQuery. Dopo lo spostamento dei dati, dovrai ricreare le tabelle esterne nella nuova destinazione. Per ulteriori informazioni sulla migrazione di tabelle esterne, consulta Introduzione alle tabelle esterne.

Cloud Storage

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

Dataflow (batch)

Dataflow è un motore di elaborazione dati gestito da Google. Per semplificare la migrazione a Dataflow e assicurare che il deployment dei job possa essere eseguito facilmente in qualsiasi regione, devi inserire tutti gli input e gli output 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 del 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 sulla modalità di migrazione dell'ambiente Dataproc in più regioni:

  • Cluster temporanei con dati su Cloud Storage: i cluster sono creati per eseguire job specifici e vengono eliminati al termine dei job. Ciò significa che viene eliminato anche il livello HDFS o qualsiasi altro stato del cluster. 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 nei job non sono impostati come hardcoded nel codice sorgente. I job ricevono invece input e output come argomenti.
    • Il provisioning dell'ambiente Dataproc è automatizzato, incluse le configurazioni dei singoli framework utilizzati nell'ambiente.
  • Cluster a lunga durata con dati esterni: hai uno o più cluster, ma sono a lunga durata. Anche se non esistono job in esecuzione nel cluster, il cluster è ancora attivo e in esecuzione. I dati e le risorse di calcolo sono separati perché vengono salvati all'esterno del cluster nelle soluzioni Google Cloud come Cloud Storage o BigQuery. In genere questo modello è efficace quando ci sono sempre job in esecuzione sul cluster, quindi non ha senso eliminare e configurare i cluster come nel modello temporaneo. Poiché i dati e le risorse di calcolo sono separati, la migrazione è simile a quella del modello temporaneo.
  • Cluster a lunga durata con dati nel cluster: il cluster dura a lungo, ma mantiene anche stato, dati o entrambi all'interno del cluster, comunemente come dati su HDFS. Questo tipo di utilizzo complica le operazioni di migrazione perché i dati e le risorse di calcolo non sono separati; se esegui la migrazione di uno senza l'altro, c'è un rischio elevato di creare incoerenze. In questo scenario, valuta la possibilità di spostare i dati e lo stato all'esterno 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 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 Google Cloud di Apache 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 del deployment di Cloud Composer, puoi salvare e caricare gli snapshot dell'ambiente.

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

Cloud Composer non gestisce i dati, ma attiva altri framework e piattaforme di elaborazione 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 sull'ambiente di origine. In alcuni casi, questo 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 consente di creare pipeline di dati utilizzando un editor visivo. Cloud Data Fusion è basato sul progetto open source CDAP. Come Cloud Composer, Cloud Data Fusion non gestisce i dati in sé, ma attiva altri framework e piattaforme di elaborazione 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 all'altro. Utilizzare l'API CDAP per creare uno script di migrazione può essere difficile e richiede maggiori competenze di progettazione del software. Tuttavia, se hai molti flussi o se i flussi cambiano relativamente spesso, un processo automatizzato potrebbe essere l'approccio migliore.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori:

Accedi a LinkedIn per vedere i profili LinkedIn non pubblici.