Visualizzazione e creazione di report per le migrazioni Oracle

Questo articolo è la quarta parte di una serie in sette parti che fornisce indicazioni su come eseguire la migrazione da Oracle ad Azure Synapse Analytics. L'obiettivo di questo articolo è le 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 a data warehouse e data mart usando una gamma di 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 di BI incorporati.

• Applicazioni operative che supportano la business intelligence su richiesta eseguendo 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 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 come nell'ambiente di data warehouse legacy.

Per ottenere risultati coerenti dopo la migrazione, tutti gli strumenti di business intelligence e le dipendenze dell'applicazione 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 l'accesso e la sicurezza. Quando si affrontano questioni di accesso e sicurezza, assicurarsi di eseguire la migrazione:

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

• Tutti gli utenti di Azure Synapse.

• Tutti i gruppi di 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. Per esempio:

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

L'accesso e la sicurezza sono considerazioni importanti per l'accesso ai dati nel sistema migrato e vengono illustrate in modo più dettagliato in Sicurezza, accesso e operazioni per le migrazioni Oracle.

Suggerimento

Per poter eseguire la migrazione dei report e delle visualizzazioni, è necessario eseguire la migrazione di utenti, gruppi di utenti, ruoli e assegnazioni dei privilegi di sicurezza di accesso.

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 si aspettano una migrazione senza problemi, senza sorprese che distruggono la fiducia nel sistema migrato in Azure Synapse. Fare attenzione ad attenuare qualsiasi timore che gli utenti potrebbero avere attraverso una buona comunicazione. Gli utenti si aspettano che:

• La struttura della tabella rimane invariata quando si fa riferimento direttamente alle query.

• I nomi di tabella e colonna rimangono invariati quando si fa riferimento direttamente alle query. Ad esempio, i campi calcolati definiti nelle colonne negli strumenti di business intelligence non devono avere esito negativo quando vengono generati report aggregati.

• L'analisi cronologica rimane invariata.

• Se possibile, i tipi di dati rimangono invariati.

• Il comportamento della query rimane invariato.

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

Suggerimento

La comunicazione e il coinvolgimento degli utenti aziendali sono fondamentali per il successo.

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

Suggerimento

È probabile che le viste e le query SQL che utilizzano estensioni di query SQL proprietarie generino incompatibilità che influenzano i report e i dashboard BI.

Altri problemi, ad esempio il comportamento dei valori o delle variazioni dei tipi di NULL dati tra le piattaforme DBMS, devono essere testati per garantire che anche le lievi differenze non esistano nei risultati del calcolo. Ridurre al minimo questi problemi ed eseguire tutti i passaggi necessari per impedire agli utenti aziendali di essere interessati da tali problemi. A seconda del tuo ambiente data warehouse legacy, gli strumenti di terze parti che possono aiutare a nascondere le differenze tra l'ambiente legacy e il nuovo ambiente, in modo che gli strumenti e le applicazioni di Business Intelligence vengano eseguiti senza modifiche.

Il test è fondamentale per la visualizzazione e la migrazione dei report. È necessario un gruppo di test e dati di test concordati per eseguire ed eseguire di nuovo 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 mantenerli impegnati e parte del progetto.

Suggerimento

Usare test ripetibili per garantire che i report, i dashboard e altre visualizzazioni vengano migrati correttamente.

Si potrebbe pensare di passare agli strumenti di BUSINESS Intelligence, ad esempio per eseguire la migrazione a Power BI. La tentazione è apportare tali modifiche contemporaneamente allo schema, ai dati, all'elaborazione ETL e altro ancora. Tuttavia, per ridurre al minimo i rischi, è preferibile eseguire prima la migrazione ad Azure Synapse e far funzionare tutto correttamente prima di intraprendere un'ulteriore 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 su entrambi gli ambienti. In alternativa, se il fornitore degli strumenti di Business Intelligence esistenti offre il loro prodotto su Azure, potete 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.

C'è molto da pensare qui, quindi diamo un'occhiata più da vicino.

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 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, eseguire questa operazione 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 dagli utenti.

La virtualizzazione dei dati interrompe la dipendenza tra gli utenti aziendali che usano gli strumenti di business intelligence self-service e lo schema fisico del data warehouse sottostante e dei data mart di cui viene eseguita la migrazione.

Suggerimento

La virtualizzazione dei dati consente di proteggere gli utenti aziendali dalle modifiche strutturali durante la migrazione, in modo che rimangano inconsapevoli di tali modifiche. Le modifiche strutturali includono modifiche dello schema che ottimizzano il modello di dati per Azure Synapse.

