Visualizzazione e creazione di report per le migrazioni Teradata

Questo articolo è la quarta parte di una serie in sette parti che offre indicazioni su come eseguire la migrazione da Teradata ad Azure Synapse Analytics. Questo articolo si concentra sulle procedure consigliate per la visualizzazione e la creazione di report.

Accedere ad Azure Synapse Analytics usando gli strumenti di business intelligence di Microsoft e di terze parti

Le organizzazioni accedono ai data warehouse e ai data mart usando vari strumenti e applicazioni di business intelligence (BI). Ecco alcuni esempi di prodotti BI:

• Strumenti di Microsoft BI, ad esempio Power BI.

• Applicazioni di Office, ad esempio fogli di calcolo di Microsoft Excel.

• Strumenti di business intelligence di terze parti di fornitori diversi.

• Applicazioni di analisi personalizzate con funzionalità di strumenti BI incorporate.

• Applicazioni operative che supportano la business intelligence su richiesta tramite l'esecuzione di query e report su una piattaforma BI che a sua volta esegue query sui dati in un data warehouse o un data mart.

• Strumenti di sviluppo di data science interattivi, ad esempio Notebook di Spark di Azure Synapse, Azure Machine Learning, RStudio e Jupyter Notebook.

Se si esegue la migrazione della visualizzazione e della creazione di report come parte della migrazione del data warehouse, tutte le query, i report e i dashboard esistenti generati dai prodotti BI devono essere eseguiti nel nuovo ambiente. I prodotti BI devono produrre gli stessi risultati in Azure Synapse di quelli prodotti nell'ambiente di data warehouse legacy.

Per ottenere risultati coerenti dopo la migrazione, tutte le dipendenze dell'applicazione e degli strumenti di business intelligence devono funzionare dopo aver eseguito la migrazione dello schema e dei dati del data warehouse ad Azure Synapse. Le dipendenze includono aspetti meno visibili, ad esempio accesso e sicurezza. Quando si lavora sull'accesso e la sicurezza, assicurarsi di eseguire la migrazione di:

• Autenticazione in modo che gli utenti possano accedere ai database del data warehouse e del data mart in Azure Synapse.

• Tutti gli utenti in Azure Synapse.

• Tutti i gruppi utenti in Azure Synapse.

• Tutti i ruoli in Azure Synapse.

• Tutti i privilegi di autorizzazione che regolano il controllo di accesso ad Azure Synapse.

• Assegnazioni di utenti, ruoli e privilegi per eseguire il mirroring degli elementi presenti nel data warehouse esistente prima della migrazione. Ad esempio:

  • Privilegi degli oggetti di database assegnati ai ruoli
  • Ruoli assegnati ai gruppi utenti
  • Utenti assegnati a gruppi utenti e/o ruoli

L'accesso e la sicurezza sono considerazioni importanti per l'accesso ai dati nel sistema di cui è stata eseguita la migrazione e sono descritti in modo più dettagliato in Sicurezza, accesso e operazioni per le migrazioni di Teradata.

Eseguire la migrazione di tutti i dati necessari per assicurarsi che i report e i dashboard che eseguono query sui dati nell'ambiente legacy producano gli stessi risultati in Azure Synapse.

Gli utenti aziendali prevedono di eseguire una migrazione senza problemi, senza sorprese che distruggano la fiducia nel sistema migrato in Azure Synapse. È consigliabile chiarire eventuali perplessità che gli utenti potrebbero avere attraverso una buona comunicazione. Gli utenti si aspettano che:

• La struttura della tabella rimanga invariata quando richiamata direttamente nelle query.

• I nomi di tabelle e colonne rimangano invariati quando richiamati direttamente nelle query. Ad esempio, i campi calcolati definiti nelle colonne degli strumenti di business intelligence non devono presentare quando vengono generati report aggregati.

• L'analisi cronologica rimane invariata.

• Se possibile, i tipi di dati rimangono invariati.

• Il comportamento delle query rimane invariato.

• I driver ODBC/JDBC vengono testati per garantire che il comportamento delle query rimanga invariato.

