Fase 1: Migratiestrategie en -planning

Dit artikel is fase 1 van de 4 fasen uit de reeks beste praktijken voor de migratie van Azure Synapse Spark naar Microsoft Fabric.

Start hier voordat u notebooks, Spark-taakdefinities, pools ofwel lake-metagegevens migreert. Dit artikel helpt u bij het beoordelen van het bereik van uw Synapse Spark-estate, het kiezen van een migratiebenadering die overeenkomt met uw tijdlijn voor risicotolerantie en levering en inzicht in de Fabric verschillen die van invloed zijn op de planning.

Aan het einde van deze stap moet u weten wat er moet worden verplaatst, welk migratiepatroon moet worden gebruikt, waar de belangrijkste compatibiliteitsrisico's zich bevinden en voor welke beperkingen voor terugdraaien of parallel uitvoeren u rekening moet houden.

In dit artikel leert u het volgende:

• Beoordeel uw Synapse Spark-footprint.
• Kies tussen lift-and-shift, gefaseerde modernisering en parallelle uitvoering.
• Houd rekening met terugdraai- en synchronisatiebeperkingen.
• Bekijk de belangrijkste functie en architectuurverschillen tussen Synapse Spark en Fabric Spark.

Uw Synapse Spark-footprint beoordelen

Azure Synapse Analytics omvat meerdere workloadtypen. Deze handleiding is gericht op het migreren van Spark-pools, notebooks, Spark-taakdefinities, lakedatabases en Hive Metastore-metagegevens naar Microsoft Fabric. Raadpleeg de bijbehorende handleidingen voor toegewezen SQL-pools, pijplijnen, Data Explorer en beveiligingsmigratie.

Het Fabric-evaluatieprogramma uitvoeren

Voordat u de migratie plant, voert u het Fabric Assessment Tool uit om een uitgebreid rapport van uw Synapse-bronwerkruimte te genereren. Het hulpprogramma scant uw werkruimte en voegt een overzicht van alle objecten samen: Spark-pools, notebooks, Spark-taakdefinities, lakedatabases, gekoppelde services en hun configuraties, zodat u een duidelijk beeld krijgt van het migratiebereik.

1. Download het hulpprogramma. Het Fabric Assessment Tool is beschikbaar in de Microsoft fabric-toolbox GitHub-repository bij microsoft/fabric-toolbox.

2. Voer de evaluatie uit. Wijs het hulpprogramma aan bij uw Azure Synapse werkruimte. Het scant alle Spark-gerelateerde items en produceert een rapport met objectaantallen, configuraties, afhankelijkheden en mogelijke compatibiliteitsproblemen.

3. Bekijk het rapport. Gebruik de evaluatie-uitvoer om inzicht te krijgen in het bereik van uw migratie: hoeveel notebooks, pools, SJD's en databases moeten worden gemigreerd, welke gekoppelde services worden gebruikt en welke potentiële obstakels er bestaan (GPU-pools, niet-ondersteunde functies en andere).

Migratiepatronen

Kies uw migratiepatroon op basis van beperkingen van uw organisatie, risicotolerantie en tijdlijn.

Lift-and-shift-patroon

