Fabrickörmiljö 1.2 (EOSA)

Microsoft Fabric Runtime är en Azure-integrerad plattform baserad på Apache Spark som möjliggör körning och hantering av datateknik och datavetenskapsupplevelser. Det här dokumentet beskriver Komponenter och versioner av Runtime 1.2.

De viktigaste komponenterna i Runtime 1.2 är:

• Apache Spark 3.4.1
• Operativsystem: Mariner 2.0
• Java: 11
• Scala: 2.12.17
• Python: 3.10
• Deltasjön: 2.4.0
• R: 4.2.2

Microsoft Fabric Runtime 1.2 levereras med en samling standardnivåpaket, inklusive en fullständig Anaconda-installation och vanliga bibliotek för Java/Scala, Python och R. Dessa bibliotek inkluderas automatiskt när du använder notebook-filer eller jobb i Microsoft Fabric-plattformen. I dokumentationen finns en fullständig lista över bibliotek. Microsoft Fabric distribuerar regelbundet underhållsuppdateringar för Runtime 1.2, vilket ger felkorrigeringar, prestandaförbättringar och säkerhetskorrigeringar. Att hålla dig uppdaterad garanterar optimal prestanda och tillförlitlighet för dina databehandlingsuppgifter.

Nya funktioner och förbättringar av Spark Release 3.4.1

Apache Spark 3.4.0 är den femte versionen på 3.x-linjen. Den här versionen, driven av den öppna källkodsgemenskapen, löste över 2 600 Jira-biljetter. Den introducerar en Python-klient för Spark Connect, förbättrar strukturerad direktuppspelning med asynkron förloppsspårning och tillståndskänslig Python-bearbetning. Den utökar Pandas API-täckning med stöd för NumPy-indata, förenklar migrering från traditionella informationslager via ANSI-efterlevnad och nya inbyggda funktioner. Det förbättrar också utvecklingsproduktiviteten och debuggabilityen med minnesprofilering. Dessutom baseras Runtime 1.2 på Apache Spark 3.4.1, en underhållsversion som fokuserar på stabilitetskorrigeringar.

Viktiga höjdpunkter

Läs den fullständiga versionen av viktig information för en specifik Apache Spark-version genom att besöka både Spark 3.4.0 och Spark 3.4.1.

Nya anpassade frågeoptimeringar

Stöd för samtidiga skrivningar i Spark

Det uppstår ett 404-fel med meddelandet "Åtgärden misslyckades: Den angivna sökvägen finns inte" är ett vanligt problem när du utför parallella datainfogningar i samma tabell med hjälp av en SQL INSERT INTO-fråga. Det här felet kan leda till dataförlust. Vår nya funktion, File Output Committer Algorithm, löser det här problemet så att kunderna kan utföra parallell datainfogning sömlöst.

Om du vill komma åt den spark.sql.enable.concurrentWrites här funktionen aktiverar du funktionsflaggan, som är aktiverad som standard från Och med Runtime 1.2 (Spark 3.4). Även om den här funktionen också är tillgänglig i andra Spark 3-versioner är den inte aktiverad som standard. Den här funktionen stöder inte parallell körning av INSERT OVERWRITE-frågor där varje samtidigt jobb skriver över data på olika partitioner i samma tabell dynamiskt. För detta ändamål erbjuder Spark en alternativ funktion som kan aktiveras genom att spark.sql.sources.partitionOverwriteMode konfigurera inställningen till dynamisk.

Intelligenta läsningar som hoppar över filer från misslyckade uppdrag

I det nuvarande Spark-committer-systemet, när en infogning i en tabell misslyckas men vissa uppgifter lyckas, samexisterar de filer som genereras av lyckade uppgifter med filer från det misslyckade arbetet. Den här samexistensen kan orsaka förvirring för användare eftersom det blir svårt att skilja mellan filer som tillhör framgångsrika och misslyckade jobb. När ett jobb läser från en tabell medan ett annat infogar data samtidigt i samma tabell kan läsjobbet dessutom komma åt icke-kommitterade data. Om ett skrivjobb misslyckas kan läsjobbet bearbeta felaktiga data.

