Visualisierung und Berichterstellung für Netezza-Migrationen

Dieser Artikel ist Teil vier einer siebenteiligen Reihe, die Anleitungen zum Migrieren von Netezza zu Azure Synapse Analytics bietet. Der Schwerpunkt dieses Artikels ist bewährte Methoden für Visualisierung und Berichterstellung.

Zugreifen auf Azure Synapse Analytics mit Microsoft- und Drittanbieter-BI-Tools

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

• Microsoft BI-Tools wie Power BI.

• Office-Anwendungen, z. B. Microsoft Excel-Tabellen.

• BI-Tools von verschiedenen Drittanbietern

• Benutzerdefinierte Analyseanwendungen mit eingebetteter BI-Toolfunktionalität.

• Operative Anwendungen, die On-Demand BI unterstützen, indem Abfragen und Berichte auf einer BI-Plattform ausgeführt werden, die wiederum Daten in einem Data Warehouse oder Data Mart abfragt.

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

Wenn Sie Visualisierungen und Berichte als Teil Ihrer Data Warehouse-Migration migrieren, müssen alle vorhandenen Abfragen, Berichte und Dashboards, die von BI-Produkten generiert werden, in der neuen Umgebung ausgeführt werden. Ihre BI-Produkte müssen auf Azure Synapse dieselben Ergebnisse erzielen wie in Ihrer älteren Data Warehouse-Umgebung.

Für konsistente Ergebnisse nach der Migration müssen alle BI-Tools und Anwendungsabhängigkeiten funktionieren, nachdem Sie Ihr Data Warehouse-Schema und Ihre Daten nach Azure Synapse migriert haben. Die Abhängigkeiten umfassen weniger sichtbare Aspekte, z. B. Zugriff und Sicherheit. Stellen Sie beim Thema Zugriff und Sicherheit sicher, dass Sie Folgendes migrieren:

• 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 für Azure Synapse.

• Alle Autorisierungsberechtigungen für die Zugriffssteuerung für Azure Synapse.

• Benutzer-, Rollen- und Berechtigungszuweisungen, um zu spiegeln, was Sie in Ihrem vorhandenen Data Warehouse vor der Migration hatten. Beispiel:

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

Der Zugriff und die Sicherheit sind wichtige Überlegungen für den Datenzugriff im migrierten System und werden in Sicherheit, Zugriff und Vorgängen für Netezza-Migrationen ausführlicher behandelt.

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

Geschäftsbenutzer erwarten eine nahtlose Migration ohne Überraschungen, die ihr Vertrauen in das migrierte System in Azure Synapse zerstören. Achten Sie darauf, jegliche Ängste Ihrer Benutzer durch gute Kommunikation abzubauen. Ihre Benutzer erwarten Folgendes:

• Die Tabellenstruktur bleibt dieselbe, wenn in Abfragen direkt darauf verwiesen wird.

• Tabellen- und Spaltennamen bleiben unverändert, wenn direkt in Abfragen darauf verwiesen wird. Beispielsweise sollten berechnete Felder, die in Spalten in BI-Tools definiert sind, nicht fehlschlagen, wenn aggregierte Berichte erstellt werden.

• Die historische Analyse bleibt unverändert.

• Datentypen bleiben nach Möglichkeit gleich.

• Das Abfrageverhalten bleibt unverändert.

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

Wenn BI-Tools Abfrageansichten in der zugrunde liegenden Data Warehouse- oder Data Mart-Datenbank abfragen, funktionieren diese Ansichten nach der Migration noch? Einige Ansichten funktionieren möglicherweise nicht, wenn proprietäre SQL-Erweiterungen für Ihr älteres Data Warehouse DBMS vorhanden sind, die in Azure Synapse keine Entsprechung haben. Wenn ja, müssen Sie über diese Inkompatibilitäten wissen und eine Möglichkeit finden, sie zu lösen.

