Scegliere un kernel del notebook in Microsoft Fabric

I notebook in Microsoft Fabric supportano tre tipi di kernel: Python, Spark e T-SQL. Il kernel Spark supporta quattro linguaggi, PySpark, SparkSQL, Scala e SparkR, tutti supportati dallo stesso calcolo Spark. Questa guida è incentrata sulla decisione tra il kernel Python e il kernel Spark, poiché questi kernel sono le scelte più comuni per i carichi di lavoro di progettazione dei dati. Entrambi vengono eseguiti nella stessa esperienza notebook, ma differiscono in termini di modello di calcolo, scalabilità, funzionalità del motore e compatibilità Delta Lake. Questa guida fornisce una valutazione bilanciata che consente di scegliere il kernel corretto ed evitare errori comuni sui costi e sulle prestazioni.

Importante

La scelta del kernel del notebook non riguarda semplicemente i costi o le dimensioni dei dati. La configurazione di calcolo, i requisiti delle funzionalità Delta Lake, la maturità del motore e la crescita dei dati prevista svolgono tutti ruoli importanti per prendere la decisione giusta.

Informazioni sulle opzioni di calcolo

Un malinteso comune è che il kernel Python è sempre più economico del kernel Spark per carichi di lavoro di dati di piccole dimensioni. In realtà, il costo dipende dalla modalità di configurazione del calcolo per ogni kernel.

Python calcolo del kernel

Il kernel Python viene eseguito in un computer a nodo singolo che per impostazione predefinita è 2 vCore (1 CU) e può essere configurato per l'avvio fino a 64 vCore (32 CU). Questo ambiente non ha alcuna esecuzione distribuita. Il pool di avvio viene inizializzato in circa 5 secondi, rendendolo veloce per il lavoro interattivo.

Calcolo del kernel Spark

Il kernel Spark usa pool di Spark con diverse opzioni di configurazione:

Configurazione del cluster vCore disponibili per gli esecutori Ora di inizio sessione CU consumate dopo l'inizio della sessione
Pool di avvio (impostazione predefinita) Nodi di lavoro a 8 core, scalabilità automatica abilitata; viene avviato come nodo singolo e viene ridimensionato in modo proattivo a un ruolo di lavoro dedicato entro pochi minuti dall'avvio della sessione ~5 secondi 8 unità di calcolo (minimo, dopo l'aumento proattivo delle prestazioni)
Single-node*, 8-vCore (tramite pool di avvio) L'executor e il driver a 8 core condividono lo stesso nodo ~5 secondi (con pool preriscaldato) 4 CU
Pool personalizzato a nodo singolo*, 4-vCore L'executor e il driver a 4 core condividono lo stesso nodo Richiede un pool personalizzato; l'avvio della sessione è in genere compreso tra 3 e 5 minuti 2 CUs
Pool personalizzato multinodo Scalabilità con dimensioni del cluster L'avvio della sessione è in genere compreso tra 3 e 5 minuti Variabile

Quando si usa il pool di avvio, una sessione Spark a nodo singolo 8-vCore inizia in circa 5 secondi, paragonabile al kernel Python. Un cluster Spark a nodo singolo mantiene costi simili al kernel Python, fornendo al contempo l'accesso a tutte le funzionalità native di Spark, incluso il motore di esecuzione nativo .

Annotazioni

Esistono due modi per configurare pool spark a nodo singolo. Per la maggior parte dei carichi di lavoro, è in genere consigliabile usare il primo metodo Overprovisioned a nodo singolo. Il secondo metodo, classico a nodo singolo è migliore quando sono presenti processi pesanti del driver, ma vincola la quantità di risorse utilizzabili dagli executor spark.

  • Nodo singolo con overprovisioning: inizia con un pool Spark (ovvero Starter Pool) configurato con ridimensionamento automatico e allocazione dinamica abilitati, con ridimensionamento automatico impostato da 1 a > 1 nodo. Creare un elemento Environment che fa riferimento al pool di Spark e impostare il numero di executor su 1. I notebook che usano questo ambiente vengono predisposti con un cluster Spark a nodo singolo, in cui sia il driver che l'executor condividono tutte le risorse.
  • Nodo singolo classico: creare un pool di Spark con il numero massimo di nodi impostato su 1. Questa configurazione funziona con la scalabilitàautomatica e l'allocazione dinamica abilitata o disabilitata, perché la selezione non ha alcun effetto sulla strategia di provisioning. I notebook che usano questo pool di Spark hanno 50% di v-core allocati al driver e 50% allocati come executor.

