Condividi tramite

Runtime di Fabric 1.2 (GA)

  • Articolo

Il runtime di Microsoft Fabric è una piattaforma integrata in Azure basata su Apache Spark che consente l'esecuzione e la gestione di esperienze di data engineering e data science. Questo documento illustra i componenti e le versioni del Runtime 1.2.

I componenti principali del Runtime 1.2 includono:

  • Apache Spark 3.4.1
  • Sistema operativo: Mariner 2.0
  • Java: 11
  • Scala: 2.12.17
  • Python: 3.10
  • Delta Lake: 2.4.0
  • R: 4.2.2

Suggerimento

Usare sempre la versione di runtime ga più recente per il carico di lavoro di produzione, che attualmente è Runtime 1.3.

Screenshot che mostra dove selezionare la versione del runtime.

Il Runtime 1.2 di Microsoft Fabric include una raccolta di pacchetti a livello predefinito, tra cui un'installazione completa di Anaconda e librerie comunemente usate per Java/Scala, Python e R. Queste librerie sono incluse automaticamente quando si usano notebook o processi nella piattaforma Microsoft Fabric. Per un elenco completo delle librerie, vedere la documentazione. Microsoft Fabric implementa periodicamente gli aggiornamenti di manutenzione per il Runtime 1.2, fornendo correzioni di bug, miglioramenti delle prestazioni e patch di sicurezza. Rimanere aggiornati garantisce prestazioni e affidabilità ottimali per le attività di elaborazione dei dati.

Nuove funzionalità e miglioramenti della Release 3.4.1 di Spark

Apache Spark 3.4.0 è la quinta release nella linea 3.x. Questa release, basata sulla community open source, ha risolto oltre 2.600 ticket Jira. Introduce un client Python per Spark Connect, migliora Structured Streaming con il rilevamento dello stato asincrono e l'elaborazione con stato Python. Espande la copertura dell'API Pandas con il supporto dell'input NumPy, semplifica la migrazione dai data warehouse tradizionali tramite la conformità ANSI e nuove funzioni predefinite. Migliora anche la produttività della distribuzione e il debug con la profilatura della memoria. Inoltre, il Runtime 1.2 è basato su Apache Spark 3.4.1, una versione di manutenzione incentrata su correzioni per la stabilità.

In primo piano

Leggere la versione completa delle note sulla versione per una versione specifica di Apache Spark visitando sia Spark 3.4.0 che Spark 3.4.1.

Nuove ottimizzazioni di query personalizzate

Supporto scritture simultanee in Spark

Se si verifica un errore 404 con il messaggio "Operazione non riuscita: il percorso specificato non esiste", si tratta di un problema comune quando si eseguono inserimenti di dati paralleli nella stessa tabella usando una query SQL INSERT INTO. Questo errore può comportare la perdita di dati. La nuova funzionalità, l'algoritmo di commit dell'output dei file, risolve questo problema, consentendo ai clienti di eseguire facilmente l'inserimento parallelo dei dati.

Per accedere a questa funzionalità, abilitare il flag della funzionalità spark.sql.enable.concurrentWrites, che è abilitato per impostazione predefinita a partire dal Runtime 1.2 (Spark 3.4). Anche se questa funzionalità è disponibile anche in altre versioni di Spark 3, non è abilitata per impostazione predefinita. Questa funzionalità non supporta l'esecuzione parallela di query INSERT OVERWRITE in cui ogni processo simultaneo sovrascrive i dati in partizioni diverse della stessa tabella in modo dinamico. A questo scopo, Spark offre una funzionalità alternativa che può essere attivata configurando l'impostazione spark.sql.sources.partitionOverwriteMode su dinamica.

Letture intelligenti, che ignorano i file di processi non riusciti

Nel sistema di commit di Spark corrente, quando un inserimento in un processo di tabella ha esito negativo ma alcune attività hanno esito positivo, i file generati dalle attività riuscite coesistono con i file del processo non riuscito. Questa coesistenza può causare confusione per gli utenti perché diventa difficile distinguere tra i file appartenenti a processi riusciti e non riusciti. Inoltre, quando un processo legge da una tabella mentre un altro inserisce i dati contemporaneamente nella stessa tabella, il processo di lettura potrebbe accedere a dati di cui non è stato eseguito il commit. Se un processo di scrittura non riesce, il processo di lettura potrebbe elaborare dati non corretti.

