Visualisierung und Berichterstellung für Oracle-Migrationen

Dieser Artikel ist Teil vier einer siebenteiligen Reihe, die Anleitungen zur Migration von Oracle zu Azure Synapse Analytics enthält. In diesem Artikel werden schwerpunktmäßig bewährte Methoden für die Visualisierung und Berichterstellung behandelt.

Zugreifen auf Azure Synapse Analytics mit BI-Tools von Microsoft und Drittanbietern

Organisationen greifen mit einer Reihe von Business Intelligence-Tools und -Anwendungen auf Data Warehouses und Data Marts zu. Einige Beispiele für BI-Produkte:

• Microsoft BI-Tools wie Power BI

• Office-Anwendungen wie Microsoft Excel-Arbeitsblätter

• BI-Tools von verschiedenen Drittanbietern

• Benutzerdefinierte Analyseanwendungen mit eingebetteter BI-Funktionalität

• Operative Anwendungen, die bedarfsabhängige Business Intelligence (BI) unterstützen und Abfragen und Berichte auf einer BI-Plattform ausführen, wodurch wiederum Daten in einem Data Warehouse oder Data Mart abgefragt werden

• Interaktive Data Science-Entwicklungstools wie Azure Synapse-Spark-Notebooks, Azure Machine Learning, RStudio und Jupyter Notebook-Instanzen.

Wenn Sie im Rahmen der Migration Ihres Data Warehouse auch Visualisierungen und die Berichterstellung migrieren, müssen alle vorhandenen, von BI-Produkten generierten Abfragen, Berichte und Dashboards in der neuen Umgebung ausgeführt werden. Ihre BI-Produkte müssen in Azure Synapse dieselben Ergebnisse wie in Ihrer bisherigen Data Warehouse-Umgebung erzielen.

Um auch nach der Migration von Data Warehouse-Schemas und Daten zu Azure Synapse konsistente Ergebnisse zu erzielen, müssen alle BI-Tools und Anwendungsabhängigkeiten in der neuen Umgebung funktionieren. Zu den Abhängigkeiten zählen auch weniger offensichtliche Aspekte wie Zugriff und Sicherheit. Stellen Sie in Hinblick auf Zugriff und Sicherheit auch die Migration folgender Elemente sicher:

• Authentifizierung, damit Benutzer sich bei den Data Warehouse- und Data Mart-Datenbanken in Azure Synapse anmelden können

• Alle Benutzer zu Azure Synapse

• Alle Benutzergruppen zu Azure Synapse

• Alle Rollen zu Azure Synapse

• Alle Autorisierungsberechtigungen für die Zugriffssteuerung zu Azure Synapse

• Benutzer-, Rollen- und Berechtigungszuweisungen, um die Zuweisungen im vorhandenen Data Warehouse vor der Migration widerzuspiegeln Beispiel:

  • Berechtigungen für Datenbankobjekte, die Rollen zugewiesen sind
  • Rollen, die Benutzergruppen zugewiesen sind
  • Benutzer, die Benutzergruppen und/oder Rollen zugewiesen sind

Zugriff und Sicherheit sind wichtige Aspekte für den Datenzugriff im migrierten System. Sie werden ausführlicher unter Sicherheit, Zugriff und Vorgänge für Oracle-Migrationen erläutert.

Tipp

Damit eine erfolgreiche Migration von Berichten und Visualisierungen möglich ist, müssen zuerst vorhandene Benutzer, Benutzergruppen, Rollen und Zuweisungen von Sicherheitsberechtigungen für den Zugriff migriert werden.

Migrieren Sie alle erforderlichen Daten, um sicherzustellen, dass die Berichte und Dashboards, die Daten in der Legacyumgebung abfragen, dieselben Ergebnisse auch in Azure Synapse erzeugen.

Geschäftsbenutzer erwarten eine nahtlose Migration ohne Überraschungen, die ihr Vertrauen in das zu Azure Synapse migrierte System zerstören könnten. Gehen Sie durch eine gute Kommunikation auf mögliche Befürchtungen Ihrer Benutzer ein. Ihre Benutzer erwarten Folgendes:

• Die Tabellenstruktur bleibt unverändert, wenn in Abfragen direkt auf sie verwiesen wird.

• Tabellen- und Spaltennamen bleiben unverändert, wenn in Abfragen direkt auf sie verwiesen wird. Beispielsweise sollten bei berechneten Feldern, die in BI-Tools in Spalten definiert sind, beim Erstellen von aggregierten Berichten keine Fehler auftreten.

• Historische Analysen bleiben unverändert.

• Datentypen bleiben, sofern möglich, unverändert.

• Das Abfrageverhalten bleibt unverändert.

• ODBC/JDBC-Treiber werden getestet, um sicherzustellen, dass das Abfrageverhalten unverändert bleibt.

Tipp

Die Kommunikation mit den Geschäftsbenutzern und deren Beteiligung sind für den Erfolg entscheidend.