Se le query degli strumenti BI vengono visualizzate nel database del data warehouse o del data mart sottostante, queste viste continueranno a funzionare dopo la migrazione? Alcune viste potrebbero non funzionare se sono presenti estensioni SQL proprietarie specifiche del DBMS del data warehouse legacy che non hanno equivalenti in Azure Synapse. In tal caso, è necessario conoscere tali incompatibilità e trovare un modo per risolverle.

Altri problemi, ad esempio il comportamento dei valori NULL o delle variazioni dei tipi di dati nelle piattaforme DBMS, devono essere testati per garantire che non ci siano differenze, anche minime, nei risultati del calcolo. Ridurre al minimo questi problemi ed eseguire tutti i passaggi necessari per impedire che gli utenti aziendali siano interessati da tali problemi. A seconda dell'ambiente del data warehouse legacy, gli strumenti di terze parti consentono di nascondere le differenze tra gli ambienti legacy e i nuovi ambienti in modo che gli strumenti e le applicazioni di business intelligence vengano eseguiti senza cambiamenti.

Il test è fondamentale per la visualizzazione e la migrazione dei report. È necessario un gruppo di test e dati di test concordati per eseguire ed rieseguire i test in entrambi gli ambienti. Anche un test harness è utile e alcuni sono menzionati in questa guida. Inoltre, è importante coinvolgere gli utenti aziendali nell'aspetto di test della migrazione per mantenere alta la fiducia e coinvolgerli come parte del progetto.

Si potrebbe pensare di passare agli strumenti di business intelligence, ad esempio per eseguire la migrazione a Power BI. La tentazione è di apportare tali modifiche contemporaneamente alla migrazione dello schema, dei dati, dell'elaborazione ETL e di altro ancora. Tuttavia, per ridurre al minimo i rischi, è preferibile eseguire prima la migrazione ad Azure Synapse e assicurarsi che tutto funzioni correttamente prima di intraprendere un'ulteriore operazione di modernizzazione.

Se gli strumenti di business intelligence esistenti vengono eseguiti in locale, assicurarsi che possano connettersi ad Azure Synapse tramite il firewall in modo da poter eseguire confronti con entrambi gli ambienti. In alternativa, se il fornitore degli strumenti BI esistenti offre il proprio prodotto in Azure, è possibile provarlo lì. Lo stesso vale per le applicazioni in esecuzione in locale che incorporano BI o chiamano il server BI su richiesta, ad esempio richiedendo un "report headless" con dati XML o JSON.

A take proposito sono molti gli aspetti da considerare, pertanto l'argomento verrà approfondito.

Usare la virtualizzazione dei dati per ridurre al minimo l'impatto della migrazione sugli strumenti e i report di Business Intelligence

Durante la migrazione, si potrebbe essere tentati di soddisfare i requisiti a lungo termine, ad esempio l'apertura di richieste aziendali, l'aggiunta di dati mancanti o l'implementazione di nuove funzionalità. Tuttavia, tali modifiche possono influire sull'accesso degli strumenti di business intelligence al data warehouse, soprattutto se la modifica comporta modifiche strutturali al modello di dati. Se si vuole adottare una tecnica di modellazione dei dati agile o implementare modifiche strutturali, è consigliabile farlo dopo la migrazione.

Un modo per ridurre al minimo l'effetto delle modifiche dello schema o di altre modifiche strutturali negli strumenti di business intelligence consiste nell'introdurre la virtualizzazione dei dati tra gli strumenti di business intelligence e il data warehouse e i data mart. Il diagramma seguente illustra come la virtualizzazione dei dati può nascondere una migrazione agli utenti.

La virtualizzazione dei dati interrompe 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.

Con la virtualizzazione dei dati, qualsiasi alterazione dello schema effettuata durante la migrazione 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. Inoltre, se si apportano modifiche strutturali, è sufficiente aggiornare i mapping tra il data warehouse o i data mart e le tabelle virtuali. Con la virtualizzazione dei dati, gli utenti non sono consapevoli dei cambiamenti strutturali. I partner Microsoft forniscono software di virtualizzazione dei dati.

Identificare prima i report ad alta priorità di cui eseguire la migrazione