Flaggan spark.sql.auto.cleanup.enabled styr vår nya funktion och åtgärdar det här problemet. När det är aktiverat hoppar Spark automatiskt över att läsa filer som inte har committerats när det utför spark.read eller väljer frågor från en tabell. Filer som skrivs innan den här funktionen aktiveras fortsätter att läsas som vanligt.

Här är de synliga ändringarna:

• Alla filer innehåller nu en tid-{jobID} identifierare i sina filnamn.
• I stället för markören _success som vanligtvis skapas på utdataplatsen när jobbet har slutförts genereras en ny _committed_{jobID} markör. Den här markören associerar lyckade jobb-ID:er med specifika filnamn.
• Vi har introducerat ett nytt SQL-kommando som användarna kan köra regelbundet för att hantera lagring och rensa oanvända filer. Syntaxen för det här kommandot är följande:
  • Så här rensar du en specifik katalog: CLEANUP ('/path/to/dir') [RETAIN number HOURS];
  • Rensa en specifik tabell: CLEANUP [db_name.]table_name [RETAIN number HOURS]; I den här syntaxen path/to/dir representerar den plats-URI där rensning krävs och number är ett dubbelt typvärde som representerar kvarhållningsperioden. Standardperioden för kvarhållning är sju dagar.
• Vi introducerade ett nytt konfigurationsalternativ med namnet spark.sql.deleteUncommittedFilesWhileListing, som är inställt false på som standard. Om du aktiverar det här alternativet blir det automatiskt att ta bort ogenomförda filer under läsningar, men det här scenariot kan göra läsåtgärderna långsammare. Vi rekommenderar att du kör rensningskommandot manuellt när klustret är inaktivt i stället för att aktivera den här flaggan.

Migreringsguide från Runtime 1.1 till Runtime 1.2

När du migrerar från Runtime 1.1, som drivs av Apache Spark 3.3, till Runtime 1.2, som drivs av Apache Spark 3.4, läser du den officiella migreringsguiden.

Nya funktioner och förbättringar av Delta Lake 2.4

Delta Lake är ett öppen källkod projekt som gör det möjligt att bygga en sjöhusarkitektur ovanpå datasjöar. Delta Lake tillhandahåller ACID-transaktioner, skalbar metadatahantering och förenar bearbetning av strömmande data och batchdata ovanpå befintliga datasjöar.

Mer specifikt erbjuder Delta Lake:

• ACID-transaktioner på Spark: Serialiserbara isoleringsnivåer säkerställer att läsarna aldrig ser inkonsekventa data.
• Skalbar metadatahantering: Använder Spark-distribuerad bearbetningskraft för att hantera alla metadata för petabyteskalningstabeller med miljarder filer på ett enkelt sätt.
• Sammanslagning av direktuppspelning och batch : En tabell i Delta Lake är en batchtabell och en strömmande källa och mottagare. Strömmande datainmatning, batchbearbetning av historisk dataåterfyllnad, interaktiva sökfrågor fungerar smidigt direkt från start.
• Schemahantering: Hanterar automatiskt schemavariationer för att förhindra infogning av felaktiga poster under dataprocessering.
• Tidsresa: Dataversioner möjliggör återställningar, fullständiga historiska granskningsspår och reproducerbara maskininlärningsexperiment.
• Upserts och borttagningar: Stöder sammanslagnings-, uppdaterings- och borttagningsåtgärder för att möjliggöra komplexa användningsfall såsom dataändringsinsamling, långsamt föränderliga dimensionsåtgärder (SCD), strömmande infogning och uppdatering, och så vidare.

Läs den fullständiga versionen av versionsanteckningarna för Delta Lake 2.4.

Standardnivåpaket för Java-, Scala- och Python-bibliotek

En lista över alla standardnivåpaket för Java, Scala, Python och deras respektive versioner finns i viktig information.

Relaterat innehåll

• Läs mer om Apache Spark Runtimes i Fabric – Översikt, Versionshantering, Stöd för flera körningstider och uppgradering av Delta Lake-protokollet