Funktionieren Sichten, die von BI-Tools in der zugrunde liegenden Data Warehouse- oder Data Mart-Datenbank abgefragt werden, auch noch nach der Migration? Einige Sichten funktionieren möglicherweise nicht, wenn proprietäre SQL-Erweiterungen speziell für das DBMS Ihres Legacy-Data Warehouse vorhanden sind, für die es in Azure Synapse keine Entsprechung gibt. In diesem Fall müssen Sie diese Unvereinbarkeiten kennen und eine Lösungsmöglichkeit finden.

Tipp

Ansichten und SQL-Abfragen mit proprietären SQL-Abfrageerweiterungen führen wahrscheinlich zu Inkompatibilitäten, die sich auf BI-Berichte und -Dashboards auswirken.

Bei anderen Problemen (z. B. Verhalten von NULL-Werten oder Datentypvariationen auf DBMS-Plattformen) muss anhand von Tests sichergestellt werden, dass in den Berechnungsergebnissen auch keine noch so geringfügigen Unterschiede auftreten. Beschränken Sie diese Probleme auf ein Minimum, und führen Sie alle erforderlichen Schritte aus, damit Geschäftsbenutzer nicht davon betroffen sind. Abhängig von Ihrer Data Warehouse-Legacyumgebung können Drittanbietertools beim Verbergen der Unterschiede zwischen der Legacy- und der neuen Umgebung helfen, sodass BI-Tools und -Anwendungen unverändert ausgeführt werden.

Tests sind für die Migration von Visualisierungen und Berichten wichtig. Sie benötigen eine Testsammlung sowie vereinbarte Testdaten für die Ausführung und erneute Ausführung von Tests in beiden Umgebungen. Eine Testumgebung ist ebenfalls nützlich (einige Beispiele dafür finden Sie in diesem Leitfaden). Im Rahmen der Tests der Migration ist es auch wichtig, Geschäftsbenutzer einzubeziehen, um deren Vertrauen in das Projekt sowie Engagement und Teilhabe zu fördern.

Tipp

Verwenden Sie wiederholbare Tests, um sicherzustellen, dass Berichte, Dashboards und andere Visualisierungen erfolgreich migriert werden.

Möglicherweise denken Sie über einen Austausch der BI-Tools nach (z. B. über eine Migration zu Power BI). Dabei könnten Sie in Versuchung geraten, während der Migration Ihres Schemas, der Daten, der ETL-Verarbeitung (Extrahieren, Transformieren und Laden) auch derartige Veränderungen vorzunehmen. Wenn Sie das Risiko minimieren möchten, empfiehlt es sich jedoch, zuerst zu Azure Synapse zu migrieren und die einwandfreie Funktion aller notwendigen Komponenten sicherzustellen, bevor sie weitere Modernisierungsmaßnahmen durchführen.

Wenn Ihre vorhandenen BI-Tools lokal ausgeführt werden, stellen Sie sicher, dass sie über Ihre Firewall eine Verbindung mit Azure Synapse herstellen können, damit Sie Vergleiche der beiden Umgebungen anstellen können. Falls der Anbieter Ihrer vorhandenen BI-Tools sein Produkt in Azure anbietet, können Sie die Tools alternativ im Azure-Portal ausprobieren. Das Gleiche gilt für lokal ausgeführte Anwendungen mit eingebetteter BI oder Anwendungen, die bei Bedarf Ihren BI-Server aufrufen, um z. B. einen „Headless-Bericht“ mit XML- oder JSON-Daten anzufordern.

Hier sind viele Überlegungen erforderlich, die im Folgenden genauer betrachtet werden.

Nutzung der Datenvirtualisierung zum Minimieren der Auswirkungen der Migration auf BI-Tools und Berichte

Während der Migration könnten Sie in Versuchung geraten, langfristige Anforderungen (z. B. geschäftliche Anfragen öffnen, fehlende Daten hinzufügen, neue Features implementieren usw.) zu erfüllen. Solche Änderungen können jedoch den Zugriff von BI-Tools auf Ihr Data Warehouse beeinträchtigen, insbesondere wenn es um strukturelle Änderungen an Ihrem Datenmodell geht. Wenn Sie eine flexible Datenmodellierungsmethode einführen oder strukturelle Änderungen implementieren möchten, sollten Sie dies erst nach der Migration tun.

Eine Möglichkeit zum Minimieren der Auswirkungen von Schemaänderungen oder anderen strukturellen Änderungen auf Ihre BI-Tools ist die Einführung der Datenvirtualisierung zwischen BI-Tools und Data Warehouse und Data Marts. Das folgende Diagramm zeigt, wie eine Migration mithilfe der Datenvirtualisierung vor Benutzern verborgen werden kann.

Durch die Virtualisierung der Daten wird die Abhängigkeit zwischen Geschäftsbenutzern, die Self-Service-BI-Tools nutzen, und dem physischen Schema des zugrunde liegenden Data Warehouse bzw. der Data Marts, die migriert werden, aufgehoben.

