Fase 1: Migrationsstrategi og planlægning

Denne artikel er fase 1 af 4 i Azure Synapse Spark to Microsoft Fabric migration best practices-serien.

Start her, før du migrerer nogen notesbøger, Spark-jobdefinitioner, pools eller sømetadata. Denne artikel hjælper dig med at vurdere omfanget af din Synapse Spark-ejendom, vælge en migrationsmetode, der matcher din risikotolerance og leveringstid, og forstå de forskelle i Fabric, der påvirker planlægningen.

Ved slutningen af dette trin bør du vide, hvad der skal flyttes, hvilket migrationsmønster du skal bruge, hvor de største kompatibilitetsrisici er, og hvilke rollback- eller parallel-run-begrænsninger du skal tage højde for.

I denne artikel lærer du, hvordan du:

• Vurder dit Synapse Spark-fodaftryk.
• Vælg mellem lift-and-shift, faseopdelt modernisering og parallelkørsel.
• Tag højde for rollback- og synkroniseringsbegrænsninger.
• Gennemgå vigtige forskelle i funktioner og arkitektur mellem Synapse Spark og Fabric Spark.

Vurder dit Synapse Spark-fodaftryk

Azure Synapse Analytics omfatter flere workload-typer. Denne guide fokuserer på at migrere Spark-pools, notebooks, Spark-jobdefinitioner, lake-databaser og Hive Metastore-metadata til Microsoft Fabric. For dedikeret vejledning om SQL pool, pipeline, Data Explorer og sikkerhedsmigrering, se ledsagende vejledninger.

Kør Fabric Assessment Tool

Før du planlægger din migration, skal du køre Fabric Assessment Tool for at generere en omfattende rapport over dit Synapse-kilde-arbejdsområde. Værktøjet scanner dit arbejdsområde og samler et resumé af alle objekter — Spark-pools, notesbøger, Spark-jobdefinitioner, lake-databaser, linked services og deres konfigurationer — hvilket giver dig et klart billede af migrationsområdet.

1. Download værktøjet. Fabric Assessment Tool er tilgængeligt i Microsoft fabric-toolbox GitHub-arkivet på microsoft/fabric-toolbox.

2. Kør vurderingen. Peg værktøjet på din Azure Synapse workspace. Den scanner alle Spark-relaterede elementer og udarbejder en rapport med objektantal, konfigurationer, afhængigheder og potentielle kompatibilitetsproblemer.

3. Gennemse rapporten. Brug vurderingsoutputtet til at forstå omfanget af din migration: hvor mange notebooks, pools, SJD'er og databaser der skal migreres, hvilke linkede tjenester der er i brug, og hvilke potentielle blokeringer der findes (GPU-pools, ikke-understøttede funktioner og andre).

Migrationsmønstre

Vælg dit migrationsmønster baseret på dine organisatoriske begrænsninger, risikotolerance og tidsplan.

Lift-and-shift-mønster

