Fas 2: Migrering av Spark-arbetsbelastning

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

Använd den här artikeln om du vill migrera dina Spark-arbetsbelastningar från Azure Synapse till Microsoft Fabric. Den här artikeln beskriver hur du kör Migration Assistant, omstrukturerar kodmönster som inte kan konverteras automatiskt och migrera Spark-poolkonfigurationer, miljöer och bibliotek.

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

  • Förstå migreringsarbetsflödet för standardarbetsytor (icke-Git) och Git-aktiverade Synapse-arbetsytor.
  • Använd Spark-Migration Assistant för att migrera notebook-filer, Spark-jobbdefinitioner och pooler.
  • Omstrukturera Synapse-specifika kodmönster för Fabric kompatibilitet.
  • Migrera Inställningar, miljöer och bibliotek för Spark-pooler.
  • Identifiera och lösa bibliotekskompatibilitetsluckor mellan Synapse och Fabric.

Migrera med Migration Assistant

Spark-Migration Assistant automatiserar migreringen av notebook-filer, Spark-jobbdefinitioner, pooler och lakedatabasmetadata från Synapse till Fabric. Assistenten kopierar och transformerar dina objekt, men slutför inte migreringen – du behöver fortfarande omstrukturera kod, stämma av konfigurationsluckor och verifiera resultatet.

Stegvisa instruktioner om hur du kör assistenten finns i Spark Synapse to Fabric Spark Migration Assistant (preview).

Assistenten migrerar följande objekt:

  • Spark-pooler migreras till Fabric-Pooler och motsvarande miljöobjekt.
  • Anteckningsblock och deras associerade miljöer migreras.
  • Spark-jobbdefinitioner migreras med associerade miljöer.
  • Lake-databaser mappas till Fabric scheman. Hanterade Delta-tabeller migreras via OneLake-kataloggenvägar.

Viktigt!

Spark-konfigurationer, anpassade bibliotek och anpassade körinställningar migreras inte av assistenten. Du måste konfigurera dessa manuellt i Fabric-miljöer. Synapse-arbetsytor under ett virtuellt nätverk kan inte migreras med assistenten.

Migrering av standardarbetsytor (inte Git)

För arbetsytor där notebook-filer och SJD:ar lagras direkt i Synapse (inte på en Git-lagringsplats):

  1. Kör Spark-migrationsassistent från din Fabric-arbetsmiljö (Migrate>Dataingenjörsobjekt). Välj synapse-källarbetsytan och migrera alla Spark-objekt.

  2. Verifiera beroenden: kontrollera att samma Spark-version används. Om notebook-filer refererar till andra notebook-filer via mssparkutils.notebook.run(), kontrollerar du att de också har migrerats. Migration Assistant bevarar mappstrukturen (Fabric stöder upp till 10 kapslingsnivåer).

  3. Refaktorkod: ersätt mssparkutils med notebookutils, ersätt länkade tjänstreferenser med Fabric Anslutningar och uppdatera filsökvägar. Mer information finns i avsnittet Refactor Spark-kod .

Migrering av Git-aktiverad arbetsyta

Observera att Synapse och Fabric använder olika Git-serialiseringsformat för arbetsytor där notebook-filer och SJD:er lagras i en Azure DevOps eller GitHub lagringsplats. Synapse lagrar notebook-filer som JSON; Fabric använder källformatet .py/.scala eller .ipynb. Du kan inte peka en Fabric arbetsyta på samma Synapse Git-gren direkt.

  1. Migrera objekt. Använd Spark-Migration Assistant för att migrera notebook-filer och SJD:er från Synapse-arbetsytan till en Fabric arbetsyta. Detta konverterar objekt till Fabric-kompatibelt format.

  2. Refaktorisera koden. Använd samma kodrefaktorisering som standardscenariot – ersätt mssparkutils, uppdatera filsökvägar och ersätt länkade tjänster. Mer information finns i avsnittet Refactor Spark-kod .

  3. Anslut Fabric arbetsyta till Git. Anslut din Fabric arbetsyta till en ny gren eller mapp på lagringsplatsen (Arbetsyteinställningar>Source Control>Git Integration). Använd en separat gren eller mapp från ditt Synapse-innehåll för att undvika konflikter. Kommitera Fabric arbetsytans innehåll för att lägga till det i den nya grenen.

  4. Konfigurera distributionspipelines (valfritt). Konfigurera Fabric distributionskedjor (Dev → Test → Prod) för kontinuerlig CI/CD. Fabric stöder automatisk bindning för standardsjöhus och anslutna miljöer när du distribuerar mellan steg.

