Fase 1: Migrasjonsstrategi og planlegging

Denne artikkelen er fase 1 av 4 i Azure Synapse Spark til Microsoft Fabric migreringsbeste praksis-serien.

Start her før du migrerer noen notatbøker, Spark-jobbdefinisjoner, pooler eller lake-metadata. Denne artikkelen hjelper deg med å vurdere omfanget av din Synapse Spark-eiendom, velge en migreringsmetode som passer din risikotoleranse og leveringstid, og forstå forskjellene i Fabric som påvirker planleggingen.

Ved slutten av dette steget bør du vite hva som må flyttes, hvilket migrasjonsmønster du skal bruke, hvor de største kompatibilitetsrisikoene ligger, og hvilke rollback- eller parallellkjøringsbegrensninger du må ta hensyn til.

I denne artikkelen lærer du hvordan du:

• Vurder ditt Synapse Spark-fotavtrykk.
• Velg mellom løft-og-skift, fasebasert modernisering og parallellkjøring.
• Ta hensyn til tilbakerullings- og synkroniseringsbegrensninger.
• Gå gjennom viktige funksjons- og arkitekturforskjeller mellom Synapse Spark og Fabric Spark.

Vurder ditt Synapse Spark-fotavtrykk

Azure Synapse Analytics omfatter flere workload-typer. Denne guiden fokuserer på å migrere Spark-pooler, notatbøker, Spark-jobbdefinisjoner, lake-databaser og Hive Metastore-metadata til Microsoft Fabric. For dedikert veiledning om SQL-pool, pipeline, Data Explorer og sikkerhetsmigrering, se tilhørende veiledninger.

Kjør Fabric Assessment Tool

Før du planlegger migreringen, kjør Fabric Assessment Tool for å generere en omfattende rapport over Synapse-kildearbeidsområdet ditt. Verktøyet skanner arbeidsområdet ditt og samler en oppsummering av alle objekter — Spark-pooler, notatbøker, Spark-jobbdefinisjoner, lake-databaser, tilknyttede tjenester og deres konfigurasjoner — noe som gir deg et klart bilde av migreringsomfanget.

1. Last ned verktøyet. Fabric Assessment Tool er tilgjengelig i Microsoft fabric-toolbox GitHub-repositoriet på microsoft/fabric-toolbox.

2. Kjør vurderingen. Pek verktyget mot ditt Azure Synapse workspace. Den skanner alle Spark-relaterte elementer og lager en rapport med antall objekter, konfigurasjoner, avhengigheter og potensielle kompatibilitetsproblemer.

3. Se gjennom rapporten. Bruk vurderingsresultatet for å forstå omfanget av migreringen din: hvor mange notatbøker, pooler, SJD-er og databaser som må migreres, hvilke koblede tjenester som er i bruk, og hvilke potensielle blokkere som finnes (GPU-pooler, ikke-støttede funksjoner og andre).

Migrasjonsmønstre

Velg ditt migrasjonsmønster basert på organisatoriske begrensninger, risikotoleranse og tidslinje.

Løft-og-skift-mønster

Migrer alle Spark-arbeidsbelastninger samtidig ved hjelp av Migration Assistant med minimale endringer. Fokuser på å få notatbøker og jobber til å kjøre i Fabric så raskt som mulig — refaktorere kun det som går i stykker (lenkede tjenester, filstier, ustøttede API-er). Aksepterer den nåværende arkitekturen as-is.

Bruk løft-og-skift når:

• Arbeidsområdet ditt i Synapse blir avviklet med en fast tidsfrist, og du må handle raskt.
• Dine Spark-arbeidsbelastninger er allerede godt arkitektonert (Delta-først, ren kode, få lenkede tjenesteavhengigheter).
• Arbeidsplassen din er håndterbar for en engangsmigrering, og teamet ditt kan håndtere refaktoreringsarbeidet i én sprint.
• Nedstrømsbrukere (Power BI, API-er) tåler et kort overgangsvindu.

Fasevis modernisering

Migrer arbeidsbelastninger trinnvis etter prioritet, og omstrukturer underveis. Start med arbeidsbelastningene med høyest verdi eller minst risiko først. Når du migrerer hver batch, konsolider Spark-pooler til færre miljøer, ta i bruk Lakehouse beste praksis (Delta-først, V-Order for BI-forbrukere), aktiver NEE, og redesign for Direct Lake.

Bruk trinnvis modernisering når:

• Du har et stort eller komplekst Synapse-miljø med flere team og ulike arbeidsbelastninger som ikke kan migreres på én gang.
• Din nåværende arkitektur har teknisk gjeld du vil ta tak i (ikke-Delta-formater, mount-point-avhengigheter, omfattende Spark-pooler).
• Du har fleksibilitet i tidsplanen og ønsker å forbedre ytelse og kostnadseffektivitet under migreringen.
• Ulike arbeidsbelastninger har forskjellige eiere og krever uavhengige migreringsplaner.

Parallelkjøringsmønster