Tipp

Die Datenvirtualisierung ermöglicht Ihnen, Geschäftsbenutzer während der Migration vor strukturellen Änderungen abzuschirmen, sodass diese für sie nicht spürbar sind. Strukturelle Änderungen beinhalten Schemaänderungen, die Ihr Datenmodell für Azure Synapse optimieren.

Mit der Datenvirtualisierung können sämtliche Schemaänderungen, die während eine Migration zu Azure Synapse vorgenommen werden (z. B. Leistungsverbesserungen), vor den Geschäftsbenutzern verborgen werden, da diese nur auf virtuelle Tabellen auf der Datenvirtualisierungsebene zugreifen. Wenn Sie strukturelle Änderungen vornehmen, brauchen Sie nur die Zuordnungen zwischen Data Warehouse bzw. Data Marts und allen virtuellen Tabellen zu aktualisieren. Durch die Datenvirtualisierung merken die Benutzer nichts von den strukturellen Änderungen. Microsoft-Partner bieten Software für die Datenvirtualisierung an.

Identifizieren von Berichten mit hoher Priorität, die zuerst migriert werden sollen

Welche Ihrer vorhandenen Berichte und Dashboards als Erstes migriert werden sollen, ist eine wichtige Frage bei der Migration zu Azure Synapse. Bei dieser Entscheidung spielen u. U. mehrere Faktoren eine Rolle:

• Verwendung

• Geschäftswert

• Einfache Migration

• Datenmigrationsstrategie

Diese Faktoren werden in den folgenden Abschnitten erläutert.

Unabhängig von Ihrer Entscheidung müssen Sie Ihre Geschäftsbenutzer einbeziehen, da diese die Berichte, Dashboards und andere Visualisierungen erstellen und Geschäftsentscheidungen anhand von daraus gewonnenen Erkenntnissen treffen. Alle profitieren von folgenden Möglichkeiten:

• Nahtloses Migrieren von Berichten und Dashboards
• Migrieren von Berichten und Dashboards mit minimalem Aufwand
• Ausrichten der BI-Tools auf Azure Synapse statt auf Ihr Data Warehouse-Legacysystem und Abrufen von vergleichbaren Berichten, Dashboards und anderen Visualisierungen

Migrieren von Berichten basierend auf der Verwendung

Die Verwendung ist häufig ein Indikator für den Geschäftswert. Nicht verwendete Berichte und Dashboards tragen eindeutig nicht zu Geschäftsentscheidungen bei bzw. haben keinen aktuellen Wert. Wenn Sie keine Möglichkeit haben, herauszufinden, welche Berichte und Dashboards nicht verwendet werden, können Sie eines der verschiedenen BI-Tools verwenden, die Nutzungsstatistiken bereitstellen.

Wenn Ihr Legacy-Data Warehouse seit vielen Jahren in Betrieb ist, ist die Wahrscheinlichkeit groß, dass Hunderte, wenn nicht Tausende von Berichten vorhanden sind. Es lohnt sich, ein Inventar der Berichte und Dashboards zu zusammenzustellen, ihren geschäftlichen Zweck zu identifizieren und Nutzungsstatistiken auszuwerten.

Ermitteln Sie bei nicht verwendeten Berichten, ob sie ausgemustert werden können, um den Migrationsaufwand zu verringern. Die folgende Frage ist wichtig bei der Entscheidung, ob ein nicht verwendeter Bericht ausgemustert werden soll: Wird der Bericht nicht verwendet wird, weil ihn die Mitarbeitenden nicht kennen, weil er keinen Geschäftswert bietet, oder weil er durch einen anderen Bericht ersetzt wurde?

Migrieren von Berichten basierend auf dem Geschäftswert

Die Verwendung allein ist nicht immer ein guter Indikator für den Geschäftswert. Sie sollten auch berücksichtigen, in welchem Umfang die Erkenntnisse aus einem Bericht zum Geschäftswert beitragen. Eine Möglichkeit dazu besteht darin, die Rentabilität jeder Geschäftsentscheidung, die sich auf den Bericht stützt, und das Ausmaß der Abhängigkeit zu bewerten. Diese Informationen sind jedoch in den meisten Organisationen nicht so ohne weiteres verfügbar.

Eine weitere Möglichkeit zum Bewerten des Geschäftswerts besteht darin, die Ausrichtung eines Berichts auf die Geschäftsstrategie zu betrachten. Eine von Führungskräften festgelegte Geschäftsstrategie definiert in der Regel strategische Geschäftsziele, Key Performance Indicators (KPIs), die zu erreichenden KPI-Ziele und die dafür zuständigen Personen. Sie können einen Bericht anhand seines Beitrags zu den strategischen Geschäftszielen klassifizieren, z. B. Betrugsreduzierung, verbesserte Kundenbindung und optimierte Geschäftsabläufe. Anschließend können Sie die Migration der Berichte und Dashboards priorisieren, die mit Zielen hoher Priorität verknüpft sind. Auf diese Weise kann eine frühe Migration für einen Geschäftswert in einem strategischen Bereich sorgen.