Con la virtualizzazione dei dati, qualsiasi modifica dello schema apportata durante una migrazione ad Azure Synapse, ad esempio per ottimizzare le prestazioni, può essere nascosta agli utenti aziendali perché ha accesso 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 rimangono inconsapevoli 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 è quali migrare per primi. Diversi fattori possono guidare tale decisione, ad esempio:

• Uso

• Valore aziendale

• Facilità di migrazione

• Strategia di migrazione dei dati

Le sezioni seguenti illustrano questi fattori.

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

• Eseguire facilmente la migrazione di report e dashboard,
• Eseguire la migrazione di report e dashboard con un impegno minimo e
• Indirizzare gli strumenti BI verso Azure Synapse invece del sistema di data warehouse legacy e ottenere i report, dashboard e altre visualizzazioni equivalenti.

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 valore corrente. Se non si ha un modo per scoprire quali report e dashboard non sono usati, è possibile usare uno dei diversi strumenti di business intelligence che forniscono statistiche di utilizzo.

Se il data warehouse legacy è in esecuzione da anni, esiste una buona probabilità di avere centinaia, se non migliaia, di report esistenti. Vale la pena compilare un inventario di report e dashboard e identificarne lo scopo aziendale e le statistiche di utilizzo.

Per i report inutilizzati, determinare se dismetterli per ridurre lo sforzo di migrazione. Una domanda chiave quando si decide se rimuovere un report inutilizzato è se il report non è usato perché gli utenti non lo conoscono, 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 sull'entità della 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 dall'esecutivo definisce in genere obiettivi aziendali strategici (SBO), indicatori di prestazioni chiave (KPI), obiettivi KPI che devono essere raggiunti e chi è responsabile del loro raggiungimento. È possibile classificare un report in base agli SBO a cui contribuisce, come la riduzione delle frodi, il miglioramento dell'engagement dei clienti e l'ottimizzazione delle operazioni aziendali. È 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 a quale livello aziendale vengono usati. Gli SBO richiedono 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 degli obiettivi della strategia aziendale seguente per valutare report e dashboard.

Livello	Nome del report/dashboard	Scopo aziendale	Reparto usato	Frequenza di utilizzo	Priorità aziendale
Strategico
Tattico
Operativo

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 per facilitare 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 al 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 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 data mart forniscono i dati per i report.

Suggerimento

La strategia di migrazione dei dati influisce su quali report e visualizzazioni vengono migrati per primi.

Problemi tecnici di incompatibilità durante la migrazione che possono influire su report e visualizzazioni dei dati

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. Questi 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 data warehouse o data mart che forniscono dati per report, dashboard e altre visualizzazioni possono essere:

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

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

Nella maggior parte dei casi, esiste una soluzione alternativa alle incompatibilità. Ad esempio, è possibile eseguire la migrazione dei dati in un tipo di tabella non supportato in 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.

Suggerimento

Le incompatibilità dello schema includono i tipi di tabella DBMS del warehouse legacy e i tipi di dati non supportati in Azure Synapse.

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 utilizzare 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 oggetti di database Oracle non supportati.

Suggerimento

Eseguire una query sul catalogo di sistema del DBMS del warehouse legacy per individuare le incompatibilità dello schema con Azure Synapse.

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

Incompatibilità SQL

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

• Accede alle viste DBMS legacy del data warehouse 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 report

Il portfolio 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à di SQL sulla migrazione del portfolio di report ad Azure Synapse. È necessario usare un modo più preciso per valutare l'effetto delle incompatibilità SQL.

Usare istruzioni EXPLAIN per trovare incompatibilità SQL

È possibile trovare incompatibilità SQL esaminando i log delle attività SQL recenti nel data warehouse Oracle 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 EXPLAIN istruzioni in Azure Synapse. Tutte le istruzioni SQL contenenti estensioni SQL proprietarie non supportate verranno rifiutate da Azure Synapse quando vengono eseguite le EXPLAIN istruzioni. Questo approccio consente di valutare l'entità delle incompatibilità SQL.

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

Suggerimento

Misurare l'impatto delle incompatibilità SQL raccogliendo i file di log del DBMS ed eseguendo le istruzioni EXPLAIN.

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 abbia funzionato. 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 data warehouse esistenti ed migrati con:

• Identificare se le modifiche apportate allo schema durante la migrazione influiscono sulla possibilità di eseguire i report, i risultati del report 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 dell'accesso ai dati per garantire la migrazione dell'elenco di controllo di accesso .Verify that all data access security privileges are migrated to ensure access control list (ACL) migration.

