Apache Spark-kjøretider i Fabric

Fabric Runtime er en Azure-integrert plattform basert på Apache Spark som muliggjør gjennomføring og administrasjon av dataingeniør- og datavitenskapsopplevelser. Den kombinerer viktige komponenter fra både interne og åpne kildekilder, noe som gir kundene en omfattende løsning. For enkelhets skyld, se Fabric Runtime drevet av Apache Spark som Fabric Runtime.

Viktige komponenter i Fabric Runtime:

• Apache Spark – et kraftig distribuert databehandlingsbibliotek med åpen kildekode som muliggjør store databehandlings- og analyseoppgaver. Apache Spark tilbyr en allsidig plattform med høy ytelse for datateknikk og datavitenskapsopplevelser.

• Delta Lake – et lagringslag med åpen kildekode som gir ACID-transaksjoner og andre funksjoner for datapålitelighet til Apache Spark. Delta Lake er integrert i Fabric Runtime og forbedrer databehandlingsfunksjonene og sikrer datakonsekvens på tvers av flere samtidige operasjoner.

• Native Execution Engine – en transformativ forbedring for Apache Spark-arbeidsbelastninger, som gir betydelige ytelsesgevinster ved å utføre Spark-spørringer direkte på lakehouse-infrastruktur. Integrert sømløst, krever det ingen kodeendringer og unngår leverandørlåsing. Den støtter både Parquet- og Delta-formater på tvers av Apache Spark API-er i Runtime 1.3 (Spark 3.5) og Runtime 2.0 (Spark 4.1).

  Støttede operatører overføres fra JVM-baserte Spark til en vektorisert C++-kjøringsvei via Apache Gluten og Velox, noe som gir kolonneformede, SIMD-akselerert prosessering med innebygd støtte for Parquet- og Delta-formater. Når en operatør ikke støttes, faller utførelsen automatisk tilbake til JVM-baserte Spark. I representative benchmarks (TPC-DS med skaleringsfaktor 1000 ved bruk av Delta) oppnådde motoren opptil seks ganger raskere ytelse sammenlignet med åpen kildekode Spark, noe som tilsvarer omtrent 83% beregningskostnadsbesparelser på en fast størrelse Fabric-klynge.

  Den innebygde stien bevarer Fabric Spark-spørringsoptimaliseringer, inkludert adaptiv spørringsutførelse, kostnadsbaserte omskrivinger, kolonnebeskjæring og predikat-pushdown. Du kan slå av native kjøring per applikasjon ved å bruke konfigurasjonen spark.native.enabled . Under kjøring av bærbare datamaskiner viser Fabric Spark Advisor sanntidsvarsler når kjøringen faller tilbake til JVM-baserte Spark, og hjelper deg med å diagnostisere når native offload ikke er iverksatt.

• Standardnivåpakker for Java/Scala,Python og R – pakker som støtter ulike programmeringsspråk og miljøer. Disse pakkene installeres og konfigureres automatisk, slik at utviklere kan bruke sine foretrukne programmeringsspråk for databehandlingsoppgaver.

• Fabric Runtime er bygget på et robust åpen kildekode-operativsystem, som sikrer kompatibilitet med ulike maskinvarekonfigurasjoner og systemkrav.

I tabellen nedenfor finner du en omfattende sammenligning av nøkkelkomponenter, inkludert Apache Spark-versjoner, støttede operativsystemer, Java, Scala, Python, Delta Lake og R, for Apache Spark-baserte kjøretider innenfor Fabric-plattformen.

Besøk Runtime 1.3 eller Runtime 2.0 for å utforske detaljer, nye funksjoner, forbedringer og migreringsscenarier for den spesifikke runtime-versjonen.

Stoffoptimaliseringer

I Fabric inkluderer både Spark-motoren og Delta Lake-implementasjonene plattformspesifikke optimaliseringer og funksjoner. Disse funksjonene bruker innebygde integrasjoner i plattformen. Du kan deaktivere alle disse funksjonene for å oppnå standard funksjonalitet i Spark og Delta Lake. Fabric Runtimes for Apache Spark omfatter:

• Den komplette åpen kildekode-versjonen av Apache Spark.
• En samling med nesten 100 innebygde, distinkte forbedringer for spørringsytelse. Disse forbedringene inkluderer funksjoner som partisjonsbufring (aktivering av filsystempartisjonsbufferen for å redusere metalagerkall) og Krysskobling til projeksjon av skalarunderspørring.
• Innebygd intelligent hurtigbuffer.

Innenfor Fabric Runtime for Apache Spark og Delta Lake tjener native writer-funksjoner to hovedformål:

• De tilbyr differensiert ytelse for å skrive arbeidsbelastninger, noe som optimaliserer skriveprosessen.
• De går som standard over til V-ordensoptimalisering av Delta Parquet-filer. Delta Lake V-order-optimaliseringen er avgjørende for å levere overlegen leseytelse på tvers av alle Fabric-motorer. For å få en dypere forståelse av hvordan den fungerer og hvordan du administrerer den, se Delta Lake tabelloptimalisering og V-orden.

Støtte for flere kjøretider

Fabric støtter flere kjøretider, så du kan bytte mellom dem og redusere risikoen for kompatibilitetsproblemer eller forstyrrelser.

