Phase 1: Migrationsstrategie und -planung

Dieser Artikel ist Phase 1 von 4 in der Serie der bewährten Methoden zur Migration von Azure Synapse Spark zu Microsoft Fabric.

Beginnen Sie hier, bevor Sie Notizbücher, Spark-Auftragsdefinitionen, Pools oder Lake-Metadaten migrieren. In diesem Artikel können Sie den Umfang Ihres Synapse Spark-Bestandes bewerten, einen Migrationsansatz auswählen, der Ihrer Risikotoleranz und der Übermittlungszeitachse entspricht und die Unterschiede der Fabric verstehen, die sich auf die Planung auswirken können.

Am Ende dieses Schritts sollten Sie wissen, was verschoben werden muss, welches Migrationsmuster verwendet werden muss, wo die hauptkompatibilitätsrisiken sind und welche Rollback- oder parallelen Einschränkungen Sie berücksichtigen müssen.

In diesem Artikel erfahren Sie, wie Sie:

• Bewerten Sie Ihren Synapse Spark-Fußabdruck.
• Wählen Sie zwischen Lift-and-Shift, phasenweiser Modernisierung und Parallelbetrieb.
• Berücksichtigen Sie Rollback- und Synchronisierungseinschränkungen.
• Überprüfen Sie wichtige Features und Architekturunterschiede zwischen Synapse Spark und Fabric Spark.

Bewerten Sie Ihren Synapse Spark-Fußabdruck

Azure Synapse Analytics umfasst mehrere Workloadtypen. Dieser Leitfaden konzentriert sich auf die Migration von Spark-Pools, Notizbüchern, Spark-Auftragsdefinitionen, Lake-Datenbanken und Hive-Metastore-Metadaten zu Microsoft Fabric. Informationen zu dedizierten SQL-Pools, Pipeline-, Data Explorer- und Sicherheitsmigrationsanleitungen finden Sie in den Begleithandbüchern.

Führen Sie das Fabric-Bewertungstool aus

Führen Sie vor der Planung der Migration das Fabric Bewertungstool aus, um einen umfassenden Bericht ihres Synapse-Quellarbeitsbereichs zu generieren. Das Tool überprüft Ihren Arbeitsbereich und aggregiert eine Zusammenfassung aller Objekte – Spark Pools, Notizbücher, Spark-Auftragsdefinitionen, Lake-Datenbanken, verknüpfte Dienste und deren Konfigurationen – und bietet Ihnen ein klares Bild des Migrationsumfangs.

1. Laden Sie das Tool herunter. Das Fabric Bewertungstool ist in der Microsoft fabric-Toolbox GitHub Repository unter microsoft/fabric-toolbox verfügbar.

2. Führen Sie die Bewertung aus. Zeigen Sie das Tool auf Ihren Azure Synapse Arbeitsbereich. Es überprüft alle Spark-bezogenen Elemente und erzeugt einen Bericht mit Objektanzahl, Konfigurationen, Abhängigkeiten und potenziellen Kompatibilitätsproblemen.

3. Überprüfen Sie den Bericht. Verwenden Sie die Bewertungsausgabe, um den Umfang Ihrer Migration zu verstehen: Wie viele Notizbücher, Pools, SJDs und Datenbanken migriert werden müssen, welche verknüpften Dienste verwendet werden, und welche potenziellen Blocker vorhanden sind (GPU-Pools, nicht unterstützte Features und andere).

Migrationsmuster

Wählen Sie Ihr Migrationsmuster basierend auf Ihren Organisationseinschränkungen, Risikotoleranz und Zeitachse aus.

Lift-and-Shift-Muster

Migrieren Sie alle Spark-Workloads gleichzeitig mithilfe der Migration Assistant mit minimalen Änderungen. Konzentrieren Sie sich darauf, Notizbücher und Aufträge in Fabric so schnell wie möglich auszuführen – refaktorieren Sie nur das, was fehlschlägt (verknüpfte Dienste, Dateipfade, nicht unterstützte APIs). Übernehmen Sie die aktuelle Architektur as-is.

Verwenden Sie das Lift-and-Shift-Modell, wenn:

