Dela via

Infrastrukturkörning 1.2 (GA)

  • Artikel

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

Dricks

Använd alltid den senaste GA-körningsversionen för din produktionsarbetsbelastning, som för närvarande är Runtime 1.3.

Skärmbild som visar var du väljer körningsversion.

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, som drivs av communityn med öppen källkod, 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.

Smarta läsningar, som hoppar över filer från misslyckade jobb

I det aktuella Spark-incheckningssystemet, när en infogning i ett tabelljobb misslyckas men vissa uppgifter lyckas, samexisterar filerna som genereras av de lyckade uppgifterna med filer från det misslyckade jobbet. 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 data som inte har genererats. 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 checkats in när de 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. Standardkvarhållningsperioden är inställd på 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 data inmatning, batch historisk återfyllnad, interaktiva frågor fungerar helt enkelt direkt.
  • Schemaframtvingande: Hanterar automatiskt schemavariationer för att förhindra infogning av felaktiga poster under inmatning.
  • 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 aktivera komplexa användningsfall som change-data-capture, långsamt föränderliga dimensionsåtgärder (SCD), strömmande upserts och så vidare.

Läs den fullständiga versionen av viktig information 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