Tips/Råd

Behåll Din Synapse Git-gren intakt som en historisk referens. Skapa en ny gren eller mapp för Fabric innehåll. Fabric lagrar notebook-filer som källfiler (.py för PySpark) i stället för JSON, vilket ger renare Git-diff för kodgranskning.

Omstrukturera Spark-kod

När du har migrerat dina notebook-filer och Spark-jobbdefinitioner måste du åtgärda kodmönster som Migration Assistant inte kan konvertera automatiskt. Det här avsnittet vägleder dig genom att ersätta Synapse-specifika API:er, uppdatera filsökvägar och ändra mönster för autentiseringsuppgifter så att de fungerar med Fabric.

Granskning före omstrukturering

Innan du tar itu med enskilda refaktoriseringsmönster kör du en kodbasomfattande sökning i alla notebook-filer för att identifiera Synapse-specifik kod som behöver ändras.

Sökmönster Kategori Åtgärd krävs
spark.synapse.linkedService Länkade tjänster Ta bort; ersätt med direkt slutpunktsautentisering eller Key Vault hemligheter
getSecretWithLS Credentials Ersätt med getSecret(vaultUrl, secretName)
TokenLibrary Token/autentisering Ta bort; använd en direkt OAuth-konfiguration eller notebookutils
synapsesql SQL-anslutningsprogram Ersätt spark.read.synapsesql() med Delta-formatläsningar
mssparkutils Spark Utils Ersätt med notebookutils (de flesta API:er identiska)
spark.catalog.listDatabases Katalog-API Ersätt med spark.sql("SHOW DATABASES")
spark.catalog.currentDatabase Katalog-API Ersätt med spark.sql("SELECT CURRENT_DATABASE()")
spark.catalog.getDatabase Katalog-API Ersätt med spark.sql("DESCRIBE DATABASE ...")
spark.catalog.listFunctions Katalog-API Stöds inte i Fabric – ta bort
spark.catalog.registerFunction Katalog-API Stöds inte – använd spark.udf.register() i stället
spark.catalog.functionExists Katalog-API Stöds inte i Fabric – ta bort
LinkedServiceBasedTokenProvider Autentiseringsprovider Ersätt med ClientCredsTokenProvider
getPropertiesAsMap Länkade tjänster Ta bort; konfigurera lagringskontot direkt
spark.storage.synapse Länkade tjänster Ta bort – stöds inte i Fabric
/user/trusted-service-user/ Filsökvägar Ersätt med OneLake-sökväg eller genvägssökväg
cosmos.oltp Cosmos DB Uppdatera för att använda Key Vault för hemligheter i stället för länkad tjänst
kusto.spark.synapse Kusto/ADX Ersätt länkad tjänstautentisering med accessToken via getToken()

Tips/Råd

Kör dessa sökningar över hela lagringsplatsen för notebook-filer före migreringen. Anteckningsböcker med noll matchningar är säkra att migrera oförändrade. Notebook-filer med matchningar bör prioriteras för kodrefaktorisering med hjälp av den detaljerade vägledningen i följande avsnitt.

Filsökvägsanvändning

Uppdatera Synapse-anteckningsböcker som använder relativa sökvägar eller lagringsvägar hanterade av Synapse, så att de använder direkta abfss:// sökvägar eller OneLake-sökvägar i Fabric.