Migreer alle Spark-workloads tegelijk met behulp van de Migration Assistant met minimale wijzigingen. Richt u op het zo snel mogelijk uitvoeren van notebooks en processen in Fabric: herstructureer alleen wat niet werkt (gekoppelde services, bestandspaden, niet-ondersteunde API's). Accepteer de huidige architectuur as-is.

Gebruik lift-and-shift wanneer:

• Uw Synapse-werkruimte wordt buiten gebruik gesteld op een vaste deadline en u moet snel gaan.
• Uw Spark-workloads zijn al goed ontworpen (Delta-first, schone code, enkele gekoppelde serviceafhankelijkheden).
• Uw werkruimtevoetafdruk is beheerbaar voor een eenmalige migratie en uw team kan de herstructurering in één sprint afhandelen.
• Downstreamgebruikers (Power BI, API's) kunnen een kort schakelvenster tolereren.

Gefaseerde modernisering

Werkbelastingen incrementeel migreren op basis van prioriteit, waarbij u de architectuur steeds opnieuw ontwerpt. Begin eerst met de workloads met het hoogste of laagste risico. Wanneer u elke batch migreert, voegt u Spark-pools samen in minder omgevingen, neemt u best practices voor Lakehouse (Delta-first, V-Order voor BI-consumenten) in, schakelt u NEE in en ontwerpt u opnieuw voor Direct Lake.

Gebruik gefaseerde modernisering wanneer:

• U hebt een grote of complexe Synapse-omgeving met meerdere teams en diverse workloads die niet in één shot kunnen worden gemigreerd.
• Uw huidige architectuur heeft technische schulden die u wilt aanpakken (niet-Delta-indelingen, koppelpuntafhankelijkheden, sprawling Spark-pools).
• U hebt flexibiliteit op de tijdlijn en wilt de prestaties en kostenefficiëntie tijdens de migratie verbeteren.
• Verschillende workloads hebben verschillende eigenaren en hebben onafhankelijke migratieschema's nodig.

Parallelle uitvoering patroon

Beide omgevingen tegelijk uitvoeren tijdens de overgang. Nieuwe Spark-workloads omleiden naar Fabric, terwijl verouderde workloads blijven uitgevoerd op Synapse. Valideer gemigreerde werkbelastingen door resultaten naast elkaar te vergelijken voordat u overstapt. Geleidelijk Synapse uit bedrijf nemen naarmate het vertrouwen groeit.

Gebruik een parallelle uitvoering wanneer:

• Uw workloads hebben strikte SLA's of wettelijke vereisten waarvoor uitgebreide validatie nodig is voordat de cutover plaatsvindt.
• U moet bewijzen dat de prestaties van Fabric voldoen aan of meer dan Synapse zijn voordat belanghebbenden de afbouw goedkeuren.
• Uw downstreamgebruikers (dashboards, API's, ML-modellen) kunnen tijdens de overgang geen discrepanties verdragen.
• U migreert productiepijplijnen waarbij onjuiste resultaten een hoog bedrijfseffect hebben (financiële rapportage, naleving).

Parallel uitvoeren introduceert een probleem met gegevenssynchronisatie dat u vooraf moet ontwerpen. Kies een van deze patronen:

• Gedeelde opslaglaag: Zorg ervoor dat zowel Synapse als Fabric lezen en schrijven naar dezelfde ADLS Gen2-opslag via OneLake-snelkoppelingen. Hierdoor blijven beide platforms op dezelfde Delta-bestanden staan, maar u moet schrijfconflicten voorkomen door ervoor te zorgen dat slechts één platform tegelijkertijd naar een bepaalde tabel schrijft.
• Write-once, read-both: Houd Synapse als de primaire schrijver tijdens de overgang en laat Fabric dezelfde gegevens lezen via snelkoppelingen. Nadat u de gemigreerde notebooks in Fabric hebt gevalideerd, wijzigt u het schrijfpad naar Fabric en maakt u van Synapse een alleen-lezenconsument totdat deze wordt buiten gebruik gesteld. Dit is de veiligste optie voor de meeste migraties.
• Dual-write: Vermijd het uitvoeren van dezelfde ETL in beide omgevingen tegelijkertijd, tenzij u al geautomatiseerde vergelijkings- en afstemmingshulpprogramma's hebt. Dubbele schrijfbewerkingen hebben de neiging om verschillen, duplicatie en operationele overhead te creëren.

Parallelle uitvoering is ook van invloed op wijzigingsbeheer. Hoewel Synapse de actieve ontwikkelomgeving blijft, worden wijzigingen in het schema van een Notebook, Spark-taakdefinitie, Spark-poolconfiguratie of Lake-databaseschema in Synapse niet automatisch doorgevoerd in Fabric. U moet de betrokken assets opnieuw migreren om beide omgevingen op elkaar af te stemmen.

• Notebook-codewijzigingen: Voer de Spark-Migration Assistant opnieuw uit of exporteer de bijgewerkte notitieblokken handmatig opnieuw en importeer deze opnieuw. Pas de Fabric-specifieke codeherstructurering opnieuw toe, waaronder notebookutils, bestandspadwijzigingen en Key Vault geheime sleutels.
• Spark-taakdefinitiewijzigingen: opnieuw migreren via de Migration Assistant of de bijgewerkte SJDs handmatig opnieuw creëren in Fabric.
• Spark-poolconfiguratiewijzigingen: Werk de bijbehorende Fabric-omgeving bij zodat deze overeenkomt met de gewijzigde knooppuntgrootte, instellingen voor automatische schaalaanpassing en bibliotheken.
• Lake-databaseschemawijzigingen: Voer de HMS-export-/importnotebooks opnieuw uit of maak of wijzig handmatig de betrokken tabellen in het Fabric lakehouse.

Als u de overhead voor opnieuw migreren wilt verminderen, moet u een wijzigingsblokkering aan de Synapse-zijde instellen zodra de migratie begint. Als wijzigingen onvermijdelijk zijn, houdt u een wijzigingslogboek bij zodat u deze opnieuw kunt afspelen in Fabric voordat u cutover uitvoert.

Overwegingen voor terugdraaien

Synapse-to-Fabric-migratie is een kopieerbewerking. Uw Synapse-bronwerkruimte wordt niet gewijzigd of verwijderd. Uw oorspronkelijke Spark-pools, -notebooks en -gegevens blijven tijdens het proces intact. Dit maakt terugdraaien eenvoudig:

• Als de migratieresultaten niet tevreden zijn, kunt u uw bestaande Synapse-werkruimte blijven gebruiken. Er hoeven geen wijzigingen te worden teruggezet.
• Verwijder de gemigreerde Fabric artefacten (notebooks, omgevingen, Spark-taakdefinities) en probeer het opnieuw nadat u problemen hebt opgelost.
• OneLake-snelkoppelingen wijzen naar uw bestaande ADLS Gen2-opslag. Het verwijderen van snelkoppelingen heeft geen invloed op de onderliggende gegevens.
• Maak uw Synapse-werkruimte niet buiten gebruik totdat alle gemigreerde workloads zijn gevalideerd in Fabric en downstreamafnemers zijn omgeleid.

Functiepariteit en belangrijke verschillen

Inzicht in de architectuurverschillen tussen Synapse en Fabric is essentieel voor de planning. In de volgende tabellen worden belangrijke verschillen in de rekenarchitectuur en spark-mogelijkheden gemarkeerd.

Zie Compare Fabric en Azure Synapse Spark: Belangrijke verschillen voor de volledige vergelijking.

Compute en architectuur

Spark: Synapse Spark versus Fabric Spark

Verwante inhoud

• Fase 1: Migratiestrategie en -planning
• Fase 2: Migratie van Spark-workload
• Fase 3: Hive-metastore en gegevensmigratie
• Fase 4: Migratie van beveiliging en governance