Som standard bruker alle nye arbeidsområder den nyeste GA-versjonen, som for øyeblikket er Runtime 1.3.

Hvis du vil endre kjøretidsversjonen på arbeidsområdenivå, kan du gå til Innstillinger for arbeidsområde>Innstillinger for datateknikk/vitenskap>Spark-innstillinger. Velg ønsket kjøretidsversjon fra de tilgjengelige alternativene på fanen Miljø. Velg Lagre for å bekrefte valget.

Etter at du har gjort denne endringen, bruker alle systemopprettede elementer i arbeidsområdet, inkludert innsjøhus, Spark-stillingsbeskrivelser og notatbøker, den nyvalgte arbeidsplassnivåversjonen fra neste Spark-økt. Hvis du for øyeblikket bruker en notatbok med en eksisterende økt til en jobb eller en annen aktivitet relatert til innsjøen, fortsetter den Spark-økten som den er. Men fra og med neste økt eller jobb gjelder den valgte runtime-versjonen.

For å endre kjøretiden på gjenstandsnivå Environment , opprett et nytt miljøobjekt eller åpne et eksisterende. Under nedtrekksmenyen Runtime , velg ønsket runtime-versjon fra de tilgjengelige alternativene, velg Save, og deretter Publish dine endringer. Deretter kan du bruke dette Environment elementet med din Notebook eller Spark Job Definition.

Konsekvensene av kjøretidsendringer på Spark-innstillinger

Systemet migrerer alle Spark-innstillinger. Men hvis systemet oppdager at en Spark-innstilling ikke er kompatibel med Runtime B, vises en advarsel og innstillingen implementeres ikke.

Konsekvensene av kjøretidsendringer på bibliotekbehandling

Biblioteksadministrasjonssystemet migrerer alle biblioteker fra Runtime A til Runtime B, inkludert både offentlige og egendefinerte runtimeer. Hvis Python- og R-versjonene forblir de samme, fungerer bibliotekene som de skal. Men for JAR-er er det en betydelig sjanse for at de ikke fungerer på grunn av endringer i avhengigheter og andre faktorer som endringer i Scala, Java, Spark og operativsystemet.

Du er ansvarlig for å oppdatere eller erstatte biblioteker som ikke fungerer med Runtime B. Hvis det oppstår en konflikt, som betyr at Runtime B inkluderer et bibliotek som opprinnelig ble definert i Runtime A, prøver bibliotekadministrasjonssystemet å lage nødvendig avhengighet for Runtime B basert på innstillingene dine. Byggeprosessen mislykkes imidlertid hvis det oppstår konflikt. I feilloggen kan du se hvilke biblioteker som forårsaker konflikter og gjøre justeringer i deres versjoner eller spesifikasjoner.

Oppgrader Delta Lake-protokollen

Delta Lake-funksjoner er alltid bakoverkompatible, noe som sikrer at tabeller laget i en lavere Delta Lake-versjon sømløst kan samhandle med høyere versjoner. Men når du aktiverer visse funksjoner (for eksempel ved å bruke metoden delta.upgradeTableProtocol(minReaderVersion, minWriterVersion) ), kan du kompromittere fremtidskompatibiliteten med lavere Delta Lake-versjoner. I slike tilfeller må du endre arbeidsbelastninger som refererer til de oppgraderte tabellene for å samsvare med en Delta Lake-versjon som opprettholder kompatibilitet.

Hver Delta-tabell er tilknyttet en protokollspesifikasjon som definerer funksjonene den støtter. Applikasjoner som samhandler med tabellen, enten for lesing eller skriving, er avhengige av denne protokollspesifikasjonen for å avgjøre om de er kompatible med tabellens funksjonssett. Hvis en applikasjon mangler evnen til å håndtere en funksjon som er oppført som støttet i tabellens protokoll, kan den ikke lese fra eller skrive til den tabellen.

Protokollspesifikasjonen er delt inn i to distinkte komponenter: «lese»-protokollen og «skrive»-protokollen. For mer informasjon, se Hvordan håndterer Delta Lake funksjonskompatibilitet?

Du kan kjøre kommandoen delta.upgradeTableProtocol(minReaderVersion, minWriterVersion) i PySpark-miljøet, og i Spark SQL og Scala. Denne kommandoen initierer en oppdatering på Delta-tabellen.

Når du utfører denne oppgraderingen, får du en advarsel om at oppgradering av Delta-protokollversjonen er en ikke-reversibel prosess. Denne prosessen betyr at når du først har kjørt oppdateringen, kan du ikke angre den.

Oppgraderinger av protokollversjoner kan potensielt påvirke kompatibiliteten til eksisterende Delta Lake-tabelllesere, skrivere eller begge deler. Derfor bør du være forsiktig og oppgradere protokollversjonen kun når det er nødvendig, for eksempel ved innføring av nye funksjoner i Delta Lake.

I tillegg bør du verifisere at alle nåværende og fremtidige produksjonsarbeidsbelastninger og prosesser er kompatible med Delta Lake-tabeller ved bruk av den nye protokollversjonen for å sikre en sømløs overgang og forhindre potensielle forstyrrelser.

Relatert innhold

• Runtime 2.0 (Spark 4.1, Java 21, Python 3.13, Delta Lake 4.2)
• Kjøretid 1.3 (Spark 3.5, Java 11, Python 3.11, Delta Lake 3.2)