Före (Synapse) Efter (Fabric)
"abfss://...@<synapse_storage>.dfs.core.windows.net/user/trusted-service-user/deltalake" "abfss://<workspace_id>@onelake.dfs.fabric.microsoft.com/<lakehouse_id>/Tables/deltalake"
spark.read.synapsesql("<pool>.<schema>.<table>") spark.read.format("delta").load("abfss://.../<lakehouse>/Tables/<table>")

Tips/Råd

Ersätt alla Synapse-hanterade lagringssökvägar med OneLake-sökvägar (abfss://<workspace_id>@onelake.dfs.fabric.microsoft.com/<item_id>/...). För ADLS Gen2-data skapar du OneLake-genvägar och refererar till genvägssökvägarna i stället.

Api för Spark-katalog

Fabric stöder inte flera spark.catalog metoder. Ersätt dem med Spark SQL-motsvarigheter.

Före (Synapse) Efter (Fabric)
spark.catalog.listDatabases() spark.sql("SHOW DATABASES").show()
spark.catalog.currentDatabase() spark.sql("SELECT CURRENT_DATABASE()").first()["current_database()"]
spark.catalog.getDatabase(db_name) spark.sql(f"DESCRIBE DATABASE {db_name}").show()
spark.catalog.listFunctions() Stöds inte i Fabric – ta bort eller hoppa över
spark.catalog.registerFunction(name, fn) Stöds inte i Fabric – använd spark.udf.register() i stället
spark.catalog.functionExists(name) Stöds inte i Fabric – ta bort eller hoppa över

Note

spark.catalog tabellmetoder som createTable(), tableExists() och listTables() fungerar normalt i Fabric. Endast katalogmetoder på databasnivå och funktionsnivå kräver refaktorisering.

MSSparkUtils och NotebookUtils

Ersätt mssparkutils-anrop med motsvarigheterna Fabric notebookutils. De vanligaste ändringarna som rör autentiseringsuppgifter är:

Före (Synapse) Efter (Fabric)
mssparkutils.credentials.getSecretWithLS("sampleLS", secretKey) notebookutils.credentials.getSecret("https://<vault>.vault.azure.net/", secretKey)
TokenLibrary.getSecret("foo", "bar") notebookutils.credentials.getSecret("https://foo.vault.azure.net/", "bar")

I Fabric stöds inte länkad tjänstbaserad hemlig hämtning (getSecretWithLS). Referera i stället till Key Vault-URL:en direkt med hjälp av notebookutils.credentials.getSecret(vaultUrl, secretName). Samma mönster gäller för TokenLibrary.getSecret() anrop.

Note

De flesta mssparkutils.fs metoder (till exempel ls, cp, mv, rm, mkdirs, head) fungerar på samma sätt som notebookutils.fs i Fabric. De primära ändringarna är autentiseringsuppgifter och hemliga metoder samt notebook.run() sökvägsreferenser.

Azure Data Explorer (Kusto)-anslutning

Synapse-notebook-filer som ansluter till Azure Data Explorer (Kusto) via länkade tjänster måste omstruktureras för att använda direkt slutpunktsautentisering.

Före (Synapse) Efter (Fabric)
.option("spark.synapse.linkedService", "AzureDataExplorer1") Ta bort länkade tjänstreferenser
Läs med alternativkonfiguration för länkad tjänst .option("accessToken", notebookutils.credentials.getToken("https://<cluster>.kusto.windows.net"))

Ersätt det länkade tjänstalternativet med ett accessToken alternativ. Använd notebookutils.credentials.getToken() för att hämta en token för kusto-klusterslutpunkten. Resten av frågealternativen (kustoDatabase, kustoQuery) förblir oförändrade.

Cosmos DB-anslutning

Uppdatera anslutningar till Cosmos DB i Synapse som använder länkade tjänster eller getSecretWithLS.

Före (Synapse) Efter (Fabric)
.option("spark.synapse.linkedService", "CosmosDbLS") Ta bort länkade tjänstreferenser
mssparkutils.credentials.getSecretWithLS("cosmosKeyLS", "cosmosKey") notebookutils.credentials.getSecret("https://<vault>.vault.azure.net/", "cosmosKey")

Ersätt referensen för den länkade tjänsten med direkt Cosmos DB-slutpunktskonfiguration. Lagra Cosmos DB-kontonyckeln i Azure Key Vault och hämta den med hjälp av notebookutils.credentials.getSecret(vaultUrl, secretName) i stället för getSecretWithLS().

Länkade tjänstreferenser

Ersätt alla synapse-länkade tjänstreferenser i Fabric.

Före (Synapse) Efter (Fabric)
spark.conf.set("spark.storage.synapse.linkedServiceName", ls_name) Ta bort – stöds inte i Fabric
spark.conf.set("fs.azure.account.oauth.provider.type", "com.microsoft.azure.synapse.tokenlibrary.LinkedServiceBasedTokenProvider") spark.conf.set("fs.azure.account.oauth.provider.type", "org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider")
TokenLibrary.getPropertiesAsMap(linked_service_cfg) Ta bort – använd direkt anslutningssträng eller tjänsthuvudkonfiguration

I Fabric finns det inga länkade tjänster. Ersätt Synapse-tokenprovidern med OAuth-standardklientautentiseringsuppgifter (tjänstens huvudnamn). Konfigurera fs.azure.account.auth.type, oauth.provider.type, client.id, client.secret och client.endpoint direkt med hjälp av spark.conf.set().

Tokenbibliotek

Synapse TokenLibrary för att hämta token och läsa länkade tjänstegenskaper är inte tillgängligt i Fabric. Ersätt den med motsvarande mönster.

Före (Synapse) Efter (Fabric)
TokenLibrary.getPropertiesAsMap(serviceConnection) Ta bort – konfigurera lagringskontot direkt
val my_account = conexion("Endpoint").toString.substring(8) val my_account = "<storage_account_name>" // Hardcode or retrieve via notebookutils
mssparkutils.fs.head(internalPath, Int.MaxValue) notebookutils.fs.head(internalPath, Int.MaxValue)

För OAuth-baserad ADLS Gen2-åtkomst konfigurerar du autentiseringsuppgifterna för tjänstehuvudprincipen direkt med hjälp av spark.conf.set() och lagringskontospecifika nycklar (till exempel fs.azure.account.auth.type.<account>.dfs.core.windows.net) i stället för att förlita dig på de länkade tjänsternas token-leverantörer.

Viktigt!

Granska alla anteckningsböcker för referenser till länkade tjänster innan övergången. Eventuella återstående spark.synapse.linkedService, TokenLibrary eller getSecretWithLS-anrop misslyckas vid körning i Fabric.

Migrering av Spark-jobbdefinition

Spark-jobbdefinitioner (SJD: er) är batchjobbkonfigurationer som refererar till en huvud körbar fil (.py, .jar, eller .R), valfria referensbibliotek, kommandoradsargument och en lakehouse-kontext. Spark-Migration Assistant hanterar SJD-migrering automatiskt, men viktiga skillnader mellan Synapse och Fabric SJD kräver uppmärksamhet.

Viktiga skillnader mellan Synapse och Fabric SJD

  • Lakehouse-kontext krävs. I Fabric måste varje SJD ha minst ett sjöhus associerat med det. Det här lakehouse fungerar som standardfilsystem för Spark-körning. All kod som använder relativa sökvägar läser och skriver från standard lakehouse. I Synapse använder SJD:er standardlagringen för arbetsytan (ADLS Gen2) som standardfilsystem.

  • Språk som stöds. Fabric stöder PySpark (Python), Spark (Scala/Java) och SparkR. .NET för Spark (C#/F#) stöds inte i Fabric. Du måste skriva om dessa arbetsbelastningar i Python eller Scala före migreringen.

  • Återförsökspolicy. Fabric SJD stöder inbyggda återförsöksprinciper, till exempel maximalt återförsök och återförsöksintervall. Den här funktionen är användbar för Spark Structured Streaming-jobb som måste köras på obestämd tid.

  • Miljöbindning. I Synapse associeras SJDs till en Spark-pool. I Fabric binder SJD:er till en miljö som innehåller poolkonfiguration, bibliotek och Spark-egenskaper. Migration Assistant mappar automatiskt Synapse-poolreferenser till Fabric Miljöer.

  • Schemaläggning. Fabric SJD:er har inbyggd schemaläggning (Settings>Schedule) utan att en separat pipeline krävs. I Synapse kräver SJD-schemaläggning en pipeline med en Spark Job-aktivitet. Om du har Synapse-pipelines som bara utlöser SJD:er bör du överväga att använda Fabric inbyggda SJD-schemaläggning i stället för att migrera pipelinen.

  • Importera/exportera. Synapse stöder UI-baserad JSON-import och -export för SJD:er. Fabric stöder inte import eller export av användargränssnittet. Använd Spark-Migration Assistant eller rest-API:et för Fabric för att skapa eller uppdatera SJD:er programmatiskt.

Omstrukturera SJD-kod

Samma kodrefaktoriseringsmönster i den här artikeln gäller för SJD-huvudfiler. Ändringarna delas in i två kategorier.

Källkodsändringar (inuti .py, .jareller .R huvudfilen):

  • Ersätt mssparkutils med notebookutils för autentiseringsuppgifter och filsystemåtgärder.
  • Uppdatera hårdkodade filsökvägar i kod till OneLake-sökvägar abfss:// eller genvägssökvägar när det behövs. SJD:er som endast använder relativa sökvägar mot standard lakehouse kanske inte kräver ändringar.
  • Ersätt referenser till länkade tjänster i kod med Key Vault-sekretess eller Fabric-anslutningar.

Note

DMTS-anslutningar stöds ännu inte i Fabric Spark-jobbdefinitioner (stöds endast i notebook-filer). Om din SJD-kod använder DMTS omstrukturerar du för att använda direkt slutpunktsautentisering.

SJD-konfigurationsändringar (i inställningarna för Fabric SJD-objekt):

  • Kontrollera att ADLS Gen2-sökvägar som refereras av huvuddefinitionsfiler fortfarande är tillgängliga från Fabric arbetsytan. Om filer lagrades i Synapse-arbetsytans interna lagring laddar du upp dem på nytt till Fabric SJD eller flyttar dem till en tillgänglig ADLS Gen2-plats.
  • Kontrollera att alla referensfiler (.py, .R, .jar) är tillgängliga efter migreringen. Ladda upp alla filer som har lagrats i Synapse-arbetsytans interna lagring.
  • Om kommandoradsargument innehåller Synapse-specifika sökvägar eller anslutningssträngar uppdaterar du dem till Fabric motsvarigheter.

Migrera pooler, miljöer och bibliotek

När dina notebook-filer och Spark-jobbdefinitioner har migrerats måste du bestämma dig för pool- och miljöstrategin. I det här avsnittet förklaras när du kan använda Fabric startpooler (i stället för att migrera), när du ska skapa anpassade miljöer och hur du identifierar och löser kompatibilitetsluckor för bibliotek.

Migrering av Spark-pool

Startpooler för Fabric

Fabric Startpooler möjliggör start av Spark-sessioner på sekundnivå – en betydande förbättring jämfört med Synapse Spark-pooler, som kräver kalla starter som tar flera minuter för att starta kluster. Startpooler är redo att användas från plattformen och kräver ingen konfiguration.

Tips/Råd

Om din Synapse Spark-pool inte har några anpassade konfigurationer, inga anpassade bibliotek och inga specifika krav på nodstorlek utöver Medel migrerar du inte poolen. Låt i stället notebook-filer och Spark-jobbdefinitioner använda standardinställningarna för Fabric-arbetsytans startpool. Den här metoden ger dig de snabbaste starttiderna och noll omkostnader för poolhantering. Skapa bara en anpassad pool eller miljö när du har ett specifikt behov.

När du ska skapa en anpassad pool eller miljö

Skapa en anpassad Fabric-pool och/eller miljö endast när ditt behov kräver det.

  • En specifik nodstorlek (Liten, Stor, XLarge, XXLarge) skiljer sig från standardvärdet Medel.
  • Anpassade bibliotek (pip-paket, conda-paket, JAR-paket, wheel-paket) som inte finns i Fabrics egen inbyggda körning.
  • Anpassade Spark-egenskaper (till exempel spark.sql.shuffle.partitions, spark.executor.memory) utöver standardvärdena.
  • Hanterade privata slutpunkter för åtkomst till privata datakällor (kräver anpassade pooler).
  • En specifik Spark-körningsversion som skiljer sig från standardvärdet för arbetsytan.

Konfigurations- och biblioteksmigrering

Migrera Spark-konfigurationer och -bibliotek till Fabric miljöer.

Detaljerade anvisningar om hur du migrerar bibliotek till Fabric miljöer finns i Migrera Spark-bibliotek från Azure Synapse till Fabric.

  1. Exportera Spark-konfigurationer. I Synapse Studio går du till Hantera>Spark Pools> välj pool >Konfigurationer + Bibliotek> ladda ner som .yml/.conf/.json.

  2. Importera till systemmiljö. I Fabric skapar du en miljöartefakt. Gå till Spark Compute>Spark-egenskaper>Ladda upp den exporterade Sparkproperties.yml filen.

  3. Migrera bibliotek. För bibliotek på poolnivå laddar du upp paket (wheels, JAR:er, tar-filer) till miljöns biblioteksektion. För PyPI/Conda-paket lägger du till dem i miljöns offentliga bibliotekskonfiguration.

Viktigt!

Biblioteksinställningar på arbetsytenivå i Fabric är utgångna. Migrera alla bibliotek till miljöartefakter. Migreringen tar bort befintliga konfigurationer på arbetsytan permanent – ladda ned alla inställningar innan du aktiverar Miljöer.

Bibliotekskompatibilitet: Synapse jämfört med Fabric

Fabric Runtime 1.3 (Spark 3.5) levereras med inbyggda bibliotek med 223 Python, 183 Java/Scala och 135 R. De flesta Synapse-bibliotek är tillgängliga i Fabric, men det finns luckor som kan orsaka körningsfel om de inte åtgärdas före migreringen.

Om du vill identifiera vilka bibliotek dina anteckningsböcker faktiskt använder, kör dessa kontroller innan du går igenom gap-tabellerna.

  • Python notebooks: Sök efter import och from ... import instruktioner i alla .py / .ipynbfiler.
  • Java/Scala notebook-filer och SJD: Sök efter import-instruktioner och Maven-koordinater; leta efter paket som com.azure.cosmos.spark eller com.microsoft.kusto.spark.
  • Exportera fullständig beroendelista: Kör pip freeze i en Synapse-anteckningsbok, och jämför mot manifestet Fabric Runtime 1.3. Det är bara bibliotek som visas i både pip freeze-utdata och gaptabellerna nedan som behöver åtgärdas.
  • Anpassade bibliotek på poolnivå och arbetsytenivå: I Synapse Studio går du till Hantera>Apache Spark-pooler> välj pool >Paket för att se anpassade bibliotek som måste laddas upp igen till en Fabric-miljö.

Python bibliotek saknas i Fabric

Kategori Bibliotek Åtgärd
CUDA/GPU (9 libs) libcublas, libcufft, libcufile, libcurand, libcusolver, libcusparse, libnpp, libnvfatbin, libnvjitlink, libnvjpeg Inte tillgängligt – Fabric stöder inte GPU-pooler. Omstrukturera GPU-arbetsbelastningar för att använda CPU-baserade alternativ eller behålla Synapse.
HTTP/API-klienter httpx, httpcore, h11, google-auth, jmespath Installera via miljö: pip install httpx google-auth jmespath
ML/förklarbarhet tolka, tolka-kärna Installera via miljö: pip install interpret
Data serialisering marshmallow, jsonpickle, frozendict, fixedint Installera via miljö om det behövs: pip install marshmallow jsonpickle
Loggning/telemetriövervakning fluent-logger, humanfriendly, library-metadata-cooker, impulse-python-handler fluent-logger: installera om det används. Andra är interna för Synapse – troligtvis inte behövs.
Jupyter internals jupyter-client, jupyter-core, jupyter-ui-poll, jupyterlab-widgets, ipython-pygments-lexers Fabric hanterar Jupyter-infrastrukturen internt. Dessa bibliotek behövs vanligtvis inte i användarkoden.
System-/C-bibliotek libgcc, libstdcxx, libgrpc, libabseil, libexpat, libnsl, libzlib Systembibliotek på låg nivå. Importeras vanligtvis inte direkt. Installera endast om du har C-tillägg som är beroende av dem.
Fil/samtidighet filelock, fsspec, knack Installera via miljö om det används: pip install filelock fsspec

Java/Scala-bibliotek saknas i Fabric

Bibliotek Synapse-version Åtgärd
azure-cosmos-analytics-spark 2.2.5 Installera som en anpassad JAR-fil i Fabric Environment om dina Spark-jobb använder Cosmos DB-analysanslutningsappen.
junit-jupiter-params 5.5.2 Endast testbibliotek. Behövs inte i notebook-filer för produktion.
junit-platform-commons 1.5.2 Bibliotek endast för test. Behövs inte i produktionsnotebooks.

R-bibliotek

Endast en skillnad: Synapse innehåller lightgbm R-paketet (v4.6.0) som inte finns i Fabric. Installera via miljö om det behövs. Fabric lägger till FabricTelemetry (v1.0.2) som är internt för Fabric.

Anmärkningsvärda versionsskillnader

68 Python bibliotek finns på båda plattformarna men med olika versioner. De flesta är mindre versionsskillnader, men 17 har större versionshopp som kan påverka beteendet.

Bibliotek Fabricversion Synapse-version Impact
libxgboost 2.0.3 3.0.1 XGBoost API ändras mellan v2 och v3. Testa modelltränings-/förutsägelsekod.
flaska 2.2.5 3.0.3 Flask 3.x har icke-bakåtkompatibla ändringar. Om du kör Flask-API:er från notebooks bör du testa noggrant.
Lxml 4.9.3 5.3.0 Mindre API-ändringar. Testa XML-parsningsarbetsflöden.
Libprotobuf 3.20.3 4.25.3 Protobuf 4.x har icke-bakåtkompatibla ändringar för anpassade proto-definitioner.
markupsafe 2.1.3 3.0.2 MarkupSafe 3.x släpper Python 3.7-stöd men API:et är kompatibelt.
libpq 12.17 17.4 PostgreSQL-klientbibliotek. Huvudversionshopp – testa DB-anslutningar.
libgcc-ng /libstdcxx-ng 11.2.0 15.2.0 GCC-körning. Kan påverka C-tilläggskompatibiliteten.

Note

Synapse levererar vanligtvis nyare versioner av bibliotek på systemnivå (GCC, protobuf, libpq) medan Fabric levererar nyare versioner av data/ML-bibliotek (mer Python paket totalt sett). Om du behöver en viss version fäster du den i din Fabric Miljö-konfiguration.

Tips/Råd

Kör en snabb kompatibilitetskontroll: exportera synapse-poolens bibliotekslista (pip freeze), jämför med manifestet för Fabric Runtime 1.3, och installera eventuella saknade bibliotek i Fabric-miljön innan du kör migrerade notebooks. En rad-för-rad-jämförelse av alla inbyggda bibliotek och versioner mellan Fabric och Synapse Spark-körmiljöer finns i microsoft/synapse-spark-runtime GitHub-repository.

Relaterat innehåll

  • Last updated on