Andere Probleme, z. B. das Verhalten von NULL Werten oder Datentypvariationen auf DBMS-Plattformen, müssen getestet werden, um sicherzustellen, dass selbst geringfügige Unterschiede in Berechnungsergebnissen nicht vorhanden sind. Minimieren Sie diese Probleme, und ergreifen Sie alle erforderlichen Schritte, um Geschäftsbenutzer davor zu schützen, von ihnen betroffen zu sein. Abhängig von Ihrer Altsystem-Data-Warehouse-Umgebung können Drittanbietertools helfen, die Unterschiede zwischen den Alt- und neuen Umgebungen zu verbergen, sodass BI-Tools und -Anwendungen unverändert ausgeführt werden.

Tests sind für die Visualisierung und die Berichtmigration von entscheidender Bedeutung. Sie benötigen eine Testsuite und vereinbarte Testdaten, um Tests in beiden Umgebungen auszuführen und erneut auszuführen. Ein Testgurt ist auch nützlich, und einige werden in diesem Handbuch erwähnt. Außerdem ist es wichtig, geschäftliche Benutzer in den Testaspekt der Migration einzubeziehen, um das Vertrauen hoch zu halten und sie engagiert und teil des Projekts zu halten.

Möglicherweise denken Sie daran, BI-Tools zu wechseln, z. B. zum Migrieren zu Power BI. Die Versuchung besteht darin, solche Änderungen gleichzeitig vorzunehmen, indem Sie Ihr Schema, Ihre Daten, DIE ETL-Verarbeitung und vieles mehr migrieren. Um das Risiko zu minimieren, ist es jedoch besser, zuerst zu Azure Synapse zu migrieren und alles zu erledigen, bevor sie eine weitere Modernisierung unternehmen.

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 mit beiden Umgebungen ausführen können. Alternativ können Sie es ausprobieren, wenn der Anbieter Ihrer vorhandenen BI-Tools sein Produkt auf Azure anbietet. Das gleiche gilt für Anwendungen, die lokal ausgeführt werden, die BI einbetten oder Ihren BI-Server bei Bedarf aufrufen, z. B. durch Anfordern eines "headless report" mit XML- oder JSON-Daten.

Hier gibt es viel zu denken, also werfen wir einen genaueren Blick.

Verwenden der Datenvirtualisierung, um die Auswirkungen der Migration auf BI-Tools und -Berichte zu minimieren

Während der Migration sind Sie möglicherweise versucht, langfristige Anforderungen wie das Öffnen von Geschäftsanforderungen, das Hinzufügen fehlender Daten oder die Implementierung neuer Features zu erfüllen. Solche Änderungen können sich jedoch auf den ZUGRIFF von BI-Tools auf Ihr Data Warehouse auswirken, insbesondere, wenn die Änderung strukturelle Änderungen an Ihrem Datenmodell beinhaltet. Wenn Sie eine agile Datenmodellierungsmethode einführen oder strukturelle Änderungen implementieren möchten, führen Sie dies nach der Migration aus .

Eine Möglichkeit, die Auswirkungen von Schemaänderungen oder anderen strukturellen Änderungen auf Ihre BI-Tools zu minimieren, besteht darin, die Datenvirtualisierung zwischen den BI-Tools und Ihrem Data Warehouse und Data Marts einzuführen. Das folgende Diagramm zeigt, wie die Datenvirtualisierung eine Migration von Benutzern ausblenden kann.

Die Datenvirtualisierung unterbricht die Abhängigkeit zwischen Geschäftsbenutzern, die Self-Service BI-Tools verwenden, und dem physischen Schema des zugrunde liegenden Data Warehouses und data marts, die migriert werden.