Prestazioni in base alla scalabilità del carico di lavoro

I benchmark che confrontano Fabric Spark con il motore di esecuzione nativo con motori di Python a computer singolo (ad esempio Pandas, DuckDB o Polars) nei carichi di lavoro ELT end-to-end mostrano modelli chiari in base alla scalabilità dei dati:

Scala dati (compressi) Vantaggio del motore
Ultra-piccolo (< ~140 MB) I motori a macchina singola Python (DuckDB, Polars) sono più veloci.
Piccolo (~1-2 GB) I motori Python mantengono ancora un vantaggio, ma Fabric Spark con NEE diventa competitivo con l’aumentare del numero di core disponibili per ciascun motore, in particolare nelle operazioni ad alta intensità di scrittura.
Medio medio (~10-13 GB) Fabric Spark con il motore di esecuzione nativo è competitivo o più veloce della maggior parte dei motori che operano su una singola macchina. I motori Python su singola macchina possono incorrere in errori di esaurimento della memoria (OOM) con un numero inferiore di vCore.
Media e superiore (~100 GB+) Per la maggior parte dei carichi di lavoro, Fabric Spark con il motore di esecuzione nativo è il motore più veloce e affidabile.

Scalabilità oltre i dati di piccole dimensioni

Prendere in considerazione il tasso di crescita dei dati quando si seleziona un motore. I motori di Python non distribuiti funzionano bene per dati veramente piccoli, ma la migrazione del codice quando i dati superano i limiti sono costosi. A partire da Spark in una configurazione a nodo singolo, è possibile passare facilmente a una configurazione multinodo senza riscrivere le pipeline di progettazione dei dati.

La compatibilità Delta Lake

La compatibilità delta Lake è una considerazione fondamentale quando si seleziona un motore. Fabric Spark offre supporto Delta Lake nativo e completo, mentre i motori di Python possono avere lacune significative:

Importante

La tabella di supporto delle funzionalità seguente riflette lo stato di ogni motore a partire da giugno 2026 ed è basato su test diretti su Fabric Spark Runtime 1.3 e 2.0. L'ecosistema open source di Python per Delta Lake si evolve rapidamente: delta-rs, DuckDB e Polars rilasciano frequentemente nuove versioni che aggiungono periodicamente un supporto esteso al protocollo Delta. Verificare sempre la documentazione corrente e le note sulla versione per ogni motore prima di basarsi su una funzionalità specifica nell'ambiente di produzione:

Funzionalità Delta Lake Fabric Spark delta-rs (Python) DuckDB Polars
Leggi le tabelle Delta ✅ ✅ ✅ ✅
Scrivere tabelle Delta ✅ ✅ Aggiungere, sovrascrivere (incluso quello basato su predicato), UPDATE, DELETE, MERGE ⚠️ Solo INSERT (richiede ATTACH ... (TYPE delta, READ_WRITE)); nessuna operazione UPDATE/DELETE/MERGE; usare delta-rs per altre operazioni di scrittura ⚠️ Aggiunta, sovrascrittura (inclusa quella basata su predicati), solo merge; nessun UPDATE/DELETE
Garanzie ACID/Controllo della concorrenza ottimistica ✅ ✅ ⚠️ INSERT è solo in append; nessun rilevamento nativo dei conflitti; usare delta-rs con version pinning per l'isolamento lettura-poi-scrittura ⚠️ OCC sulle scritture; le letture di Polars sono al di fuori del perimetro della transazione: richiedono il version pinning esplicito per l'isolamento lettura- quindi scrittura
Evoluzione dello schema in fase di scrittura ✅ ✅ ❌ Nessuna evoluzione dello schema in INSERT ✅
Mapping delle colonne ✅ ❌ ✅ ❌
Vettori di eliminazione (lettura) ✅ ❌ ✅ ✅
Vettori di eliminazione (scrittura) ✅ ❌ ❌ ❌
Ampliare il tipo (lettura) ✅ ❌ ✅ ❌
Ampliare il tipo (scrittura) ✅ ❌ ❌ ❌
Esclusione dei file ✅ ✅ ✅ ✅
Operazioni di scrittura partizionate ✅ ✅ ❌ Usare delta-rs per scrivere con il partizionamento ✅
Liquid Clustering (scrittura) ✅ ❌ ❌ ❌
Tempo di viaggio ✅ ✅ ✅ ✅
RESTORE ✅ ✅ ❌ Usare delta-rs per ripristinare le tabelle ❌ Usare delta-rs per ripristinare le tabelle
Clone parziale (creazione) ✅ ❌ ❌ ❌
Clone parziale (lettura) ✅ ❌ ❌ ❌
Tracciamento delle righe ✅ ⚠️ Le operazioni di lettura e scrittura riescono, ma il tracciamento _metadata delle righe non è accessibile; le pipeline che si basano su row_id per la deduplicazione o l'acquisizione delle modifiche ai dati (CDC) devono utilizzare Spark per la lettura ⚠️ Le operazioni di lettura e scrittura riescono, ma il tracciamento _metadata delle righe non è disponibile; le pipeline che si affidano a row_id per la deduplicazione o il CDC devono usare Spark per la lettura ⚠️ Le operazioni di lettura e scrittura riescono, ma il tracciamento _metadata delle righe non è disponibile; le pipeline che si affidano a row_id per la deduplicazione o il CDC devono usare Spark per la lettura
Colonne di identità (sola lettura) ✅ ✅ ✅ ✅
Colonne di identità (scrittura) ✅ ❌ ❌ ❌
Colonne generate (sola lettura) ✅ ✅ ✅ ✅
Colonne generate (scrittura) ✅ ❌ ❌ ❌
Feed di dati delle modifiche (lettura) ✅ ✅ ❌ Usare delta-rs per leggere il feed di dati delle modifiche ❌ Usare delta-rs per leggere il feed di dati delle modifiche
Feed di dati delle modifiche (scrittura) ✅ ❌ ❌ ❌
Punti di controllo V2 (lettura) ✅ ❌ ✅ ❌
Punti di controllo V2 (scrittura) ✅ ❌ ❌ ❌
Intervallo di checkpoint ✅ Configurabile (impostazione predefinita 10) ⚠️ Configurabile (impostazione predefinita 100) ❌ INSERT non scrive i checkpoint; il log cresce senza limiti senza manutenzione esterna tramite delta-rs ⚠️ Configurabile (impostazione predefinita 100)
OTTIMIZZA ✅ ✅ ❌ Usare delta-rs per ottimizzare ❌ Usare delta-rs per ottimizzare
Compattazione automatica ✅ ❌ ❌ ❌
VUOTO ✅ ❌ Rischio: accumulo di file orfani ❌ Rischio: accumulo di file orfani ❌ Rischio: accumulo di file orfani
VACUUM LITE ✅ ✅ ❌ Usare delta-rs per eseguire il vacuum lite ❌ Usare delta-rs per eseguire il vacuum lite

