Fas 1: Migreringsstrategi och planering

Den här artikeln är fas 1 av 4 i serien om bästa praxis för migrering från Azure Synapse Spark till Microsoft Fabric.

Börja här innan du migrerar notebook-filer, Spark-jobbdefinitioner, pooler eller lakemetadata. Den här artikeln hjälper dig att utvärdera omfattningen av din Synapse Spark-egendom, välja en migreringsmetod som matchar din tidslinje för risktolerans och leverans och förstå de Fabric skillnader som påverkar planeringen.

I slutet av det här steget bör du veta vad som behöver flyttas, vilket migreringsmönster som ska användas, var de största kompatibilitetsriskerna finns och vilka återställnings- eller parallellkörningsbegränsningar du behöver ta hänsyn till.

I den här artikeln lär du dig att:

• Utvärdera ditt Synapse Spark-fotavtryck.
• Välj mellan lift och skift, stegvis modernisering och parallell körning.
• Ta hänsyn till begränsningar för återställning och synkronisering.
• Granska viktiga funktions- och arkitekturskillnader mellan Synapse Spark och Fabric Spark.

Utvärdera ditt Synapse Spark-fotavtryck

Azure Synapse Analytics omfattar flera arbetsbelastningstyper. Den här guiden fokuserar på att migrera Spark-pooler, notebook-filer, Spark-jobbdefinitioner, lakedatabaser och Hive Metastore-metadata till Microsoft Fabric. Vägledning för dedikerad SQL-pool, pipeline, Data Explorer och säkerhetsmigrering finns i tillhörande guider.

Kör utvärderingsverktyget för Fabric

Innan du planerar migreringen kör du Fabric Assessment Tool för att generera en omfattande rapport om din Synapse-källarbetsyta. Verktyget söker igenom din arbetsyta och sammanställer en sammanfattning av alla objekt – Spark-pooler, notebook-filer, Spark-jobbdefinitioner, sjödatabaser, länkade tjänster och deras konfigurationer – vilket ger dig en tydlig bild av migreringsomfånget.

1. Ladda ned verktyget. Fabric Assessment Tool är tillgängligt i Microsoft fabric-toolbox GitHub-repository på microsoft/fabric-toolbox.

2. Kör utvärderingen. Peka verktyget på din Azure Synapse arbetsyta. Den söker igenom alla Spark-relaterade objekt och skapar en rapport med antal objekt, konfigurationer, beroenden och potentiella kompatibilitetsproblem.

3. Granska rapporten. Använd utvärderingsutdata för att förstå migreringens omfattning: hur många notebook-filer, pooler, SJD:er och databaser som behöver migreras, vilka länkade tjänster som används och vilka potentiella blockerare som finns (GPU-pooler, funktioner som inte stöds och andra).

Migreringsmönster

Välj ditt migreringsmönster baserat på organisationens begränsningar, risktolerans och tidslinje.

Lift-and-shift-mönster

Migrera alla Spark-arbetsbelastningar samtidigt med hjälp av Migration Assistant med minimala ändringar. Fokusera på att få notebooks och jobb att köras i Fabric så snabbt som möjligt – omstrukturera endast det som går sönder (länkade tjänster, filsökvägar, API:er som inte stöds). Acceptera den aktuella arkitekturen som den är.

Använd lift-and-shift när:

• Ditt Synapse-arbetsområde avvecklas inom en fast tidsram och du måste agera snabbt.
• Dina Spark-arbetsbelastningar är redan väldefinierade (Delta-first, ren kod, få länkade tjänstberoenden).
• Din arbetsytas fotavtryck är hanterbart för en engångsmigrering och ditt team kan hantera refaktoriseringsarbetet i en enda sprint.
• Nedströmsanvändare (Power BI, API:er) kan tolerera ett kort övergångsfönster.

Stegvis modernisering

Migrera arbetslaster inkrementellt efter prioritet och omdesigna under tiden. Börja med arbetsbelastningar med högst eller lägsta risk först. När du migrerar varje batch konsoliderar du Spark-pooler till färre miljöer, tillämpar Lakehouse-metodtips (Delta-first, V-Order för BI-konsumenter), aktiverar NEE och gör om designen för Direct Lake.

Använd stegvis modernisering när:

• Du har en stor eller komplex Synapse-miljö med flera team och olika arbetsuppgifter som inte kan migreras i ett enda steg.
• Din aktuella arkitektur har tekniska skulder som du vill hantera (icke-Delta-format, monteringspunktsberoenden, spretiga Spark-pooler).
• Du har flexibilitet på tidslinjen och vill förbättra prestanda och kostnadseffektivitet under migreringen.
• Olika arbetsbelastningar har olika ägare och behöver oberoende migreringsscheman.

Mönster för parallell körning

