Apache Spark Runtimes i Stoff

Microsoft Fabric Runtime er en Azure-integrert plattform basert på Apache Spark som muliggjør utførelse og administrasjon av datateknikk og datavitenskapsopplevelser. Den kombinerer viktige komponenter fra både interne og åpne kildekilder, noe som gir kundene en omfattende løsning. For enkelhetskraft refererer vi til Microsoft 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.

• 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.

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

Nedenfor finner du en omfattende sammenligning av viktige komponenter, inkludert Apache Spark-versjoner, støttede operativsystemer, Java, Scala, Python, Delta Lake og R, for både Runtime 1.1 og Runtime 1.2 i Microsoft Fabric-plattformen.

	Kjøretid 1.1	Kjøretid 1.2	Kjøretid 1.3
Apache Spark	3.3.1	3.4.1	3.5.0
Operativsystemet	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
Deltasjøen	2.2.0	2.4.0	3.0.0
R	4.2.2	4.2.2	Ikke tilgjengelig

Gå til Runtime 1.1 eller Runtime 1.2 for å utforske detaljer, nye funksjoner, forbedringer og overføringsscenarioer for den bestemte kjøretidsversjonen.

Stoffoptimaliseringer

Både Spark-motoren og Delta Lake-implementeringene i Microsoft Fabric inneholder plattformspesifikke optimaliseringer og funksjoner. Disse funksjonene er utformet for å bruke opprinnelige integreringer i plattformen. Det er viktig å være oppmerksom på at alle disse funksjonene kan deaktiveres for å oppnå standard Spark- og Delta Lake-funksjonalitet. 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.

I Fabric Runtime for Apache Spark og Delta Lake finnes det opprinnelige forfatterfunksjoner som tjener to viktige formål:

1. De tilbyr differensiert ytelse for å skrive arbeidsbelastninger, noe som optimaliserer skriveprosessen.
2. De er standard til V-Order-optimalisering av Delta Parquet-filer. Delta Lake V-Order optimalisering er avgjørende for å levere overlegen leseytelse på tvers av alle Fabric-motorer. Hvis du vil ha en dypere forståelse av hvordan den fungerer og hvordan du administrerer den, kan du se den dedikerte artikkelen om tabelloptimalisering for Delta Lake og V-Order.

Støtte for flere kjøretider

Fabric støtter flere kjøretider, noe som gir brukerne fleksibilitet til sømløst å bytte mellom dem, noe som minimerer risikoen for inkompatibilitet eller forstyrrelser.

Som standard bruker alle nye arbeidsområder den nyeste kjøretidsversjonen, som for øyeblikket er Runtime 1.2.

Hvis du vil endre kjøretidsversjonen på arbeidsområdenivå, går du til arbeidsområde Innstillinger > Dataingeniør ing/Science > Spark Compute > Workspace Level Default, og velger ønsket kjøretid fra de tilgjengelige alternativene.

Når du har gjort denne endringen, vil alle systemopprettede elementer i arbeidsområdet, inkludert Lakehouses, SJDs og Notebooks, fungere ved hjelp av den nylig valgte kjøretidsversjonen på arbeidsområdenivå fra neste Spark-økt. Hvis du for øyeblikket bruker en notatblokk med en eksisterende økt for en jobb eller en lakehouse-relatert aktivitet, fortsetter Spark-økten som den er. Fra og med neste økt eller jobb brukes imidlertid den valgte kjøretidsversjonen.

Konsekvensene av kjøretidsendringer på Spark Innstillinger

Generelt sett tar vi sikte på å overføre alle Spark-innstillinger. Hvis vi imidlertid identifiserer at Spark-innstillingen ikke er kompatibel med Runtime B, utsteder vi en advarsel og avstår fra å implementere innstillingen.

Konsekvensene av kjøretidsendringer på bibliotekbehandling

Generelt sett er vår tilnærming å overføre alle biblioteker fra Runtime A til Runtime B, inkludert både offentlige og egendefinerte kjøretider. Hvis Python- og R-versjonene forblir uendret, skal bibliotekene fungere som de skal. For Jars er det imidlertid en betydelig sannsynlighet for at de ikke fungerer på grunn av endringer i avhengigheter og andre faktorer som endringer i Scala, Java, Spark og operativsystemet.