Bei der Datenvirtualisierung können alle Während einer Migration zu Azure Synapse vorgenommenen Schemaänderungen, z. B. zur Optimierung der Leistung, von Geschäftsbenutzern ausgeblendet werden, da sie nur Zugriff auf virtuelle Tabellen in der Datenvirtualisierungsebene haben. Und wenn Sie strukturelle Änderungen vornehmen, müssen Sie nur die Zuordnungen zwischen dem Data Warehouse oder data marts und allen virtuellen Tabellen aktualisieren. Bei der Datenvirtualisierung sind die Benutzer nicht mit strukturellen Änderungen vertraut. Microsoft-Partner stellen Datenvirtualisierungssoftware bereit.

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

Eine zentrale Frage beim Migrieren Ihrer vorhandenen Berichte und Dashboards nach Azure Synapse ist, welche zuerst migriert werden sollen. Mehrere Faktoren können diese Entscheidung fördern, z. B.:

• Verwendung

• Geschäftswert

• Einfache Migration

• Datenmigrationsstrategie

In den folgenden Abschnitten werden diese Faktoren erläutert.

Unabhängig davon, was Ihre Entscheidung ist, müssen Sie Ihre Geschäftsbenutzer einbeziehen, da sie die Berichte, Dashboards und andere Visualisierungen erstellen und Geschäftsentscheidungen basierend auf Erkenntnissen dieser Elemente treffen. Jeder hat Vorteile, wenn Sie:

• Nahtloses Migrieren von Berichten und Dashboards
• Migrieren von Berichten und Dashboards mit minimalem Aufwand und
• Zeigen Sie Ihre BI-Tools auf Azure Synapse anstelle Ihres älteren Data Warehouse-Systems, und rufen Sie ähnliche Berichte, Dashboards und andere Visualisierungen ab.

Migrieren von Berichten basierend auf der Verwendung

Die Nutzung ist häufig ein Indikator für den Geschäftswert. Nicht verwendete Berichte und Dashboards tragen eindeutig nicht zu Geschäftsentscheidungen bei oder bieten 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 altes Data Warehouse seit Jahren in Betrieb ist, besteht eine gute Chance, dass Sie Hunderte, wenn nicht Tausende von Berichten haben. Es lohnt sich, einen Bestand von Berichten und Dashboards zu kompilieren und deren Geschäftszweck- und Nutzungsstatistiken zu identifizieren.

Ermitteln Sie bei nicht verwendeten Berichten, ob sie außer Betrieb genommen werden sollen, um den Migrationsaufwand zu verringern. Eine wichtige Frage bei der Entscheidung, ob ein nicht verwendeter Bericht außer Betrieb genommen werden soll, ist, ob der Bericht nicht verwendet wird, weil es nicht bekannt ist, weil er keinen geschäftlichen Wert bietet oder weil er von einem anderen Bericht abgelöst wurde.

Migrieren von Berichten basierend auf dem Geschäftswert

Die Nutzung allein ist nicht immer ein guter Indikator für den Geschäftlichen Wert. Möglicherweise sollten Sie berücksichtigen, inwieweit die Erkenntnisse eines Berichts zu einem geschäftlichen Wert beitragen. Eine Möglichkeit, dies zu tun, besteht darin, die Rentabilität jeder Geschäftsentscheidung zu bewerten, die auf dem Bericht und dem Umfang der Abhängigkeit beruht. Diese Informationen sind jedoch in den meisten Organisationen nicht leicht verfügbar.

Eine weitere Möglichkeit zur Bewertung des Geschäftswerts besteht darin, die Ausrichtung eines Berichts mit der Geschäftsstrategie zu betrachten. Die von Ihrer Geschäftsleitung festgelegte Geschäftsstrategie legt in der Regel strategische Geschäftsziele (SBOs), Key Performance Indicators (KPIs), KPI-Ziele fest, die erreicht werden müssen, und wer für die Erreichung dieser Ziele verantwortlich ist. Sie können einen Bericht nach den SBOs klassifizieren, zu denen der Bericht beiträgt, z. B. Betrugsreduzierung, verbessertes Kundenengagement und optimierte Geschäftsabläufe. Anschließend können Sie für die Migration die Berichte und Dashboards priorisieren, die mit zielen mit hoher Priorität verknüpft sind. Auf diese Weise kann die anfängliche Migration geschäftswert in einem strategischen Bereich liefern.