Una domanda fondamentale quando si esegue la migrazione dei report e dei dashboard esistenti ad Azure Synapse è: per quale di questi eseguire prima la migrazione? Diversi fattori possono influenzare tale decisione, ad esempio:

• Utilizzo

• Valore aziendale

• Facilità di migrazione

• Strategia di migrazione dei dati

Le sezioni seguenti illustrano questi fattori.

Indipendentemente dalla decisione, questa deve coinvolgere gli utenti aziendali essi perché producono report, dashboard e altre visualizzazioni e prendono decisioni aziendali in base alle informazioni dettagliate di tali elementi. Tutti ne traggono vantaggio quando è possibile:

• eseguire facilmente la migrazione di report e dashboard,
• eseguire la migrazione di report e dashboard con un impegno minimo e
• puntare gli strumenti BI ad Azure Synapse invece del sistema di data warehouse legacy e ottenere report, dashboard e altre visualizzazioni simili.

Eseguire la migrazione dei report in base all'utilizzo

L'utilizzo è spesso un indicatore del valore aziendale. I report e i dashboard inutilizzati non contribuiscono chiaramente alle decisioni aziendali o offrono il valore corrente. Se non si è in grado di scoprire quali report e dashboard non sono usati, è possibile usare uno dei diversi strumenti di business intelligence che forniscono statistiche sull'utilizzo.

Se il data warehouse legacy è in esecuzione da anni, esiste una buona probabilità che esistano centinaia, se non migliaia, di report. È consigliabile compilare un inventario di report e dashboard e identificarne lo scopo aziendale e le statistiche di utilizzo.

Per i report inutilizzati, determinare se rimuoverli per ridurre il lavoro di migrazione. Una domanda chiave quando si decide se rimuovere un report inutilizzato è se il report non è usato perché gli utenti non ne conoscono l'esistenza, perché non offre alcun valore aziendale o perché è stato sostituito da un altro report.

Eseguire la migrazione dei report in base al valore aziendale

L'utilizzo da solo non è sempre un buon indicatore del valore aziendale. È possibile considerare la misura in cui le informazioni dettagliate di un report contribuiscono al valore aziendale. Un modo per farlo consiste nel valutare la redditività di ogni decisione aziendale che si basa sul report e il grado di dipendenza. Tuttavia, è improbabile che tali informazioni siano facilmente disponibili nella maggior parte delle organizzazioni.

Un altro modo per valutare il valore aziendale consiste nell'esaminare l'allineamento di un report con la strategia aziendale. La strategia aziendale impostata dai dirigenti definisce in genere obiettivi aziendali strategici, indicatori di prestazioni chiave (KPI), obiettivi KPI che devono essere raggiunti e quale utente è responsabile del loro raggiungimento. È possibile classificare un report in base all'obiettivo aziendale strategico a cui contribuisce il report, ad esempio la riduzione delle frodi, il miglioramento dell'engagement dei clienti e le operazioni aziendali ottimizzate. È quindi possibile definire la priorità per la migrazione dei report e dei dashboard associati agli obiettivi con priorità alta. In questo modo, la migrazione iniziale può offrire valore aziendale in un'area strategica.

Un altro modo per valutare il valore aziendale consiste nel classificare i report e i dashboard come operativi, tattici o strategici per identificare in quale livello aziendale vengono usati. Gli obiettivi aziendali strategici richiedono un contributi a tutti questi livelli. Conoscendo i report e i dashboard usati, a quale livello e a quali obiettivi sono associati, è possibile concentrare la migrazione iniziale sul valore aziendale ad alta priorità. È possibile usare la tabella seguente sugli obiettivi della strategia aziendale per valutare report e dashboard.

Gli strumenti di individuazione dei metadati come Azure Data Catalog consentono agli utenti aziendali di contrassegnare e valutare le origini dati per arricchire i metadati per tali origini dati e facilitarne l'individuazione e la classificazione. È possibile usare i metadati per un report o un dashboard per comprendere il valore aziendale. Senza tali strumenti, è probabile che la comprensione del contributo dei report e dei dashboard per il valore aziendale sia un'attività dispendiosa in termini di tempo, indipendentemente dal fatto che si stia eseguendo o meno la migrazione.