Kör båda miljöerna samtidigt under övergången. Dirigera nya Spark-arbetsbelastningar till Fabric medan äldre arbetsbelastningar fortsätter i Synapse. Verifiera migrerade arbetsbelastningar genom att jämföra resultaten sida vid sida innan du skär över. Inaktivera Synapse gradvis när konfidensen byggs.

Använd en parallell körning när:

• Dina arbetsbelastningar har strikta serviceavtal eller regelkrav som kräver utökad validering före övergång.
• Du måste bevisa att Fabric prestanda uppfyller eller överskrider Synapses innan intressenterna godkänner avvecklingen.
• Dina underordnade konsumenter (instrumentpaneler, API:er, ML-modeller) kan inte tolerera någon avvikelse under övergången.
• Du migrerar produktionslinjer där felaktiga resultat har stor kommersiell påverkan (finansiell rapportering, överensstämmelse).

Parallell körning introducerar ett problem med datasynkronisering som du måste utforma i förväg. Välj något av följande mönster:

• Shared storage layer: Låta både Synapse och Fabric läsa och skriva till samma ADLS Gen2-lagring via OneLake-genvägar. Detta säkerställer att båda plattformarna är synkroniserade med samma Delta-filer, men du måste förhindra skrivkonflikter genom att se till att endast en plattform skriver till en viss tabell åt gången.
• Write-once, read-both: Behåll Synapse som primär författare under övergången och låt Fabric läsa samma data via genvägar. När du har verifierat de migrerade notebook-filerna i Fabric, ändra skrivvägen till Fabric och gör Synapse till en skrivskyddad konsument fram till avvecklingen. Det här är det säkraste alternativet för de flesta migreringar.
• Dubbel skrivning: Undvik att köra samma ETL i båda miljöerna samtidigt om du inte redan har automatiserade jämförelse- och avstämningsverktyg. Dubbelskrivning tenderar att skapa skillnader, duplicering och driftkostnader.

Parallell körning påverkar även ändringshantering. Även om Synapse fortfarande är den aktiva utvecklingsmiljön återspeglas inte alla ändringar i notebook-filer, Spark-jobbdefinitioner, Spark-poolkonfigurationer eller lake-databasscheman som görs i Synapse automatiskt i Fabric. Du måste migrera de berörda resurserna igen för att hålla båda miljöerna synkroniserade.

• Notebook code changes: Kör Spark Migration Assistant igen, eller manuellt exportera och importera om de uppdaterade notebookarna. Tillämpa all Fabric-specifik kodrefaktorisering på nytt, inklusive notebookutils, uppdateringar av filsökvägar och Key Vault-sekretess.
• Förändringar i Spark-jobbdefinitionen: Återmigrera genom Migrationsassistenten eller återskapa manuellt de uppdaterade SJD:erna i Fabric.
• Spark poolkonfigurationsändringar: Uppdatera motsvarande Fabric miljö så att den matchar den ändrade nodstorleken, autoskalningsinställningarna och biblioteken.
• Ändringar i schemastrukturen för databas i Lake: Kör om HMS export-/importanteckningsböckerna, eller skapa eller ändra manuellt de berörda tabellerna i Fabric lakehouse.

Om du vill minska ommigreringskostnaderna upprättar du en ändringsstopp på Synapse-sidan när migreringen påbörjas. Om ändringarna är oundvikliga, behåll en ändringslogg så att du kan spela upp dem i Fabric innan övergången.

Överväganden för återgång

Synapse-to-Fabric-migrering är en kopieringsåtgärd – den ändrar eller tar inte bort din Synapse-källarbetsyta. Dina ursprungliga Spark-pooler, notebook-filer och data förblir intakta under hela processen. Detta gör återställningen enkel:

• Om migreringsresultaten inte är tillfredsställande fortsätter du att använda din befintliga Synapse-arbetsyta. Inga ändringar behöver återställas.
• Ta bort de migrerade Fabric artefakterna (notebook-filer, miljöer, Spark-jobbdefinitioner) och försök igen när du har åtgärdat problem.
• OneLake-genvägar pekar på din befintliga ADLS Gen2-lagring – att ta bort genvägar påverkar inte underliggande data.
• Inaktivera inte Synapse-arbetsytan förrän alla migrerade arbetsbelastningar har verifierats i Fabric och nedströmskonsumenter omdirigeras.

Funktionsparitet och viktiga skillnader

Att förstå arkitekturskillnaderna mellan Synapse och Fabric är viktigt för planeringen. Följande tabeller belyser viktiga skillnader i beräkningsarkitektur och Spark-funktioner.

Fullständig jämförelse finns i Compare Fabric och Azure Synapse Spark: Key Differences.

Beräkning och arkitektur

Spark: Synapse Spark jämfört med Fabric Spark

Relaterat innehåll

• Fas 1: Migreringsstrategi och planering
• Fas 2: Migrering av Spark-arbetsbelastning
• Fas 3: Hive-metaarkiv och datamigrering
• Fas 4: Migrering av säkerhet och styrning