Eine weitere Möglichkeit zum Auswerten des Geschäftswerts besteht darin, Berichte und Dashboards als operativen, taktischen oder strategischen zu klassifizieren, um zu identifizieren, auf welcher Geschäftsebene sie verwendet werden. SBOs erfordern Beiträge auf all diesen Ebenen. Indem Sie wissen, welche Berichte und Dashboards verwendet werden, auf welcher Ebene und welchen Zielen sie zugeordnet sind, können Sie sich auf die anfängliche Migration auf den Geschäftswert mit hoher Priorität konzentrieren. Sie können die folgende Zieltabelle für Unternehmensstrategie verwenden, um Berichte und Dashboards auszuwerten.

Metadatenermittlungstools wie Azure Data Catalog ermöglichen Es Geschäftsbenutzern, Datenquellen zu markieren und zu bewerten, um die Metadaten für diese Datenquellen zu erweitern, um ihre Ermittlung und Klassifizierung zu unterstützen. Sie können die Metadaten für einen Bericht oder ein Dashboard verwenden, um ihren Geschäftswert zu verstehen. Ohne solche Tools ist das Verständnis des Beitrags von Berichten und Dashboards zum Geschäftswert wahrscheinlich eine zeitaufwendige Aufgabe, unabhängig davon, ob Sie migrieren oder nicht.

Migrieren von Berichten basierend auf der Datenmigrationsstrategie

Wenn Ihre Migrationsstrategie zuerst auf der Migration von Data Marts basiert, wirkt sich die Reihenfolge der Data Mart-Migration darauf aus, welche Berichte und Dashboards zuerst migriert werden. Wenn Ihre Strategie auf dem Geschäftlichen Wert basiert, spiegelt die Reihenfolge, in der Sie Data Marts zu Azure Synapse migrieren, geschäftsprioritäten wider. Mithilfe von Metadatenermittlungstools können Sie Ihre Strategie implementieren, indem Sie anzeigen, welche Data Mart-Tabellen Daten für welche Berichte bereitstellen.

Probleme bei der Migrationinkompatibilität, die sich auf Berichte und Visualisierungen auswirken können

BI-Tools erstellen Berichte, Dashboards und andere Visualisierungen, indem SQL-Abfragen ausgestellt werden, die auf physische Tabellen und/oder Ansichten in Ihrem Data Warehouse oder Data Mart zugreifen. Wenn Sie Ihr älteres Data Warehouse zu Azure Synapse migrieren, können sich mehrere Faktoren auf die einfache Migration von Berichten, Dashboards und anderen Visualisierungen auswirken. Zu diesen Faktoren gehören:

• Schemainkompatibilitäten zwischen den Umgebungen

• SQL-Inkompatibilitäten zwischen den Umgebungen.

Schemainkompatibilitäten

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

• Nicht standardmäßige Tabellentypen in Ihrem älteren Data Warehouse DBMS, die in Azure Synapse keine Entsprechung haben.

• Datentypen in Ihrem älteren Data Warehouse DBMS, die in Azure Synapse keine Entsprechung haben.

In den meisten Fällen gibt es eine Problemumgehung für die Inkompatibilitäten. Sie können beispielsweise die Daten in einem nicht unterstützten Tabellentyp in eine Standardtabelle mit den passenden Datentypen migrieren, die dann auf einer Datums-/Uhrzeitspalte indiziert oder partitioniert wird. Ebenso kann es möglich sein, nicht unterstützte Datentypen in einem anderen Spaltentyp darzustellen und Berechnungen in Azure Synapse durchzuführen, um dieselben Ergebnisse zu erzielen.

