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.
Den inbyggda körningsmotorn – är en transformerande förbättring för Apache Spark-arbetsbelastningar som ger betydande prestandavinster genom att köra Spark-frågor direkt på lakehouse-infrastrukturen. Integrerat sömlöst kräver det inga kodändringar och undviker leverantörslåsning, vilket stöder både Parquet- och Delta-format i Apache Spark-API:er i Runtime 1.3 (Spark 3.5). Den här motorn ökar frågehastigheten upp till fyra gånger snabbare än traditionell OSS Spark, vilket visas av TPC-DS 1TB-riktmärket, vilket minskar driftskostnaderna och förbättrar effektiviteten för olika datauppgifter, inklusive datainmatning, ETL, analys och interaktiva frågor. Den bygger på Metas Velox och Intels Apache Gluten och optimerar resursanvändningen vid hantering av olika databearbetningsscenarier.
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 Apache Spark-baserade körningar inom Microsoft Fabric-plattformen.
Tips
Använd alltid den senaste GA-körningsversionen för din produktionsarbetsbelastning, som för närvarande är Runtime 1.3.
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.11 |
Delta Lake | 2.2.0 | 2.4.0 | 3.2 |
R | 4.2.2 | 4.2.2 | 4.4.1 |
Besök Runtime 1.1, Runtime 1.2 eller Runtime 1.3 för att utforska information, nya funktioner, förbättringar och migreringsscenarier för den specifika körningsversionen.
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:
- De erbjuder differentierade prestanda för att skriva arbetsbelastningar och optimera skrivprocessen.
- 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.
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.3.
Om du vill ändra körningsversionen på arbetsytenivå går du till Arbetsyteinställningar>Data Engineering/Science>Spark-inställningar. På fliken Miljö väljer du den önskade körtidsversionen från de tillgängliga alternativen. Välj Spara för att bekräfta ditt val.
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.
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.
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.
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 information om den.
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.
I den senaste Fabric Runtime, version 1.3 och 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