Fase 2: Spark-arbeidsbelastningsmigrering

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

Bruk denne artikkelen til å migrere dine Spark-arbeidsbelastninger fra Azure Synapse til Fabric. Denne artikkelen omhandler kjøring av Migration Assistant, refaktorering av kodemønstre som ikke kan konverteres automatisk, og migrering av Spark-poolkonfigurasjoner, miljøer og biblioteker.

I denne artikkelen lærer du hvordan du:

• Forstå migreringsarbeidsflyten for standard (ikke-Git) og Git-aktiverte Synapse-arbeidsområder.
• Bruk Spark Migration Assistant for å migrere notatbøker, Spark-jobbdefinisjoner og pooler.
• Refaktorere Synapse-spesifikke kodemønstre for Fabric-kompatibilitet.
• Migrer Spark-poolinnstillinger, miljøer og biblioteker.
• Identifiser og løs bibliotekskompatibilitetsgap mellom Synapse og Fabric.

Migrer med Migration Assistant

Spark Migration Assistant automatiserer migrering av notatbøker, Spark-jobbdefinisjoner, pooler og metadata fra lake-databaser fra Synapse til Fabric. Assistenten kopierer og transformerer elementene dine, men fullfører ikke migreringen—du må fortsatt refaktorere koden, avstemme konfigurasjonshull og validere resultatene.

For trinnvise instruksjoner for å kjøre assistenten, se Spark Synapse to Fabric Spark Migration Assistant (Forhåndsvisning).

Assistenten migrerer følgende elementer:

• Spark pools migreres til Fabric Pools og tilhørende miljøobjekter.
• Notatbøker og tilhørende miljøer migreres.
• Spark-jobbdefinisjoner migreres med tilhørende miljøer.
• Lake-databaser mappes til Fabric-skjemaer; administrerte Delta-tabeller migreres via OneLake-katalogsnarveier.

Standard (ikke-Git) arbeidsområdemigrering

For arbeidsområder hvor notatbøker og SJD-er lagres direkte i Synapse (ikke i et Git-repositorium):

1. Kjør Spark-Migration Assistant fra ditt Fabric arbeidsområde (Migrate>Data engineering items). Velg kilde-Synapse-arbeidsområdet og migrer alle Spark-elementer.

2. Valider avhengigheter mot din mål-Fabric-runtime. Runtime 2.0 er den nyeste GA og standard runtime; test Spark-versjonsforskjeller før du flytter produksjonsarbeidsbelastninger. Hvis notatbøker refererer til andre notatbøker via mssparkutils.notebook.run(), verifiser at disse notatbøkene også ble migrert. Migration Assistant bevarer mappestrukturen (Fabric støtter opptil 10 nivåer med nesting).

3. Refaktorerkode: bytt ut mssparkutils med notebookutils, bytt ut lenkede tjenestereferanser med Fabric Connections, og oppdater filstier. Se avsnittet Refactor Spark-kode for detaljer.

Git-aktivert arbeidsområdemigrering

For arbeidsområder hvor notatbøker og SJD-er lagres i et Azure DevOps- eller GitHub-repositorium, merk at Synapse og Fabric bruker forskjellige Git-serialiseringsformater. Synapse lagrer notatbøker som JSON; Fabric bruker kildeformat .py/.scala eller .ipynb. Du kan ikke peke et Fabric-arbeidsområde direkte mot samme Synapse Git-gren.

1. Migrer gjenstander. Bruk Spark Migration Assistant for å migrere notatbøker og SJD-er fra Synapse-arbeidsområdet til et Fabric-arbeidsområde. Dette konverterer elementer til Fabric-kompatibelt format.

2. Refaktorer-kode. Bruk samme koderefaktorering som i standardscenariet — bytt ut mssparkutils, oppdater filstier, erstatt lenkede tjenester. Se avsnittet Refactor Spark-kode for detaljer.

3. Koble Fabric workspace til Git. Koble Fabric-arbeidsområdet ditt til en ny gren eller mappe i repositoriet ditt (Workspace Settings>Source Control>Git Integration). Bruk en egen gren eller mappe fra Synapse-innholdet ditt for å unngå konflikter. Committer Fabric-arbeidsområdets innhold for å fylle den nye grenen.

