Migrer fra Fabric Runtime 1.3 til Runtime 2.0

Fabric Runtime 2.0 er den nyeste generelt tilgjengelige (GA) og standard kjøretiden for Apache Spark-arbeidsbelastninger i Microsoft Fabric. Den oppdaterer operativsystemet, Java, Scala, Python, R, Apache Spark og Delta Lake. Siden flere av disse oppdateringene krysser hovedversjonsgrenser, bør du validere notatbøkene, Spark-jobbdefinisjonene, bibliotekene og datapipelinene dine før du flytter produksjonsarbeidsbelastninger fra Runtime 1.3.

Denne guiden beskriver endringene som kan påvirke en migrering og gir en trinnvis prosess for å flytte arbeidsbelastningene dine til Runtime 2.0.

Hva som endret seg i Runtime 2.0

Tabellen nedenfor sammenligner hovedkomponentene i Runtime 1.3 og Runtime 2.0.

Runtime 2.0 tilbyr også nye Apache Spark 4.1-funksjonaliteter, inkludert VARIANT datatype, SQL-brukerdefinerte funksjoner, sesjonsvariabler, pipesyntaks, streng-sortering, Python Data Source API, Python brukerdefinerte tabellfunksjoner, samlet PySpark-profilering, og nye Structured Streaming tilstandsstyrings- og feilsøkings-API-er. For en oversikt, se Runtime 2.0 i Fabric.

Gjennomgå kompatibilitetsendringer

Gå gjennom følgende områder før du endrer et arbeidsområde eller miljø til Runtime 2.0.

Innebygde og tilpassede biblioteker

Runtime 2.0 fjerner flere forhåndsinstallerte Python- og R-pakker som var tilgjengelige i Runtime 1.3. Å redusere standardpakkesettet holder kjøretiden slank og reduserer overflatearealet for potensielle sikkerhetshendelser. En pakke som var tilgjengelig uten konfigurasjon i Runtime 1.3, må kanskje legges til eksplisitt i Runtime 2.0-miljøet ditt.

Bruk Library Manager for å legge til kun de pakkene som arbeidsmengden din krever, og lagre og publiser deretter miljøet. Library Manager løser pakkens nødvendige avhengigheter, så ikke legg til hver avhengighet i følgende inventarer individuelt. Ikke anta at et bibliotek er tilgjengelig eller at versjonen er uendret:

• Sammenlign Runtime 1.3- og Runtime 2.0-pakkeinventarene i Fabric runtime-releases-arkivet.
• Legg til manglende PyPI-, Conda-, Maven-, R- eller egendefinerte biblioteker i et miljø og publiser det.
• Pinne versjoner for produksjonsarbeidsbelastninger for å gjøre avhengighetsoppløsning repeterbar.
• Bekreft at Python-pakker støtter Python 3.13. Pakker med innebygde utvidelser må ha et kompatibelt Linux-hjul eller bygge vellykket på Azure Linux 3.0.
• Erstatt Scala 2.12-avhengigheter med Scala 2.13-artefakter. Artefaktnavn inkluderer ofte Scala-binærversjonen, som for eksempel _2.12 eller _2.13.
• Rekompiler egendefinerte JAR-filer mot Java 21, Scala 2.13 og Spark 4.1. Test transitive avhengigheter for konflikter med biblioteker levert under kjøretid.
• Bygg opp tilpassede native biblioteker for Azure Linux 3.0.

Fabric migrerer bibliotekspesifikasjoner når du endrer kjøretiden i et eksisterende miljø, men det kan ikke garantere at disse bibliotekene forblir kompatible. Publisering mislykkes når avhengighetsløsning finner en konflikt. For alternativer for pakkeinstallasjon og publiseringsmoduser, se Administrer biblioteker i Fabric-miljøer.

Pakker fjernet fra standardmiljøet

Følgende inventarer inkluderer brukervendte pakker og deres lavnivå- eller transitive avhengigheter. Søk i disse listene etter pakker som din Runtime 1.3-arbeidsbelastning bruker. Hvis en pakke er oppført, legg til en Python 3.13- eller R 4.5-kompatibel versjon via Library Manager i Runtime 2.0-miljøet ditt.

Endringer i gnistkonfigurasjon

Runtime 2.0 legger til og fjerner Spark-innstillinger og endrer noen standardverdier. Fabric bruker også andre standardinnstillinger enn Apache Spark for noen innstillinger.

Før du migrerer, se gjennom Spark-innstillingene du har konfigurert for arbeidsområdene, miljøene, notatbøkene og Spark-jobbdefinisjonene. Fjern innstillinger som ikke lenger støttes, og test arbeidsbelastninger som er avhengige av endrede standardinnstillinger. Bruk kjøretidsstandardene med mindre dokumentasjonen ber deg endre en innstilling.