Implicazioni chiave:

  • Funzionalità più recenti di Delta: il supporto per le funzionalità più recenti di Delta Lake, tra cui l'estensione dei tipi, i checkpoint v2, il liquid clustering, le colonne di identità, le scritture nel Change Data Feed e le letture di shallow clone, è incoerente o assente nei motori Python open source. Se la pipeline di dati dipende da una di queste funzionalità, usare Fabric Spark. Considerate i motori Python come un complemento a Spark per carichi di lavoro specifici (letture leggere, sviluppo locale, semplici aggiunte in coda) anziché come una sostituzione per uso generale.

  • Vettori di eliminazione: i vettori di eliminazione sono una procedura consigliata per le tabelle Delta (abilitate per impostazione predefinita a partire da Fabric Spark Runtime 2.0) perché migliorano notevolmente le prestazioni delle operazioni MERGE, UPDATE e DELETE tramite una strategia di merge on-read. Nessun motore di Python (delta-rs, DuckDB o Polars) supporta la scrittura di vettori di eliminazione. Se si usa un motore di Python per scrivere in tabelle con vettori di eliminazione abilitati, si verificano errori di compatibilità.

  • Garanzie ACID: non tutti i motori Python forniscono garanzie ACID native. Delta-rs supporta il controllo della concorrenza ottimistica (OCC) per operazioni di merge, aggiornamento ed eliminazione. Tuttavia, le pipeline tra motori in cui DuckDB o Polars esegue la lettura e delta-rs esegue la scrittura richiedono l'aggiunta esplicita della versione su entrambi i lati per mantenere l'isolamento di lettura-scrittura. L'INSERT di DuckDB è un'operazione di solo accodamento senza rilevamento dei conflitti.

  • Checkpointing: non tutti i motori Python scrivono checkpoint e quelli che lo fanno usano per impostazione predefinita un checkpoint ogni 100 commit, anziché ogni 10 commit, che è il valore predefinito di Spark. L'operazione INSERT di DuckDB non scrive mai checkpoint, causando la crescita senza limiti del log delle transazioni di Delta. Valutare la possibilità di impostare un intervallo di checkpoint più breve in delta-rs e Polars, ed eseguire periodicamente la manutenzione con delta-rs per le tabelle create con DuckDB.

  • Rilevamento delle righe: tutti i motori di Python possono leggere e scrivere in tabelle con il rilevamento delle righe abilitato, ma la _metadata colonna contenente row_id e row_commit_version non è accessibile all'esterno di Spark. Le pipeline che si basano su row_id per la deduplicazione o CDC devono usare Spark per la lettura.

  • OPTIMIZE e VACUUM: i motori di Python si basano sulla deltalake libreria per la compattazione e il vuoto. Anche se delta-rs può essere veloce per queste operazioni, questo approccio introduce una gestione aggiuntiva delle dipendenze e le operazioni non vengono orchestrate in modo nativo nel modo in cui si trovano in Spark. Le tabelle scritte esclusivamente tramite motori di Python accumulano file di piccole dimensioni e log delle transazioni non associati senza manutenzione esplicita.

  • Cloni superficiali: i motori di Python non supportano la lettura delle tabelle create tramite clone superficiale a causa di limitazioni assolute di risoluzione del percorso. Nessun motore di Python supporta la creazione di cloni superficiali.

Maturità del motore e supporto Microsoft

Supporto per Fabric Spark

Fabric Spark è Microsoft fork di Apache Spark open source. Microsoft gestisce e spedisce il runtime, ovvero:

  • Microsoft supporta gli elementi interni di Spark e Delta Lake end-to-end, incluso il motore di esecuzione nativo (NEE), basato su Velox e Apache Glutine.
  • È possibile aprire ticket di supporto per il comportamento di Spark, piani di query, problemi di memoria e bug del motore.
  • I miglioramenti delle prestazioni vengono continuamente forniti come parte degli aggiornamenti di runtime di Fabric. Il codice esistente diventa più veloce senza modifiche al codice.

supporto del motore di Python

Microsoft non mantiene un fork di motori OSS Python come DuckDB o Polars. Il supporto è limitato ai problemi nelle integrazioni di OneLake fornite come parte del runtime di Fabric, ad esempio l'autenticazione o l'accesso al file system. Se si verifica una regressione delle prestazioni, un bug del motore o un'API interrotta tra le versioni della libreria, è necessario interagire direttamente con le community open source per tali librerie.

Maturità operativa

Esperienza reale nella creazione di benchmark ELT end-to-end con questi motori evidenzia differenze significative nella maturità operativa:

  • Spark: il codice scritto per una versione di runtime viene eseguito senza modifiche nelle versioni più recenti ed esegue più velocemente a causa di un continuo investimento di progettazione Microsoft. Spark UI e la telemetria di Fabric offrono monitoraggio in tempo reale e visibilità completa sulle query attive, sui piani di esecuzione e sulla cronologia delle esecuzioni dei processi.
  • DuckDB e Polars: le modifiche all'API e al comportamento tra le versioni possono richiedere il refactoring del codice man mano che i motori si evolvono e le API. Entrambi i motori non dispongono del monitoraggio in tempo reale: quando un processo viene eseguito più a lungo del previsto, non esiste un equivalente all'interfaccia utente di Spark per comprendere cosa accade. L'autenticazione a OneLake può richiedere soluzioni alternative specifiche della versione.
  • Sovraccarico dello stack di dati componibile: l'uso di DuckDB o Polars per un flusso di lavoro ELT completo significa in genere unire più librerie ( ad esempio DuckDB per l'analisi e la trasformazione dei dati, delta-rs per operazioni di scrittura e manutenzione). La compatibilità della libreria deve essere mantenuta tra i componenti e deve essere considerata ogni volta che la versione della libreria viene aggiornata oltre a quanto fornito nel runtime.

