Fase 1: strategia e pianificazione della migrazione

Questo articolo è la fase 1 di 4 nella serie delle migliori pratiche di migrazione da Azure Synapse Spark a Microsoft Fabric.

Iniziare da qui prima di eseguire la migrazione di notebook, definizioni di processi Spark, pool o metadati lake. Questo articolo illustra come valutare l'ambito dell'ambiente Synapse Spark, scegliere un approccio di migrazione corrispondente alla sequenza temporale di tolleranza e recapito dei rischi e comprendere le differenze Fabric che influiscono sulla pianificazione.

Al termine di questo passaggio, è necessario sapere cosa è necessario spostare, quale modello di migrazione usare, dove si trovano i principali rischi di compatibilità e quali vincoli di rollback o di esecuzione parallela è necessario tenere conto.

In questo articolo vengono illustrate le operazioni seguenti:

Valuta l'impronta di Synapse Spark.
Scegliere tra lift-and-shift, modernizzazione in più fasi ed esecuzione parallela.
Tenere conto dei vincoli di rollback e sincronizzazione.
Esaminare le differenze chiave tra le funzionalità e l'architettura tra Synapse Spark e Fabric Spark.

Valuta il consumo di Synapse Spark

Azure Synapse Analytics include più tipi di carico di lavoro. Questa guida è incentrata sulla migrazione di pool di Spark, notebook, definizioni di processi Spark, database Lake e metadati Metastore Hive a Microsoft Fabric. Per informazioni su pool SQL dedicato, pipeline, Esplora dati e indicazioni sulla migrazione della sicurezza, vedere le guide complementari.

Carico di lavoro Synapse	Destinazione Fabric	Strumento di migrazione/Percorso
Pool di Spark	Fabric Spark (Lakehouse)	Assistente Migrazione Spark (anteprima); migrazione manuale di pool/ambiente
Computer portatili	Notebook dell'infrastruttura	Spark Migration Assistant; refactoring del codice per le API specifiche di Synapse
Definizioni di job Spark	Definizioni dei job Spark di Fabric	Spark Migration Assistant (scelta consigliata); ricreazione manuale, se necessario
Database Lake	catalogo Fabric Lakehouse	Spark Migration Assistant (tabelle Delta tramite collegamenti); esportazione/importazione HMS per tabelle non-Delta
Hive Metastore	catalogo Fabric Lakehouse	Notebook HMS per esportazione/importazione; Collegamenti rapidi a OneLake per i dati
servizi collegati	Connessioni Fabric / Key Vault	Creare connessioni Fabric; eseguire la migrazione dei segreti a Key Vault; effettuare il refactoring del codice del notebook

Eseguire lo strumento di valutazione Fabric

Prima di pianificare la migrazione, eseguire lo strumento di valutazione Fabric per generare un report completo dell'area di lavoro di origine Synapse. Lo strumento analizza l'area di lavoro e aggrega un riepilogo di tutti gli oggetti, ovvero pool di Spark, notebook, definizioni di processi Spark, database lake, servizi collegati e relative configurazioni, offrendo un quadro chiaro dell'ambito di migrazione.

Scaricare lo strumento. Lo strumento di valutazione Fabric è disponibile nel repository GitHub di Microsoft denominato microsoft/fabric-toolbox.
Eseguire la valutazione. Puntare lo strumento nell'area di lavoro Azure Synapse. Analizza tutti gli elementi correlati a Spark e genera un report con conteggi degli oggetti, configurazioni, dipendenze e potenziali problemi di compatibilità.
Esaminare il report. Usare l'output della valutazione per comprendere l'ambito della migrazione: quanti notebook, pool, unità SSD e database devono essere migrati, quali servizi collegati sono in uso e quali potenziali blocchi esistono (pool di GPU, funzionalità non supportate e altri).

Suggerimento

Eseguire lo strumento di valutazione all'inizio del processo di pianificazione. Il report consente di stimare lo sforzo, identificare gli ostacoli e assegnare priorità a quali carichi di lavoro migrare per primi. Funge anche da inventario di base per la fase 1 dell'elenco di controllo per la migrazione.

