Condividi tramite

Motore di esecuzione nativo per Fabric Spark

  • Articolo

Il motore di esecuzione nativo è un miglioramento rivoluzionario per le esecuzioni di processi Apache Spark in Microsoft Fabric. Questo motore vettorializzato ottimizza le prestazioni e l'efficienza delle query Spark eseguendole direttamente nell'infrastruttura lakehouse. L'integrazione perfetta del motore significa che non richiede modifiche al codice ed evita il blocco del fornitore. Supporta le API Apache Spark ed è compatibile con Runtime 1.2 (Spark 3.4) e funziona con entrambi i formati Parquet e Delta. Indipendentemente dalla posizione dei dati all'interno di OneLake o se si accede ai dati tramite collegamenti, il motore di esecuzione nativo ottimizza l'efficienza e le prestazioni.

Il motore di esecuzione nativo eleva significativamente le prestazioni delle query riducendo al minimo i costi operativi. Offre un notevole miglioramento della velocità, ottenendo fino a quattro volte più veloci prestazioni rispetto al tradizionale Spark OSS (software open source), come convalidato dal benchmark TPC-DS 1TB. Il motore si basa sulla gestione di un'ampia gamma di scenari di elaborazione dati, che vanno dall'inserimento di dati di routine, dai processi batch e dalle attività ETL (estrazione, trasformazione, caricamento) a complesse analisi di data science e query interattive reattive. Gli utenti traggono vantaggio dai tempi di elaborazione accelerati, dalla velocità effettiva aumentata e dall'utilizzo ottimizzato delle risorse.

Il motore di esecuzione nativo si basa su due componenti principali del sistema operativo: Velox, una libreria di accelerazione del database C++ introdotta da Meta e Apache Glutine (incubazione), un livello intermedio responsabile dell'offload dell'esecuzione dei motori SQL basati su JVM nei motori nativi introdotti da Intel.

Nota

Il motore di esecuzione nativo è attualmente disponibile in anteprima pubblica. Per altre informazioni, vedere le limitazioni correnti. In questa fase dell'anteprima non sono previsti costi aggiuntivi associati all'uso.

Quando usare il motore di esecuzione nativo

Il motore di esecuzione nativo offre una soluzione per l'esecuzione di query su set di dati su larga scala; ottimizza le prestazioni usando le funzionalità native delle origini dati sottostanti e riducendo al minimo il sovraccarico in genere associato allo spostamento e alla serializzazione dei dati negli ambienti Spark tradizionali. Il motore supporta vari operatori e tipi di dati, tra cui l'aggregazione hash rollup, il join a cicli annidati broadcast (BNLJ) e i formati di timestamp precisi. Tuttavia, per sfruttare appieno le funzionalità del motore, è consigliabile considerare i casi d'uso ottimali:

  • Il motore è efficace quando si lavora con i dati in formati Parquet e Delta, che possono essere elaborati in modo nativo ed efficiente.
  • Le query che comportano trasformazioni e aggregazioni complesse traggono vantaggio in modo significativo dalle funzionalità di elaborazione e vettorizzazione a colonne del motore.
  • Il miglioramento delle prestazioni è particolarmente importante negli scenari in cui le query non attivano il meccanismo di fallback evitando funzionalità o espressioni non supportate.
  • Il motore è particolarmente adatto per le query che richiedono un utilizzo intensivo del calcolo, anziché semplici o associate a I/O.

Per informazioni sugli operatori e sulle funzioni supportate dal motore di esecuzione nativo, vedere la documentazione di Apache Gluten.

Abilitare il motore di esecuzione nativo

Per usare le funzionalità complete del motore di esecuzione nativo durante la fase di anteprima, sono necessarie configurazioni specifiche. Le procedure seguenti illustrano come attivare questa funzionalità per notebook, definizioni di processi Spark e interi ambienti.

Importante