Eseguire la migrazione dei report in base alla strategia di migrazione dei dati

Se la strategia di migrazione si basa innanzitutto sulla migrazione dei data mart, l'ordine di migrazione del data mart influirà sui report e sui dashboard di cui viene eseguita prima la migrazione. Se la strategia è basata sul valore aziendale, l'ordine in cui si esegue la migrazione dei data mart ad Azure Synapse rifletterà le priorità aziendali. Gli strumenti di individuazione dei metadati consentono di implementare la strategia mostrando quali tabelle di data mart forniscono i dati per quali report.

Problemi di incompatibilità della migrazione che possono influire su report e visualizzazioni

Gli strumenti di business intelligence producono report, dashboard e altre visualizzazioni eseguendo query SQL che accedono a tabelle fisiche e/o viste nel data warehouse o nel data mart. Quando si esegue la migrazione del data warehouse legacy ad Azure Synapse, diversi fattori possono influire sulla facilità di migrazione di report, dashboard e altre visualizzazioni. Tali fattori includono:

• Incompatibilità dello schema tra gli ambienti.

• Incompatibilità SQL tra gli ambienti.

Incompatibilità dello schema

Durante una migrazione, le incompatibilità dello schema nelle tabelle di data warehouse o data mart che forniscono dati per report, dashboard e altre visualizzazioni possono essere:

• Tipi di tabelle non standard nel DBMS del data warehouse legacy che non hanno un equivalente in Azure Synapse.

• Tipi di dati nel DBMS del data warehouse legacy che non hanno un equivalente in Azure Synapse.

Nella maggior parte dei casi, esiste una soluzione alle incompatibilità. Ad esempio, è possibile eseguire la migrazione dei dati in un tipo di tabella non supportato a una tabella standard con tipi di dati appropriati e indicizzati o partizionati in una colonna di data/ora. Analogamente, potrebbe essere possibile rappresentare i tipi di dati non supportati in un altro tipo di colonna ed eseguire calcoli in Azure Synapse per ottenere gli stessi risultati.

Per identificare i report interessati dalle incompatibilità dello schema, eseguire query sul catalogo di sistema del data warehouse legacy per identificare le tabelle con tipi di dati non supportati. È quindi possibile usare i metadati dello strumento BI per identificare i report che accedono ai dati in tali tabelle. Per altre informazioni su come identificare le incompatibilità dei tipi di oggetto, vedere Tipi di oggetto di database Teradata non supportati.

L'effetto delle incompatibilità dello schema nei report, nei dashboard e in altre visualizzazioni potrebbe essere minore di quanto si pensi, perché molti strumenti BI non supportano i tipi di dati meno generici. Di conseguenza, il data warehouse legacy potrebbe avere già viste che eseguono il comando CAST sui tipi di dati non supportati per tipi più generici.

Incompatibilità SQL

Durante una migrazione, è probabile che le incompatibilità SQL influiscano su tutti i report, i dashboard o altre visualizzazione in un'applicazione o in uno strumento che:

• Accede alle viste DBMS del data warehouse legacy che includono funzioni SQL proprietarie che non hanno equivalenti in Azure Synapse.

• Esegue query SQL che includono funzioni SQL proprietarie, specifiche del dialetto SQL dell'ambiente legacy, che non hanno equivalenti in Azure Synapse.

Misurare l'impatto delle incompatibilità SQL nel portfolio di creazione dei report

Il portfolio di creazione di report può includere servizi di query incorporati, report, dashboard e altre visualizzazioni. Non fare affidamento sulla documentazione associata a tali elementi per misurare l'effetto delle incompatibilità SQL sulla migrazione del portfolio di creazione di report ad Azure Synapse. È necessario usare un modo più preciso per valutare l'effetto delle incompatibilità SQL.

Usare le istruzioni EXPLAIN per trovare incompatibilità SQL