Indicazioni sulle decisioni

Usa il kernel di Python quando

  • I tuoi dati sono ridotti, inferiori a circa 1 GB compressi, e contano soprattutto le prestazioni pure dei motori su singola macchina.
  • Si sta creando un'orchestrazione dell'API leggera, integrazioni REST/gRPC o automazione del flusso di controllo in cui il calcolo distribuito comporta un sovraccarico non necessario.
  • Si sta eseguendo un'esplorazione interattiva rapida di set di dati di piccole dimensioni in cui la latenza delle query ad hoc è la priorità.
  • Il carico di lavoro richiede una versione Python precedente rispetto a quella fornita nel runtime di Spark Fabric corrente.
  • Si conoscono e si accettano le limitazioni delle funzionalità Delta Lake del motore di Python in uso.

Usa il kernel di Spark quando

  • I dati sono pari o superiori a 1 GB in forma compressa, oppure si prevede che raggiungano tali dimensioni.
  • Hai bisogno della piena compatibilità con Delta Lake, inclusi i vettori di eliminazione, la mappatura delle colonne, l'ampliamento dei tipi, OPTIMIZE, VACUUM e le garanzie ACID.
  • Hai bisogno di funzionalità di livello produttivo, come variabili di ambiente, gestione delle librerie basata sugli elementi, elevata concorrenza e pianificazione dei processi FAIR o first-in, first-out (FIFO).
  • È necessario il monitoraggio live e la visibilità operativa completa dei processi in esecuzione.
  • Ci si basa su API native di Spark, ad esempio MLlib, Spark SQL o Spark Streaming.
  • Vuoi il supporto end-to-end di Microsoft per il tuo motore di elaborazione dei dati.
  • Si vuole poter passare dal calcolo a nodo singolo al calcolo multinodo senza riscrivere il codice.
  • È necessario creare notebook in PySpark, SparkSQL, Scala o SparkR.

Suggerimento

Per i carichi di lavoro con scalabilità compressa o superiore a 1 GB, è consigliabile iniziare con un cluster Spark a nodo singolo 8-vCore usando il pool di avvio. Si ottiene un avvio della sessione pressoché istantaneo, tutte le funzionalità di Fabric Spark, incluso NEE, e la possibilità di scalare a più nodi quando necessario, il tutto continuando a operare su un solo nodo, proprio come il kernel Python.

Differenze principali a colpo d'occhio

Categoria Kernel Python Kernel Spark
Calcolo predefinito Macchina virtuale a nodo singolo a 2 vCore (VM) (scalabile fino a 64 vCore) Pool di avvio: nodi di lavoro 8-vCore con scalabilità automatica
Configurazione minima a nodo singolo 2 vCore 8 vCore (pool di avvio, ~5 sec start); 4 vCore (pool personalizzato, avvio più lungo)
Ora di avvio ~5 secondi ~5 secondi (pool di avvio); più a lungo per i pool personalizzati
Esecuzione distribuita No Sì
Lingue disponibili Python PySpark, SparkSQL, Scala, SparkR
Versione di Python Più versioni disponibili Legato alla versione del runtime di Fabric Spark
Delta Lake (supporto completo delle funzionalità) No Sì
Monitoraggio in tempo reale Limited Completo (pagina monitoraggio processi + interfaccia utente Spark)
supporto del motore Microsoft Solo integrazioni di OneLake Supporto completo per il runtime
accesso alla libreria Python Installazione di pip pip install + elementi dell'ambiente
API Spark native (MLlib, Streaming) No Sì
Funzionalità di produzione (env vars, ambienti) Limited Completo
Supporto della concorrenza elevata No Sì
V-order per modelli semantici veloci di Direct Lake No Sì
Cache dell'archivio oggetti che consente di accelerare le letture ripetute Dipende dal motore (DuckDB ha una cache integrata, Polars no) Sì (cache intelligente)
Scalabilità a più nodi No Sì