Il motore di esecuzione nativo supporta attualmente la versione più recente del runtime ga, ovvero Runtime 1.2 (Apache Spark 3.4, Delta Lake 2.4).

Abilitare per un notebook o una definizione di processo Spark

Per abilitare il motore di esecuzione nativo per un singolo notebook o una definizione di processo Spark, è necessario incorporare le configurazioni necessarie all'inizio dello script di esecuzione:

%%configure 
{ 
   "conf": {
       "spark.native.enabled": "true", 
       "spark.gluten.enabled": "true", 
       "spark.shuffle.manager": "org.apache.spark.shuffle.sort.ColumnarShuffleManager" 
   } 
}

Per i notebook, inserire i comandi di configurazione necessari nella prima cella. Per le definizioni dei processi Spark, includere le configurazioni nella prima linea della definizione del processo Spark.

Screenshot che mostra come abilitare il motore di esecuzione nativo all'interno del notebook.

Il motore di esecuzione nativo è integrato con pool personalizzati, vale a dire che l'abilitazione di questa funzionalità avvia una nuova sessione, in genere richiede fino a due minuti per l'avvio.

Importante

La configurazione del motore di esecuzione nativo deve essere eseguita prima dell'avvio della sessione Spark. Dopo l'avvio della sessione Spark, l'impostazione spark.shuffle.manager diventa non modificabile e non può essere modificata. Assicurarsi che queste configurazioni siano impostate all'interno del %%configure blocco nei notebook o nel generatore di sessioni Spark per le definizioni dei processi Spark.

Abilitare a livello di ambiente

Per garantire un miglioramento uniforme delle prestazioni, abilitare il motore di esecuzione nativo in tutti i processi e i notebook associati all'ambiente:

  1. Passare alle impostazioni dell'ambiente.

  2. Passare alle proprietà di Spark.

  3. Completare i campi nella schermata delle proprietà spark, come illustrato nell'immagine seguente.

Proprietà valore
spark.native.enabled true
spark.gluten.enabled true
spark.shuffle.manager org.apache.spark.shuffle.sort.ColumnarShuffleManager

Screenshot che mostra come abilitare il motore di esecuzione nativo all'interno dell'elemento dell'ambiente.

Se abilitata a livello di ambiente, tutti i processi e i notebook successivi ereditano l'impostazione. Questa ereditarietà garantisce che qualsiasi nuova sessione o risorsa creata nell'ambiente tragga automaticamente vantaggio dalle funzionalità di esecuzione avanzate.

Controllo a livello di query

I meccanismi per abilitare il motore di esecuzione nativo a livello di tenant, area di lavoro e ambiente, perfettamente integrati con l'interfaccia utente, sono in fase di sviluppo attivo. Nel frattempo, è possibile disabilitare il motore di esecuzione nativo per query specifiche, in particolare se coinvolgono operatori non attualmente supportati (vedere limitazioni). Per disabilitare, impostare spark.gluten.enabled sulla configurazione spark.enabled su false per la cella specifica contenente la query.

%%sql 
SET spark.native.enabled=FALSE; 
SET spark.gluten.enabled=FALSE;

Screenshot che mostra come disabilitare il motore di esecuzione nativo all'interno di un notebook.

Dopo aver eseguito la query in cui il motore di esecuzione nativo è disabilitato, è necessario riabilitarlo per le celle successive impostando spark.glutin.enabled su true. Questo passaggio è necessario perché Spark esegue le celle di codice in sequenza.

%%sql 
SET spark.native.enabled=TRUE; 
SET spark.gluten.enabled=TRUE;

Identificare le operazioni eseguite dal motore

Esistono diversi metodi per determinare se un operatore nel processo Apache Spark è stato elaborato usando il motore di esecuzione nativo.

Interfaccia utente Spark e server cronologia Spark