È possibile trovare incompatibilità SQL esaminando i log delle attività SQL recenti nel data warehouse Teradata legacy. Usare uno script per estrarre un set rappresentativo di istruzioni SQL in un file. Aggiungere quindi un prefisso a ogni istruzione SQL con un'istruzione EXPLAIN ed eseguire tali istruzioni EXPLAIN in Azure Synapse. Tutte le istruzioni SQL contenenti estensioni SQL proprietarie non supportate verranno rifiutate da Azure Synapse quando vengono eseguite le istruzioni EXPLAIN. Questo approccio consente di valutare l'entità delle incompatibilità SQL.

I metadati del DBMS del data warehouse legacy consentono anche di identificare le viste incompatibili. Come indicato in precedenza, acquisire un set rappresentativo di istruzioni SQL dai log applicabili, anteporre a ogni istruzione SQL un'istruzione EXPLAIN ed eseguire le istruzioni EXPLAIN in Azure Synapse per identificare le viste con SQL incompatibile.

Testare la migrazione di report e dashboard ad Azure Synapse Analytics

Un elemento chiave della migrazione del data warehouse è il test dei report e dei dashboard in Azure Synapse per verificare che la migrazione sia stata eseguita correttamente. Definire una serie di test e un set di risultati necessari per ogni test che verrà eseguito per verificare l'esito positivo. Testare e confrontare i report e i dashboard nei sistemi di data warehouse esistenti e di cui è stata eseguita la migrazione per:

• Identificare se le modifiche apportate allo schema durante la migrazione hanno influito sulla possibilità di eseguire i report, creare report dei risultati o le visualizzazioni dei report corrispondenti. Un esempio di modifica dello schema è se è stato eseguito il mapping di un tipo di dati incompatibile a un tipo di dati equivalente supportato in Azure Synapse.

• Verificare che venga eseguita la migrazione di tutti gli utenti.

• Verificare che venga eseguita la migrazione di tutti i ruoli e che gli utenti vengano assegnati a tali ruoli.

• Verificare che venga eseguita la migrazione di tutti i privilegi di sicurezza di accesso ai dati per garantire la migrazione dell'elenco di controllo di accesso (ACL).

• Garantire risultati coerenti per tutte le query, i report e i dashboard noti.

• Assicurarsi che i dati e la migrazione ETL siano completi e senza errori.

• Assicurarsi che la privacy dei dati venga mantenuta.

• Testare le prestazioni e la scalabilità.

• Testare la funzionalità analitica.

Per informazioni su come eseguire la migrazione di utenti, gruppi utenti, ruoli e privilegi, vedere Sicurezza, accesso e operazioni per le migrazioni di Teradata.

Automatizzare il test il più possibile per rendere ogni test ripetibile e supportare un approccio coerente alla valutazione dei risultati del test. L'automazione funziona bene per i normali report noti e può essere gestita tramite le pipeline di Azure Synapse o l'orchestrazione di Azure Data Factory. Se è già disponibile un gruppo di query di test per i test di regressione, è possibile usare gli strumenti di test esistenti per automatizzare i test post-migrazione.

L'analisi e la creazione di report ad hoc sono più complesse e richiedono la compilazione di un set di test per verificare che gli stessi report e dashboard pre- e post-migrazione siano coerenti. Se si trovano incoerenze, la possibilità di confrontare la derivazione dei metadati tra i sistemi originali e migrati durante i test di migrazione diventa fondamentale. Tale confronto può evidenziare le differenze e individuare la posizione in cui le incoerenze hanno avuto origine, quando il rilevamento mediante altri mezzi risulta difficile.

Analizzare la derivazione per comprendere le dipendenze tra report, dashboard e dati

La comprensione della derivazione è un fattore fondamentale per la corretta migrazione di report e dashboard. La derivazione è costituita da metadati che mostrano il percorso dei dati migrati in modo da poterne tenere traccia da un report o un dashboard fino all'origine dati. La derivazione mostra in che modo i dati sono stati trasferiti da punto a un altro, la loro posizione nel data warehouse e/o nel data mart e quali report e dashboard lo usano. La derivazione consente di comprendere cosa accade ai dati quando si spostano attraverso archivi dati diversi, ad esempio file e database, pipeline ETL diverse e nei report. Quando gli utenti aziendali hanno accesso alla derivazione dei dati, si migliora l'attendibilità, si infonde fiducia e si supportano decisioni aziendali informate.