Merkbare endringer i standardverdi

Tabellen nedenfor viser utvalgte grunnlinjeendringer. Ikke satt betyr at baseline ikke eksplisitt setter en verdi; det betyr ikke at funksjonen er deaktivert.

Runtime 2.0 bruker ROCKSDB også i stedet for LEVELDB for spark.shuffle.service.db.backend og setter spark.shuffle.service.removeShuffle til true. Spark bruker den eksterne stokkingstjenesten for å slette unødvendige stokkeblokker for deallokerte eksekutorer.

Delta parallell snapshot-lasting, parallell datahopping og driver-side snapshot-lasting endres også fra false til true. Test spørringsforsinkelse og bruk av driverressurser, spesielt for spørringer som får tilgang til flere Delta-tabeller.

Øktstart-overstyringer og native utførelse

Fabric-funksjonsutrullinger kan overstyre baseline-verdier når en økt starter.

Når du bruker den native utførelsesmotoren, inkluder følgende sjekker i regresjonstestene dine:

• Valider minnebruk med standarden for kolonnebatch-størrelse som øker fra 4 096 til 10 240.
• Sammenlign stokkingsplaner og ytelse med den sorteringsbaserte kolonnestokk-terskelen som synker fra 100 000 til 4 000 partisjoner.
• Sammenlign resultater med regelmessig uttrykk og ytelse. Native engine Java regex støtter endringer fra deaktivert til aktivert, og innstillingen som faller tilbake alle regex-uttrykk til Spark endres fra true til .false

Apache Spark 4.1 sine standardinnstillinger beholdt annerledes i Fabric

Fabric Runtime 2.0 overstyrer bevisst følgende Apache Spark 4.1-standardinnstillinger. Ikke anta at en upstream Spark 4.1-standard gjelder uendret i Fabric.

Spark SQL og DataFrame-oppførsel

Spark 4.1 introduserer atferdsendringer som kan endre spørringsresultater eller føre til at tidligere aksepterte spørringer feiler. Vær spesielt oppmerksom på ANSI SQL-oppførsel, casting, dato- og tidsstempeloperasjoner, datatyper, JDBC-mappinger og utdaterte SQL-konfigurasjoner.

Kjør regresjonstester som sammenligner:

• Utdataskjemaer, inkludert type, presisjon, skala og nullbarhet.
• Radteller og samlede resultater.
• Null, overløp, divisjon med null, og ugyldig kast-oppførsel.
• Dato, tidsstempel, tidssone og intervallresultater.
• JDBC-kilde- og sinktypemappinger.
• Spørreplaner og ytelse for kritiske arbeidsbelastninger.

Ikke bruk gamle kompatibilitetsinnstillinger som permanent migreringsstrategi. Hvis du midlertidig bruker en for å isolere en feil, oppdater den berørte koden og fjern innstillingen før du fullfører migreringen. For det komplette settet med atferdsendringer, se Spark SQL-migreringsguiden.

Python og pandas API på Spark

Runtime 2.0 flyttes fra Python 3.11 til Python 3.13 og inkluderer PySpark-endringene introdusert i Spark 4.1. Spark 4.1 øker også minimumsstøttede versjoner av pandas, NumPy og PyArrow, og fjerner API-er som tidligere ble foreldet i tidligere utgivelser.

Vanlige pandas API-oppdateringer på Spark inkluderer:

• Erstatt DataFrame.iteritems og Series.iteritems med items.
• Erstatt DataFrame.append og Series.append med ps.concat.
• Erstatt fjernede inplace parametere på kategoriske operasjoner med tildelinger.
• Gå gjennom endrede parameternavn og standardinnstillinger, som inclusive og Series.str.replace(regex=...).
• Valider resultatkolonnenavn, indeksnavn, d-typer og rekkefølge.

For den komplette listen, se PySpark-migreringsguiden.

Java- og Scala-applikasjoner

Scala 2.13 er ikke binærkompatibel med Scala 2.12. Å gjenbruke en Runtime 1.3 JAR i Runtime 2.0 kan forårsake klasselastingsfeil selv om kildekoden ikke har endret seg. Bygg en separat Runtime 2.0-artefakt og oppdater alle Scala-kryssbygde avhengigheter.

Spark 4.1 endrer også sine interne servlet-API-referanser fra javax til .jakarta Gå gjennom tilpassede lyttere, Spark-utvidelser og biblioteker som samhandler med Sparks interne deler. For andre endringer på motornivå, se Spark Core-migreringsguiden.

Strømmingsarbeidsbelastninger og koblinger