Accedere all'interfaccia utente spark o al server cronologia Spark per individuare la query da esaminare. Nel piano di query visualizzato all'interno dell'interfaccia cercare i nomi di nodo che terminano con il suffisso Transformer. Il suffisso indica che il motore di esecuzione nativo ha eseguito l'operazione. Ad esempio, i nodi possono essere etichettati come RollUpHashAggregateTransformer, ProjectExecTransformer, BroadcastHashJoinExecTransformer, ShuffledHashJoinExecTransformer o BroadcastNestedLoopJoinExecTransformer.

Screenshot che mostra come controllare la visualizzazione DAG che termina con il suffisso Transformer.

Spiegazione del dataframe

In alternativa, è possibile eseguire il df.explain() comando nel notebook per visualizzare il piano di esecuzione. All'interno dell'output cercare gli stessi suffissi transformer . Questo metodo consente di verificare rapidamente se le operazioni specifiche vengono gestite dal motore di esecuzione nativo.

Screenshot che mostra come controllare il piano fisico per la query e vedere che la query è stata eseguita dal motore di esecuzione nativo.

Meccanismo di fallback

In alcuni casi, il motore di esecuzione nativo potrebbe non essere in grado di eseguire una query a causa di motivi come le funzionalità non supportate. In questi casi, l'operazione esegue il fallback al motore Spark tradizionale. Questo meccanismo di fallback garantisce che non vi sia alcuna interruzione del flusso di lavoro.

Screenshot che mostra il meccanismo di fallback.

Screenshot che mostra come controllare i log associati al meccanismo di fallback.

Limiti

Anche se il motore di esecuzione nativo migliora le prestazioni per i processi Apache Spark, tenere presente le limitazioni correnti.

  • Il motore non supporta la scrittura partizionata per le tabelle Delta. Alcune operazioni specifiche di Delta non sono supportate, incluse le operazioni di merge, le analisi dei checkpoint e i vettori di eliminazione.
  • Alcune funzionalità ed espressioni Spark non sono compatibili con il motore di esecuzione nativo, ad esempio funzioni definite dall'utente (UDF) e la array_contains funzione, nonché lo streaming strutturato spark. L'utilizzo di queste operazioni o funzioni incompatibili come parte di una libreria importata causerà anche il fallback al motore Spark.
  • Le analisi dalle soluzioni di archiviazione che usano endpoint privati non sono supportate.
  • Il motore non supporta la modalità ANSI, quindi cerca e una volta abilitata la modalità ANSI, viene eseguito il fallback a vanilla Spark.

Quando si usano filtri di data nelle query, è essenziale assicurarsi che i tipi di dati su entrambi i lati del confronto corrispondano per evitare problemi di prestazioni. I tipi di dati non corrispondenti potrebbero non portare il boost di esecuzione delle query e potrebbero richiedere cast espliciti. Assicurarsi sempre che i tipi di dati del lato sinistro (LHS) e del lato destro (RHS) di un confronto siano identici, perché i tipi non corrispondenti non verranno sempre eseguiti automaticamente. Se una mancata corrispondenza del tipo non è inevitabile, usare il cast esplicito per trovare le corrispondenze con i tipi di dati, ad esempio CAST(order_date AS DATE) = '2024-05-20'. Le query con tipi di dati non corrispondenti che richiedono il cast non verranno accelerate dal motore di esecuzione nativo, quindi garantire la coerenza dei tipi è fondamentale per mantenere le prestazioni. Ad esempio, anziché order_date = '2024-05-20' dove order_date è DATETIME e la stringa è DATE, eseguire il cast order_date esplicito per DATE garantire tipi di dati coerenti e migliorare le prestazioni.

Nota

Il motore di esecuzione nativo è attualmente in anteprima e le informazioni dettagliate sono importanti per microsoft. Invitiamo l'utente a condividere il feedback e i risultati della valutazione direttamente con il team del prodotto. Compilare il modulo di feedback. Non vediamo l'ora del vostro prezioso input e siamo desiderosi di discutere i vostri risultati in dettaglio.

Contenuto correlato