Apache Spark Runtimes i Infrastrukturresurser

Microsoft Fabric Runtime är en Azure-integrerad plattform baserad på Apache Spark som möjliggör körning och hantering av datateknik och datavetenskapsupplevelser. Den kombinerar viktiga komponenter från både interna källor och källor med öppen källkod, vilket ger kunderna en omfattande lösning. För enkelhetens skull refererar vi till Microsoft Fabric Runtime som drivs av Apache Spark som Fabric Runtime.

Huvudkomponenter i Fabric Runtime:

• Apache Spark – ett kraftfullt bibliotek med distribuerad databehandling med öppen källkod som möjliggör storskalig databearbetning och analysuppgifter. Apache Spark är en mångsidig och högpresterande plattform för datateknik och datavetenskap.

• Delta Lake – ett lagringslager med öppen källkod som ger APACHE Spark acid-transaktioner och andra funktioner för datatillförlitlighet. Delta Lake är integrerat i Fabric Runtime och förbättrar databehandlingsfunktionerna och säkerställer datakonsekvens i flera samtidiga åtgärder.

• Standardpaket för Java/Scala, Python och R – paket som stöder olika programmeringsspråk och miljöer. Dessa paket installeras och konfigureras automatiskt, vilket gör att utvecklare kan använda sina föredragna programmeringsspråk för databearbetningsuppgifter.

• Microsoft Fabric Runtime bygger på ett robust operativsystem med öppen källkod som säkerställer kompatibilitet med olika maskinvarukonfigurationer och systemkrav.

Nedan hittar du en omfattande jämförelse av viktiga komponenter, inklusive Apache Spark-versioner, operativsystem som stöds, Java, Scala, Python, Delta Lake och R, för både Runtime 1.1 och Runtime 1.2 på Microsoft Fabric-plattformen.

	Körning 1.1	Körning 1.2	Körning 1.3
Apache Spark	3.3.1	3.4.1	3.5.0
Operativsystem	Ubuntu 18.04	Mariner 2.0	Mariner 2.0
Java	8	11	11
Scala	2.12.15	2.12.17	2.12.17
Python	3,10	3,10	3,10
Delta Lake	2.2.0	2.4.0	3.0.0
R	4.2.2	4.2.2	Ej tillämpligt

Besök Runtime 1.1 eller Runtime 1.2 för att utforska information, nya funktioner, förbättringar och migreringsscenarier för den specifika körningsversionen.

Infrastrukturoptimeringar

I Microsoft Fabric innehåller både Spark-motorn och Delta Lake-implementeringarna plattformsspecifika optimeringar och funktioner. De här funktionerna är utformade för att använda inbyggda integreringar på plattformen. Observera att alla dessa funktioner kan inaktiveras för att uppnå standardfunktionerna spark och Delta Lake. Infrastrukturkörningar för Apache Spark omfattar:

• Den fullständiga versionen av Apache Spark med öppen källkod.
• En samling med nästan 100 inbyggda, distinkta förbättringar av frågeprestanda. De här förbättringarna omfattar funktioner som partitionscachelagring (vilket gör att FileSystem-partitionscachen kan minska metaarkivanrop) och Korskoppling till projektion av skalära underfrågor.
• Inbyggd intelligent cache.

I Fabric Runtime för Apache Spark och Delta Lake finns det inbyggda skrivfunktioner som har två viktiga syften:

1. De erbjuder differentierade prestanda för att skriva arbetsbelastningar och optimera skrivprocessen.
2. De är standard för V-Order-optimering av Delta Parquet-filer. Delta Lake V-Order-optimeringen är avgörande för att leverera överlägsen läsprestanda för alla Fabric-motorer. Mer information om hur det fungerar och hur du hanterar det finns i den dedikerade artikeln om Delta Lake-tabelloptimering och V-Order.

Stöd för flera körningar

Fabric stöder flera körningar, vilket ger användarna flexibilitet att smidigt växla mellan dem, vilket minimerar risken för inkompatibiliteter eller störningar.

Som standard använder alla nya arbetsytor den senaste körningsversionen, som för närvarande är Runtime 1.2.

Om du vill ändra körningsversionen på arbetsytans nivå går du till Arbetsyta Inställningar > Datateknik/Science > Spark Compute > Workspace Level Default och väljer önskad körning bland de tillgängliga alternativen.

När du har gjort den här ändringen fungerar alla systemskapade objekt på arbetsytan, inklusive Lakehouses, SJD och Notebooks, med den nyligen valda körningsversionen på arbetsytenivå från och med nästa Spark-session. Om du för närvarande använder en notebook-fil med en befintlig session för ett jobb eller någon lakehouse-relaterad aktivitet fortsätter spark-sessionen som den är. Från och med nästa session eller jobb tillämpas dock den valda körningsversionen.

Konsekvenser av körningsändringar på Spark Inställningar

I allmänhet strävar vi efter att migrera alla Spark-inställningar. Men om vi upptäcker att Spark-inställningen inte är kompatibel med Runtime B utfärdar vi ett varningsmeddelande och avstår från att implementera inställningen.

Konsekvenser av körningsändringar i bibliotekshantering

I allmänhet är vår metod att migrera alla bibliotek från Runtime A till Runtime B, inklusive både offentliga och anpassade runtimes. Om Python- och R-versionerna förblir oförändrade bör biblioteken fungera korrekt. För Jars finns det dock en betydande sannolikhet att de inte fungerar på grund av ändringar i beroenden och andra faktorer som ändringar i Scala, Java, Spark och operativsystemet.

