Condividi tramite

Runtime 1.2 (GA)

  • Articolo

Microsoft Fabric Runtime è 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 di Runtime 1.2.

Microsoft Fabric Runtime 1.2 è la versione più recente del runtime ga. I componenti principali di 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

Screenshot che mostra dove selezionare la versione di runtime.

Microsoft Fabric Runtime 1.2 include una raccolta di pacchetti di livello predefiniti, tra cui un'installazione completa di Anaconda e librerie comunemente usate per Java/Scala, Python e R. Queste librerie vengono 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 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 di Spark Release 3.4.1

Apache Spark 3.4.0 è la quinta versione nella riga 3.x. Questa versione, guidata dalla 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 le nuove funzioni predefinite. Migliora anche la produttività e il debug dello sviluppo con la profilatura della memoria. Inoltre, Runtime 1.2 è basato su Apache Spark 3.4.1, una versione di manutenzione incentrata sulle correzioni di 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 delle scritture simultanee in Spark

Se si verifica un errore 404 con il messaggio "Operazione non riuscita: il percorso specificato non esiste" è un problema comune quando si eseguono inserimenti di dati paralleli nella stessa tabella usando una query SQL INSERT INTO. Questo errore può causare 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 spark.sql.enable.concurrentWrites flag di funzionalità, che è abilitato per impostazione predefinita a partire da 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 dai 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 ai dati non inviati. Se un processo di scrittura non riesce, il processo di lettura potrebbe elaborare dati non corretti.

Il spark.sql.auto.cleanup.enabled flag controlla la nuova funzionalità, risolvendo questo problema. Quando è abilitata, Spark ignora automaticamente i file di lettura 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 come di consueto.

Ecco le modifiche visibili:

  • Tutti i file ora includono un tid-{jobID} identificatore nei nomi file.
  • Invece del _success marcatore creato in genere nella posizione di output al completamento del processo, viene generato un nuovo _committed_{jobID} marcatore. 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 rappresenta path/to/dir l'URI della posizione in cui è necessaria la pulizia ed number è un valore di tipo doppio 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 per false 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 cleanup quando il cluster è inattiva anziché abilitare questo flag.

Guida alla migrazione da Runtime 1.1 a Runtime 1.2

Quando si esegue la migrazione da Runtime 1.1, basato su Apache Spark 3.3, a 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 creare un'architettura lakehouse su data lake lake. Delta Lake offre transazioni ACID, gestione scalabile dei metadati e unifica l'elaborazione dei dati in streaming e batch su data lake esistenti.

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 spark per gestire tutti i metadati per le tabelle con scalabilità petabyte con miliardi di file con facilità.
  • Streaming e unificazione batch : una tabella in Delta Lake è una tabella batch e un'origine di streaming e un sink. Inserimento di dati in streaming, riempimento cronologico batch, query interattive funzionano tutti al di fuori della scatola.
  • Imposizione dello schema: gestisce automaticamente le varianti dello schema per impedire l'inserimento di record non validi durante l'inserimento.
  • Tempo di spostamento: il controllo delle versioni dei dati consente il rollback, i audit trail cronologici completi e gli esperimenti di Machine Learning riproducibili.
  • Upserts ed eliminazioni: supporta operazioni di merge, aggiornamento ed eliminazione per abilitare casi d'uso complessi come change-data-capture, operazioni a modifica lenta della dimensione (SCD), upsert di streaming e così via.

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

Pacchetti di livello predefiniti per le librerie Java, Scala, Python

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

Contenuto correlato