Modelli di migrazione

Scegliere il modello di migrazione in base ai vincoli dell'organizzazione, alla tolleranza di rischio e alla sequenza temporale.

Modello lift-and-shift (migrazione diretta)

Eseguire la migrazione di tutti i carichi di lavoro Spark contemporaneamente usando il Migration Assistant con modifiche minime. Concentrarsi sull'esecuzione di notebook e processi in Fabric il più rapidamente possibile: effettuare il refactoring solo di ciò che si rompe (servizi collegati, percorsi di file, API non supportate). Accettare l'architettura corrente as-is.

Usa la strategia di migrazione lift-and-shift quando:

L'area di lavoro di Synapse viene rimossa in base a una scadenza fissa ed è necessario spostarsi rapidamente.
I carichi di lavoro Spark sono già ben architettati (Delta-first, codice pulito, poche dipendenze del servizio collegato).
L'impronta dell'area di lavoro è abbastanza gestibile per una migrazione unica, e il team può affrontare lo sforzo di refactoring in un singolo sprint.
I consumer downstream (Power BI, API) possono tollerare una breve finestra di passaggio.

Modernizzazione in più fasi

Eseguire la migrazione incrementale dei carichi di lavoro in base alla priorità, riprogettando man mano che si procede. Iniziare prima con i carichi di lavoro con il valore più alto o con il rischio più basso. Quando si esegue la migrazione di ogni batch, consolidare i pool di Spark in un numero inferiore di ambienti, adottare le procedure consigliate di Lakehouse (Delta-first, V-Order per i consumatori di BI), abilitare NEE e riprogettare per Direct Lake.

Usare la modernizzazione in più fasi quando:

Si dispone di un ambiente Synapse di grandi dimensioni o complesso con più team e carichi di lavoro diversi che non possono essere migrati in un unico colpo.
L'architettura attuale presenta un debito tecnico che si desidera affrontare (formati non Delta, dipendenze dai punti di montaggio, pool Spark complessi).
Si ha flessibilità sulla sequenza temporale e si vuole migliorare le prestazioni e l'efficienza dei costi durante la migrazione.
I diversi carichi di lavoro hanno proprietari diversi e richiedono pianificazioni di migrazione indipendenti.

Modello di esecuzione parallela

Eseguire entrambi gli ambienti contemporaneamente durante la transizione. Instradare i nuovi carichi di lavoro Spark su Fabric mentre i carichi di lavoro legacy continuano su Synapse. Convalidare i carichi di lavoro migrati confrontando i risultati fianco a fianco prima del passaggio. Disattivare gradualmente Synapse man mano che aumenta la fiducia.

Usare un'esecuzione parallela quando:

I tuoi carichi di lavoro hanno rigidi SLA o requisiti normativi che richiedono un'estesa validazione prima del cutover.
È necessario dimostrare che le prestazioni di Fabric soddisfano o superano quelle di Synapse prima che gli stakeholder approvino la dismissione.
I consumer downstream (dashboard, API, modelli di Machine Learning) non possono tollerare alcuna discrepanza durante la transizione.
Stai eseguendo la migrazione delle pipeline di produzione in cui i risultati non corretti hanno un impatto significativo sul business (report finanziari, conformità).

L'esecuzione parallela introduce un problema di sincronizzazione dei dati che è necessario progettare in anticipo. Scegliere uno dei modelli seguenti:

Livello di archiviazione condiviso: Consentire sia a Synapse che a Fabric di leggere e scrivere nello stesso archivio ADLS Gen2 tramite collegamenti OneLake. Ciò mantiene entrambe le piattaforme sugli stessi file Delta, ma è necessario evitare conflitti di scrittura assicurandosi che una sola piattaforma scriva una determinata tabella alla volta.
Scrivi-una-volta, leggi-entrambi: Mantieni Synapse come il writer primario durante la transizione e consenti a Fabric di leggere gli stessi dati tramite scorciatoie. Dopo aver convalidato i notebook migrati in Fabric, passare al percorso di scrittura verso Fabric e rendere Synapse un consumatore in sola lettura fino alla dismissione. Questa è l'opzione più sicura per la maggior parte delle migrazioni.
Doppia scrittura: Evitare di eseguire lo stesso ETL in entrambi gli ambienti contemporaneamente, a meno che non siano già stati automatizzati gli strumenti di confronto e riconciliazione. La doppia scrittura tende a creare divergenza, duplicazione e sovraccarico operativo.