Eine weitere Möglichkeit zum Bewerten des Geschäftswerts besteht darin, Berichte und Dashboards als operativ, taktisch oder strategisch zu klassifizieren und zu ermitteln, auf welcher Geschäftsebene sie verwendet werden. Strategische Geschäftsziele setzen eine Beteiligung all dieser Ebenen voraus. Zu wissen, welche Berichte und Dashboards auf welcher Ebene verwendet werden und mit welchen Zielen sie verknüpft sind, hilft Ihnen, sich bei der Migration auf Geschäftswerte mit hoher Priorität zu konzentrieren. Sie können die folgende Tabelle Unternehmensstrategieziel verwenden, um Berichte und Dashboards zu bewerten.

Ebene	Berichts-/Dashboardname	Geschäftlicher Zweck	Abteilung	Häufigkeit der Verwendung	Geschäftliche Priorität
Strategisch
Taktisch
Bei Betrieb

Metadatenermittlungstools wie Azure Data Catalog bieten Benutzern die Möglichkeit zum Markieren und Bewerten von Datenquellen, um die Metadaten für diese Datenquellen anzureichern und deren Ermittlung und Klassifizierung zu unterstützen. Mithilfe der Metadaten für einen Bericht oder ein Dashboard können Sie deren Geschäftswert besser verstehen. Ohne solche Tools kann es eine zeitintensive Aufgabe sein, den Anteil von Berichten und Dashboards am Geschäftswert zu verstehen, und zwar unabhängig von einer Migration.

Migrieren von Berichten basierend auf der Datenmigrationsstrategie

Wenn Ihre Migrationsstrategie darauf beruht, zuerst die Data Marts zu migrieren, hat die Migrationsreihenfolge Einfluss darauf, welche Berichte und Dashboards zuerst migriert werden. Wenn Ihre Strategie auf dem Geschäftswert beruht, entspricht die Reihenfolge der Migration der Data Marts zu Azure Synapse den geschäftlichen Prioritäten. Metadatenermittlungstools können Ihnen bei der Implementierung Ihrer Strategie helfen, indem sie zeigen, welche Data Mart-Tabellen Daten für welche Berichte bereitstellen.

Tipp

Durch Ihre Datenmigrationsstrategie wird beeinflusst, welche Berichte und Visualisierungen zuerst migriert werden.

Inkompatibilitätsprobleme bei der Migration, die sich auf Berichte und Visualisierungen auswirken können

BI-Tools erstellen Berichte, Dashboards und andere Visualisierungen, indem sie mithilfe von SQL-Abfragen auf physische Tabellen und/oder Sichten in Ihrem Data Warehouse oder Data Mart zugreifen. Wenn Sie Ihr Legacy-Data Warehouse zu Azure Synapse migrieren, können mehrere Faktoren eine einfache Migration von Berichten, Dashboards und anderen Visualisierungen beeinträchtigen. Dazu zählen folgende Faktoren:

• Schemainkompatibilitäten zwischen den Umgebungen

• SQL-Inkompatibilitäten zwischen den Umgebungen

Schemainkompatibilitäten

Bei einer Migration können folgende Schemainkompatibilitäten in den Data Warehouse- oder Data Mart-Tabellen, die Daten für Berichte, Dashboards und andere Visualisierungen bereitstellen, auftreten:

• Nicht standardmäßige Tabellentypen im Datenbankverwaltungssystem (DBMS) Ihres Legacy-Data Warehouse, für die es keine Entsprechung in Azure Synapse gibt

• Datentypen im Datenbankverwaltungssystem (DBMS) Ihres Legacy-Data Warehouse, für die es keine Entsprechung in Azure Synapse gibt

In den meisten Fällen gibt es eine Problemumgehung für die Inkompatibilitäten. Die Daten in einem nicht unterstützten Tabellentyp können z. B. in eine Standardtabelle mit entsprechenden Datentypen migriert und nach einer Datums-/Uhrzeitspalte indiziert oder partitioniert werden. Ebenso ist es möglich, nicht unterstützte Datentypen in einem anderen Spaltentyp darzustellen und Berechnungen in Azure Synapse auszuführen, um dieselben Ergebnisse zu erzielen.

Tipp

Zu Schemainkompatibilitäten zählen Tabellen- und Datentypen im Legacy-Data Warehouse-DBMS, die in Azure Synapse nicht unterstützt werden.

Führen Sie zum Identifizieren der Berichte, die von Schemainkompatibilitäten betroffen sind, Abfragen des Systemkatalogs Ihres Legacy-Data Warehouse aus, um Tabellen mit nicht unterstützten Datentypen zu ermitteln. Anschließend können Sie mithilfe von Metadaten aus Ihrem BI-Tool die Berichte identifizieren, die auf Daten in diesen Tabellen zugreifen. Weitere Informationen zum Identifizieren von Objekttyp-Inkompatibilitäten finden Sie unter Nicht unterstützte Oracle-Datenbankobjekttypen.

