Fase 2: Migrazione del carico di lavoro Spark

Questo articolo è la fase 2 di 4 della serie sulle procedure consigliate per la migrazione da Azure Synapse Spark a Microsoft Fabric.

Usare questo articolo per eseguire la migrazione dei carichi di lavoro Spark da Azure Synapse a Microsoft Fabric. Questo articolo illustra l'esecuzione di Migration Assistant, il refactoring dei modelli di codice che non possono essere convertiti automaticamente e la migrazione di configurazioni, ambienti e librerie del pool Spark.

In questo articolo vengono illustrate le operazioni seguenti:

  • Informazioni sul flusso di lavoro di migrazione per le aree di lavoro Synapse standard (non Git) e abilitate per Git.
  • Usare l'Migration Assistant Spark per eseguire la migrazione di notebook, definizioni di processi Spark e pool.
  • Effettuare il refactoring di modelli di codice specifici di Synapse per la compatibilità con Fabric.
  • Eseguire la migrazione di impostazioni, ambienti e librerie del pool di Spark.
  • Identificare e risolvere i gap di compatibilità delle librerie tra Synapse e Fabric.

Eseguire la migrazione con il Migration Assistant

Spark Migration Assistant automatizza la migrazione di notebook, definizioni di processi Spark, pool e metadati del database lake da Synapse a Fabric. L'assistente copia e trasforma gli elementi, ma non completa la migrazione, ma è comunque necessario effettuare il refactoring del codice, risolvere i gap di configurazione e convalidare i risultati.

Per istruzioni passo passo sull’esecuzione dell’assistente, vedere Spark Synapse to Fabric Spark Migration Assistant (Preview).

L'assistente esegue la migrazione degli elementi seguenti:

  • I pool di Spark vengono migrati in pool di Fabric e gli artefatti dell'ambiente corrispondenti.
  • Viene eseguita la migrazione dei notebook e dei relativi ambienti associati.
  • Le definizioni dei processi Spark vengono migrate con gli ambienti associati.
  • I database Lake vengono mappati agli schemi Fabric. Le tabelle Delta gestite vengono migrate tramite collegamenti al catalogo OneLake.

Importante

Le configurazioni spark, le librerie personalizzate e le impostazioni dell'executor personalizzato non vengono migrate dall'assistente. È necessario configurare questi elementi manualmente in ambienti Fabric. Le aree di lavoro di Synapse in una rete virtuale non possono essere migrate con l'assistente.

Migrazione dell'area di lavoro standard (non Git)

Per le aree di lavoro in cui i notebook e i dischi SSD vengono archiviati direttamente in Synapse (non in un repository Git):

  1. Esegui l'Assistente Migrazione Spark dall'ambiente di lavoro Fabric (Migrazione>Elementi di ingegneria dei dati). Selezionare l'area di lavoro synapse di origine ed eseguire la migrazione di tutti gli elementi spark.

  2. Convalidare le dipendenze: verificare che venga usata la stessa versione di Spark. Se i notebook fanno riferimento ad altri notebook tramite mssparkutils.notebook.run(), verificare che anche la loro migrazione sia stata completata. Il Migration Assistant mantiene la struttura delle cartelle (Fabric supporta fino a 10 livelli di annidamento).

  3. Refattorizzazione del codice: sostituire mssparkutils con notebookutils, cambiare i riferimenti ai servizi collegati con Connessioni Fabric e aggiornare i percorsi dei file. Per informazioni dettagliate, vedere la sezione Refactoring del codice Spark .

Migrazione delle aree di lavoro abilitate a Git