Um die von Schemainkompatibilitäten betroffenen Berichte zu identifizieren, führen Sie Abfragen für den Systemkatalog Ihres legacy Data Warehouse aus, um die Tabellen mit nicht unterstützten Datentypen zu identifizieren. Anschließend können Sie Metadaten aus Ihrem BI-Tool verwenden, um die Berichte zu identifizieren, die auf Daten in diesen Tabellen zugreifen. Weitere Informationen zum Identifizieren von Inkompatibilitäten des Objekttyps finden Sie unter Nicht unterstützte Netezza-Datenbankobjekttypen.

Die Auswirkungen von Schemainkompatibilitäten auf Berichte, Dashboards und andere Visualisierungen sind möglicherweise kleiner als Sie denken, 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

Während einer Migration wirken sich SQL-Inkompatibilitäten wahrscheinlich auf Berichte, Dashboards oder andere Visualisierungen in einer Anwendung oder einem Tool aus, die:

• Greift auf ältere Data Warehouse-DBMS-Ansichten zu, die proprietäre SQL-Funktionen enthalten, die in Azure Synapse keine Entsprechung haben.

• Gibt SQL-Abfragen an, die proprietäre SQL-Funktionen enthalten, die speziell für den SQL-Dialekt Ihrer Legacyumgebung spezifisch sind und keine Entsprechung in Azure Synapse aufweisen.

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

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

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

Sie finden SQL-Inkompatibilitäten, indem Sie die _v_qryhist Systemtabelle abfragen, um aktuelle SQL-Aktivitäten in Ihrem älteren Netezza-Data Warehouse anzuzeigen. Weitere Informationen finden Sie in der Abfrageverlaufstabelle. 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 voran, und führen Sie diese EXPLAIN Anweisungen in Azure Synapse aus. Alle SQL-Anweisungen, die proprietäre nicht unterstützte SQL-Erweiterungen enthalten, werden von Azure Synapse abgelehnt, wenn die EXPLAIN Anweisungen ausgeführt werden. Mit diesem Ansatz können Sie den Umfang der SQL-Inkompatibilitäten bewerten.

Metadaten aus Ihrem älteren Data Warehouse-DBMS können Ihnen auch helfen, inkompatible Ansichten zu identifizieren. Erfassen Sie wie zuvor einen repräsentativen Satz von SQL-Anweisungen, präfixieren Sie jede SQL-Anweisung mit einer EXPLAIN Anweisung, und führen Sie diese EXPLAIN Anweisungen in Azure Synapse aus, um Ansichten mit inkompatiblem SQL zu identifizieren.

Testbericht 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 funktioniert hat. Definieren Sie eine Reihe von Tests und eine Reihe von erforderlichen Ergebnissen für jeden Test, den Sie ausführen, um den Erfolg zu überprüfen. Testen und vergleichen Sie die Berichte und Dashboards in Ihren vorhandenen und migrierten Data Warehouse-Systemen mit:

• Identifizieren Sie, ob Schemaänderungen, die während der Migration vorgenommen wurden, die Fähigkeit von Berichten, ausgeführt zu werden, die Ergebnisse zu melden oder die Visualisierungen der entsprechenden Berichte beeinflusst haben. Ein Beispiel für eine Schemaänderung ist, wenn Sie einen inkompatiblen Datentyp einem entsprechenden Datentyp zugeordnet haben, der in Azure Synapse unterstützt wird.

• Stellen Sie sicher, dass alle Benutzer migriert werden.

• Stellen Sie sicher, dass alle Rollen migriert werden, und benutzer werden diesen Rollen zugewiesen.

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

• Stellen Sie konsistente Ergebnisse für alle bekannten Abfragen, Berichte und Dashboards sicher.

• Stellen Sie sicher, dass die Daten- und ETL-Migration abgeschlossen und fehlerfrei ist.

• Stellen Sie sicher, dass der Datenschutz eingehalten wird.

• Testen Sie Leistung und Skalierbarkeit.

• Testen Sie die analytische Funktionalität.

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