Negli ambienti di data warehouse multi-fornitore, gli analisti aziendali nei team BI potrebbero mappare la derivazione dei dati. Ad esempio, se si usano fornitori diversi per ETL, data warehouse e creazione di report e ogni fornitore ha un proprio repository di metadati, capire da dove proviene un elemento dati specifico in un report può essere complesso e dispendioso in termini di tempo.

Per eseguire facilmente la migrazione da un data warehouse legacy ad Azure Synapse, usare la derivazione dei dati end-to-end per dimostrare una migrazione simile quando si confrontano i report e i dashboard generati da ogni ambiente. Per mostrare il percorso dei dati end-to-end, è necessario acquisire e integrare i metadati da diversi strumenti. L'accesso a strumenti che supportano l'individuazione automatica dei metadati e la derivazione dei dati, consente di identificare report duplicati o processi ETL e di trovare report basati su origini dati obsolete, discutibili o inesistenti. È possibile usare tali informazioni per ridurre il numero di report e processi ETL di cui si esegue la migrazione.

È anche possibile confrontare la derivazione end-to-end di un report in Azure Synapse con la derivazione end-to-end dello stesso report nell'ambiente legacy per verificare le differenze che potrebbero essersi verificate inavvertitamente durante la migrazione. Questo tipo di confronto è estremamente utile quando è necessario testare e verificare la corretta esecuzione della migrazione.

La visualizzazione della derivazione dei dati non solo riduce il tempo, lo sforzo e l'errore nel processo di migrazione, ma consente anche una migrazione più rapida.

Usando strumenti automatizzati di individuazione dei metadati e derivazione dei dati che confrontano la derivazione, è possibile verificare che un report in Azure Synapse prodotto dai dati di cui è stata eseguita la migrazione venga prodotto nello stesso modo nell'ambiente legacy. Questa funzionalità consente anche di determinare:

• Quali dati devono essere migrati per garantire la corretta esecuzione di report e dashboard in Azure Synapse.

• Quali trasformazioni sono state e devono essere eseguite per garantire la corretta esecuzione in Azure Synapse.

• Come ridurre la duplicazione dei report.

Gli strumenti automatizzati di individuazione dei metadati e derivazione dei dati semplificano notevolmente il processo di migrazione perché consentono alle aziende di acquisire maggiore consapevolezza degli asset di dati e di sapere quali elementi devono essere migrati in Azure Synapse per ottenere un solido ambiente di creazione di report.

Diversi strumenti ETL offrono funzionalità di derivazione end-to-end, quindi verificare se lo strumento ETL esistente ha tale funzionalità se si prevede di usarlo con Azure Synapse. Le pipeline di Azure Synapse o Data Factory supportano entrambi la possibilità di visualizzare la derivazione nei flussi di mapping. I partner di Microsoft forniscono anche strumenti automatizzati di individuazione dei metadati, derivazione dei dati e confronto della derivazione.

Eseguire la migrazione dei livelli semantici degli strumenti BI ad Azure Synapse Analytics

Alcuni strumenti di business intelligence hanno ciò che è noto come livello di metadati semantici. Tale livello semplifica l'accesso degli utenti aziendali alle strutture di dati fisiche sottostanti in un database del data warehouse o del data mart. Il livello di metadati semantici semplifica l'accesso fornendo oggetti di alto livello, ad esempio dimensioni, misure, gerarchie, metriche calcolate e join. Gli oggetti di alto livello usano termini aziendali familiari agli analisti aziendali ed eseguono il mapping alle strutture di dati fisiche nel data warehouse o nel data mart.

In una migrazione del data warehouse, è possibile che vengano forzate le modifiche ai nomi di colonna o ai nomi delle tabelle. Ad esempio, in Teradata i nomi delle tabelle possono avere un valore "#". In Azure Synapse, "#" è consentito solo come prefisso per un nome di tabella per indicare una tabella temporanea. In Teradata, le TABELLE TEMPORANEE non hanno necessariamente un "#" nel nome, ma devono averlo in Synapse. In questi casi potrebbe essere necessario eseguire alcune rielaborazioni per modificare i mapping delle tabelle.