Per le aree di lavoro in cui i notebook e i dischi SSD vengono archiviati in un repository Azure DevOps o GitHub, si noti che Synapse e Fabric usano formati di serializzazione Git diversi. Synapse archivia i notebook come JSON; Fabric usa il formato di origine .py/.scala o .ipynb. Non è possibile puntare direttamente un'area di lavoro Fabric nello stesso ramo Git di Synapse.

  1. Eseguire la migrazione degli elementi. Usare l'Migration Assistant Spark per eseguire la migrazione di notebook e unità SSD dall'area di lavoro Synapse a un'area di lavoro Fabric. In questo modo gli elementi vengono convertiti in formato compatibile con Fabric.

  2. Eseguire il refactoring del codice. Applicare lo stesso refactoring del codice dello scenario standard: sostituire mssparkutils, aggiornare i percorsi dei file, sostituire i servizi collegati. Per informazioni dettagliate, vedere la sezione Refactoring del codice Spark .

  3. Collegare l'area di lavoro di Fabric a Git. Connettere l'area di lavoro Fabric a una nuova cartella o ramo nel repository (>Source Control>Git Integration). Usare un ramo o una cartella separata dal contenuto di Synapse per evitare conflitti. Eseguire il commit del contenuto dell'area di lavoro Fabric per popolare il nuovo ramo.

  4. Configurare le pipeline di distribuzione (facoltativo). Configurare le pipeline di distribuzione di Fabric (Sviluppo → Test → Prod) per il CI/CD continuo. Fabric supporta l'associazione automatica per i lakehouse predefiniti e gli ambienti collegati durante la distribuzione in più fasi.

Suggerimento

Mantenere intatto il ramo Git di Synapse come riferimento cronologico. Creare un nuovo ramo o una nuova cartella per i contenuti Fabric. Fabric archivia i notebook come file di origine (.py per PySpark) anziché JSON, che fornisce differenze Git più pulite per la revisione del codice.

Eseguire il refactoring del codice Spark

Dopo la migrazione dei notebook e delle definizioni dei processi Spark, è necessario correggere i modelli di codice che il Migration Assistant non può convertire automaticamente. Questa sezione illustra la sostituzione delle API specifiche di Synapse, l'aggiornamento dei percorsi di file e la modifica dei modelli di credenziali da usare con Fabric.

Verifica preliminare al refactoring

Prima di affrontare i singoli modelli di refactoring, eseguire una ricerca a livello di codebase in tutti i notebook per identificare il codice specifico di Synapse che richiede modifiche.

Criterio di ricerca Categoria Azione necessaria 
spark.synapse.linkedService Servizi collegati Rimuovere; sostituire con l'autenticazione diretta dell'endpoint o i segreti di Key Vault
getSecretWithLS Credentials Sostituire con getSecret(vaultUrl, secretName)
TokenLibrary Token/autenticazione Rimuovere, usare direttamente la configurazione OAuth o Notebookutils
synapsesql Connettore SQL Sostituire spark.read.synapsesql() con la lettura in formato Delta
mssparkutils Spark Utils Sostituire con notebookutils (la maggior parte delle API è identica)
spark.catalog.listDatabases API Catalogo Sostituire con spark.sql("SHOW DATABASES")
spark.catalog.currentDatabase API Catalogo Sostituire con spark.sql("SELECT CURRENT_DATABASE()")
spark.catalog.getDatabase API Catalogo Sostituire con spark.sql("DESCRIBE DATABASE ...")
spark.catalog.listFunctions API Catalogo Non supportato in Fabric - eliminare
spark.catalog.registerFunction API Catalogo Non supportato: usare spark.udf.register() invece
spark.catalog.functionExists API Catalogo Non supportato in Fabric : rimuovere
LinkedServiceBasedTokenProvider Provider di autenticazione Sostituire con ClientCredsTokenProvider
getPropertiesAsMap Servizi collegati Rimuovere; configurare direttamente l'account di archiviazione
spark.storage.synapse Servizi collegati Rimuovi : non supportato in Fabric
/user/trusted-service-user/ Percorsi dei file Sostituire con il percorso di OneLake o percorso di scelta rapida
cosmos.oltp Cosmos DB Aggiornare per usare Key Vault per i segreti anziché per il servizio collegato
kusto.spark.synapse Kusto/ADX Sostituire l'autenticazione del servizio collegato con accessToken tramite getToken()