Tipp

Fragen Sie den Systemkatalog des Datenbankverwaltungssystems (DBMS) Ihres Legacy-Data Warehouse ab, um Schemainkompatibilitäten mit Azure Synapse zu ermitteln.

Die Auswirkungen von Schemainkompatibilitäten auf Berichte, Dashboards und andere Visualisierungen sind möglicherweise geringer als gedacht, da viele BI-Tools die weniger generischen Datentypen nicht unterstützen. Daher sind in Ihrem Legacy-Data Warehouse wahrscheinlich bereits Sichten vorhanden, die nicht unterstützte Datentypen mit CAST in generischere Typen umwandeln.

SQL-Inkompatibilitäten

Bei einer Migration wirken sich SQL-Inkompatibilitäten wahrscheinlich auf alle Berichte, Dashboards oder andere Visualisierungen in einer Anwendung oder einem Tool aus, die bzw. das:

• Auf Ansichten des Legacy-Data Warehouse-DBMS zugreift, die proprietäre SQL-Funktionen ohne Äquivalent in Azure Synapse enthalten

• SQL-Abfragen sendet, die spezielle proprietäre SQL-Funktionen des SQL-Dialekts Ihrer Legacyumgebung enthalten, die in Azure Synapse keine Entsprechung haben.

Beurteilen der Auswirkungen von SQL-Inkompatibilitäten auf Ihr Berichtsportfolio

Ihr Berichtsportfolio kann eingebettete Abfragedienste, Berichte, Dashboards und andere Visualisierungen enthalten. Verlassen Sie sich nicht auf die diesen Elementen zugeordnete Dokumentation, um die Auswirkungen von SQL-Inkompatibilitäten auf die Migration Ihres Berichtsportfolios zu Azure Synapse zu bewerten. Sie müssen eine präzisere Methode verwenden, um den Effekt von SQL-Inkompatibilitäten zu bewerten.

Verwenden von EXPLAIN-Anweisungen zum Ermitteln von SQL-Inkompatibilitäten

Sie können SQL-Inkompatibilitäten finden, indem Sie die Protokolle der letzten SQL-Aktivität in Ihrem alten Oracle Data Warehouse überprüfen. Verwenden Sie ein Skript, um einen repräsentativen Satz von SQL-Anweisungen in eine Datei zu extrahieren. Stellen Sie dann jeder SQL-Anweisung eine EXPLAIN-Anweisung als Präfix voran, und führen Sie anschließend diese EXPLAIN-Anweisungen in Azure Synapse aus. SQL-Anweisungen, die nicht unterstützte proprietäre SQL-Erweiterungen enthalten, werden bei der Ausführung der EXPLAIN-Anweisungen von Azure Synapse abgelehnt. Dieser Ansatz hilft Ihnen, den Umfang der SQL-Inkompatibilitäten zu bewerten.

Metadaten aus dem DBMS Ihres Legacy-Data Warehouse sind ebenfalls hilfreich, um inkompatible Sichten zu ermitteln. Erfassen Sie wie zuvor einen repräsentativen Satz von SQL-Anweisungen aus den entsprechenden Protokollen, stellen Sie jeder SQL-Anweisung eine EXPLAIN-Anweisung als Präfix voran, und führen Sie diese EXPLAIN-Anweisungen in Azure Synapse aus, um Sichten mit inkompatiblem SQL zu identifizieren.

Tipp

Beurteilen Sie die Auswirkungen von SQL-Inkompatibilitäten, indem Sie Ihre DBMS-Protokolldateien sammeln und EXPLAIN-Anweisungen ausführen.

Testen der Bericht- und Dashboardmigration zu Azure Synapse Analytics

Ein wichtiges Element der Data Warehouse-Migration ist das Testen von Berichten und Dashboards in Azure Synapse, um zu überprüfen, ob die Migration erfolgreich war. Definieren Sie eine Reihe von Tests sowie die erforderlichen Ergebnisse für jeden Test, den Sie zum Überprüfen der erfolgreichen Migration ausführen. Testen Sie die Berichte und Dashboards, und vergleichen Sie sie im vorhandenen und migrierten Data Warehouse-System auf folgende Punkte:

• Identifizieren Sie, ob während der Migration vorgenommene Schemaänderungen die Ausführung von Berichten, die Berichtsergebnisse oder die entsprechenden Berichtsvisualisierungen beeinträchtigt haben. Ein Beispiel für eine Schemaänderung ist die Zuordnung eines inkompatiblen Datentyps zu einem gleichwertigen Datentyp, der in Azure Synapse unterstützt wird.

• Überprüfen Sie, ob alle Benutzer migriert wurden.