Brukeren er ansvarlig for å oppdatere eller erstatte biblioteker som ikke fungerer med Runtime B. Hvis det er en konflikt, som betyr at Runtime B inkluderer et bibliotek som opprinnelig ble definert i Runtime A, vil bibliotekbehandlingssystemet vårt prøve å opprette den nødvendige avhengigheten for Runtime B basert på brukerens innstillinger. Byggeprosessen vil imidlertid mislykkes hvis det oppstår en konflikt. I feilloggen kan brukere se hvilke biblioteker som forårsaker konflikter og foreta justeringer i versjonene eller spesifikasjonene.

Oppgrader Delta Lake-protokollen

Delta Lake-funksjoner er alltid bakoverkompatible, slik at tabeller som er opprettet i en lavere Delta Lake-versjon, sømløst kan samhandle med høyere versjoner. Men når visse funksjoner er aktivert (for eksempel ved hjelp delta.upgradeTableProtocol(minReaderVersion, minWriterVersion) av metode, kan videresendingskompatibilitet med lavere Delta Lake-versjoner bli kompromittert. I slike tilfeller er det viktig å endre arbeidsbelastninger som refererer til de oppgraderte tabellene for å justere med en Delta Lake-versjon som opprettholder kompatibilitet.

Hver Delta-tabell er knyttet til en protokollspesifikasjon, og definerer funksjonene den støtter. Programmer 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 et program mangler muligheten til å håndtere en funksjon som støttes i tabellens protokoll, kan det ikke leses fra eller skrive til tabellen.

Protokollspesifikasjonen er delt inn i to forskjellige komponenter: leseprotokollen og skriveprotokollen. Gå til siden «Hvordan administrerer Delta Lake funksjonskompatibilitet?» for å lese detaljer om den.

Brukere kan utføre kommandoen delta.upgradeTableProtocol(minReaderVersion, minWriterVersion) i PySpark-miljøet, og i Spark SQL og Scala. Denne kommandoen gjør det mulig for dem å starte en oppdatering i Delta-tabellen.

Det er viktig å være oppmerksom på at når du utfører denne oppgraderingen, får brukerne en advarsel som angir at oppgradering av Delta-protokollversjonen er en ikke-uopprettelig prosess. Dette betyr at når oppdateringen er utført, kan den ikke angres.

Protokollversjonsoppgraderinger kan potensielt påvirke kompatibiliteten til eksisterende tabelllesere, forfattere eller begge deler av Delta Lake. Derfor er det tilrådelig å fortsette med forsiktighet og oppgradere protokollversjonen bare når det er nødvendig, for eksempel når du tar i bruk nye funksjoner i Delta Lake.

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

Delta 2.2 vs Delta 2.4 endringer

I den nyeste Fabric Runtime, versjon 1.2, er standard tabellformat (spark.sql.sources.default) nå delta. I tidligere versjoner av Fabric Runtime, versjon 1.1 og på alle Synapse Runtime for Apache Spark som inneholder Spark 3.3 eller under, ble standard tabellformat definert som parquet. Se tabellen med konfigurasjonsdetaljer for Apache Spark for forskjeller mellom Azure Synapse Analytics og Microsoft Fabric.

Alle tabeller som er opprettet ved hjelp av Spark SQL, PySpark, Scala Spark og Spark R, oppretter tabellen som delta standard når tabelltypen utelates. Hvis skript eksplisitt angir tabellformatet, blir dette respektert. Kommandoen USING DELTA opprett tabellkommandoer i Spark blir overflødig.

Skript som forventer eller antar parquet tabellformat bør revideres. Følgende kommandoer støttes ikke 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

Versjonskontroll

Runtime-versjonsnummereringen vår, mens den er nært knyttet til Semantic Versioning, følger en litt annen tilnærming. Den store versjonen av runtime tilsvarer hovedversjonen av Apache Spark. Runtime 1 tilsvarer derfor Spark versjon 3. På samme måte justeres den kommende Runtime 2 med Spark 4.0. Det er viktig å være oppmerksom på at mellom gjeldende kjøretid, Runtime 1.1 og Runtime 1.2, kan det forekomme endringer, inkludert tillegg eller fjerning av ulike biblioteker. I tillegg tilbyr plattformen vår en biblioteksbehandlingsfunksjon som gjør det mulig for brukere å installere eventuelle ønskede biblioteker.

Relatert innhold

• Kjøretid 1.3 (Spark 3.5, Java 11, Python 3.10, Delta Lake 3.0)
• Kjøretid 1.2 (Spark 3.4, Java 11, Python 3.10, Delta Lake 2.4)
• Kjøretid 1.1 (Spark 3.3, Java 8, Python 3.10, Delta Lake 2.2)