Den utdaterte EventHubConnector som er inkludert i Runtime 1.3, er ikke tilgjengelig i Runtime 2.0. Bruk Apache Spark Kafka-connectoren med det Kafka-kompatible endepunktet for Azure Event Hubs. For oppsettveiledning, se Use Apache Spark with Azure Event Hubs for Apache Kafka.

For relevante scenarioer kan du også evaluere Fabric eventstream for å ta inn strømmedata og behandle dem i en notatbok med Spark Structured Streaming. For mer informasjon, se Query eventstream i Microsoft Fabric fra en bærbar PC med Spark Structured Streaming.

For hver strukturert strømmingsarbeidsbelastning:

• Test om Runtime 2.0-spørringen kan starte på nytt fra en kopi av det eksisterende sjekkpunktet.
• Valider tilstandsfulle operasjoner, hendelsestid-vannmerker, triggere, kilde- og senkingsalternativer, samt utdataskjemaer.
• Hold kildedataene og det opprinnelige sjekkpunktet tilgjengelig til valideringen er fullført.
• Hvis et sjekkpunkt er inkompatibelt, planlegg en kontrollert omstart med et nytt sjekkpunkt. Ta hensyn til gjenspilling eller hoppet over input, og gjør sinken idempotent før du starter på nytt.

Se gjennom migreringsguiden for strukturert strømming for endringer i kompatibilitet oppstrøms.

Delta Lake-tabeller

Delta Lake opprettholder bakoverkompatibilitet for eksisterende tabeller, slik at Runtime 2.0 kan fungere med tabeller laget av Runtime 1.3. Å aktivere en nyere tabellfunksjon kan imidlertid heve tabellens leser- eller skriverprotokoll og forhindre at eldre motorer eller andre Fabric-opplevelser bruker tabellen.

Under den innledende kjøretidsmigreringen:

• Ikke oppgrader tabellprotokoller eller aktiver Delta Lake 4.2-funksjoner.
• Inspiser funksjonene og protokollversjonene av nyopprettede tabeller samt eksisterende tabeller. Runtime 2.0 setter spark.databricks.delta.properties.defaults.enableDeletionVectors til true; verifiser den resulterende tabellmetadataen i stedet for å anta at det å unngå manuell funksjonsaktivering bevarer kompatibiliteten.
• Testlesinger, skrivinger, sammenslåinger, skjemautvikling, vedlikeholdsoperasjoner og samtidig tilgang.
• Identifiser hver motor som leser eller skriver hver tabell, inkludert SQL-analyseendepunktet, Power BI, pipelines, dataflyter, hendelsesstrømmer og eksterne motorer.
• Aktiver en ny Delta-funksjon kun etter at alle forbrukere støtter den.

Delta Lake 4.2-spesifikke funksjoner er eksperimentelle i Fabric og er begrenset til Spark-opplevelser. For støttematriser og standardprotokollversjoner, se Delta Lake tabellformatinteroperabilitet.

Migrer arbeidsbelastningene dine

Bruk en trinnvis migrering i stedet for å endre kjøretiden for et produksjonsarbeidsområde umiddelbart.

1. Inventar arbeidsbelastningene dine i Runtime 1.3

Noter følgende informasjon:

• Notatbøker, Spark-jobbdefinisjoner, pipelines, tidsplaner og avlidende elementer.
• Arbeidsplass- og objektnivå-miljøtildelinger.
• Spark-konfigurasjoner, inkludert eventuelle innstillinger for eldre kompatibilitet.
• Offentlige, private og tilpassede biblioteker og deres løse versjoner.
• Egendefinerte JAR-filer, Python-hjul, R-pakker, native biblioteker og initialiseringslogikk.
• Datakilder, destinasjoner, hemmeligheter, forbindelser og nettverkskrav.
• Delta-tabeller og alle ikke-Spark-brukere av disse tabellene.
• Strømming av sjekkpunkter, skjemaer, offsets og gjenopprettingskrav.
• Forventede utdataskjemaer, radantall, datakvalitetskontroller og ytelsesbaselines.

Prioriter arbeidsbelastninger som bruker egendefinerte biblioteker, native kode, Scala, streaming state eller avanserte Delta-funksjoner.

2. Lag et testmiljø for Runtime 2.0

Lag et separat miljøelement og velg 2.0 (Spark 4.1, Delta 4.2) som kjøretid. Legg til de nødvendige bibliotekene, lagre miljøet, og publiser det. Legg miljøet til kopier av representative notatbøker og Spark-jobbdefinisjoner i et utviklings- eller testarbeidsområde.

Hvis produksjonsarbeidsområdet ditt fortsatt bruker Runtime 1.3, bør du ikke endre kjøretiden før testingen er fullført. Hold den eksisterende konfigurasjonen tilgjengelig for tilbakerulling under validering.

