Apache Spark-körmiljöer i Fabric

Fabric Runtime är en Azure-integrerad plattform baserad på Apache Spark som möjliggör genomförande och hantering av data engineering- och data science-upplevelser. 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, se Fabric Runtime powered by 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.

• Native Execution Engine – en omvälvande förbättring för Apache Spark-arbetsbelastningar, som erbjuder betydande prestandaförbättringar genom att direkt köra Spark-frågor på lakehouse-infrastruktur. När det väl är integrerat krävs inga kodändringar och leverantörsinlåsning undviks. Den stöder både Parquet- och Delta-format över Apache Spark API:er i Runtime 1.3 (Spark 3.5) och Runtime 2.0 (Spark 4.1).

  Stödda operatorer avlastas från den JVM-baserade Spark till en C++-körningssökväg som är vektoriserad via Apache Gluten och Velox, vilket möjliggör kolumnär, SIMD-accelererad bearbetning med inbyggt stöd för Parquet- och Delta-format. När en operator inte stöds återgår körningen automatiskt till JVM-baserad Spark. I representativa riktmärken (TPC-DS vid skalningsfaktor 1000 med Delta) uppnådde motorn upp till sex gånger snabbare prestanda jämfört med öppen källkod Spark, vilket innebär cirka 83 % besparing av beräkningskostnader på ett Fabric-kluster med fast storlek.

  Den ursprungliga vägen bevarar optimeringar av Fabric Spark-frågor, inklusive anpassningsbar frågekörning, kostnadsbaserade omskrivningar, kolumnbeskärning och predikatpushdown. Du kan växla inbyggd exekvering per applikation genom att använda konfigurationen spark.native.enabled . Under körning av notebook-celler får Fabric Spark Advisor realtidsaviseringar när körningen återgår till JVM-baserade Spark, vilket hjälper dig att diagnostisera när inbyggd avlastning inte tillämpas.

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

• Fabric Runtime är byggt på ett robust öppen källkodsoperativsystem, vilket säkerställer kompatibilitet med olika hårdvarukonfigurationer och systemkrav.

I följande tabell hittar du en omfattande jämförelse av nyckelkomponenter, inklusive Apache Spark-versioner, stödda operativsystem, Java, Scala, Python, Delta Lake och R, för Apache Spark-baserade runtimes inom Fabric-plattformen.

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

Nätverksoptimeringar

I Fabric innehåller både Spark-motorn och Delta Lake-implementationerna plattformsspecifika optimeringar och funktioner. Dessa funktioner använder inbyggda integrationer inom plattformen. Du kan inaktivera alla dessa funktioner för att uppnå standardfunktionalitet i Spark och Delta Lake. Körningsmiljöer 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.

Inom Fabric Runtime för Apache Spark och Delta Lake fyller inbyggda skrivarfunktioner två huvudfunktioner:

• De erbjuder differentierad prestanda för skrivarbete, optimerar skrivprocessen.
• De går tillbaka till V-ordningsoptimering av Delta Parquet-filer. Delta Lake V-order-optimeringen är avgörande för att leverera överlägsen läsprestanda över alla Fabric-motorer. För att få en djupare förståelse för hur det fungerar och hur man hanterar det, se Delta Lake tabelloptimering och V-order.

Stöd för flera körmiljöer

Fabric stöder flera körtider, så du kan växla mellan dem och minska risken för kompatibilitetsproblem eller störningar.

Som standard använder alla nya arbetsytor den senaste GA-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.

Efter att du gjort denna ändring använder alla systemskapade objekt i arbetsytan, inklusive sjöhus, Spark-jobbbeskrivningar och anteckningsböcker, den nyvalda arbetsytsnivåversionen från och med nästa Spark-session. Om du för närvarande använder en notebook med en befintlig session för ett jobb eller någon lakehouse-relaterad aktivitet fortsätter Spark-sessionen som vanligt. Men från och med nästa session eller jobb gäller den valda runtime-versionen.