4. Sett opp distribusjonspipelines (valgfritt). Konfigurer Fabric distribusjonspipelines (Dev → Test → Prod) for pågående CI/CD. Fabric støtter autobinding for standard innsjøhus og tilknyttede miljøer når man deployerer på tvers av nivåer.

Refaktor-Spark-kode

Etter å ha migrert notatbøkene og Spark-jobbdefinisjonene dine, må du fikse kodemønstre som Migration Assistant ikke kan konvertere automatisk. Denne delen veileder deg gjennom å erstatte Synapse-spesifikke API-er, oppdatere filstier og endre legitimasjonsmønstre for å fungere med Fabric.

Pre-refaktoreringsrevisjon

Før du adresserer individuelle refaktoreringsmønstre, kjør et kodebaseomfattende søk på tvers av alle notatbøker for å identifisere Synapse-spesifikk kode som trenger endringer.

Bruk av filsti

Oppdater Synapse-notatbøker som bruker relative stier eller Synapse-administrerte lagringsstier til å bruke direkte abfss:// stier eller OneLake-stier i Fabric.

Spark Catalog API

Fabric støtter ikke flere spark.catalog metoder. Bytt dem ut med Spark SQL-ekvivalenter.

MSSparkUtils og NotebookUtils

Erstatt mssparkutils kall med Fabric notebookutils ekvivalenter. De vanligste endringene knyttet til kvalifikasjoner er:

I Fabric støttes ikke linked service-basert hemmelig henting (getSecretWithLS). Referer i stedet direkte til Key Vault-URL-en ved å bruke notebookutils.credentials.getSecret(vaultUrl, secretName). Det samme mønsteret gjelder for TokenLibrary.getSecret() kall.

Azure Data Explorer (Kusto) connector

Synapse-notatbøker som kobles til Azure Data Explorer (Kusto) via koblede tjenester må refaktoreres for å bruke direkte endepunktsautentisering.

Bytt ut den tilknyttede tjenesten med et alternativ.accessToken Bruk notebookutils.credentials.getToken() for å hente en token for Kusto-klyngens endepunkt. Resten av spørringsalternativene (kustoDatabase, kustoQuery) forblir uendret.

Cosmos DB-kontakt

Oppdater Azure Cosmos DB-tilkoblinger i Synapse som bruker koblede tjenester eller getSecretWithLS.

Erstatt den lenkede tjenestereferansen med direkte Azure Cosmos DB-endepunktkonfigurasjon. Lagre Azure Cosmos DB-kontonøkkelen i Azure Key Vault og hent den ved å bruke notebookutils.credentials.getSecret(vaultUrl, secretName) i stedet for getSecretWithLS().

Lenkede tjenestereferanser

Bytt ut alle Synapse-lenkede tjenestereferanser i Fabric.

I Fabric finnes det ingen tilknyttede tjenester. Bytt ut Synapse-tokenleverandøren med standard OAuth-klientlegitimasjoner (tjenesteprincipal). Konfigurer fs.azure.account.auth.type, oauth.provider.type, client.id, , client.secretog client.endpoint direkte ved å bruke spark.conf.set().

Tokenbibliotek

Synapses TokenLibrary for å hente tokens og lese linked service-egenskaper er ikke tilgjengelig i Fabric. Bytt det ut med tilsvarende mønstre.

For OAuth-basert ADLS Gen2-tilgang, konfigurer tjenesteprincipal-legitimasjonen direkte ved å bruke spark.conf.set() med lagringskonto-spesifikke nøkler (for eksempel fs.azure.account.auth.type.<account>.dfs.core.windows.net) i stedet for å stole på leverandører av koblede tjenestetoken.

Migrasjon av spark-jobbdefinisjon

Spark-jobbdefinisjoner (SJD-er) er batch-jobbkonfigurasjoner som refererer til en hovedkjørbar fil (.py, .jar, eller .R), valgfrie referansebiblioteker, kommandolinjeargumenter og en lakehouse-kontekst. Selv om Spark Migration Assistant håndterer SJD-migrering automatisk, krever viktige forskjeller mellom Synapse- og Fabric-SJD-er oppmerksomhet.

Viktige forskjeller mellom Synapse og Fabric SJDs

