Pianificazione preventiva, esecuzione e post-migrazione. Strategie da seguire per un passaggio efficace verso l’ambiente cloud. Guida pratica per gestire le priorità, valutare le modifiche e riconfigurare lo schema. Focus su dati, sicurezza e utenti
Per tanti anni l’Europa è stata la regione più scettica al mondo in termini di riluttanza ad adottare il cloud. Negli ultimi anni, la situazione è cambiata e molte aziende stanno adottando in modo deciso il cloud sia per i sistemi transazionali sia per i sistemi analitici. In particolare, lo slancio verso i sistemi analitici è stato significativo, soprattutto per quanto riguarda la data science e la migrazione dei data warehouse nel cloud.
Quasi tutti i principali sistemi di gestione dei database (DBMS) che supportano i data warehouse in locale ora funzionano anche nel cloud. La scelta è quindi vastissima: dai principali fornitori di servizi cloud come AWS, Microsoft e Google, a molti altri tra cui Oracle, IBM, Teradata, Snowflake ed Exasol. Un gran numero di aziende ha già migrato il proprio data warehouse o sta pianificando e implementando la migrazione del data warehouse. Tuttavia, non si tratta di un esercizio semplice. Alcuni data warehouse risalgono a circa vent’anni fa e quindi hanno già svolto forti quantità di lavoro, subendo anche cambiamenti molto significativi in un periodo di tempo così lungo. Di conseguenza, la migrazione del data warehouse nel cloud richiede una riflessione molto attenta.
Le tre fasi della migrazione
La migrazione dei data warehouse nel cloud si articola in tre fasi principali: la pianificazione preliminare, la migrazione vera e propria, e infine l’attività post-migrazione. La pianificazione pre-migrazione comprende: il business case (perché farlo?), l’ambito (per esempio, un data mart alla volta o l’intero data warehouse), la formazione del team di migrazione, la decisione sulle modifiche necessarie, la selezione delle tecnologie, la configurazione dell’ambiente cloud e la definizione dei test da eseguire. La migrazione vera e propria comporta molti altri aspetti, come la migrazione dello schema; la migrazione dei dati; la migrazione dell’elaborazione e del caricamento ETL; la migrazione di utenti, ruoli e gruppi; la migrazione dei privilegi di sicurezza dell’accesso; Migrazione di dashboard e report, compresi gli script delle operazioni di data warehouse; e infine la migrazione di qualsiasi modello di machine learning nel database.
L’attività successiva alla migrazione prevede l’esecuzione in parallelo con il data warehouse esistente, i test, i benchmark delle prestazioni, la modernizzazione post migrazione e l’integrazione con altri carichi di lavoro analitici che potrebbero già essere in esecuzione sul cloud. C’è molto a cui pensare. Senza dubbio, la pianificazione è la chiave del successo. Un passo fondamentale è quello di effettuare una valutazione dettagliata del data warehouse esistente, esaminando i modelli di dati del data warehouse e dei data mart, i flussi di dati ETL, le dipendenze (per esempio, le procedure archiviate), la qualità dei dati, la ridondanza dei dati e le difficoltà di manutenzione. Si potrebbe anche voler valutare le tecnologie esistenti in uso. Da questa valutazione si potrà capire se è necessaria una semplice migrazione “così com’è”, se sono necessarie alcune modifiche o se si ritiene che il data warehouse sia alla fine del proprio ciclo di vita e che sia necessaria una riprogettazione completa con una semplice migrazione dei dati nel sistema esistente.
Gestire le modifiche, quando e come?
Senza dubbio, in una migrazione di data warehouse c’è sempre la tentazione di apportare modifiche. Tuttavia, è necessario prestare attenzione, perché più si cambia, maggiore è il rischio per il progetto di migrazione del data warehouse. Se è necessario apportare modifiche, una buona domanda da porsi è: “Bisogna apportare modifiche prima della migrazione, dopo la migrazione o durante la migrazione?”. È chiaro che più tentativi si fanno durante la migrazione stessa, maggiore è il rischio per l’intero progetto. A mio parere, è meglio apportare modifiche prima o dopo la migrazione e ridurre al minimo le modifiche apportate durante la migrazione. Ciononostante, si dovranno sicuramente apportare alcune modifiche. Tra queste potrebbe esserci il cambio di sistema di gestione (DBMS). Questo cambiamento comporta di per sé una serie di sfide. Per esempio, rispetto al data warehouse esistente, ci si devono aspettare differenze di tipo di tabella, di tipo di dati, di vincoli di integrità, di privilegi del database e, naturalmente, di SQL.
Le domande chiave da porsi quando si pianifica la migrazione di un data warehouse sono molte. Le persone sono formate e hanno competenze nel cloud di destinazione e nel DBMS del data warehouse? Come si intende prevenire le interruzioni per gli utenti durante la migrazione? Si ha intenzione di introdurre maggiore agilità nel data warehouse e, se sì, come? Si ha intenzione di cambiare il design del modello di dati, per esempio da Kimball a Data Vault? Si ha intenzione di cambiare la tecnologia sottostante, per esempio DBMS, strumenti ETL, strumenti di BI o altro? Quali sono i carichi di lavoro e i processi che si possono migrare con il minimo sforzo? Quali sono i processi che oggi presentano problemi e che trarrebbero beneficio da una reingegnerizzazione? Quali carichi di lavoro sono obsoleti e richiedono una revisione completa? Che cosa è necessario migrare e in quale ordine?
Per quanto riguarda la strategia di migrazione effettiva del data warehouse, si presentano diverse opzioni tra cui scegliere. Le tre principali includono: la migrazione “Lift & Shift,” che prevede il trasferimento del data warehouse senza modifiche sostanziali; la semplificazione del data warehouse esistente seguita dalla migrazione; la completa riprogettazione su un DBMS analitico in cloud. L’obiettivo chiave durante la migrazione del data warehouse è quello di trovare un modo per ridurre al minimo il numero di dati da migrare, al fine di accelerare l’intero progetto di migrazione. Pertanto, vale la pena di identificare i dati ridondanti e inutilizzati. Per i data warehouse che hanno 10, 15 o 20 anni, si potrebbe rimanere sorpresi di sapere quanta ridondanza di dati esista. Se si dispone di dati ridondanti, vale la pena chiedersi: “Perché migrare dati che non sono mai stati utilizzati negli ultimi due o tre anni?”. Una cosa che si può fare è archiviare quei dati, ma mantenerli online e poi migrare il resto dei dati del data warehouse in cloud.
Riconfigurazione della struttura
Per quanto riguarda la migrazione dello schema, ovviamente se non si cambia il DBMS, la migrazione dovrebbe essere relativamente semplice, a patto che non si stia riprogettando drasticamente il modello di dati. Per esempio, la migrazione da un data warehouse con un design Kimball in esecuzione on-prem a Oracle Autonomous Data Warehouse in esecuzione su Oracle Cloud. In questo caso, gli strumenti per migrare il data warehouse dovrebbero essere disponibili presso il fornitore del DBMS (Oracle in questo caso). Tuttavia, se si sta cambiando il DBMS, vanno considerati molti aspetti quando si tratta di migrazione dello schema, tra cui i tipi di dati, i rapporti di compressione dei dati, gli indici del database, le procedure archiviate, le viste del database e così via. Gli indici esistenti possono essere una buona indicazione delle opzioni di prestazione, ma ovviamente dipende dal DBMS verso cui si sta effettuando la migrazione. Alcuni sistemi di gestione di database cloud, come ad esempio Snowflake, non utilizzano indici tradizionali. Anche la migrazione dei dati ha le sue sfide, considerando che i data warehouse contengono dati storici che possono risalire a molti anni.
Anche in questo caso, quindi, è necessario porsi delle domande. Qual è la dimensione attuale dei dati? I dati sono compressi? Quali saranno le dimensioni dei dati quando saranno decompressi al momento dell’esportazione? C’è spazio libero su disco nel data center per archiviare temporaneamente i dati? È necessario ottenere l’approvazione per rendere disponibile questo spazio su disco di riserva nel data center? Quante tabelle non utilizzate esistono nel data warehouse e nei mart esistenti? E infine, qual è la larghezza di banda della rete ed è sufficiente per spostare i dati? Quando si migra un data warehouse nel cloud, è fondamentale affrontare una serie di complessi interrogativi. La gestione dei metadati, la sicurezza e i gruppi di utenti sono solo alcune delle sfide da considerare. Se stai pianificando la tua prima migrazione nel cloud, non dimenticare che un approccio completo è fondamentale per il successo del tuo progetto.
Mike Ferguson
Managing director di Intelligent Business Strategies e analista specializzato in business intelligence ed enterprise business integration. Con oltre trent’anni di esperienza in ambito IT, ha svolto attività di consulenza per importanti aziende su temi quali la business intelligence, l’enterprise architecture, la business process integration, l’application integration e la data integration. Oltre a essere speaker in numerosi eventi e seminari in tutto il mondo, è anche autore di svariati articoli tecnici.
Mike Ferguson presenterà per Technology Transfer i seguenti seminari online live streaming: “Costruire una data strategy competitiva per una azienda data-driven” il 24 novembre 2023 – “La modernizzazione del data warehouse” il 4-5 dicembre 2023 – “Cataloghi dati” il 6 dicembre 2023.