Per ottenere coerenza tra più strumenti di business intelligence, creare un livello semantico universale usando un server di virtualizzazione dei dati che si trova tra gli strumenti e le applicazioni di business intelligence e Azure Synapse. Nel server di virtualizzazione dei dati usare nomi di dati comuni per oggetti di alto livello, ad esempio dimensioni, misure, gerarchie e join. In questo modo si configurano tutti gli elementi, inclusi campi calcolati, join e mapping, una sola volta anziché in ogni strumento. Quindi, puntare tutti gli strumenti di business intelligence nel server di virtualizzazione dei dati.

Con la virtualizzazione dei dati, si ottiene la coerenza tra tutti gli strumenti di business intelligence e si interrompe la dipendenza tra gli strumenti e le applicazioni di business intelligence e le strutture di dati fisici sottostanti in Azure Synapse. I partner di Microsoft consentono di ottenere coerenza in Azure. Il diagramma seguente illustra come un vocabolario comune nel server di virtualizzazione dei dati consenta a più strumenti di business intelligence di visualizzare un livello semantico comune.

Conclusioni

In una migrazione lift-and-shift del data warehouse, la maggior parte dei report, dei dashboard e di altre visualizzazioni dovrebbe essere migrata facilmente.

Durante una migrazione da un ambiente legacy, è possibile che i dati nelle tabelle del data warehouse o del data mart legacy vengano archiviati in tipi di dati non supportati. Oppure è possibile trovare viste legacy del data warehouse che includono SQL proprietario senza equivalenti in Azure Synapse. In questo caso, è necessario risolvere questi problemi per garantire una corretta migrazione ad Azure Synapse.

Non fare affidamento sulla documentazione gestita dall'utente per capire dove si trovano i problemi. Usare invece istruzioni EXPLAIN perché sono un modo rapido e pragmatico per identificare le incompatibilità SQL. Rielaborare le istruzioni SQL incompatibili per ottenere funzionalità equivalenti in Azure Synapse. Usare anche strumenti automatizzati di individuazione dei metadati e derivazione per comprendere le dipendenze, trovare report duplicati e identificare report non validi che si basano su origini dati obsolete, discutibili o inesistenti. Usare gli strumenti di derivazione per confrontare la derivazione e verificare che i report in esecuzione nell'ambiente del data warehouse legacy vengano prodotti in modo identico in Azure Synapse.

Non eseguire la migrazione dei report che non vengono più usati. I dati di utilizzo dello strumento di business intelligence consentono di determinare quali report non sono in uso. Per i report, i dashboard e altre visualizzazioni di cui si vuole eseguire la migrazione, eseguire la migrazione di tutti gli utenti, i gruppi utenti, i ruoli e i privilegi. Se si usa il valore aziendale per guidare la strategia di migrazione dei report, associare i report agli obiettivi aziendali strategici e alle priorità per identificare il contributo delle informazioni dettagliate dei report rispetto a obiettivi specifici. Se si esegue la migrazione del data mart in base al data mart, usare i metadati per identificare quali report dipendono da quali tabelle e viste, in modo da poter prendere una decisione informata sui data mart di cui eseguire prima la migrazione.

Le modifiche strutturali apportate al modello di dati del data warehouse o del data mart possono verificarsi durante una migrazione. Prendere in considerazione l'uso della virtualizzazione dei dati per proteggere gli strumenti e le applicazioni BI dalle modifiche strutturali. Con la virtualizzazione dei dati, è possibile usare un vocabolario comune per definire un livello semantico comune. Il livello semantico comune garantisce nomi di dati comuni coerenti, definizioni, metriche, gerarchie e join in tutti gli strumenti e le applicazioni BI nel nuovo ambiente Azure Synapse.

Passaggi successivi

Per altre informazioni sulla riduzione dei problemi di SQL, vedere l'articolo successivo di questa serie: Ridurre al minimo i problemi di SQL per le migrazioni di Teradata.