Glossario

  • Transazioni ACID: set di proprietà (Atomicità, Coerenza, Isolamento, Durabilità) che garantiscono l'elaborazione affidabile delle operazioni del database. Delta Lake implementa la semantica ACID usando il controllo della concorrenza ottimistica e i log delle transazioni.
  • Controllo della concorrenza ottimistica (OCC): strategia di concorrenza in cui le transazioni procedono senza blocco, quindi verificare in fase di commit che non si siano verificate modifiche in conflitto. Delta Lake usa OCC; le pipeline multi-engine (ad esempio, letture con Polars seguite da scritture con delta-rs) richiedono un version pinning esplicito per mantenere l'isolamento.
  • Compattazione automatica: una funzionalità Delta Lake nel runtime di Fabric Spark che unisce automaticamente file di piccole dimensioni in file più grandi dopo le operazioni di scrittura, riducendo la frammentazione dei file senza un passaggio OPTIMIZE separato.
  • Change Data Feed (CDF): funzionalità Delta Lake che registra le modifiche a livello di riga (inserimento, aggiornamento, eliminazione) in una tabella, abilitando l'elaborazione incrementale dei dati e le pipeline CDC. Solo Fabric Spark supporta la scrittura di metadati CDF (Change Data Feed); I motori di Python OSS possono leggere ma non produrlo.
  • Mappatura delle colonne: una funzionalità di Delta Lake che consente di rinominare o eliminare le colonne senza riscrivere i file Parquet sottostanti. Supportato da Fabric Spark; non supportato da delta-rs o Polars.
  • delta-rs: un'implementazione open source in Rust del protocollo Delta Lake con binding Python (il pacchetto deltalake PyPI). Fornisce supporto di lettura/scrittura Delta negli ambienti Python OSS, ma offre una copertura funzionale più limitata rispetto a delta-spark, che supporta il runtime Fabric Spark.
  • Vettori di eliminazione: ottimizzazione Delta Lake che usa operazioni merge-on-read per ridurre la quantità di dati riscritti durante le operazioni MERGE, UPDATE e DELETE. Abilitato per impostazione predefinita in Fabric Spark Runtime 2.0; non supportato per le scritture da parte di qualsiasi motore di Python OSS.
  • Pianificazione FAIR: criteri di pianificazione Spark che allocano le risorse del cluster in modo equo tra processi simultanei, assicurando che nessun singolo processo monopolizzi il cluster.
  • Pianificazione FIFO: un criterio di pianificazione di Spark che esegue i job in ordine di arrivo (First-In-First-Out), dando priorità al primo job inviato.
  • Liquid Clustering: una funzionalità di Delta Lake che riorganizza i dati in modo incrementale per ottimizzare le prestazioni delle query senza richiedere un partizionamento esplicito. Supportato solo da Fabric Spark.
  • NEE (Native Execution Engine): un motore di query C++ vettorializzato basato su Velox e Apache Gluten che accelera i carichi di lavoro di Fabric Spark. NEE è disponibile senza costi di calcolo aggiuntivi e non richiede modifiche al codice.
  • Tracciamento delle righe: una funzionalità di Delta Lake che assegna a ogni riga un row_id e un row_commit_version stabili tramite una colonna _metadata. Tutti i motori possono leggere e scrivere in tabelle con il rilevamento delle righe abilitato, ma solo Fabric Spark può accedere al contenuto della _metadata colonna.
  • Pool di Spark: risorsa di calcolo condivisa per l'esecuzione di carichi di lavoro Spark distribuiti. Il pool iniziale fornisce nodi preriscaldati per tempi di avvio della sessione pressoché istantanei (~5 secondi), con la scalabilità automatica abilitata per impostazione predefinita.
  • V-order: un'ottimizzazione della scrittura Fabric che ordina e comprime i dati Parquet in modo da migliorare le prestazioni di lettura per i modelli semantici Power BI Direct Lake e altri percorsi di lettura Fabric.
  • Cache intelligente: cache del disco intelligente in Fabric Spark che accelera le letture ripetute degli stessi file di tabella Delta memorizzando i dati dei file nella cache localmente nei nodi executor.

Contenuti correlati

  • Last updated on