Automatisieren Sie tests so weit wie möglich, um jeden Test wiederholbar zu machen und einen konsistenten Ansatz zur Auswertung von Testergebnissen zu unterstützen. Automatisierung funktioniert gut für bekannte regelmäßige Berichte und kann über Azure Synapse-Pipelines oder Azure Data Factory-Orchestrierung verwaltet werden. Wenn Sie bereits über eine Reihe von Testabfragen für Regressionstests verfügen, können Sie die vorhandenen Testtools verwenden, um die Tests nach der Migration zu automatisieren.

Ad-hoc-Analysen und -Berichte sind schwieriger und erfordern die Kompilierung einer Reihe von Tests, um zu überprüfen, ob die gleichen Berichte und Dashboards vor und nach der Migration konsistent sind. Wenn Sie Inkonsistenzen finden, ist die Möglichkeit, die Metadatenlinie zwischen den ursprünglichen und migrierten Systemen während der Migrationstests zu vergleichen, entscheidend. Dieser Vergleich kann Unterschiede und Punkt hervorheben, an dem Inkonsistenzen entstanden sind, wenn die Erkennung mit anderen Mitteln schwierig ist.

Analysieren der Linien, um Abhängigkeiten zwischen Berichten, Dashboards und Daten zu verstehen

Ihr Verständnis der Linien ist ein wichtiger Faktor bei der erfolgreichen Migration von Berichten und Dashboards. "Lineage" ist Metadaten, die die Reise migrierter Daten anzeigen, sodass Sie den Pfad aus einem Bericht oder Dashboard bis zurück zur Datenquelle nachverfolgen können. Die Lineage zeigt, wie Daten von Punkt zu Punkt gereist sind, ihren Ort im Data Warehouse und/oder Data Mart, und in welchen Berichten und Dashboards sie verwendet werden. Die Lineage kann Ihnen helfen, zu verstehen, was mit Daten passiert, da sie durch verschiedene Datenspeicher, z. B. Dateien und Datenbanken, verschiedene ETL-Pipelines und berichte, durchgeht. Wenn Geschäftsbenutzer Zugriff auf Datenherkunft haben, verbessert dies das Vertrauen, stärkt das Selbstvertrauen und unterstützt fundierte Geschäftsentscheidungen.

In Data Warehouse-Umgebungen mit mehreren Anbietern arbeiten möglicherweise Unternehmensanalysten in BI-Teams die Datenherkunft aus. Wenn Sie beispielsweise unterschiedliche Anbieter für ETL, Data Warehouse und Reporting verwenden und jeder Anbieter über ein eigenes Metadatenrepository verfügt, wird herauszufinden, wo ein bestimmtes Datenelement in einem Bericht stammt, schwierig und zeitaufwändig sein kann.

Um nahtlos von einem älteren Data Warehouse zu Azure Synapse zu migrieren, verwenden Sie die End-to-End-Datenlinie, um eine like-for-like-Migration zu beweisen, wenn Sie die berichte und Dashboards vergleichen, die von jeder Umgebung generiert werden. Um die End-to-End-Datenreise anzuzeigen, müssen Sie Metadaten aus mehreren Tools erfassen und integrieren. Wenn Sie Zugriff auf Tools haben, die automatisierte Metadatenermittlung und Datenlinie unterstützen, können Sie doppelte Berichte oder ETL-Prozesse identifizieren und Berichte finden, die auf veralteten, fragwürdigen oder nicht vorhandenen Datenquellen basieren. Sie können diese Informationen verwenden, um die Anzahl der von Ihnen migrierten Berichte und ETL-Prozesse zu reduzieren.

Sie können auch die End-to-End-Linie eines Berichts in Azure Synapse mit der End-to-End-Linie desselben Berichts in Ihrer Legacyumgebung vergleichen, um nach Unterschieden zu suchen, die während der Migration versehentlich aufgetreten sind. Dieser Vergleichstyp ist besonders nützlich, wenn Sie den Migrationserfolg testen und überprüfen müssen.

