Pianificare la migrazione di un data warehouse

La migrazione di un data warehouse rappresenta una sfida per qualsiasi azienda. Per un'esecuzione corretta e per evitare imprevisti indesiderati e costi non pianificati, è necessario eseguire ricerche approfondite sulla sfida, mitigare i rischi e pianificare la migrazione per assicurarsi di essere il più pronti possibile. A livello generale, il piano deve coprire i passaggi del processo di migrazione del data warehouse e le attività al loro interno. I passaggi principali del processo sono:

• Preparazione pre-migrazione
• Strategia ed esecuzione della migrazione
• Post-migrazione

Ad esempio, la preparazione include elementi come la predisposizione del team di migrazione del data warehouse in termini di formazione delle competenze e di familiarità con la tecnologia. Include anche la configurazione di un lab del modello di verifica, la comprensione della modalità di gestione degli ambienti di test e produzione, l'autorizzazione appropriata per la migrazione dei dati e di un sistema di produzione all'esterno del firewall aziendale e la configurazione del software di migrazione nel data center per consentire la migrazione.

Per una migrazione di data warehouse senza problemi, il piano deve stabilire una chiara comprensione di:

• Caso aziendale, inclusi i driver, i vantaggi aziendali e i rischi.
• Ruoli e responsabilità del team di migrazione.
• Set di competenze e training necessari per consentire la corretta migrazione.
• Budget allocato per la migrazione completa.
• Strategia di migrazione.
• Come evitare rischi nel progetto di migrazione per evitare ritardi o rilavorazioni.
• Il sistema data warehouse esistente, l'architettura, lo schema, i volumi di dati, i flussi di dati, la sicurezza e le dipendenze operative.
• Differenze tra il sistema DBMS data warehouse locale e Azure Synapse, ad esempio tipi di dati, funzioni SQL, logica e altre considerazioni.
• Elementi di cui eseguire la migrazione e priorità.
• Attività di migrazione, approcci, ordine e scadenze.
• Modalità di controllo della migrazione.
• Come impedire interruzioni per gli utenti durante la migrazione.
• Cosa è necessario fare in locale per evitare ritardi e abilitare la migrazione.
• Strumenti per abilitare la migrazione sicura di schemi, dati ed elaborazione ETL in Azure.
• Modifiche di progettazione del modello di dati necessarie durante e dopo la migrazione.
• Eventuali modifiche alla tecnologia di pre-migrazione o post-migrazione e come ridurre al minimo le rilavorazioni.
• Deprecazione della tecnologia post-migrazione.
• Come implementare test e controllo di qualità per dimostrare il successo.
• Checkpoint per valutare lo stato di avanzamento e consentire di prendere decisioni.
• Piano di emergenza e i punti di ripristino dello stato precedente in caso di problemi.

Per ottenere questa comprensione, è necessario preparare e avviare attività specifiche prima di intraprendere qualsiasi migrazione. Diamo un'occhiata più in dettaglio.

Preparazione pre-migrazione

Esistono diversi aspetti da affrontare prima di iniziare una migrazione di data warehouse.

Ruoli chiave in un team di migrazione del data warehouse

I ruoli principali in un progetto di migrazione includono:

• Titolare dell'azienda
• Project manager (con un'esperienza di metodologia agile come Scrum)
• Coordinatore progetto
• Cloud engineer
• Amministratore del database (DBMS di data warehouse e Azure Synapse)
• Modellatori di dati
• Sviluppatori ETL
• Esperto di virtualizzazione dei dati (possibilmente un amministratore di database)
• Tecnico di test
• Business analyst (per testare query, report e analisi dello strumento BI)

Il team deve anche supportare il team dell'infrastruttura locale.

Competenze e formazione per la preparazione del team per la migrazione

Per quanto riguarda le competenze, l'esperienza è importante in una migrazione di data warehouse. Assicurarsi quindi che i membri appropriati del team di migrazione siano formati in nozioni fondamentali sul cloud di Azure, archiviazione BLOB di Azure, Azure Data Lake Storage, Azure Data Box, ExpressRoute, gestione delle identità di Azure, Azure Data Factory e Azure Synapse. È probabile che gli esperti di modellazione dei dati necessitino di ottimizzare i modelli di dati di Microsoft Azure Synapse dopo la migrazione dal data warehouse esistente.

Valutazione del data warehouse esistente

Un'altra parte della preparazione alla migrazione è la necessità di una valutazione completa del data warehouse esistente per comprendere appieno l'architettura, gli archivi dati, lo schema, la logica di business, i flussi di dati, la funzionalità DBMS usata, il funzionamento del warehouse e le dipendenze. Maggiore è la comprensione, meglio è. Una conoscenza dettagliata del funzionamento del sistema consente di comunicare e coprire tutte le basi.

Lo scopo della valutazione non è solo quello di garantire una comprensione dettagliata della configurazione corrente da parte del team di migrazione, ma anche di comprenderne i punti di forza e i punti deboli. Il risultato di una valutazione dell'attuale data warehouse può quindi influire sulla strategia di migrazione in termini di lift-and-shift rispetto a un approccio più ampio. Ad esempio, se il risultato di una valutazione è che il data warehouse si trova alla fine del ciclo di vita, chiaramente la strategia sarà piuttosto una migrazione dei dati a un data warehouse appena progettato in Azure Synapse rispetto a un approccio lift-and-shift.

Preparazione locale per la migrazione dei dati

Oltre a preparare e predisporre il team di migrazione per l'ambiente di destinazione e a valutare la configurazione corrente, è altrettanto importante impostare gli elementi in movimento in locale poiché i data warehouse di produzione tendono a essere controllati in modo significativo dalle procedure IT e dai processi di approvazione. Per evitare ritardi, assicurarsi che i team dell'infrastruttura e delle operazioni del data center siano pronti per la migrazione dei dati, dello schema, dei processi ETL e così via nel cloud di Azure. La migrazione dei dati può essere eseguita tramite:

• Da AzCopy ad Archiviazione BLOB di Azure.
• Microsoft Azure ExpressRoute per trasferire i dati compressi direttamente in Azure.
• Esportazione di file in Azure Data Box.

I fattori principali che influenzano quale di queste opzioni è selezionata sono le dimensioni del volume di dati (in terabyte) e la velocità di rete (in Mbps). È necessario calcolare il tempo necessario per eseguire la migrazione dei dati tramite la rete, considerando che i dati potrebbero essere compressi nel data warehouse e non esserlo più una volta esportati. Questa situazione può rallentare il trasferimento dei dati. Ricomprimere i dati tramite Gzip quando li si sposta con uno dei metodi precedenti. PolyBase può elaborare direttamente i dati compressi in Gzip. I volumi di dati di grandi dimensioni verranno probabilmente trasferiti tramite Azure Data Box se lo spostamento dei dati richiede troppo tempo.

Inoltre, per permettere ad Azure Data Factory di controllare l'esecuzione di esportazioni di dati del data warehouse esistenti da Azure, è necessario installare software di runtime di integrazione self-hosted nel data center per consentire la migrazione. Dati questi requisiti, se è necessaria un'approvazione formale per rendere possibile questa operazione, l'avvio tempestivo dei processi di approvazione appropriati per autorizzare questa operazione consentirà di evitare ritardi.

Preparazione di Azure per la migrazione di schemi e dati

In termini di preparazione sul lato Azure, l'importazione dei dati dovrà essere gestita tramite Microsoft Azure ExpressRoute o Microsoft Azure Data Box. Le pipeline di Azure Data Factory sono un modo ideale per caricare i dati nell'archiviazione BLOB di Azure e quindi caricarli da questa posizione in Azure Synapse usando PolyBase. Per sviluppare una pipeline di questo tipo, è quindi necessaria la preparazione sul lato Azure.

L'alternativa consiste nell'usare lo strumento ETL esistente in Azure se supporta Azure Synapse, ovvero configurare lo strumento in Azure da Azure Marketplace e predisporre una pipeline per importare i dati e caricarli in Archiviazione BLOB di Azure.

Definizione di una strategia di migrazione

Obiettivi della migrazione

In qualsiasi strategia deve essere presente un set di obiettivi definiti per indicare il successo. È quindi possibile impostare le modalità per raggiungerli e gli utenti che ne avranno responsabilità. Nella tabella seguente sono riportati esempi di obiettivi di migrazione e metriche corrispondenti per impostare gli obiettivi per in un progetto di migrazione di data warehouse cloud:

Tipi di obiettivi ed esempi di metriche:

Migliorare le prestazioni complessive

• Prestazioni di migrazione dei dati
• Prestazioni ETL
• Prestazioni di caricamento dei dati
• Prestazioni delle query complesse
• Numero di utenti simultanei

Esecuzione a costi inferiori

• Costo del calcolo in base al carico di lavoro, ad esempio numero di ore di calcolo x costo all'ora per:
  • Creazione di report standard
  • Query ad hoc
  • Elaborazione batch ELT
• Costo dell'archiviazione (staging, tabelle di produzione, indici, spazio temporaneo)

Operare con livelli di servizio e disponibilità migliori

• Contratti di servizio
• Disponibilità elevata

Migliorare la produttività

• Attività automatizzate, riduzione dell'organico amministrativo

Una corretta migrazione di data warehouse può quindi essere interpretata come un data warehouse che viene eseguito alla stessa o a una maggiore velocità, a costi inferiori rispetto al sistema legacy da cui è stata eseguita la migrazione. L'assegnazione di proprietari a questi obiettivi crea la responsabilità del loro raggiungimento. Garantisce inoltre che i test in un lab di modello di verifica, come definito nella sezione di riduzione dei rischi di questa guida, verranno considerati riusciti se identificano modi in cui è possibile raggiungere gli obiettivi.

Approccio alla migrazione

Sono disponibili diverse opzioni strategiche per la migrazione dei data warehouse esistenti ad Azure Synapse:

• Usare un approccio lift-and-shift con il data warehouse esistente così com'è.
• Semplificare il data warehouse esistente e quindi eseguirne la migrazione.
• Riprogettare completamente il data warehouse in Azure Synapse ed eseguire la migrazione dei dati.

I risultati della valutazione del data warehouse esistente influirà in modo significativo sulla strategia. Un buon risultato della valutazione potrebbe consigliare una strategia di lift-and-shift. Un risultato mediocre dovuto a una bassa agilità può indicare che è necessaria una semplificazione prima della migrazione. Un esito negativo potrebbe indicare che è necessaria una riprogettazione completa.

L'approccio lift-and-shift lascia l'architettura così com'è, cercando di ridurre al minimo il lavoro di spostamento del sistema esistente. Se lo strumento ETL esistente supporta già Azure Synapse, è possibile modificare la destinazione con il minimo sforzo. Tuttavia, vi saranno differenze per quanto riguarda tipi di tabella, tipi di dati, funzioni di SQL, viste, logica di business delle stored procedure e così via. Queste differenze e i relativi modi per aggirarle sono descritti in dettaglio nei documenti approfonditi di questa serie sulla migrazione.

Semplificare il data warehouse esistente prima della migrazione punta a ridurre la complessità per semplificare la migrazione stessa. Può includere:

• La rimozione o l'archiviazione di tabelle inutilizzate prima della migrazione per evitare la migrazione di dati non usati.
• La conversione di data mart fisici in data mart virtuali tramite il software di virtualizzazione dei dati per ridurre gli elementi di cui è necessario eseguire la migrazione. La conversione migliora anche l'agilità e riduce il costo totale di proprietà, quindi può essere considerata come una modernizzazione durante la migrazione.

È anche possibile semplificare come prima cosa eq uindi usare l'approccio lift-and-shift per gli elementi rimanenti.

Ambito di migrazione

Indipendentemente dalla strategia scelta, è necessario definire chiaramente l'ambito della migrazione, gli elementi che essa includerà e se si eseguirà la migrazione in modo incrementale o in una sola volta. Un esempio di migrazione incrementale è la migrazione dei data mart come prima cosa, seguita dal data warehouse. Questo approccio consente di concentrarsi sulle aree aziendali ad alta priorità, consentendo al team di sviluppare in modo incrementale competenze durante la migrazione di ogni mart, prima di eseguire la migrazione del data warehouse stesso.

Definizione degli elementi della migrazione

Creare un inventario di tutti gli elementi di cui è necessario eseguire la migrazione. Sono inclusi schema, dati, processi ETL (pipeline), privilegi di autorizzazione, utenti, livelli di accesso semantico dello strumento BI e applicazioni analitiche. In ognuno degli articoli di migrazione approfonditi di questa serie viene fornita una descrizione dettagliata delle operazioni di migrazione dell'inventario. Di seguito sono riportati i relativi collegamenti.

• Considerazioni sulla migrazione dello schema, sulla progettazione e sulle prestazioni.
• Migrazione dei dati, elaborazione ETL e caricamento.
• Accedere alle operazioni di sicurezza e data warehouse.
• Migrazione di visualizzazioni e report.
• Riduzione al minimo dell'impatto dei problemi SQL.
• Strumenti di terze parti che consentono di eseguire la migrazione del data warehouse.

Se non si è certi dell'approccio migliore, eseguire test in un lab di modello di verifica per identificare le tecniche ottimali. Per altre informazioni, vedere la sezione sulla riduzione dei rischi del progetto di migrazione di data warehouse.

Controllo della migrazione

La migrazione del data warehouse in Azure Synapse comporta attività da eseguire:

• Locale, ad esempio l'esportazione dei dati.
• In rete, ad esempio il trasferimento dei dati.
• Nel cloud di Azure, ad esempio, trasformazione, integrazione e caricamento dei dati.

Il problema è che la gestione di queste attività può essere complessa se script e utilità vengono tutti sviluppati, testati ed eseguiti in modo indipendente negli ambienti locali e di Azure. Aggiunge complessità soprattutto se il controllo della versione, la gestione dei test e l'esecuzione della migrazione non sono coordinati.

È consigliabile evitare queste complessità e controllarle da una posizione comune tramite un repository di controllo del codice sorgente per gestire le modifiche da sviluppo a test e produzione. L'esecuzione della migrazione comporterà attività da eseguire in locale, in rete e in Azure. Poiché Azure Synapse è l'ambiente di destinazione, il controllo dell'esecuzione della migrazione da Azure semplifica la gestione. Usare Azure Data Factory per creare una pipeline di controllo della migrazione al fine di controllare l'esecuzione sia in locale che in Azure. Ciò introduce l'automazione e riduce al minimo gli errori. Data Factory diventa uno strumento di orchestrazione della migrazione, non solo uno strumento di integrazione dei dati aziendali.

Altre opzioni per controllare la migrazione disponibili dai partner Microsoft in esecuzione in Azure includono strumenti di automazione del data warehouse per provare ad automatizzare la migrazione. Fornitori come WhereScape e Attunity, ad esempio. La maggior parte di questi strumenti di automazione è destinata a un approccio lift-and-shift alla migrazione. Anche in questo caso, alcuni elementi potrebbero non essere supportati da tali strumenti, ad esempio le stored procedure. Questi prodotti e molti altri sono descritti in dettaglio in una guida separata dedicata agli strumenti di terze parti che consentono di eseguire la migrazione ad Azure Synapse.

Test di migrazione

La prima cosa che serve per i test è definire una serie di fasi e risultati necessari per ogni test da eseguire al fine verificare e indicare l'esito positivo. È importante assicurarsi che tutti gli aspetti siano testati e confrontati tra i sistemi esistenti e trasferiti, tra cui:

• SCHEMA
• Tipi di dati convertiti dove necessario
• Usare lo schema definito dall'utente in Azure Synapse per distinguere tra le tabelle di data warehouse e data mart
• Utenti
• Ruoli e assegnazioni degli utenti a tali ruoli
• Privilegi di sicurezza per l'accesso ai dati
• Privacy e conformità dei dati
• Privilegi che regolano le funzionalità di amministrazione
• Qualità e integrità dei dati
• Elaborazione ETL che popola Azure Synapse nel data warehouse e dal data warehouse a qualsiasi data mart, inclusi i test
• Tutte le righe sono corrette in tutte le tabelle, inclusa la cronologia
• Elaborazione delle dimensioni a modifica lenta
• Elaborazione di Change Data Capture
• Calcoli e aggregazioni che usano funzioni che possono differire tra sistemi diversi
• Risultati di tutte le query, i report e i dashboard noti
• Prestazioni e scalabilità
• Funzionalità analitica
• Costi nel nuovo ambiente con pagamento in base al consumo

Automatizzare il test il più possibile, rendendo ogni test ripetibile e consentendo un approccio coerente alla valutazione dei risultati. Se i report e i dashboard non sono coerenti, la possibilità di confrontare la derivazione dei metadati tra i sistemi originali e migrati è utile durante i test di migrazione, poiché può evidenziare le differenze e individuare dove si sono verificate quando non sono facili da rilevare.

Il modo migliore per eseguire questa operazione in modo sicuro è creare ruoli, assegnare privilegi di accesso ai ruoli e quindi associare gli utenti ai ruoli. Per accedere al data warehouse appena trasferito, configurare un processo automatizzato per creare nuovi utenti e assegnare ruoli. Eseguire la stessa operazione per rimuovere gli utenti dai ruoli.

Comunicare il cambiamento a tutti gli utenti in modo che sappiano cosa cambierà e cosa aspettarsi.

Rimozione dei rischi dal progetto di migrazione del data warehouse

Un altro fattore critico della migrazione di data warehouse è la riduzione dei rischi del progetto al fine di ottimizzare la probabilità di successo. È possibile eseguire diverse operazioni per ridurre i rischi di una migrazione di data warehouse. e comprendono:

• Definizione di un lab di verifica per consentire al team di provare, eseguire test, comprendere eventuali problemi e identificare correzioni e ottimizzazioni che consentono di convalidare gli approcci di migrazione, migliorare le prestazioni e ridurre i costi. Consente inoltre di stabilire modi per automatizzare le attività, usare strumenti predefiniti e compilare modelli per acquisire le procedure consigliate, apprendere dall'esperienza e tenere traccia delle lezioni apprese. Si tratta di un modo prezioso per attenuare i rischi e aumentare le probabilità di successo. Inoltre, è possibile assegnare i proprietari ai test responsabili del raggiungimento degli obiettivi di migrazione definiti nella relativa strategia.
• Introdurre la virtualizzazione dei dati tra gli strumenti di BI e i data warehouse e i data mart. Introdurre la trasparenza degli utenti usando la virtualizzazione dei dati per ridurre i rischi in una migrazione di data warehouse e nascondere la migrazione agli utenti usando gli strumenti di business intelligence per la virtualizzazione dei dati, come illustrato nel diagramma seguente.

Lo scopo è quello di interrompere la dipendenza tra gli utenti aziendali usando gli strumenti di business intelligence self-service e lo schema fisico del data warehouse e dei data mart sottostanti di cui viene eseguita la migrazione. Introducendo la virtualizzazione dei dati, qualsiasi alternanza dello schema effettuata durante la migrazione di data warehouse e data mart ad Azure Synapse, ad esempio per ottimizzare le prestazioni, può essere nascosta agli utenti aziendali perché questi accedono solo alle tabelle virtuali nel livello di virtualizzazione dei dati. Se è necessaria una modifica strutturale, modificare solo i mapping tra il data warehouse o i data mart e le tabelle virtuali in modo che gli utenti rimangano inconsapevoli di tali modifiche e non siano a conoscenza della migrazione.

• Cercare di archiviare tutte le tabelle esistenti identificate come mai usate prima della migrazione del data warehouse, perché non è necessario eseguirne la migrazione. Un modo possibile per eseguire questa operazione è archiviare i dati inutilizzati nell'archiviazione BLOB di Azure o in Azure Data Lake Storage e creare tabelle esterne in Azure Synapse per tali dati in modo che risultino ancora online.
• Si consideri la possibilità di introdurre una macchina virtuale (VM) in Azure con una versione di sviluppo (in genere gratuita) della versione legacy esistente di DBMS del data warehouse in esecuzione in questa macchina virtuale. Ciò consente di spostare rapidamente lo schema del data warehouse esistente nella macchina virtuale e quindi in Azure Synapse mentre si lavora interamente nel cloud di Azure.
• Definire l'ordine di migrazione e le dipendenze.
• Assicurarsi che i team dell'infrastruttura e delle operazioni siano pronti per la migrazione dei dati il prima possibile nel progetto di migrazione.
• Identificare le differenze nella funzionalità DBMS e dove la logica di business proprietaria potrebbe diventare un problema. Ad esempio, è improbabile che la migrazione delle stored procedure per l'elaborazione ELT sia semplice e che non conterrà derivazione dei metadati poiché le trasformazioni sono nascoste nel codice.
• Considerare una strategia per eseguire la migrazione dei data mart come prima cosa, seguita dal data warehouse origine dei data mart. Il motivo è che abilita la migrazione incrementale, la rende più gestibile ed è possibile assegnare priorità alla migrazione in base alle esigenze aziendali.
• Considerare la possibilità di usare la virtualizzazione dei dati per semplificare l'architettura di data warehouse corrente prima di eseguire la migrazione, ad esempio per sostituire i data mart con data mart virtuali, in modo da poter eliminare gli archivi dati fisici e i processi ETL per i data mart senza perdere alcuna funzionalità prima della migrazione. In questo modo si riduce il numero di archivi dati di cui eseguire la migrazione, si riducono le copie dei dati, si riduce il costo totale di proprietà e si migliora l'agilità. Questa operazione richiede il passaggio da data mart fisici a data mart virtuali prima di eseguire la migrazione del data warehouse. In molti modi, è possibile considerare questo passaggio di modernizzazione del data warehouse prima della migrazione.

Passaggi successivi

Per altre informazioni sulle migrazioni di data warehouse, partecipare a un workshop virtuale sulla modernizzazione del data warehouse cloud in Azure di Informatica.