Suggerimento

Eseguire queste ricerche nell'intero repository di notebook prima della migrazione. I notebook con zero corrispondenze sono sicuri da migrare così come sono. I notebook che contengono corrispondenze dovrebbero avere la priorità per il refactoring del codice usando le indicazioni dettagliate nelle sezioni seguenti.

Utilizzo del percorso del file

Aggiornare i notebook di Synapse che usano percorsi relativi o percorsi di archiviazione gestiti da Synapse per usare percorsi diretti abfss:// o percorsi OneLake in Fabric.

Prima (Synapse) After (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>")

Suggerimento

Sostituire tutti i percorsi di archiviazione gestiti da Synapse con i percorsi OneLake (abfss://<workspace_id>@onelake.dfs.fabric.microsoft.com/<item_id>/...). Per i dati di ADLS Gen2, creare collegamenti a OneLake e fare riferimento ai percorsi di scelta rapida.

Catalogo API Spark

Fabric non supporta alcuni metodi spark.catalog. Sostituirli con gli equivalenti di Spark SQL.

Prima (Synapse) After (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() Non supportato nel Fabric. Rimuovere o ignorare.
spark.catalog.registerFunction(name, fn) Non supportato in Fabric: usare invece spark.udf.register()
spark.catalog.functionExists(name) Non supportato su Fabric — ignorare o rimuovere

Note

spark.catalog metodi di tabella, ad esempio createTable(), tableExists() e listTables() funzionano normalmente in Fabric. Solo i metodi di catalogo a livello di database e a livello di funzione richiedono il refactoring.

MSSparkUtils e NotebookUtils

Sostituire le chiamate mssparkutils con gli equivalenti Fabric notebookutils. Le modifiche più comuni relative alle credenziali sono:

Prima (Synapse) After (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")

In Fabric il recupero segreto basato su servizi collegati (getSecretWithLS) non è supportato. Fare invece riferimento direttamente all'URL di Key Vault usando notebookutils.credentials.getSecret(vaultUrl, secretName). Lo stesso modello si applica alle TokenLibrary.getSecret() chiamate.

Note

La maggior parte dei metodi mssparkutils.fs (ad esempio, ls, cp, mv, rm, mkdirs, head) funziona in modo identico a notebookutils.fs in Fabric. Le modifiche principali riguardano i metodi delle credenziali, i metodi dei segreti e i riferimenti del percorso notebook.run().

Connettore di Esplora dati di Azure (Kusto)

I notebook di Synapse che si connettono a Esplora dati di Azure (Kusto) tramite servizi collegati devono essere ristrutturati per usare l'autenticazione diretta dell'endpoint.

Prima (Synapse) After (Fabric)
.option("spark.synapse.linkedService", "AzureDataExplorer1") Rimuovere le informazioni di riferimento sul servizio collegato
Leggere con il set di opzioni del servizio collegato .option("accessToken", notebookutils.credentials.getToken("https://<cluster>.kusto.windows.net"))

Sostituire l'opzione del servizio collegato con un'opzione accessToken . Usare notebookutils.credentials.getToken() per ottenere un token per l'endpoint del cluster Kusto. Le altre opzioni di query (kustoDatabase, kustoQuery) rimangono invariate.

Connettore Cosmos DB

Aggiorna le connessioni Cosmos DB in Synapse che usano servizi connessi o getSecretWithLS.

Prima (Synapse) After (Fabric)
.option("spark.synapse.linkedService", "CosmosDbLS") Rimuovere le informazioni di riferimento sul servizio collegato
mssparkutils.credentials.getSecretWithLS("cosmosKeyLS", "cosmosKey") notebookutils.credentials.getSecret("https://<vault>.vault.azure.net/", "cosmosKey")

Sostituire il riferimento al servizio collegato con la configurazione diretta dell'endpoint Cosmos DB. Archiviare la chiave dell'account Cosmos DB in Azure Key Vault e recuperarla usando notebookutils.credentials.getSecret(vaultUrl, secretName) anziché getSecretWithLS().

Riferimenti al servizio collegato

Sostituire tutti i riferimenti al servizio collegato Synapse in Fabric.

Prima (Synapse) After (Fabric)
spark.conf.set("spark.storage.synapse.linkedServiceName", ls_name) Rimuovi : non supportato in 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) Rimuovi — usare stringa di connessione diretta o configurazione principale del servizio

In Fabric non sono presenti servizi collegati. Sostituire il provider di token Synapse con credenziali client OAuth standard (principale del servizio). Configurare fs.azure.account.auth.type, oauth.provider.typeclient.id, client.secret, e client.endpoint direttamente usando spark.conf.set().

Libreria di token

Il TokenLibrary di Synapse per ottenere i token e leggere le proprietà del servizio connesso non è disponibile in Fabric. Sostituirlo con modelli equivalenti.

Prima (Synapse) After (Fabric)
TokenLibrary.getPropertiesAsMap(serviceConnection) Rimuovi — configurare direttamente l'account di archiviazione
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)

Per l'accesso ad ADLS Gen2 basato su OAuth, configurare le credenziali del principal del servizio direttamente usando spark.conf.set() con le chiavi specifiche dell'account di archiviazione (ad esempio fs.azure.account.auth.type.<account>.dfs.core.windows.net) anziché basarsi sui provider di token di servizio collegati.

Importante

Esaminare tutti i notebook per i riferimenti ai servizi collegati prima del passaggio. Tutte le chiamate rimanenti spark.synapse.linkedService, TokenLibrary o getSecretWithLS hanno esito negativo in fase di esecuzione in Fabric.

Migrazione della definizione del lavoro Spark

Le definizioni dei processi Spark (SJD) sono configurazioni di processi batch che fanno riferimento a un file eseguibile principale (.py, .jaro .R), librerie di riferimento facoltative, argomenti della riga di comando e un contesto lakehouse. L'Assistente di Migrazione Spark gestisce automaticamente la migrazione SJD, ma richiedono attenzione le importanti differenze tra Synapse e Fabric SJD.

Differenze principali tra Synapse e SJDs Fabric

  • Contesto lakehouse obbligatorio. In Fabric, ogni SJD deve avere almeno una lakehouse associata. Questo lakehouse funge da file system predefinito per il runtime di Spark. Qualsiasi codice che usa percorsi relativi legge e scrive dal lakehouse predefinito. In Synapse, gli SJD utilizzano l'archiviazione predefinita dell'area di lavoro (ADLS Gen2) come file system predefinito.

  • Lingue supportate. Fabric supporta PySpark (Python), Spark (Scala/Java) e SparkR. .NET per Spark (C#/F#) non è supportato in Fabric. È necessario riscrivere questi carichi di lavoro in Python o Scala prima della migrazione.

  • Criteri di ripetizione dei tentativi. Fabric SJDs supportano politiche di ritrasmissione predefinite, come il numero massimo di tentativi e l'intervallo di ritentativi. Questa funzionalità è utile per i processi Spark Structured Streaming che devono essere eseguiti a tempo indeterminato.

  • Collegamento di ambiente. In Synapse, i file SJD vengono associati a un pool di Spark. In Fabric, le unità SSD si associano a un ambiente, che contiene le proprietà di configurazione, librerie e Spark del pool. Il Migration Assistant esegue automaticamente il mapping dei riferimenti del pool Synapse agli ambienti Fabric.

  • Pianificazione. Le Fabric SJDs dispongono di una pianificazione integrata (Settings>Schedule) senza richiedere una pipeline separata. In Synapse, la pianificazione SJD richiede una pipeline con un'attività Spark Job. Se si dispone di pipeline Synapse che attivano solo unità SJD, è consigliabile utilizzare la pianificazione SJD integrata di Fabric invece di eseguire la migrazione della pipeline.

  • Importazione/esportazione. Synapse supporta l'importazione e l'esportazione JSON basate sull'interfaccia utente per IJD. Fabric non supporta l'importazione o l'esportazione dell'interfaccia utente. Usare lo Spark Migration Assistant o l'API REST Fabric per creare o aggiornare SJD programmaticamente.

Eseguire il refactoring del codice SJD

Gli stessi modelli di refactoring del codice in questo articolo si applicano ai file principali di SJD. Le modifiche rientrano in due categorie.

Modifiche al codice sorgente (all'interno del .pyfile principale , .jaro .R ):

  • Sostituire mssparkutils con notebookutils per le operazioni su credenziali e file system.
  • Aggiornare i percorsi di file codificati staticamente nel codice in percorsi OneLake abfss:// o percorsi di collegamento, se necessario. Le unità SSD che usano solo percorsi relativi rispetto alla lakehouse predefinita potrebbero non richiedere modifiche.
  • Sostituire i riferimenti ai servizi collegati nel codice con segreti Key Vault o connessioni Fabric.

Note

Le connessioni DMTS non sono ancora supportate nelle definizioni dei processi Spark Fabric (supportate solo nei notebook). Se il codice SJD usa DMTS, effettuare il refactoring per usare l'autenticazione diretta degli endpoint.

modifiche alla configurazione di SJD (nelle impostazioni dell'elemento SJD Fabric):

  • Verificare che i percorsi di ADLS Gen2 a cui fanno riferimento i file di definizione principali siano ancora accessibili dall'area di lavoro Fabric. Se i file sono stati archiviati nell'archiviazione interna dell'area di lavoro di Synapse, caricarli nuovamente nel Fabric SJD o spostarli in un percorso ad ADLS Gen2 accessibile.
  • Verificare che tutti i file di riferimento (.py, .R, .jar) siano accessibili dopo la migrazione. Caricare nuovamente tutti i file archiviati nell'archiviazione interna dell'area di lavoro di Synapse.
  • Se gli argomenti della riga di comando contengono percorsi specifici di Synapse o stringhe di connessione, li aggiorna ai rispettivi equivalenti di Fabric.

Eseguire la migrazione di pool, ambienti e librerie

Dopo aver eseguito la migrazione dei notebook e delle definizioni dei processi di lavoro Spark, è necessario decidere la strategia dei pool e degli ambienti. Questa sezione illustra quando è possibile usare Fabric pool starter (invece di eseguire la migrazione), quando creare ambienti personalizzati e come identificare e risolvere i gap di compatibilità della libreria.

Migrazione del pool di Spark

Pool di Avvio di Fabric

I pool di avvio di Fabric offrendo miglioramenti significativi rispetto ai pool di Synapse Spark, che richiedono avvii a freddo dei cluster che durano minuti. I pool di avvio sono pronti per l'uso dalla piattaforma e non richiedono alcuna configurazione.

Suggerimento

Se il pool di Spark synapse non ha configurazioni personalizzate, nessuna libreria personalizzata e nessun requisito specifico per le dimensioni dei nodi oltre Medium, non eseguire la migrazione del pool. Invece, lascia che i tuoi notebook e le definizioni di job Spark utilizzino le impostazioni predefinite del 'Starter Pool' dell'area di lavoro Fabric. Questo approccio offre i tempi di avvio più rapidi e un sovraccarico di gestione del pool pari a zero. Creare un pool o un ambiente personalizzato solo quando si ha una necessità specifica.

Quando creare un pool o un ambiente personalizzato

Creare un Fabric pool personalizzato e/o un ambiente solo quando il carico di lavoro richiede:

  • Dimensioni specifiche del nodo (Small, Large, XLarge, XXLarge) diverse dal valore predefinito Medium.
  • Librerie personalizzate (pacchetti pip, pacchetti conda, JAR, ruote) che non sono nel runtime predefinito Fabric.
  • Proprietà Spark personalizzate (ad esempio spark.sql.shuffle.partitions, , spark.executor.memory) oltre le impostazioni predefinite.
  • Endpoint privati gestiti per l'accesso a origini dati private (richiede pool personalizzati).
  • Una versione specifica del runtime spark diversa dall'impostazione predefinita dell'area di lavoro.

Migrazione della configurazione e della libreria

Eseguire la migrazione di configurazioni e librerie Spark in ambienti Fabric.

Per informazioni dettagliate sulla migrazione delle librerie agli ambienti Fabric, vedere Migrate Spark Libraries from Azure Synapse to Fabric.

  1. Esportare le configurazioni di Spark. In Synapse Studio passare a Gestisci>Spark Pools> selezionare pool >Configurations + Libraries> scaricare come .yml/.conf/.json.

  2. Importa nell'ambiente. In Fabric, creare un artefatto Ambiente. Passare a Spark Compute>Spark Properties> caricare il file esportato.

  3. Eseguire la migrazione delle librerie. Per le librerie a livello di pool, caricare i pacchetti (wheel, JAR, tar) nella sezione delle librerie dell'ambiente. Per i pacchetti PyPI/Conda, aggiungerli alla configurazione della libreria pubblica dell'ambiente.

Importante

Le impostazioni della libreria a livello di area di lavoro in Fabric sono deprecate. Eseguire la migrazione di tutte le librerie agli artefatti di ambiente. La migrazione rimuove definitivamente le configurazioni esistenti a livello di area di lavoro, scarica tutte le impostazioni prima di abilitare Ambienti.

Compatibilità della libreria: Synapse e Fabric

Fabric Runtime 1.3 (Spark 3.5) include 223 librerie Python, 183 Java/Scala e 135 librerie R integrate. La maggior parte delle librerie Synapse è disponibile in Fabric, ma esistono lacune che possono causare errori di runtime se non risolti prima della migrazione.

Per identificare le librerie effettivamente usate dai notebook, eseguire questi controlli prima di esaminare le tabelle delle lacune.

  • Python notebooks: Cerca istruzioni import e from ... import in tutti i file \\.py / .ipynb.
  • Notebook Java/Scala e SJDs: Cerca istruzioni import e coordinate Maven; cerca pacchetti come com.azure.cosmos.spark o com.microsoft.kusto.spark.
  • Export full dependency list: Eseguire pip freeze in un notebook Synapse, e comparare con il manifesto del runtime di Fabric 1.3. Solo le librerie che appaiono sia nel tuo output pip freeze sia nelle tabelle delle lacune sottostanti richiedono un'azione.
  • Librerie personalizzate a livello di pool e di area di lavoro: In Synapse Studio passa a Gestione>Pool Apache Spark> seleziona il pool >Packages per vedere le librerie personalizzate che devono essere ricaricate in un ambiente Fabric.

Python librerie mancanti da Fabric

Categoria Biblioteche Action
CUDA/GPU (9 librerie) libcublas, libcufft, libcufile, libcurand, libcusolver, libcusparse, libnpp, libnvfatbin, libnvjitlink, libnvjpeg Non disponibile: Fabric non supporta i pool GPU. Effettuare il refactoring dei carichi di lavoro GPU per usare alternative basate sulla CPU o continuare a usare Synapse.
Client HTTP/API httpx, httpcore, h11, google-auth, jmespath Eseguire l'installazione tramite ambiente di sistema: pip install httpx google-auth jmespath
ML/Interpretability interpretare, nucleo-di-interpretazione Eseguire l'installazione tramite Ambiente: pip install interpret
Serializzazione dei dati marshmallow, jsonpickle, frozendict, fixedint Eseguire l'installazione tramite Ambiente, se necessario: pip install marshmallow jsonpickle
Registrazione/telemetria fluent-logger, humanfriendly, library-metadata-elaboratore, impulse-python-handler fluent-logger: installare se usato. Altri sono interni a Synapse, probabilmente non necessari.
Interni di Jupyter jupyter-client, jupyter-core, jupyter-ui-poll, jupyterlab-widgets, ipython-pygments-lexers Fabric gestisce internamente l'infrastruttura di Jupyter. Queste librerie in genere non sono necessarie nel codice utente.
Librerie di sistema/C libgcc, libstdcxx, libgrpc, libabseil, libexpat, libnsl, libzlib Librerie di sistema di basso livello. In genere non è stato importato direttamente. Installare solo se sono presenti estensioni C che dipendono da esse.
File/concorrenza filelock, fsspec, knack Eseguire l'installazione tramite Ambiente se usato: pip install filelock fsspec

librerie Java/Scala mancanti da Fabric

Raccolta Versione di Synapse Action
azure-cosmos-analytics-spark 2.2.5 Installare come file JAR personalizzato nell'ambiente Fabric se i processi Spark usano il connettore di analisi di Cosmos DB.
junit-jupiter-params 5.5.2 Libreria solo per test. Non necessario nei notebook di produzione.
junit-platform-commons 1.5.2 Libreria esclusivamente per test. Non necessario nei notebook di produzione.

Librerie R

Una sola differenza: Synapse include il pacchetto lightgbm R (v4.6.0) che non è in Fabric. Eseguire l'installazione tramite Ambiente, se necessario. Fabric aggiunge FabricTelemetry (v1.0.2) che è interno a Fabric.

Differenze di versione rilevanti

68 Python librerie esistono in entrambe le piattaforme, ma con versioni diverse. La maggior parte delle differenze di versione è secondaria, ma 17 presenta salti di versione principali che potrebbero influire sul comportamento.

Raccolta Versione Fabric Versione di Synapse Impatto
libxgboost 2.0.3 3.0.1 L'API XGBoost cambia tra v2 e v3. Testare il codice di addestramento/predizione del modello.
beuta 2.2.5 3.0.3 Flask 3.x presenta modifiche di rilievo. Se si servono le API Flask dai notebook, eseguire un test approfondito.
lxml 4.9.3 5.3.0 Modifiche minime all'API. Testare i flussi di lavoro di analisi XML.
libprotobuf 3.20.3 4.25.3 Protobuf 4.x presenta modifiche di rilievo per le definizioni proto personalizzate.
markupsafe 2.1.3 3.0.2 MarkupSafe 3.x elimina Python supporto 3.7, ma l'API è compatibile.
libpq 12.17 17.4 Libreria client PostgreSQL. Passaggio della versione principale: testare le connessioni del database.
libgcc-ng / libstdcxx-ng 11.2.0 15.2.0 Runtime GCC Potrebbe influire sulla compatibilità delle estensioni C.

Note

Synapse offre in genere versioni più recenti delle librerie a livello di sistema (GCC, protobuf, libpq), mentre Fabric offre versioni più recenti di librerie di dati/ML (più pacchetti Python complessivamente). Se è necessaria una versione specifica, aggiungerla nella configurazione di Fabric Environment.

Suggerimento

Eseguire un rapido controllo di compatibilità: esportare l'elenco di librerie del pool Synapse (pip freeze), confrontarsi con il manifesto di Fabric Runtime 1.3 e pre-installare eventuali librerie mancanti nell'ambiente Fabric prima di eseguire i notebook migrati. Per un confronto line-by-line di ogni libreria e versione predefinita tra i runtime di Fabric e Synapse Spark, vedere microsoft/synapse-spark-runtime GitHub repository.

Contenuti correlati

  • Last updated on