• Ihr Synapse-Arbeitsbereich wird an einem festen Stichtag außer Betrieb genommen, und Sie müssen schnell gehen.
• Ihre Spark-Workloads sind bereits gut konzipiert (Delta-first, sauberer Code, wenige verknüpfte Dienstabhängigkeiten).
• Ihr Arbeitsbereich-Footprint ist für eine einmalige Migration verwaltbar, und Ihr Team kann den Refactoring-Aufwand in einem einzelnen Sprint bewältigen.
• Downstream-Consumer (Power BI, APIs) können ein kurzes Switchoverfenster tolerieren.

Phasenweise Modernisierung

Migrieren Sie Workloads inkrementell nach Priorität und gestalten Sie diese während des Prozesses neu. Beginnen Sie zuerst mit den Arbeitslasten mit dem höchsten Wert oder mit dem niedrigsten Risiko. Wenn Sie jede Charge migrieren, konsolidieren Sie die Spark-Pools in weniger Umgebungen, übernehmen Sie die Lakehouse-Best Practices (Delta-First, V-Order für BI-Konsumenten), aktivieren Sie NEE und gestalten Sie für Direct Lake neu.

Phasenweise Modernisierung verwenden, wenn:

• Sie haben eine große oder komplexe Synapse-Umgebung mit mehreren Teams und verschiedenen Workloads, die nicht in einem Einzigen Schritt migriert werden können.
• Ihre aktuelle Architektur verfügt über technische Schulden, die Sie adressieren möchten (Nicht-Delta-Formate, Mount-Point-Abhängigkeiten, verzweigende Sparkpools).
• Sie haben Flexibilität auf der Zeitachse und möchten die Leistung und Kosteneffizienz während der Migration verbessern.
• Unterschiedliche Workloads haben unterschiedliche Besitzer und benötigen unabhängige Migrationszeitpläne.

Muster für parallele Ausführung

Führen Sie beide Umgebungen während des Übergangs gleichzeitig aus. Leiten Sie neue Spark-Arbeitslasten an Fabric weiter, während ältere Workloads weiterhin auf Synapse ausgeführt werden. Überprüfen Sie migrierte Arbeitslasten, indem Sie die Ergebnisse nebeneinander vergleichen, bevor Sie sie überschneiden. Synapse schrittweise außer Betrieb nehmen, während das Vertrauen wächst.

Verwenden Sie eine parallele Ausführung, wenn:

• Ihre Workloads unterliegen strengen SLAs oder behördlichen Anforderungen, die eine ausführliche Prüfung vor dem Übergang erfordern.
• Bevor die Projektbeteiligten die Außerbetriebnahme genehmigen, müssen Sie nachweisen, dass die Leistung von Fabric der von Synapse entspricht oder sie übertrifft.
• Ihre nachgeschalteten Verbraucher (Dashboards, APIs, ML-Modelle) können während des Übergangs keine Abweichungen tolerieren.
• Sie migrieren Produktionspipelinen, bei denen falsche Ergebnisse einen hohen Geschäftseffekt haben (Finanzberichterstattung, Compliance).

Parallele Ausführung führt zu einem Problem mit der Datensynchronisierung, das Sie im Vorfeld entwerfen müssen. Wählen Sie eines der folgenden Muster aus:

• Gemeinsame Speicherstruktur: Ermöglichen Sie sowohl Synapse als auch Fabric den Lese- und Schreibzugriff auf denselben ADLS Gen2-Speicher durch OneLake-Verknüpfungen. Dadurch werden beide Plattformen auf denselben Delta-Dateien beibehalten. Sie müssen jedoch Schreibkonflikte verhindern, indem Sie sicherstellen, dass jeweils nur eine Plattform in eine bestimmte Tabelle schreibt.
• Write-once, read-both: Lassen Sie Synapse während des Übergangs als primären Schreiber beibehalten und Fabric die gleichen Daten über Direktzugriffe lesen. Nachdem Sie die migrierten Notizbücher in Fabric überprüft haben, wechseln Sie den Schreibpfad zu Fabric, und setzen Sie Synapse auf einen schreibgeschützten Verbraucher, bis zur Außerbetriebnahme. Dies ist die sicherste Option für die meisten Migrationen.
• Dual-Write: Vermeiden Sie die gleichzeitige Ausführung derselben ETL in beiden Umgebungen, es sei denn, Sie verfügen bereits über automatisierte Vergleichs- und Abstimmungstools. Bei dualen Schreibvorgängen entsteht tendenziell Divergenz, Duplizierung und Betriebsaufwand.