L'esecuzione parallela influisce anche sulla gestione delle modifiche. Anche se Synapse rimane l'ambiente di sviluppo attivo, qualsiasi notebook, definizione del processo Spark, configurazione del pool Spark o modifiche dello schema del database Lake apportate in Synapse non vengono riflesse automaticamente in Fabric. È necessario eseguire nuovamente la migrazione degli asset interessati per mantenere allineati entrambi gli ambienti.

Modifiche al codice dei notebook: Eseguire di nuovo l'Assistente Migrazione Spark o riesportare e reimportare manualmente i notebook aggiornati. Riapplicare qualsiasi refactoring del codice specifico di Fabric, inclusi notebookutils, l'aggiornamento dei percorsi dei file e i segreti di Key Vault.
Modifiche alla definizione del processo Spark: Rimigrare tramite il Migration Assistant o ricreare manualmente le definizioni dei processi Spark aggiornate in Fabric.
modifiche alla configurazione del pool Spark: Aggiornare l'ambiente Fabric corrispondente in modo che corrisponda alle dimensioni del nodo modificate, alle impostazioni di scalabilità automatica e alle librerie.
Lake database schema changes: Eseguire di nuovo i notebook di esportazione/importazione HMS oppure creare o modificare manualmente le tabelle interessate nella Fabric lakehouse.

Per ridurre il sovraccarico della rimigrazione, stabilire un blocco delle modifiche sul lato Synapse una volta iniziata la migrazione. Se le modifiche sono inevitabili, mantenere un log delle modifiche in modo da poterle riprodurre in Fabric prima del cutover.

Considerazioni sul rollback

La migrazione da Synapse a Fabric è un'operazione di copia, che non modifica o elimina l'area di lavoro synapse di origine. I pool, i notebook e i dati di Spark originali rimangono intatti durante tutto il processo. Questo rende il rollback semplice:

Se i risultati della migrazione non sono soddisfacenti, continuare a usare l'area di lavoro Synapse esistente. Non è necessario ripristinare alcuna modifica.
Eliminare gli elementi Fabric migrati (notebook, ambienti, definizioni di processi Spark) e riprovare dopo aver risolto i problemi.
I collegamenti di OneLake puntano all'archiviazione di ADLS Gen2 esistente. La rimozione dei collegamenti non influisce sui dati sottostanti.
Non disattivare il tuo spazio di lavoro Synapse fino a quando tutti i carichi di lavoro migrati non vengono convalidati in Fabric e i consumer a valle vengono reindirizzati.

Suggerimento

Inizia in piccolo e dimostra rapidamente la fattibilità. Selezionare un workload Spark rappresentativo ed eseguirne la migrazione completa, dalla configurazione del pool al refactoring del notebook fino alla convalida. Scegliere un elemento che esercita i modelli più comuni (accesso ai dati, servizi collegati, operazioni del catalogo), ma è sufficientemente a basso rischio per eseguire l'iterazione. Documentare i passaggi, i problemi riscontrati e le soluzioni per creare un processo ripetibile per le migrazioni successive.

Parità di funzionalità e differenze principali

Comprendere le differenze dell'architettura tra Synapse e Fabric è fondamentale per la pianificazione. Le tabelle seguenti evidenziano le differenze principali nell'architettura di calcolo e nelle funzionalità spark.

Per il confronto completo, vedere Compare Fabric e Azure Synapse Spark: Differenze principali.

Calcolo e architettura