For å validere kommende Runtime 2.0-oppdateringer før de når standardkanalen, bruk early access-kanalen i testmiljøet ditt. For mer informasjon, se Fabric runtime release channels.

3. Oppdater biblioteker og kode

Bruk endringene identifisert i kompatibilitetsgjennomgangen:

1. Bytt ut manglende innebygde pakker med eksplisitte miljøavhengigheter.
2. Oppgrader eller bytt ut pakker som ikke støtter Python 3.13, Java 21, Scala 2.13 eller Azure Linux 3.0.
3. Bygg opp tilpassede JAR-filer og native binærfiler.
4. Oppdateringen fjernet PySpark og pandas API på Spark-kall.
5. Bytt ut EventHubConnector med Kafka-kontakten.
6. Fjern Spark-innstillinger for konfigurasjoner som ikke er tilgjengelige i Runtime 2.0, og gjennomgå eksplisitte overstyringer av konfigurasjoner med endrede standardinnstillinger.
7. Løs Spark SQL-atferdsforskjeller i koden i stedet for å være avhengig av gamle innstillinger permanent.
8. Hold eksisterende Delta-tabellfunksjoner og protokoller uendret i denne fasen.

4. Kjør kompatibilitets- og regresjonstester

Kjør de samme representative inputene på Runtime 1.3 og Runtime 2.0. Sammenligne:

• Fullføringsstatus, logger, advarsler og nye forsøk.
• Skjemaer og datatyper.
• Resultater på radnivå og aggregerte resultater.
• Delta-tabellens historikk og protokoll.
• Strømmingsfremgang, tilstand, latens og håndtering av duplikater.
• Utførelsestid, ressursbruk og kostnad.
• Nedstrøms resulterer i SQL-analyseendepunktet, Power BI, pipelines og andre forbrukere.

Inkluder feil- og gjenopprettingstester, ikke bare vellykkede forsøk. Testøkter starter på nytt, jobbforsøk, sjekkpunktgjenoppretting og samtidig tabelltilgang.

5. Rull ut Runtime 2.0

Flytt arbeidsmengder i kontrollerte batcher:

1. Publiser det validerte Runtime 2.0-miljøet.
2. Legg det til et lite sett produksjonsnotatbøker eller Spark-jobbdefinisjoner.
3. Kjør batchen og overvåk utganger og nedstrøms forbrukere.
4. Fortsett med resten av arbeidsmengden etter observasjonsperioden.
5. Sett Runtime 2.0 som arbeidsområde som standard først etter at migreringen på elementnivå er fullført.

Endring av arbeidsområdets kjøretid påvirker nye Spark-økter. Eksisterende økter fortsetter å bruke sin nåværende kjøretid til de stopper.

6. Behold en rullebane

Behold Runtime 1.3-miljøet, artefakter, bibliotekspesifikasjoner og strømmesjekkpunkter til Runtime 2.0-observasjonsperioden er over. For å rulle tilbake, koble til Runtime 1.3-miljøet på nytt eller gjenopprette forrige arbeidsområde-runtime og start en ny Spark-økt.

Sjekkliste for overføring

Før du fullfører migreringen, bekreft at:

• [ ] Alle nødvendige Python- og R-pakker er eksplisitt tilgjengelige og kompatible med Python 3.13 eller R 4.5.
• [ ] Egendefinerte JAR-filer retter seg mot Java 21, Scala 2.13 og Spark 4.1.
• [ ] Native dependencies fungerer på Azure Linux 3.0.
• [ ] Arbeidsområde, miljø, notatbok og Spark-jobbdefinisjonsinnstillinger bruker ikke fjernede Spark-konfigurasjoner.
• [ ] Arbeidsbelastninger testes mot de endrede Runtime 2.0 Spark-konfigurasjonsstandardene.
• [ ] Spark SQL og PySpark regresjonstester består.
• [ ] Event Hubs-arbeidsbelastninger bruker Kafka-kontakten.
• [ ] Strukturerte strømmingslaster starter på nytt og gjenopprettes som planlagt.
• [ ] Delta-tabellprotokoller og funksjoner forblir kompatible med alle brukere.
• [ ] Datakvalitet, ytelse og kostnadsresultater oppfyller dine akseptkriterier.
• [ ] Produksjonsutrulling, overvåking og tilbakerullingsprosedyrer dokumenteres og testes.

Relatert innhold

• Kjøretid 2.0 i Fabric
• Apache Spark runtimes i Stoff
• Apache Spark kjøretidslivssyklus i Fabric
• Administrer biblioteker i Fabric-miljøer
• Spark Runtime-utgivelser og oppdateringer