För att ändra körtiden på föremålsnivå Environment , skapa ett nytt miljöobjekt eller öppna ett befintligt. Under rullgardinsmenyn Runtime väljer du din önskade runtime-version bland de tillgängliga alternativen, väljer Save, och sedan Publish dina ändringar. Sedan kan du använda det här Environment objektet med ditt Notebook eller Spark Job Definition.

Konsekvenser av körningstidsändringar i Spark-inställningar

Systemet flyttar alla Spark-inställningar. Men om systemet identifierar att en Spark-inställning inte är kompatibel med Runtime B, visas en varning och inställningen implementeras inte.

Konsekvenser av ändringar under körning för bibliotekshantering

Bibliotekshanteringssystemet migrerar alla bibliotek från Runtime A till Runtime B, inklusive både publika och anpassade runtimes. Om Python- och R-versionerna förblir desamma fungerar biblioteken som de ska. Men för JARs finns det en betydande chans att de inte fungerar på grund av förändringar i beroenden och andra faktorer som förändringar i Scala, Java, Spark och operativsystemet.

Du är ansvarig för att uppdatera eller ersätta bibliotek som inte fungerar med Runtime B. Om det uppstår en konflikt, vilket innebär att Runtime B inkluderar ett bibliotek som ursprungligen definierades i Runtime A, försöker bibliotekshanteringssystemet skapa det nödvändiga beroendet för Runtime B baserat på dina inställningar. Byggprocessen misslyckas dock om en konflikt uppstår. I felloggen kan du se vilka bibliotek som orsakar konflikter och göra justeringar av sina versioner eller specifikationer.

Uppgradera Delta Lake-protokollet

Delta Lake-funktioner är alltid bakåtkompatibla, vilket säkerställer att tabeller skapade i en lägre Delta Lake-version sömlöst kan interagera med högre versioner. Men när du aktiverar vissa funktioner (till exempel genom att använda metoden delta.upgradeTableProtocol(minReaderVersion, minWriterVersion) ) kan du kompromettera framåtkompatibiliteten med lägre versioner i Delta Lake. I sådana fall behöver du modifiera arbetsbelastningar som refererar till de uppgraderade tabellerna för att anpassa dem till en Delta Lake-version som behåller kompatibilitet.

Varje Delta-tabell är kopplad till en protokollspecifikation som definierar vilka funktioner den stödjer. 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 en applikation saknar förmågan att hantera en funktion som anges som stödd i tabellens protokoll kan den inte läsa från eller skriva till den tabellen.

Protokollspecifikationen är uppdelad i två olika komponenter: protokollet "read" och "write". För mer information, se Hur hanterar Delta Lake funktionskompatibilitet?

Du kan köra kommandot delta.upgradeTableProtocol(minReaderVersion, minWriterVersion) i PySpark-miljön samt i Spark SQL och Scala. Detta kommando initierar en uppdatering i Delta-tabellen.

När du utför denna uppgradering får du en varning om att uppgradering av Delta-protokollets version är en icke-reversibel process. Denna process innebär att när du väl kört uppdateringen kan du inte ångra den.

Protokollversionsuppgraderingar kan potentiellt påverka kompatibiliteten för befintliga Delta Lake-tabellläsare, skrivare eller båda. Var därför försiktig och uppgradera protokollversionen endast när det är nödvändigt, till exempel vid införande av nya funktioner i Delta Lake.

Verifiera dessutom att alla nuvarande och framtida produktionsarbetsbelastningar och processer är kompatibla med Delta Lake-tabeller med den nya protokollversionen för att säkerställa en smidig övergång och förhindra eventuella störningar.

Relaterat innehåll

• Runtime 2.0 (Spark 4.1, Java 21, Python 3.13, Delta Lake 4.2)
• Körmiljö 1.3 (Spark 3.5, Java 11, Python 3.11, Delta Lake 3.2)