Capacità	Azure Synapse	Microsoft Fabric
Modello di distribuzione	PaaS (configurare e gestire le risorse)	SaaS (basato sulla capacità, nessuna gestione dell'infrastruttura)
Modello di calcolo	Pool di Spark (basati su nodi); richiede almeno 3 nodi	Unità di capacità (CU) condivise tra tutti i carichi di lavoro; Pool di Spark come modelli di configurazione; esecuzione a nodo singolo supportata; Fatturazione della scalabilità automatica per Spark (con pagamento in base all'uso, simile al modello Synapse)
Motore di elaborazione Spark	Pool di Spark Synapse (Spark 3.4, 3.5); Pool di GPU supportati	Fabric Spark (Runtime 1.2/1.3/2.0: Spark 3.4-4.0); nessun supporto GPU; viene eseguito su hardware di ultima generazione per migliorare le prestazioni
Ridimensionamento	Scalabilità automatica dei nodi per Spark (min 3 nodi)	Scalabilità automatica dei nodi per Spark (minimo a nodo singolo); ridimensionamento basato sulla capacità
Avvio della sessione	Basato sul pool; Avvio a freddo per i nuovi cluster	Pool iniziali (avvio a livello di secondi); Pool live personalizzati; Modalità ad alta concorrenza
Modello di costo	Ora per nodo (Spark); pausa/ripresa	Due opzioni: (1) Fabric Spark usa un modello di consumo condiviso basato su unità di capacità (CU) o (2) Fatturazione a scalabilità automatica per Spark, con pagamento in base alla modalità Spark

Spark: Synapse Spark e Fabric Spark

Capacità	Synapse Spark	Fabric Spark
Versioni di Spark	Spark 3.4 (EOL), 3.5 (anteprima).	Spark 3.4 (RT 1.2 EOL), 3.5 (RT 1.3 GA), 4.0 (RT 2.0 Preview)
Accelerazione delle query	Nessun motore di accelerazione nativo	Motore di esecuzione nativo (Velox/Glutine, fino a 4 volte su TPC-DS)
Modello di pool	Pool fissi con numero massimo di nodi per pool; minimo 3 nodi	Pool di avvio (avvio a livello di secondi, nessuna configurazione necessaria); Pool personalizzati per dimensioni di nodo specifiche e librerie personalizzate; Esecuzione a nodo singolo supportata
Sicurezza (rete)	Rete virtuale gestita; Endpoint privati	Endpoint privati gestiti (MPE); Criteri di accesso in uscita (OAP); Chiavi gestite dal cliente (CMK)
Supporto GPU	Pool con accelerazione GPU disponibili	Non supportato
Concorrenza elevata	Non supportato	Supportato: più notebook condividono una sessione Spark
Gestione delle librerie	Librerie a livello di pool e a livello di area di lavoro; caricamento manuale di wheel, JAR, tar.gz	Gestione delle librerie basata sull'ambiente: feed pubblici (PyPI/Conda) + caricamenti personalizzati (wheel, JAR). Per replicare le librerie a livello di area di lavoro di Synapse, creare un ambiente con le librerie necessarie e impostarlo come predefinito per l'area di lavoro. Tutti i notebook e le unità SSD nell'area di lavoro lo ereditano automaticamente.
V-Order	Non disponibile	Ottimizzazione Parquet in fase di scrittura; miglioramento di 40–60% per Power BI Direct Lake e circa 10% per l'endpoint di analisi SQL; nessun vantaggio nella lettura Spark; overhead di scrittura di 15–33%
Ottimizzare la scrittura	Disattivato per impostazione predefinita	Abilitata per impostazione predefinita
Formato tabella predefinito	Parquet (facoltativo Delta)	Delta Lake (impostazione predefinita e obbligatoria per le tabelle Lakehouse)
Hive Metastore	HMS predefinito; HMS esterno tramite Azure SQL DB o MySQL (deprecato dopo Spark 3.4)	Catalogo Lakehouse di Fabric; Migrazione HMS tramite script di esportazione/importazione
DMTS nei computer portatili	Supported	Supportato nei notebook; non ancora supportato nelle definizioni dei job di Spark
Identità gestita per KV	Supported	Supportato nei notebook e nelle definizioni di processi Spark
mssparkutils	Libreria completa (fs, credentials, notebook, env, lakehouse)	notebookutils (API simile; alcune differenze nei nomi dei metodi)

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-04-28