Die parallele Ausführung wirkt sich auch auf das Änderungsmanagement aus. Während Synapse die aktive Entwicklungsumgebung bleibt, werden alle in Synapse vorgenommenen Änderungen des Notizbuchs, der Spark-Auftragsdefinition, der Spark-Poolkonfiguration oder der Datenbankschemaänderungen, die in Synapse vorgenommen wurden, nicht automatisch in Fabric angezeigt. Sie müssen die betroffenen Assets erneut migrieren, um beide Umgebungen synchron zu halten.

• Notebook-Codeänderungen: Führen Sie den Spark-Migrationsassistent erneut aus, oder exportieren Sie die aktualisierten Notizbücher manuell erneut und importieren Sie sie. Erneutes Anwenden Fabric-spezifischer Code-Refactorings, einschließlich notebookutils, Dateipfadaktualisierungen und Key Vault Secrets.
• Spark Auftragsdefinitionsänderungen: Erneute Migration über den Migrationsassistenten oder manuelles Neuerstellen der aktualisierten SJDs in Fabric.
• Spark-Poolkonfigurationsänderungen: Aktualisieren Sie die entsprechende Fabric-Umgebung, um mit der überarbeiteten Knotengröße, den Bibliotheken und den Autoskalierungseinstellungen übereinzustimmen.
• Lake-Datenbankschemaänderungen: Führen Sie die HMS-Export-/Import-Notebooks erneut aus, oder erstellen oder ändern Sie die betroffenen Tabellen im Fabric Lakehouse manuell.

Um den Mehraufwand für die erneute Migration zu verringern, richten Sie eine Änderungssperre auf der Synapse-Seite ein, sobald die Migration beginnt. Wenn Änderungen unvermeidbar sind, behalten Sie ein Änderungsprotokoll bei, damit Sie sie vor der Übernahme in Fabric wiedergeben können.

Überlegungen zum Rollback

Synapse-to-Fabric Migration ist ein Kopiervorgang – sie ändert oder löscht den Synapse-Quellarbeitsbereich nicht. Ihre ursprünglichen Spark-Pools, -Notizbücher und -Daten bleiben während des gesamten Prozesses erhalten. Dadurch wird ein Rollback unkompliziert:

• Wenn die Migrationsergebnisse nicht zufriedenstellend sind, verwenden Sie weiterhin Ihren vorhandenen Synapse-Arbeitsbereich. Es müssen keine Änderungen zurückgesetzt werden.
• Löschen Sie die migrierten Fabric Artefakte (Notizbücher, Umgebungen, Spark-Auftragsdefinitionen), und versuchen Sie es erneut, nachdem Sie Probleme behoben haben.
• OneLake-Tastenkombinationen verweisen auf Ihren vorhandenen ADLS Gen2-Speicher – das Entfernen von Verknüpfungen wirkt sich nicht auf die zugrunde liegenden Daten aus.
• Beenden Sie Ihren Synapse-Workspace erst, wenn alle migrierten Workloads in Fabric validiert wurden und die nachgeschalteten Nutzer umgeleitet sind.

Funktionsparität und wichtige Unterschiede

Das Verständnis der architektonischen Unterschiede zwischen Synapse und Fabric ist für die Planung von entscheidender Bedeutung. In den folgenden Tabellen werden wichtige Unterschiede bei der Berechnungsarchitektur und spark-Funktionen hervorgehoben.

Den vollständigen Vergleich finden Sie unter Compare Fabric und Azure Synapse Spark: Key Differences.

Berechnen und Architektur

Spark: Synapse Spark vs. Fabric Spark

Verwandte Inhalte

• Phase 1: Migrationsstrategie und -planung
• Phase 2: Spark workload migration
• Phase 3: Hive-Metastore und Datenmigration
• Phase 4: Sicherheits- und Governancemigration