Datenlinienvisualisierung reduziert nicht nur Zeit, Aufwand und Fehler im Migrationsprozess, sondern ermöglicht auch eine schnellere Migration.

Mithilfe automatisierter Metadatenermittlungs- und Datenlinientools, die die Lineage vergleichen, können Sie überprüfen, ob ein Bericht in Azure Synapse, der aus migrierten Daten erstellt wird, auf die gleiche Weise in Ihrer Legacyumgebung erstellt wird. Diese Funktion hilft Ihnen auch, Folgendes zu bestimmen:

• Welche Daten migriert werden müssen, um eine erfolgreiche Berichts- und Dashboardausführung in Azure Synapse sicherzustellen.

• Welche Transformationen wurden bereits durchgeführt und welche sollten durchgeführt werden, um eine erfolgreiche Ausführung in Azure Synapse sicherzustellen.

• Wie die Anzahl doppelter Berichte reduziert werden kann

Automatisierte Metadatenermittlungs- und Datenlinientools vereinfachen den Migrationsprozess erheblich, da sie Unternehmen dabei helfen, sich ihrer Datenressourcen bewusster zu werden und zu wissen, was zu Azure Synapse migriert werden muss, um eine solide Berichterstellungsumgebung zu erzielen.

Mehrere ETL-Tools bieten End-to-End-Lineage-Funktionen. Überprüfen Sie daher, ob Ihr vorhandenes ETL-Tool über diese Funktion verfügt, wenn Sie sie mit Azure Synapse verwenden möchten. Sowohl Azure Synapse-Pipelines als auch Azure Data Factory unterstützen die Möglichkeit, die Datenherkunft in Zuordnungsflüssen anzuzeigen. Microsoft-Partner bieten auch automatisierte Metadatenermittlungs-, Datenlinien- und Linienvergleichstools.

Migration der Semantikebenen von BI-Tools zu Azure Synapse Analytics

Einige BI-Tools verfügen über eine semantische Metadatenebene. Diese Ebene vereinfacht den Zugriff des Geschäftsbenutzers auf die zugrunde liegenden physischen Datenstrukturen in einem Data Warehouse oder einer Data Mart-Datenbank. Die semantische Metadatenebene vereinfacht den Zugriff, indem sie allgemeine Objekte wie Dimensionen, Measures, Hierarchien, berechnete Metriken und Verknüpfungen bereitstellt. Für diese Objekte werden Unternehmensbegriffe verwendet, die Unternehmensanalysten vertraut sind und den physischen Datenstrukturen im Data Warehouse oder Data Mart entsprechen.

In einer Data Warehouse-Migration können Änderungen an Spaltennamen oder Tabellennamen bei Ihnen erzwungen werden. In IBM Netezza können Tabellennamen z. B. ein "#" aufweisen. In Azure Synapse ist "#" nur als Präfix für einen Tabellennamen zulässig, um eine temporäre Tabelle anzugeben. In IBM Netezza haben TEMPORÄRE TABELLEN nicht unbedingt ein "#" im Namen, sondern in Synapse müssen sie. 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 eine universelle semantische Ebene mithilfe eines Datenvirtualisierungsservers, der sich zwischen BI-Tools und Anwendungen und Azure Synapse befindet. Verwenden Sie auf dem Datenvirtualisierungsserver allgemeine Datennamen für Objekte auf hoher Ebene wie Dimensionen, Measures, Hierarchien und Verknüpfungen. Auf diese Weise konfigurieren Sie alles, einschließlich berechneter Felder, Verknüpfungen und Zuordnungen, nur einmal statt in jedem Tool. Verweisen Sie dann auf alle BI-Tools auf dem Datenvirtualisierungsserver.