• 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.

Suggerimento

Testare e ottimizzare le prestazioni per ridurre al minimo i costi di calcolo.

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

Automatizzare i test il più possibile per rendere ripetibili ogni test e supportare un approccio coerente alla valutazione dei risultati dei test. L'automazione funziona bene per i report regolari 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.

Suggerimento

La procedura consigliata consiste nel creare un gruppo di test automatizzato per rendere ripetibili i test.

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 da prima e dopo la 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 da altri mezzi è difficile.

Suggerimento

Sfruttare gli strumenti che confrontano la derivazione dei metadati per verificare i risultati.

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 viaggio dei dati migrati, in modo da poterne tenere traccia a partire da un report o un dashboard fino alla fonte dei dati. La linea di derivazione mostra come i dati siano stati trasferiti da un punto all'altro, la loro posizione nel data warehouse e/o nel data mart, e quali report e dashboard li utilizzano. La tracciabilità può aiutare a comprendere cosa accade ai dati mentre attraversano diversi archivi di dati, come file e database, diverse pipeline ETL, e nei report. Quando gli utenti aziendali hanno accesso alla derivazione dei dati, migliora la fiducia, infonde fiducia e supporta decisioni aziendali informate.

Suggerimento

La possibilità di accedere ai metadati e alla provenienza dei dati dai report fino alla fonte dati è fondamentale per verificare che i report migrati funzionino correttamente.

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

Suggerimento

Gli strumenti che automatizzano la raccolta di metadati e mostrano la derivazione end-to-end in un ambiente multi-fornitore sono utili durante una migrazione.

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 a quella di 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 metadati da diversi strumenti. Avere 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 l'esito positivo della migrazione.

La visualizzazione 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 migrati 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 cosa deve essere migrato in Azure Synapse per ottenere un ambiente di creazione di report solido.

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 Microsoft forniscono anche strumenti automatizzati di individuazione dei metadati, derivazione dei dati e confronto di derivazione.

Migrare i livelli semantici di uno strumento di 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 data warehouse o in un database 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.

Suggerimento

Alcuni strumenti di business intelligence hanno livelli semantici che semplificano l'accesso degli utenti aziendali alle strutture di dati fisiche nel data warehouse o nel data mart.

In una migrazione del data warehouse potrebbe essere necessario modificare i nomi delle colonne o delle tabelle. Ad esempio, Oracle consente un # carattere nei nomi di tabella, ma Azure Synapse consente # solo come prefisso del nome di tabella di indicare una tabella temporanea. In Oracle, LE TABELLE TEMPORANEE non hanno necessariamente un "#" nel nome, ma in Synapse devono. 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 strumenti di business intelligence e applicazioni 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 BI al server di virtualizzazione dei dati.

Suggerimento

Usare la virtualizzazione dei dati per creare un livello semantico comune per garantire la coerenza tra tutti gli strumenti di business intelligence in un ambiente Azure Synapse.

Con la virtualizzazione dei dati, si ottiene la coerenza tra tutti gli strumenti di business intelligence e si interrompe la dipendenza tra gli strumenti di business intelligence e le applicazioni e le strutture di dati fisici sottostanti in Azure Synapse. I partner 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 migrare facilmente.

Durante una migrazione da un ambiente legacy, è possibile che i dati nelle tabelle data warehouse o data mart legacy vengano archiviati in tipi di dati non supportati. In alternativa, è 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 identificare dove si trovano i problemi. Invece, usa le 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 e derivazione dei metadati 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 per verificare che i report in esecuzione nell'ambiente 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 di 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 a obiettivi specifici. Se si esegue la migrazione del data mart per data mart, usare i metadati per identificare quali report dipendono da quali tabelle e viste, in modo da poter prendere una decisione informata su quale data mart migrare per primo.

Suggerimento

Identificare in anticipo le incompatibilità per misurare l'entità del lavoro di migrazione. Eseguire la migrazione di utenti, ruoli di gruppo e assegnazioni di privilegi. Eseguire la migrazione solo dei report e delle visualizzazioni usati e che contribuiscono al valore aziendale.

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 di BUSINESS Intelligence 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 coerenti, definizioni, metriche, gerarchie e join comuni in tutti gli strumenti e le applicazioni BI nel nuovo ambiente Azure Synapse.

Passaggi successivi

Per altre informazioni su come ridurre al minimo i problemi di SQL, vedere l'articolo successivo di questa serie: Riduzione al minimo dei problemi di SQL per le migrazioni Oracle.