• Kontekst for Lakehouse kreves. I Fabric må hver SJD ha minst ett innsjøhus tilknyttet seg. Dette innsjøhuset fungerer som standard filsystem for Spark-runtime. All kode som bruker relative stier leses og skriver fra standard lakehouse. I Synapse bruker SJD-er arbeidsområdets standardlagring (ADLS Gen2) som standard filsystem.

• Støttede språk. Fabric støtter PySpark (Python), Spark (Scala/Java) og SparkR. .NET for Spark (C#/F#) støttes ikke i Fabric. Du må skrive om disse arbeidslastene i Python eller Scala før migrering.

• Retningslinjer for å prøve på nytt. Fabric SJD-er støtter innebygde retry-policyer, som maks retries og retry-intervall. Denne funksjonen er nyttig for Spark Structured Streaming-jobber som må kjøre på ubestemt tid.

• Miljøbinding. I Synapse binder SJD-er seg til en gnistpool. I Fabric binder SJD-er seg til et miljøobjekt, som inneholder poolkonfigurasjon, biblioteker og Spark-egenskaper. Migration Assistant kartlegger automatisk Synapse pool-referanser til miljøelementer i Fabric.

• Planlegging. Fabric SJD-er har innebygd planlegging (Settings>Schedule) uten å kreve en egen pipeline. I Synapse krever SJD-planlegging en pipeline med en Spark Job-aktivitet. Hvis du har Synapse-pipelines som kun utløser SJD-er, bør du vurdere å bruke Fabric sin innebygde SJD-planlegging i stedet for å migrere pipelinen.

• Import/eksport. Synapse støtter UI-basert JSON-import og -eksport for SJD-er. Fabric støtter ikke UI-import eller -eksport. Bruk Spark Migration Assistant eller Fabric REST API for å opprette eller oppdatere SJD-er programmatisk.

Refaktorere SJD-kode

De samme koderefaktoreringsmønstrene i denne artikkelen gjelder for SJDs hovedfiler. Endringer faller inn i to kategorier.

Endringer i kildekoden (inne i .py, .jar, eller .R hovedfilen):

• Erstatt mssparkutils med notebookutils for legitimasjon og filsystemoperasjoner.
• Oppdater hardkodede filstier i koden til OneLake-stier abfss:// eller snarveistier, når det trengs. SJD-er som kun bruker relative stier mot standard lakehouse, trenger kanskje ikke endringer.
• Erstatt lenkede tjenestereferanser i kode med Key Vault-hemmeligheter eller Fabric Connections.

SJD-konfigurasjonsendringer (i innstillingene for Fabric SJD-elementer):

• Sjekk at ADLS Gen2-baner referert til i hoveddefinisjonsfiler fortsatt er tilgjengelige fra Fabric-arbeidsområdet. Hvis filer ble lagret i Synapse workspace-intern lagring, last dem opp på nytt til Fabric SJD eller flytt dem til en tilgjengelig ADLS Gen2-lokasjon.
• Sjekk at alle referansefiler (.py, .R, .jar) er tilgjengelige etter migrering. Last opp alle filer som var lagret i Synapse arbeidsområde-intern lagring.
• Hvis kommandolinjeargumenter inneholder Synapse-spesifikke stier eller tilkoblingsstrenger, oppdater dem til Fabric-ekvivalenter.

Migrer pooler, miljøer og biblioteker

Etter at notatbøkene og Spark-jobbdefinisjonene dine er migrert, må du bestemme deg for pool- og miljøstrategi. Denne delen forklarer når du kan bruke Fabric Starter Pools (i stedet for å migrere), når du bør lage tilpassede miljøer, og hvordan du identifiserer og løser bibliotekkompatibilitetsgap.

Gnistbassengmigrasjon

Fabric Starter Pools

Fabric Starter Pools gir oppstart av Spark-sesjoner på sekundnivå — en betydelig forbedring sammenlignet med Synapse Spark-pooler, som krever kaldstarter på flere minutter for å starte klynger. Startbassengene er klare til bruk fra plattformen og krever ingen konfigurasjon.

Når skal man opprette en egendefinert pool eller miljø

Opprett en Fabric custom pool og/eller miljø kun når arbeidsmengden din krever:

• En spesifikk nodestørrelse (Liten, Stor, XLarge, XXLarge) som er forskjellig fra standard Medium.
• Egendefinerte biblioteker (pip-pakker, conda-pakker, JAR-er, hjul) som ikke er i Fabric-innebygd runtime.
• Egendefinerte Spark-egenskaper (for eksempel spark.sql.shuffle.partitions, spark.executor.memory) utover standardinnstillingene.
• Administrerte private endepunkter for tilgang til private datakilder (krever egendefinerte pooler).
• En spesifikk Spark-runtime-versjon som er forskjellig fra arbeidsområdets standard.

Konfigurasjon og bibliotekmigrering

Migrer Spark-konfigurasjoner og biblioteker til miljøelementer i Fabric.

For detaljerte steg for å migrere biblioteker til miljøelementer, se Migrate Spark Libraries from Azure Synapse to Fabric.

1. Eksporter Spark-konfigurasjoner. I Synapse Studio, gå til Manage>Spark Pools> velg pool >Configurations + Libraries> last ned som .yml/.conf/.json.

2. Importer til miljøet. I Fabric, lag et miljøobjekt. Gå til Spark Compute>Spark Properties>Last opp den eksporterte Sparkproperties.yml filen.

3. Migrer biblioteker. For pool-nivåbiblioteker, last opp pakker (hjul, JAR, tars) til miljøets biblioteksseksjon. For PyPI/Conda-pakker, legg dem til i miljøets offentlige bibliotekkonfigurasjon.

Bibliotekkompatibilitet: Synapse vs. Fabric

Bruk Runtime 2.0, den nyeste GA og standard runtime, som migreringsmål etter å ha validert arbeidsbelastningskompatibilitet. Sammenlign avhengighetene dine med pakkelageret i Fabric runtime releases-repositoriet.

Pakketellingene og gap-tabellene i denne seksjonen beskriver Runtime 1.3 (Spark 3.5), som inkluderer 223 innebygde biblioteker i Python, 183 Java/Scala og 135 R. De er ikke et Runtime 2.0-inventar eller en anbefaling om å migrere til Runtime 1.3. Runtime 2.0 endrer pakketilgjengelighet og versjoner; se Migrate from Runtime 1.3 to Runtime 2.0 for flere kompatibilitetsvurderinger.

For å identifisere hvilke biblioteker notatbøkene dine faktisk bruker, kjør disse sjekkene før du går gjennom gap-tabellene:

• Python notebooks: Søk etter import og from ... import-setninger på tvers av alle .py / .ipynb-filer.
• Java/Scala-notatbøker og SJDs: Søk etter import-setninger og Maven-koordinater; se etter pakker som com.azure.cosmos.spark eller com.microsoft.kusto.spark.
• Eksporter full avhengighetsliste: Kjør pip freeze i en Synapse-notebook og sammenlign med pakkelageret for din mål-Fabric-runtime. Identifiser manglende pakker og inkompatible versjoner; ikke stol kun på Runtime 1.3 gap-tabellene nedenfor.
• Basseng- og arbeidsområde-nivå tilpassede biblioteker: I Synapse Studio, gå til Administrer>Apache Spark Pools> og velg > for å se tilpassede biblioteker som må lastes opp på nytt til et miljøobjekt.

Python-biblioteker mangler i Fabric

Java/Scala-biblioteker mangler i Fabric

R-biblioteker

Bare én forskjell: Synapse inkluderer lightgbm R-pakken (v4.6.0) som ikke er i Fabric. Installer via miljøet om nødvendig. Fabric legger til FabricTelemetry (v1.0.2) som er Fabric-internt.

Merkbare versjonsforskjeller

68 Python-biblioteker finnes på begge plattformene, men med forskjellige versjoner. De fleste er små versjonsforskjeller, men 17 har store versjonshopp som kan påvirke oppførselen.

Relatert innhold

• Fase 1: Migrasjonsstrategi og planlegging
• Fase 3: Hive Metastore og datamigrering
• Fase 4: Sikkerhets- og styringsmigrasjon
• Migrer Azure Synapse notatbøker til Fabric
• Migrer Spark-jobbdefinisjoner fra Azure Synapse til Fabric
• Migrer Spark Pools fra Azure Synapse til Fabric