Användaren ansvarar för att uppdatera eller ersätta bibliotek som inte fungerar med Runtime B. Om det finns en konflikt, vilket innebär att Runtime B innehåller ett bibliotek som ursprungligen definierades i Runtime A, försöker vårt bibliotekshanteringssystem skapa det nödvändiga beroendet för Runtime B baserat på användarens inställningar. Byggprocessen misslyckas dock om en konflikt uppstår. I felloggen kan användarna se vilka bibliotek som orsakar konflikter och göra justeringar i sina versioner eller specifikationer.

Uppgradera Delta Lake-protokollet

Delta Lake-funktioner är alltid bakåtkompatibla, vilket säkerställer att tabeller som skapats i en lägre Delta Lake-version sömlöst kan interagera med högre versioner. Men när vissa funktioner är aktiverade (till exempel genom att använda delta.upgradeTableProtocol(minReaderVersion, minWriterVersion) metoden kan vidarebefordra kompatibilitet med lägre Delta Lake-versioner komprometteras. I sådana fall är det viktigt att ändra arbetsbelastningar som refererar till de uppgraderade tabellerna så att de överensstämmer med en Delta Lake-version som upprätthåller kompatibiliteten.

Varje Delta-tabell är associerad med en protokollspecifikation som definierar de funktioner som den stöder. Program som interagerar med tabellen, antingen för läsning eller skrivning, förlitar sig på den här protokollspecifikationen för att avgöra om de är kompatibla med tabellens funktionsuppsättning. Om ett program saknar möjlighet att hantera en funktion som anges som stöds i tabellens protokoll kan det inte läsa från eller skriva till tabellen.

Protokollspecifikationen är uppdelad i två olika komponenter: läsprotokollet och skrivprotokollet. Gå till sidan "Hur hanterar Delta Lake funktionskompatibilitet?" för att läsa mer om det.

Användare kan köra kommandot delta.upgradeTableProtocol(minReaderVersion, minWriterVersion) i PySpark-miljön och i Spark SQL och Scala. Med det här kommandot kan de initiera en uppdatering i Delta-tabellen.

Det är viktigt att observera att när de utför den här uppgraderingen får användarna en varning som anger att uppgraderingen av Delta-protokollversionen är en icke-omvänd process. Det innebär att när uppdateringen har körts kan den inte ångras.

Protokollversionsuppgraderingar kan potentiellt påverka kompatibiliteten för befintliga Delta Lake-tabellläsare, skrivare eller båda. Därför rekommenderar vi att du fortsätter med försiktighet och uppgraderar protokollversionen endast när det behövs, till exempel när du använder nya funktioner i Delta Lake.

Dessutom bör användarna kontrollera att alla aktuella och framtida produktionsarbetsbelastningar och processer är kompatibla med Delta Lake-tabeller med hjälp av den nya protokollversionen för att säkerställa en sömlös övergång och förhindra eventuella störningar.

Delta 2.2 vs Delta 2.4 ändringar

I den senaste Fabric Runtime, version 1.2, är standardtabellformatet (spark.sql.sources.default) nu delta. I tidigare versioner av Fabric Runtime, version 1.1 och på alla Synapse Runtime för Apache Spark som innehåller Spark 3.3 eller senare definierades standardtabellformatet som parquet. I tabellen med Apache Spark-konfigurationsinformation finns skillnader mellan Azure Synapse Analytics och Microsoft Fabric.

Alla tabeller som skapas med Spark SQL, PySpark, Scala Spark och Spark R, när tabelltypen utelämnas, skapar tabellen som delta standard. Om skript uttryckligen anger tabellformatet kommer det att respekteras. Kommandot USING DELTA i Spark create table-kommandon blir redundant.

Skript som förväntar sig eller antar parquet-tabellformat bör ändras. Följande kommandon stöds inte i Delta-tabeller:

• ANALYZE TABLE $partitionedTableName PARTITION (p1) COMPUTE STATISTICS
• ALTER TABLE $partitionedTableName ADD PARTITION (p1=3)
• ALTER TABLE DROP PARTITION
• ALTER TABLE RECOVER PARTITIONS
• ALTER TABLE SET SERDEPROPERTIES
• LOAD DATA
• INSERT OVERWRITE DIRECTORY
• SHOW CREATE TABLE
• CREATE TABLE LIKE

Versionshantering

Vår körningsversionsnumrering, även om den är nära relaterad till semantisk versionshantering, följer en något annorlunda metod. Körningens huvudversion motsvarar Apache Spark-huvudversionen. Därför motsvarar Runtime 1 Spark version 3. På samma sätt överensstämmer den kommande Runtime 2 med Spark 4.0. Det är viktigt att observera att mellan de aktuella körningarna, Runtime 1.1 och Runtime 1.2, kan ändringar inträffa, inklusive tillägg eller borttagning av olika bibliotek. Dessutom erbjuder vår plattform en funktion för bibliotekshantering som ger användarna möjlighet att installera önskade bibliotek.

Relaterat innehåll

• Körning 1.3 (Spark 3.5, Java 11, Python 3.10, Delta Lake 3.0)
• Körning 1.2 (Spark 3.4, Java 11, Python 3.10, Delta Lake 2.4)
• Körning 1.1 (Spark 3.3, Java 8, Python 3.10, Delta Lake 2.2)