• Überprüfen Sie, ob alle Rollen migriert und Benutzer diesen Rollen zugewiesen wurden.

• Überprüfen Sie, ob alle Sicherheitsberechtigungen für den Datenzugriff migriert wurden, um die Migration der Zugriffssteuerungsliste (Access Control List, ACL) sicherzustellen.

• Stellen Sie konsistente Ergebnisse aller bekannten Abfragen, Berichte und Dashboards sicher.

• Sicherstellen der vollständigen und fehlerfreien Daten- und ETL-Migration

• Stellen Sie die Einhaltung des Datenschutzes sicher.

• Testen der Leistung und Skalierbarkeit

• Testen der Analysefunktionen

Tipp

Testen und optimieren Sie die Leistung, um die Computekosten zu minimieren.

Informationen zum Migrieren von Benutzern, Benutzergruppen, Rollen und Berechtigungen finden Sie unter Sicherheit, Zugriff und Vorgänge für Oracle-Migrationen.

Automatisieren Sie die Tests so umfassend wie möglich, damit jeder Test reproduzierbar ist und Sie über einen konsistenten Ansatz zur Bewertung der Testergebnisse verfügen. Die Automatisierung funktioniert gut bei bekannten regulären Berichten und kann über Azure Synapse-Pipelines oder die Azure Data Factory-Orchestrierung verwaltet werden. Wenn Sie bereits über eine Sammlung von Testabfragen für Regressionstests verfügen, können Sie die Tests nach der Migration mithilfe der vorhandenen Testtools automatisieren.

Tipp

Eine bewährte Methode ist, eine Sammlung automatischer Tests zu erstellen, um die Tests reproduzierbar zu machen.

Ad-hoc-Analysen und -Berichte sind schwieriger und erfordern die Kompilierung einer Reihe von Tests, um zu überprüfen, ob dieselben Berichte und Dashboards vor und nach der Migration konsistent sind. Wenn Sie Inkonsistenzen feststellen, ist es von entscheidender Bedeutung, dass Sie während der Migrationstests die Herkunft der Metadaten zwischen dem ursprünglichen und dem migrierten System vergleichen können. Durch diesen Vergleich können Unterschiede hervorgehoben und die Ursachen für Inkonsistenzen ermittelt werden, die mit anderen Mitteln nur schwer festzustellen sind.

Tipp

Nutzen Sie Tools, die zum Überprüfen der Ergebnisse die Metadatenherkunft vergleichen können.

Analysieren der Datenherkunft zum Verstehen der Abhängigkeiten zwischen Berichten, Dashboards und Daten

Die Datenherkunft zu kennen, ist ein wichtiger Faktor bei der erfolgreichen Migration von Berichten und Dashboards. Unter Datenherkunft versteht man die Metadaten, die den Weg migrierter Daten anzeigen, sodass Sie den Pfad von einem Bericht oder Dashboard bis zurück zur Datenquelle nachverfolgen können. Die Herkunft zeigt den Weg der Daten von Punkt zu Punkt, den Speicherort der Daten im Data Warehouse und/oder Data Mart sowie die Berichte und Dashboards, die diese Daten verwenden. Mithilfe der Datenherkunft können Sie besser verstehen, was mit den Daten auf ihrem Weg durch verschiedene Datenspeicher (z. B. Dateien und Datenbanken) und unterschiedliche ETL-Pipelines in die Berichte geschieht. Wenn Geschäftsbenutzer Zugriff auf die Datenherkunft haben, schafft dies Vertrauen und unterstützt fundierte geschäftliche Entscheidungen.

Tipp

Die Möglichkeit, auf Metadaten und die Datenherkunft von Berichten bis zurück zur Datenquelle zugreifen zu können, ist für die Überprüfung der ordnungsgemäßen Funktion migrierter Berichte äußerst wichtig.

In Data Warehouse-Umgebungen mit mehreren Anbietern arbeiten möglicherweise Unternehmensanalysten in BI-Teams die Datenherkunft aus. Wenn Sie z. B. verschiedene Anbieter für ETL, Data Warehouse und Berichterstellung verwenden und jeder Anbieter über ein eigenes Metadatenrepository verfügt, kann es schwierig und zeitintensiv sein, die Herkunft eines bestimmten Datenelements in einem Bericht zu ermitteln.

Tipp

Tools für die Automatisierung der Metadatensammlung und die komplette Nachverfolgung der Datenherkunft in einer Umgebung mit mehreren Anbietern sind bei einer Migration von großem Wert.

Die komplette Nachverfolgung der Datenherkunft unterstützt die nahtlose Migration eines Legacy-Data Warehouse zu Azure Synapse, da sie beim Vergleichen von Berichten und Dashboards in den jeweiligen Umgebungen den Nachweis einer Migration in eine gleichwertige Umgebung ermöglicht. Um den kompletten Weg der Daten anzuzeigen, müssen Sie Metadaten aus mehreren Tools erfassen und integrieren. Wenn Sie Zugriff auf Tools haben, die eine automatische Ermittlung von Metadaten und Datenherkunft unterstützen, können Sie viel einfacher doppelte Berichte und ETL-Prozesse identifizieren und nach Berichten suchen, die auf veralteten, fragwürdigen oder nicht vorhandenen Datenquellen basieren. Mithilfe dieser Informationen können Sie die Anzahl von zu migrierenden Berichten und ETL-Prozessen reduzieren.