Migrer alle Spark-arbejdsbelastninger på én gang ved hjælp af Migration Assistant med minimale ændringer. Fokuser på at få notebooks og jobs kørende i Fabric så hurtigt som muligt — refaktorere kun det, der går i stykker (linked services, filstier, ikke-understøttede API'er). Accepter den nuværende arkitektur as-is.

Brug lift-and-shift når:

• Dit Synapse-arbejdsområde bliver nedlagt med en fast deadline, og du skal handle hurtigt.
• Dine Spark-arbejdsbelastninger er allerede velarkitekterede (Delta-first, ren kode, få linkede serviceafhængigheder).
• Dit arbejdspladsareal er håndterbart til en enkelt-gangs migrering, og dit team kan håndtere refaktoreringen i en enkelt sprint.
• Nedstrømsforbrugere (Power BI, API'er) kan tåle et kort skiftevindue.

Faseopdelt modernisering

Migrer arbejdsbelastninger gradvist efter prioritet, og omarkitektér undervejs. Start med de arbejdsbelastninger med den højeste eller mindst risiko først. Når du migrerer hver batch, konsoliderer du Spark-pools til færre miljøer, adopterer Lakehouse bedste praksis (Delta-first, V-Order for BI-forbrugere), aktiverer NEE og redesigner for Direct Lake.

Brug faseopdelt modernisering når:

• Du har et stort eller komplekst Synapse-miljø med flere teams og forskellige arbejdsbelastninger, som ikke kan migreres på én gang.
• Din nuværende arkitektur har teknisk gæld, du vil adressere (ikke-Delta-formater, mount-point-afhængigheder, omfattende Spark-pools).
• Du har fleksibilitet i tidsplanen og ønsker at forbedre ydeevne og omkostningseffektivitet under migreringen.
• Forskellige arbejdsbelastninger har forskellige ejere og kræver uafhængige migrationsplaner.

Parallelkørselsmønster

Kør begge miljøer samtidig under overgangen. Route nye Spark-arbejdsbelastninger til Fabric, mens ældre arbejdsbelastninger fortsætter på Synapse. Valider migrerede arbejdsbelastninger ved at sammenligne resultater side om side, før du skærer over. Gradvist deaktiver Synapse, efterhånden som tilliden vokser.

Brug en parallel kørsel, når:

• Dine arbejdsbelastninger har strenge SLA'er eller regulatoriske krav, der kræver udvidet validering før cutover.
• Du skal bevise, at Fabric-ydeevnen lever op til eller overgår Synapse, før interessenter godkender dekommissionering.
• Dine downstream-forbrugere (dashboards, API'er, ML-modeller) kan ikke tolerere nogen uoverensstemmelse under overgangen.
• Du migrerer produktionspipelines, hvor forkerte resultater har stor forretningsmæssig effekt (finansiel rapportering, compliance).

Parallel run introducerer et datasynkroniseringsproblem, som du skal designe til fra starten. Vælg et af disse mønstre:

• Delt lagerlag: Lad både Synapse og Fabric læse og skrive til samme ADLS Gen2-lager via OneLake-genveje. Dette holder begge platforme på de samme Delta-filer, men du skal forhindre skrivekonflikter ved at sikre, at kun én platform skriver til en given tabel ad gangen.
• Write-once, read-both: Behold Synapse som primær skriver under overgangen og lad Fabric læse de samme data via genveje. Efter du har valideret de migrerede notebooks i Fabric, skifter du write-to-stien til Fabric og gør Synapse til read-only-forbrugeren indtil deaktivering. Dette er den sikreste løsning for de fleste migrationer.
• Dobbeltskrivning: Undgå at køre den samme ETL i begge miljøer samtidig, medmindre du allerede har automatiserede sammenlignings- og afstemningsværktøjer. Dual-write har en tendens til at skabe divergens, duplikation og operationel overhead.

Parallel run påvirker også forandringsstyring. Selvom Synapse forbliver det aktive udviklingsmiljø, bliver enhver notebook, Spark-jobdefinition, Spark-poolkonfiguration eller lake-databaseskemaændringer foretaget i Synapse ikke automatisk afspejlet i Fabric. Du skal remigrere de berørte aktiver for at holde begge miljøer på linje.

• Notebook kodeændringer: Kør Spark Migration Assistant igen eller eksporter manuelt og importer de opdaterede notebooks. Påfør al Fabric-specifik koderefaktorering, inklusive notebookutils, filsti-opdateringer og Key Vault hemmeligheder.
• Spark jobdefinitionsændringer: Migrer igen gennem Migration Assistant eller genskab manuelt de opdaterede SJD'er i Fabric.
• Spark pool-konfigurationsændringer: Opdater det tilsvarende Fabric-miljø, så det matcher den reviderede nodestørrelse, autoskaleringsindstillinger og biblioteker.
• Lake databaseskemaændringer: Kør HMS eksport/import notesbøger igen, eller opret eller ændr manuelt de berørte tabeller i Fabric lakehouse.

For at reducere remigrationsomkostninger, indfør en ændringsfrysning på Synapse-siden, når migrationen begynder. Hvis ændringer er uundgåelige, så før en ændringslog, så du kan afspille dem igen i Fabric før cutover.

Overvejelser om tilbagerulning

Synapse-til-Fabric-migrering er en kopieringsoperation — den ændrer eller sletter ikke dit kilde-Synapse-arbejdsområde. Dine oprindelige Spark-pools, notesbøger og data forbliver intakte gennem hele processen. Dette gør rollback ligetil:

• Hvis migrationsresultaterne ikke er tilfredsstillende, så fortsæt med at bruge dit eksisterende Synapse-arbejdsområde. Ingen ændringer behøver at blive gendannet.
• Slet de migrerede Fabric-artefakter (notebooks, miljøer, Spark-jobdefinitioner) og prøv igen efter at have løst problemerne.
• OneLake-genveje peger på din eksisterende ADLS Gen2-lagring — fjernelse af genveje påvirker ikke de underliggende data.
• Afvikl ikke dit Synapse-arbejdsområde, før alle migrerede arbejdsbelastninger er valideret i Fabric, og downstream-forbrugere er omdirigeret.

Funktionsparitet og nøgleforskelle

At forstå de arkitektoniske forskelle mellem Synapse og Fabric er afgørende for planlægningen. Følgende tabeller fremhæver væsentlige forskelle i beregningsarkitektur og Spark-kapaciteter.

For den fulde sammenligning, se Sammenlign Fabric og Azure Synapse Spark: Key Differences.

Beregning og arkitektur

Spark: Synapse Spark vs. Fabric Spark

Relateret indhold

• Fase 1: Migrationsstrategi og planlægning
• Fase 2: Spark arbejdsbelastningsmigrering
• Fase 3: Hive Metastore og datamigrering
• Fase 4: Sikkerheds- og governance-migration