Mit der Datenvirtualisierung erhalten Sie Konsistenz über alle BI-Tools hinweg und unterbrechen die Abhängigkeit zwischen BI-Tools und Anwendungen und den zugrunde liegenden physischen Datenstrukturen in Azure Synapse. Microsoft-Partner können Ihnen helfen, Konsistenz in Azure zu erzielen. Das folgende Diagramm zeigt, wie ein einheitliches Vokabular auf dem Datenvirtualisierungsserver es mehreren BI-Tools ermöglicht, auf eine gemeinsame semantische Ebene zuzugreifen.

Fazit

In einer Lift- und Schicht-Data Warehouse-Migration sollten die meisten Berichte, Dashboards und andere Visualisierungen problemlos migriert werden.

Während einer Migration aus einer Legacyumgebung stellen Sie möglicherweise fest, dass Daten im älteren Data Warehouse oder data mart-Tabellen in nicht unterstützten Datentypen gespeichert werden. Alternativ können Sie ältere Data Warehouse-Ansichten finden, die proprietäre SQL ohne Entsprechung in Azure Synapse enthalten. Wenn ja, müssen Sie diese Probleme beheben, um eine erfolgreiche Migration zu Azure Synapse sicherzustellen.

Verlassen Sie sich nicht auf die vom Benutzer verwaltete Dokumentation, um zu ermitteln, wo sich Probleme befinden. Verwenden Sie EXPLAIN stattdessen Anweisungen, da sie eine schnelle, pragmatische Methode zum Identifizieren von SQL-Inkompatibilitäten sind. Überarbeiten Sie die inkompatiblen SQL-Anweisungen, um entsprechende Funktionen in Azure Synapse zu erzielen. Verwenden Sie außerdem automatisierte Metadatenermittlungs- und Linientools, um Abhängigkeiten zu verstehen, doppelte Berichte zu finden und ungültige Berichte zu identifizieren, die auf veralteten, fragwürdigen oder nicht vorhandenen Datenquellen basieren. Verwenden Sie Linientools, um die Linien zu vergleichen, um zu überprüfen, ob Berichte, die in Ihrer älteren Data Warehouse-Umgebung ausgeführt werden, in Azure Synapse identisch erstellt werden.

Migrieren Sie keine Berichte, die Sie nicht mehr verwenden. BI-Toolnutzungsdaten können Ihnen helfen, zu bestimmen, welche Berichte nicht verwendet werden. Migrieren Sie alle Benutzer, Benutzergruppen, Rollen und Berechtigungen für die Berichte, Dashboards und anderen Visualisierungen, die Sie migrieren möchten. Wenn Sie ihren Geschäftswert verwenden, um Ihre Berichtmigrationsstrategie zu fördern, ordnen Sie Berichte mit strategischen Geschäftszielen und Prioritäten zu, um den Beitrag von Berichtserkenntnissen zu bestimmten Zielen zu identifizieren. Wenn Sie Data Mart nach Data Mart migrieren, verwenden Sie Metadaten, um zu identifizieren, welche Berichte von welchen Tabellen und Ansichten abhängig sind, sodass Sie eine fundierte Entscheidung darüber treffen können, welche Data Marts zuerst migriert werden sollen.

Strukturelle Änderungen am Datenmodell Ihres Data Warehouse oder Data Mart können während einer Migration auftreten. Erwägen Sie die Verwendung der Datenvirtualisierung, um BI-Tools und -Anwendungen vor strukturellen Änderungen abzuschirmen. Mit der Datenvirtualisierung können Sie ein gemeinsames Vokabular verwenden, um eine gemeinsame semantische Ebene zu definieren. Die gemeinsame semantische Ebene garantiert konsistente gemeinsame Datennamen, Definitionen, Metriken, Hierarchien und Verknüpfungen in allen BI-Tools und -Anwendungen in der neuen Azure Synapse-Umgebung.

Nächste Schritte

Weitere Informationen zum Minimieren von SQL-Problemen finden Sie im nächsten Artikel dieser Reihe: Minimieren von SQL-Problemen für Netezza-Migrationen.