Sie können auch die komplette Datenherkunft eines Berichts in Azure Synapse mit der kompletten Datenherkunft desselben Berichts in Ihrer Legacyumgebung vergleichen, um festzustellen, ob während der Migration unbeabsichtigt Abweichungen aufgetreten sind. Diese Art von Vergleich ist besonders nützlich, wenn Sie den Migrationserfolg testen und überprüfen müssen.

Die Visualisierung der Datenherkunft reduziert nicht nur den Zeit- und Arbeitsaufwand sowie Fehler im Migrationsprozess, sondern ermöglicht auch eine schnellere Migration.

Mithilfe von Tools für die automatische Ermittlung von Metadaten und Datenherkunft, die auch die Datenherkunft vergleichen, können Sie überprüfen, ob ein Bericht in Azure Synapse, der anhand migrierter Daten erstellt wurde, in gleicher Weise wie in der Legacyumgebung erzeugt wird. Mit dieser Funktion können Sie zudem folgende Fragen beantworten:

• Welche Daten müssen migriert werden, um eine erfolgreiche Ausführung von Berichten und Dashboards in Azure Synapse sicherzustellen?

• Welche Transformationen wurden ausgeführt und sind noch erforderlich sind, um die erfolgreiche Ausführung in Azure Synapse sicherzustellen?

• Wie die Anzahl doppelter Berichte reduziert werden kann

Tools für die automatische Ermittlung von Metadaten und Datenherkunft erleichtern den Migrationsprozess erheblich, da sie im Unternehmen zu einem besseren Verständnis der Datenressourcen beitragen und darüber informieren, welche Ressourcen zu Azure Synapse migriert werden müssen, um eine solide Berichterstellungsumgebung zu realisieren.

Verschiedene ETL-Tools verfügen über Funktionen zur Ermittlung der kompletten Datenherkunft. Überprüfen Sie daher, ob Ihr vorhandenes ETL-Tool auch über diese Funktion verfügt, wenn Sie es mit Azure Synapse verwenden möchten. Sowohl Azure Synapse-Pipelines als auch Azure Data Factory unterstützen die Möglichkeit, die Datenherkunft in Zuordnungsflows anzuzeigen. Außerdem bieten Microsoft-Partner Tools für die automatische Ermittlung von Metadaten und Datenherkunft sowie den Herkunftsvergleich an.

Migrieren der semantischen Ebene von BI-Tools zu Azure Synapse Analytics

Einige BI-Tools umfassen eine so genannte semantische Metadatenebene. Diese Ebene vereinfacht den Zugriff des Geschäftsbenutzers auf die zugrundeliegenden physischen Datenstrukturen in einer Data Warehouse- oder Data Mart-Datenbank. Die semantische Metadatenebene stellt Objekte auf hoher Ebene wie Dimensionen, Kennzahlen, Hierarchien, berechnete Metriken und Verknüpfungen bereit und vereinfacht so den Zugriff. Für diese Objekte werden Unternehmensbegriffe verwendet, die Unternehmensanalysten vertraut sind und den physischen Datenstrukturen im Data Warehouse oder Data Mart entsprechen.

Tipp

Einige BI-Tools verfügen über semantische Ebenen, die den Zugriff von Geschäftsbenutzern auf physische Datenstrukturen in Ihrem Data Warehouse oder Data Mart vereinfachen.

Bei einer Data Warehouse-Migration sind Sie möglicherweise gezwungen, Spalten- oder Tabellennamen zu ändern. Beispielsweise ermöglicht Oracle ein #-Zeichen in Tabellennamen, während bei Azure Synapse # nur als Tabellennamenpräfix zulässig ist, um eine temporäre Tabelle anzugeben. In Oracle haben TEMPORARY TABLES nicht unbedingt ein "#" im Namen, aber in Synapse müssen sie es. In solchen Fällen sind möglicherweise einige Überarbeitungen erforderlich, um Tabellenzuordnungen zu ändern.

Um Konsistenz über mehrere BI-Tools hinweg zu erzielen, erstellen Sie mithilfe eines Datenvirtualisierungsservers, der zwischen BI-Tools und Anwendungen und Azure Synapse angeordnet ist, eine universelle semantische Ebene. Verwenden Sie auf dem Datenvirtualisierungsserver gemeinsame Datennamen für Objekte auf hoher Ebene wie Dimensionen, Kennzahlen, Hierarchien und Verknüpfungen. Auf diese Weise brauchen Sie alles, einschließlich berechneter Felder, Verknüpfungen und Zuordnungen, nur einmal statt in jedem Tool zu konfigurieren. Verweisen Sie dann alle BI-Tools auf den Datenvirtualisierungsserver.