Kjør begge miljøene samtidig under overgangen. Rute nye Spark-arbeidsbelastninger til Fabric mens eldre arbeidsbelastninger fortsetter på Synapse. Valider migrerte arbeidsbelastninger ved å sammenligne resultater side om side før du kutter over. Gradvis avvikle Synapse etter hvert som selvtilliten vokser.

Bruk en parallellkjøring når:

• Arbeidsbelastningene dine har strenge SLA-er eller regulatoriske krav som krever utvidet validering før cutover.
• Du må bevise at Fabric-ytelsen oppfyller eller overgår Synapse før interessenter godkjenner avvikling.
• Dine nedstrømsforbrukere (dashbord, API-er, ML-modeller) tåler ikke noen avvik under overgangen.
• Du migrerer produksjonspipelines hvor feil resultater har stor forretningseffekt (finansiell rapportering, etterlevelse).

Parallellkjøring introduserer et datasynkroniseringsproblem som du må designe for på forhånd. Velg ett av disse mønstrene:

• Delt lagringslag: Ha både Synapse og Fabric lese og skrive til samme ADLS Gen2-lagring via OneLake-snarveier. Dette holder begge plattformene på de samme Delta-filene, men du må forhindre skrivekonflikter ved å sørge for at kun én plattform skriver til en gitt tabell om gangen.
• Write-once, read-both: Behold Synapse som hovedskriver under overgangen og la Fabric lese de samme dataene via snarveier. Etter at du har validert de migrerte notatbøkene i Fabric, bytt skrive-til-stien til Fabric og gjør Synapse til den skrivebeskyttede forbrukeren til den tas ut av drift. Dette er det tryggeste alternativet for de fleste migrasjoner.
• Dobbeltskriving: Unngå å kjøre samme ETL i begge miljøer samtidig med mindre du allerede har automatisert sammenlignings- og avstemmingsverktøy. Dobbeltskriving har en tendens til å skape divergens, duplisering og operasjonell overhead.

Parallellkjøring påvirker også endringshåndtering. Selv om Synapse fortsatt er det aktive utviklingsmiljøet, reflekteres ikke endringer i notatbok, Spark-jobbdefinisjon, Spark-poolkonfigurasjon eller endringer i lake-databaseskjemaer gjort i Synapse automatisk i Fabric. Du må remigrere de berørte ressursene for å holde begge miljøene på linje.

• Notebook kodeendringer: Kjør Spark Migration Assistant på nytt eller eksporter og importer de oppdaterte notatbøkene manuelt. Gjenoppfør all Fabric-spesifikk koderefaktorering, inkludert notebookutils, filstioppdateringer og Key Vault hemmeligheter.
• Spark-jobbdefinisjonsendringer: Migrer gjennom Migration Assistant på nytt eller gjenopprett de oppdaterte SJD-ene manuelt i Fabric.
• Spark-poolkonfigurasjonsendringer: Oppdater det tilsvarende Fabric-miljøet for å matche den reviderte nodestørrelsen, autoskaleringsinnstillingene og bibliotekene.
• Lake databaseskjema-endringer: Kjør HMS eksport/import notatbøker på nytt, eller lag eller endre de berørte tabellene manuelt i Fabric lakehouse.

For å redusere remigrasjonskostnader, innfør en endringsfrys på Synapse-siden når migrasjonen begynner. Hvis endringer er uunngåelige, før en endringslogg slik at du kan spille dem om igjen i Fabric før cutover.

Tilbakerullingsvurderinger

Migrasjon fra Synapse til Fabric er en kopieringsoperasjon — den endrer eller sletter ikke kilde-Synapse-arbeidsområdet ditt. Dine opprinnelige Spark-pooler, notatbøker og data forblir intakte gjennom hele prosessen. Dette gjør rollback enkelt:

• Hvis migreringsresultatene ikke er tilfredsstillende, fortsett å bruke ditt eksisterende Synapse-arbeidsområde. Ingen endringer trenger å reverseres.
• Slett de migrerte Fabric-artefaktene (notatbøker, miljøer, Spark-jobbdefinisjoner) og prøv på nytt etter å ha løst problemene.
• OneLake-snarveier peker til din eksisterende ADLS Gen2-lagring — fjerning av snarveier påvirker ikke de underliggende dataene.
• Ikke deaktiver Synapse-arbeidsområdet før alle migrerte arbeidsmengder er validert i Fabric og nedstrømsbrukere er omdirigert.

Funksjonsparitet og viktige forskjeller

Å forstå de arkitektoniske forskjellene mellom Synapse og Fabric er avgjørende for planleggingen. Følgende tabeller fremhever viktige forskjeller i beregningsarkitektur og Spark-kapasiteter.

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

Beregning og arkitektur

Spark: Synapse Spark vs. Fabric Spark

Relatert innhold

• Fase 1: Migrasjonsstrategi og planlegging
• Fase 2: Spark-arbeidsbelastningsmigrering
• Fase 3: Hive Metastore og datamigrering
• Fase 4: Sikkerhets- og styringsmigrasjon