Il flag spark.sql.auto.cleanup.enabled controlla la nuova funzionalità risolvendo questo problema. Quando è abilitato, Spark ignora automaticamente la lettura di file che non sono stati sottoposti a commit quando esegue spark.read o seleziona query da una tabella. I file scritti prima di abilitare questa funzionalità continuano a essere letti normalmente.

Di seguito sono indicate le modifiche visibili:

  • Tutti i file ora includono un identificatore tid-{jobID} nei nomi file.
  • Invece del marcatore _success generalmente creato nella posizione di output al completamento del processo, viene generato un nuovo marcatore _committed_{jobID}. Questo marcatore associa gli ID processo riusciti a nomi di file specifici.
  • È stato introdotto un nuovo comando SQL che gli utenti possono eseguire periodicamente per gestire l'archiviazione e pulire i file di cui non è stato eseguito il commit. La sintassi per questo comando è la seguente:
    • Per pulire una directory specifica: CLEANUP ('/path/to/dir') [RETAIN number HOURS];
    • Per pulire una tabella specifica: CLEANUP [db_name.]table_name [RETAIN number HOURS]; In questa sintassi, path/to/dir rappresenta l'URI della posizione in cui è necessaria la pulizia e number è un valore di tipo double che rappresenta il periodo di conservazione. Il periodo di conservazione predefinito è impostato su sette giorni.
  • È stata introdotta una nuova opzione di configurazione denominata spark.sql.deleteUncommittedFilesWhileListing che è impostata su false per impostazione predefinita. L'abilitazione di questa opzione comporta l'eliminazione automatica dei file di cui non è stato eseguito il commit durante le letture, ma questo scenario potrebbe rallentare le operazioni di lettura. È consigliabile eseguire manualmente il comando di pulizia quando il cluster è inattivo anziché abilitare questo flag.

Guida alla migrazione dal Runtime 1.1 al Runtime 1.2

Quando si esegue la migrazione dal Runtime 1.1, basato su Apache Spark 3.3, al Runtime 1.2, basato su Apache Spark 3.4, vedere la guida ufficiale alla migrazione.

Nuove funzionalità e miglioramenti di Delta Lake 2.4

Delta Lake è un progetto open source che consente di costruire un'architettura lakehouse su Data Lake. Delta Lake offre transazioni ACID, gestione scalabile dei metadati, e unifica l'elaborazione dati in streaming e batch.

In particolare, Delta Lake offre:

  • Transazioni ACID in Spark: i livelli di isolamento serializzabili assicurano che i lettori non visualizzino mai dati incoerenti.
  • Gestione scalabile dei metadati: usa la potenza di elaborazione distribuita di Spark per gestire con facilità tutti i metadati per tabelle con scalabilità petabyte con miliardi di file.
  • Unificazione di streaming e batch: una tabella in Delta Lake è sia una tabella batch che un sink e un'origine di streaming. L'inserimento dei dati in streaming, il back-fill cronologico in batch e le query interattive funzionano senza bisogno di modifiche.
  • Imposizione dello schema: gestisce automaticamente le varianti dello schema per impedire l'inserimento di record non validi durante l'inserimento.
  • Tempo per spostamento fisico: il controllo delle versioni dei dati consente il rollback, audit trail cronologici completi ed esperimenti di apprendimento automatico riproducibili.
  • upsert e delete: supporta operazioni di unione, aggiornamento ed eliminazione per abilitare casi d'uso complessi come Change Data Capture, operazioni SCD (Slowly Changing Dimension), upsert di streaming e così via.

Leggere la versione completa delle note sulla versione per Delta Lake 2.4.

Pacchetti a livello predefinito per librerie Java, Scala, Python

Per un elenco di tutti i pacchetti a livello predefinito per Java, Scala, Python e le rispettive versioni, vedere le note sullal versione.

Contenuto correlato