Tipp

Verwenden Sie die Datenvirtualisierung, um eine gemeinsame semantische Ebene zu erstellen, die die Konsistenz aller BI-Tools in einer Azure Synapse-Umgebung gewährleistet.

Durch die Datenvirtualisierung können Sie die Konsistenz aller BI-Tools sicherstellen und die Abhängigkeit zwischen BI-Tools und Anwendungen und den zugrunde liegenden physischen Datenstrukturen in Azure Synapse aufheben. Microsoft-Partner helfen Ihnen gern beim Gewährleisten der Konsistenz in Azure. Im folgenden Diagramm wird veranschaulicht, wie Sie mit einem allgemeinen Vokabular auf dem Datenvirtualisierungsserver eine gemeinsame semantische Ebene für mehrere BI-Tools bereitstellen können:

Zusammenfassung

Bei einer Data Warehouse-Migration per Lift & Shift sollten die meisten Berichte, Dashboards und anderen Visualisierungen problemlos migriert werden.

Bei einer Migration aus einer Legacyumgebung stellen Sie möglicherweise fest, dass Daten in Legacy-Data Warehouse- oder -Data Mart-Tabellen in nicht unterstützten Datentypen gespeichert sind. Möglicherweise finden Sie auch Legacy-Data Warehouse-Sichten, die proprietäre SQL ohne Entsprechung in Azure Synapse enthalten. In diesen Fällen müssen Sie diese Probleme beheben, um eine erfolgreiche Migration zu Azure Synapse zu gewährleisten.

Verlassen Sie sich nicht auf von Benutzern verwaltete Dokumentation, um zu ermitteln, wo sich Probleme befinden. Verwenden Sie stattdessen EXPLAIN-Anweisungen, da sie eine schnelle, pragmatische Möglichkeit zum Identifizieren von SQL-Inkompatibilitäten darstellen. Überarbeiten Sie die inkompatiblen SQL-Anweisungen, um eine entsprechende Funktionalität in Azure Synapse zu erzielen. Verwenden Sie außerdem Tools für die automatische Ermittlung von Metadaten und Datenherkunft, um Abhängigkeiten zu verstehen, nach doppelten Berichten zu suchen und ungültige Berichte zu identifizieren, die auf veralteten, fragwürdigen oder nicht vorhandenen Datenquellen basieren. Verwenden Sie Tools zum Vergleichen der Datenherkunft, um zu überprüfen, ob in Ihrer Legacy-Data Warehouse-Umgebung ausgeführte Berichte in Azure Synapse auf gleiche Weise erstellt werden.

Migrieren Sie keine Berichte, die Sie nicht mehr verwenden. Nutzungsdaten von BI-Tools können Ihnen helfen, nicht verwendete Berichte zu ermitteln. Migrieren Sie für die zu migrierenden Berichte, Dashboards und andere Visualisierungen auch alle Benutzer, Benutzergruppen, Rollen und Berechtigungen. Wenn Sie Ihre Berichtmigrationsstrategie am Geschäftswert ausrichten, verknüpfen Sie die Berichte mit strategischen Geschäftszielen und Prioritäten, um den Anteil der Erkenntnisse aus den Berichten an bestimmten Zielen zu identifizieren. Wenn Sie Data Marts einzeln nacheinander migrieren, identifizieren Sie mithilfe der Metadaten, welche Berichte von welchen Tabellen und Sichten abhängig sind, damit Sie eine fundierte Entscheidung treffen können, welche Data Marts zuerst migriert werden müssen.

Tipp

Identifizieren Sie Inkompatibilitäten frühzeitig, damit Sie den Migrationsaufwand abschätzen können. Migrieren Sie Ihre Benutzer, Gruppenrollen und Berechtigungszuweisungen. Migrieren Sie nur die Berichte und Visualisierungen, die tatsächlich verwendet werden und zum Geschäftswert beitragen.

Bei einer Migration können strukturelle Änderungen am Datenmodell Ihres Data Warehouse oder Data Mart auftreten. Erwägen Sie die Verwendung der Datenvirtualisierung, um BI-Tools und Anwendungen vor strukturellen Änderungen zu schützen. Mit der Datenvirtualisierung können Sie ein gemeinsames Vokabular zum Definieren einer gemeinsamen semantischen Ebene verwenden. Eine gemeinsame semantische Ebene bietet Gewähr für gemeinsame Datennamen, Definitionen, Metriken, Hierarchien und Verknüpfungen über alle BI-Tools und Anwendungen in der neuen Azure Synapse-Umgebung hinweg.

Nächste Schritte

Weitere Informationen zum Minimieren von SQL-Problemen finden Sie im nächsten Artikel dieser Reihe: Minimieren von SQL-Problemen bei Oracle-Migrationen.