Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:✅ Warehouse in Microsoft Fabric
Dieser Artikel beschreibt die Strategie, Überlegungen und Methoden der Migration von Data Warehousing in Azure Synapse Analytics dedizierten SQL-Pools zu Microsoft Fabric Warehouse.
Tipp
Eine automatisierte Oberfläche für die Migration von dedizierten SQL-Pools von Azure Synapse Analytics ist über den Fabric-Migrations-Assistenten für Data Warehouseverfügbar. Dieser Artikel enthält wichtige strategische und Planungsinformationen.
Migration – Einführung
Als Microsoft Microsoft Fabric vorstellte, eine SaaS-Analyselösung für Unternehmen, die eine umfassende Sammlung von Diensten bietet, darunter Data Factory, Data Engineering, Data Warehousing, Data Science, Echtzeitintelligenz, und Power BI.
In diesem Artikel geht es um die Optionen für die Migration von Schema (DDL), Datenbankcode (DML) und Daten. Microsoft bietet dazu mehrere Möglichkeiten an. Hier besprechen wir jede Option im Detail und geben Tipps, welche dieser Optionen Sie für Ihr Szenario in Betracht ziehen sollten. Dieser Artikel verwendet den TPC-DS-Benchmark zur Veranschaulichung und für Leistungstests. Ihr tatsächliches Ergebnis kann von vielen Faktoren abhängen, darunter die Art der Daten, die Datentypen, die Breite der Tabellen, die Latenzzeit der Datenquelle usw.
Vorbereiten der Migration
Planen Sie Ihr Migrationsprojekt sorgfältig, bevor Sie beginnen, und stellen Sie sicher, dass Ihr Schema, Code und Daten mit Fabric Warehouse kompatibel sind. Es gibt einige Einschränkungen, die Sie berücksichtigen müssen. Quantifizieren Sie den Refactoring-Aufwand für die inkompatiblen Elemente sowie alle anderen Ressourcen, die vor der Migration benötigt werden.
Ein weiteres wichtiges Ziel der Planung besteht darin, Ihren Entwurf anzupassen, um sicherzustellen, dass Ihre Lösung die hohe Abfrageleistung von Fabric Warehouse optimal nutzt. Das Entwerfen von Data Warehouses für die Skalierung umfasst einzigartige Entwurfsmuster, weshalb herkömmliche Ansätze nicht immer optimal sind. Prüfen Sie die Leistungsrichtlinien von Fabric Warehouse, denn obwohl einige Entwurfsanpassungen nach der Migration vorgenommen werden können, sparen Sie Zeit und Mühe, wenn Sie die Änderungen früher im Prozess vornehmen. Die Migration von einer Technologie/Umgebung zu einer anderen ist immer ein großer Aufwand.
Das folgende Diagramm zeigt den Migrationslebenszyklus mit den wichtigsten Säulen, bestehend aus den Säulen Bewerten und Evaluieren, Planen und Entwerfen, Migrieren, Überwachen und Verwalten, Optimieren und Modernisieren mit den zugehörigen Aufgaben in jeder Säule, um eine reibungslose Migration zu planen und vorzubereiten.
Runbook für die Migration
Betrachten Sie die folgenden Aktivitäten als ein Runbook für die Planung Ihrer Migration von Synapse dedizierten SQL-Pools zu Fabric Warehouse.
- Bewerten und evaluieren
- Identifizieren der Ziele und Motivationen. Definieren von klaren, gewünschten Ergebnissen.
- Ermittlung, Bewertung und Baseline der bestehenden Architektur.
- Identifizieren wichtiger Projektbeteiligter und Sponsoren.
- Definieren des Umfangs der zu migrierenden Elemente.
- Klein und einfach anfangen, sich auf mehrere kleine Migrationen vorbereiten.
- Beginnen Sie, alle Phasen des Prozesses zu überwachen und zu dokumentieren.
- Erstellen einer Bestandsaufnahme der Daten und Prozesse für die Migration
- Definieren von Datenmodelländerungen (falls erforderlich)
- Den Fabric Arbeitsbereich einrichten.
- Was ist Ihr Skillset/Ihre Vorliebe?
- Nehmen Sie wann immer möglich eine Automatisierung vor.
- Verwenden von integrierten Azure-Tools und -Features zum Verringern des Migrationsaufwands.
- Frühzeitige Schulung von Mitarbeitern für die neue Plattform
- Ermitteln Sie den Weiterbildungsbedarf und die entsprechenden Trainingsressourcen, einschließlich Microsoft Learn.
- Planen und Entwerfen
- Definieren Sie die gewünschte Architektur.
- Wählen Sie die Methode/Tools für die Migration aus, um die folgenden Aufgaben auszuführen:
- Extrahieren von Daten aus der Quelle.
- Schemakonvertierung (DDL), einschließlich Metadaten für Tabellen und Ansichten
- Datenaufnahme, einschließlich historischer Daten.
- Falls notwendig, das Datenmodell mittels der Leistung und Skalierbarkeit der neuen Plattform neu konstruieren.
- Migration von Datenbankcode (DML).
- Migrieren oder Umgestalten von gespeicherten Prozeduren und Geschäftsprozessen
- Inventarisieren und extrahieren der Sicherheitsmerkmale und Objektberechtigungen aus der Quelle.
- Entwerfen und planen der Ersetzung/Änderung bestehender ETL/ELT-Prozesse für inkrementelles Laden.
- Parallele ETL/ELT-Prozesse für die neue Umgebung erstellen.
- Einen detaillierten Migrationsplan erstellen.
- Den aktuellen Zustand dem neuen gewünschten Zustand zuordnen.
- Migrieren
- Durchführung der Schema-, Daten- und Codemigration.
- Extrahieren von Daten aus der Quelle.
- Schemakonvertierung (DDL)
- Datenerfassung
- Migration von Datenbankcode (DML).
- Skalieren Sie bei Bedarf die dedizierten SQL-Poolressourcen vorübergehend, um die Migrationsgeschwindigkeit zu beschleunigen.
- Sicherheit und -Berechtigungen anwenden.
- Migrieren bestehender ETL/ELT-Prozesse für inkrementelles Laden.
- Migrieren oder Umgestalten von ETL/ELT-Prozessen für inkrementelles Laden
- Testen und vergleichen paralleler inkrementelle Ladeprozesse.
- Detailmigrationsplan nach Bedarf anpassen.
- Durchführung der Schema-, Daten- und Codemigration.
- Überwachen und Verwalten
- Parallel ausführen, mit Ihrer Quellumgebung vergleichen.
- Anwendungen, Business Intelligence-Plattformen und Abfragetools testen.
- Erstellen von Benchmarks für die Abfrageleistung und Optimieren derselben
- Überwachen und Verwalten von Kosten, Sicherheit und Leistung.
- Bewertung des Vergleichstests und Governance.
- Parallel ausführen, mit Ihrer Quellumgebung vergleichen.
- Optimieren und Modernisieren
- Wenn das Unternehmen komfortabel ist, übertragen Sie Anwendungen und primäre Berichterstellungsplattformen auf Fabric.
- Skalieren Sie Ressourcen nach oben/unten, da sich die Arbeitsauslastung von Azure Synapse Analytics zu Microsoft Fabric verschiebt.
- Erstellen Sie aus den gewonnenen Erfahrungen eine wiederholbare Vorlage für zukünftige Migrationen. Iterieren
- Identifizieren von Möglichkeiten für Kostenoptimierung, Sicherheit, Skalierbarkeit und operative Exzellenz
- Identifizieren Sie Möglichkeiten, Ihren Datenbestand mit den neuesten Fabric-Funktionen zu modernisieren.
- Wenn das Unternehmen komfortabel ist, übertragen Sie Anwendungen und primäre Berichterstellungsplattformen auf Fabric.
„Lift & Shift“ oder modernisieren?
Unabhängig von Zweck und Umfang der geplanten Migration gibt es im Allgemeinen zwei Typen von Migrationsszenarien: eine unveränderte Migration (Lift and Shift) oder einen phasenweisen Ansatz, der Architektur- und Codeänderungen einbindet.
Lift & Shift
Bei einer Lift-and-Shift-Migration wird ein vorhandenes Datenmodell mit geringfügigen Änderungen in das neue Fabric Warehouse migriert. Dieser Ansatz minimiert die Risiken und den Zeitaufwand für die Migration, indem er den neuen Aufwand reduziert, der erforderlich ist, um die Vorteile der Migration zu nutzen.
Lift-and-Shift-Migration eignet sich gut für diese Szenarien:
- Sie haben eine bestehende Umgebung mit einer kleinen Anzahl von zu migrierenden Data Marts.
- Sie haben eine vorhandene Umgebung mit Daten, die sich bereits in einem gut gestalteten Stern- oder Schneeflockenschema befinden.
- Sie sind unter Zeit- und Kostendruck, um in Fabric Warehouse zu wechseln.
Zusammenfassend funktioniert dieser Ansatz gut für die Workloads, die mit Ihrer aktuellen dedizierten Synapse SQL-Pools-Umgebung optimiert sind, und erfordert daher keine großen Änderungen in Fabric.
Modernisieren in einem phasenweisen Ansatz mit Architekturänderungen
Wenn ein Legacy-Data Warehouse über einen längeren Zeitraum weiterentwickelt wurde, müssen Sie es möglicherweise umstrukturieren, um die erforderlichen Leistungsstufen beibehalten zu können.
Möglicherweise möchten Sie auch die Architektur neu gestalten, um die neuen Engines und Features zu nutzen, die im Fabric-Arbeitsbereich verfügbar sind.
Unterschiede im Design: Dedizierte SQL-Pools von Synapse und Fabric Warehouse
Betrachten Sie die folgenden Unterschiede zwischen Azure Synapse und Microsoft Fabric Data Warehouse, wobei dedizierte SQL-Pools mit dem Fabric Warehouse verglichen werden.
Überlegungen zu Tabellen
Wenn Sie Tabellen zwischen verschiedenen Umgebungen migrieren, werden normalerweise nur die Rohdaten und die Metadaten physisch migriert. Andere Datenbankelemente aus dem Quellsystem, wie z. B. Indizes, werden in der Regel nicht migriert, weil sie in der neuen Umgebung möglicherweise nicht benötigt oder anders implementiert werden.
Leistungsoptimierungen in der Quellumgebung, wie z. B. Indizes, zeigen an, wo Sie in einer neuen Umgebung Leistungsoptimierungen hinzufügen könnten. Jetzt kümmert sich Fabric automatisch darum.
T-SQL-Überlegungen
Es gibt mehrere Syntaxunterschiede bei der Datenbearbeitungssprache (Data Manipulation Language, DML), die zu beachten sind. Weitere Informationen finden Sie unter T-SQL-Oberflächenbereich in Microsoft Fabric. Erwägen Sie auch eine Codebewertung, wenn Sie Methoden der Migration für den Datenbankcode (DML) auswählen.
Je nach den Paritätsunterschieden zum Zeitpunkt der Migration müssen Sie möglicherweise Teile Ihres T-SQL DML-Codes neu schreiben.
Unterschiede bei der Datentypzuordnung
Es gibt mehrere Datentypunterschiede in Fabric Warehouse. Weitere Informationen finden Sie unter Datentypen in Microsoft Fabric.
Die folgende Tabelle enthält die Zuordnung unterstützter Datentypen aus Synapse dedizierten SQL-Pools zu Fabric Warehouse.
Synapse dedizierte SQL-Pools | Fabric Warehouse |
---|---|
money |
decimal(19,4) |
smallmoney |
decimal(10,4) |
smalldatetime |
datetime2 |
datetime |
datetime2 |
nchar |
char |
nvarchar |
varchar |
tinyint |
smallint |
binary |
varbinary |
datetimeoffset * |
datetime2 |
* Datetime2
speichert nicht die zusätzlichen Offsetinformationen für Zeitzonen, die gespeichert sind. Da der Datentyp datetimeoffset
derzeit in Fabric Warehouse nicht unterstützt wird, müssen die Zeitzonenoffsetdaten in eine separate Spalte extrahiert werden.
Tipp
Bereit zum Migrieren?
Informationen zu den ersten Schritten mit einer automatisierten Migrationserfahrung finden Sie im Fabric-Migrations-Assistenten für Data Warehouse.
Weitere manuelle Migrationsschritte und Details finden Sie unter Migration Methoden fürdedizierte SQL-Pools für Azure Synapse Analytics zu Fabric Data Warehouse.