Del via

Stoff Kjøretid 1.2 (GA)

  • Artikkel

Microsoft Fabric Runtime er en Azure-integrert plattform basert på Apache Spark som muliggjør utførelse og administrasjon av datateknikk og datavitenskapsopplevelser. Dette dokumentet dekker Runtime 1.2-komponentene og -versjonene.

Hovedkomponentene i Runtime 1.2 inkluderer:

  • Apache Spark 3.4.1
  • Operativsystem: Mariner 2.0
  • Java: 11
  • Scala: 2.12.17
  • Python: 3.10
  • Deltasjøen: 2.4.0
  • R: 4.2.2

Tips

Bruk alltid den nyeste GA-kjøretidsversjonen for produksjonsarbeidsbelastningen, som for øyeblikket er Runtime 1.3.

Skjermbilde som viser hvor du velger kjøretidsversjon.

Microsoft Fabric Runtime 1.2 leveres med en samling standardnivåpakker, inkludert en fullstendig Anaconda-installasjon og vanlige biblioteker for Java/Scala, Python og R. Disse bibliotekene inkluderes automatisk når du bruker notatblokker eller jobber i Microsoft Fabric-plattformen. Se dokumentasjonen for en fullstendig liste over biblioteker. Microsoft Fabric ruller regelmessig ut vedlikeholdsoppdateringer for Runtime 1.2, som gir feilrettinger, ytelsesforbedringer og sikkerhetsoppdateringer. Å holde seg oppdatert sikrer optimal ytelse og pålitelighet for databehandlingsoppgavene dine.

Nye funksjoner og forbedringer i Spark Release 3.4.1

Apache Spark 3.4.0 er den femte utgivelsen på 3.x-linjen. Denne utgivelsen, drevet av åpen kildekode-fellesskapet, løste over 2600 Jira-billetter. Den introduserer en Python-klient for Spark Connect, forbedrer strukturert strømming med asynkrone fremdriftssporing og Python-tilstandsfull behandling. Den utvider Pandas API-dekning med støtte for NumPy-inndata, forenkler overføring fra tradisjonelle datalagre gjennom ANSI-samsvar og nye innebygde funksjoner. Det forbedrer også utviklingsproduktiviteten og feilsøkingen med minneprofilering. Runtime 1.2 er i tillegg basert på Apache Spark 3.4.1, en vedlikeholdsutgivelse med fokus på stabilitetsløsninger.

Høydepunkter

Les hele versjonen av produktmerknadene for en bestemt Apache Spark-versjon ved å gå til både Spark 3.4.0 og Spark 3.4.1.

Nye egendefinerte spørringsoptimaliseringer

Samtidig skriver støtte i Spark

Det oppstod en 404-feil med meldingen «Operasjonen mislyktes: Den angitte banen finnes ikke» er et vanlig problem når du utfører parallelle datainnføringer i samme tabell ved hjelp av en SQL INSERT INTO-spørring. Denne feilen kan føre til tap av data. Vår nye funksjon, File Output Committer Algorithm, løser dette problemet, slik at kundene kan utføre parallell datainnsetting sømløst.

Hvis du vil ha tilgang til denne funksjonen, aktiverer du funksjonsflagget spark.sql.enable.concurrentWrites , som aktiveres som standard fra Runtime 1.2 (Spark 3.4). Selv om denne funksjonen også er tilgjengelig i andre Spark 3-versjoner, er den ikke aktivert som standard. Denne funksjonen støtter ikke parallell kjøring av INSERT OVERWRITE-spørringer der hver samtidige jobb overskriver data på forskjellige partisjoner i samme tabell dynamisk. For dette formålet tilbyr Spark en alternativ funksjon, som kan aktiveres ved å spark.sql.sources.partitionOverwriteMode konfigurere innstillingen til dynamisk.

Smarte leser, som hopper over filer fra mislykkede jobber

Når en innsetting i en tabelljobb mislykkes i gjeldende Spark-innføringssystem, men noen oppgaver lykkes, eksisterer filene som genereres av de vellykkede oppgavene sammen med filer fra den mislykkede jobben. Denne sameksistensen kan føre til forvirring for brukere ettersom det blir utfordrende å skille mellom filer som tilhører vellykkede og mislykkede jobber. Videre, når én jobb leser fra en tabell mens en annen setter inn data samtidig i samme tabell, kan lesejobben få tilgang til uforpliktende data. Hvis en skrivejobb mislykkes, kan lesejobben behandle uriktige data.

Flagget spark.sql.auto.cleanup.enabled styrer den nye funksjonen, og løser dette problemet. Når den er aktivert, hopper Spark automatisk over lesefiler som ikke har blitt utført når den utfører spark.read eller velger spørringer fra en tabell. Filer som er skrevet før du aktiverer denne funksjonen, leses fortsatt som vanlig.

Her er de synlige endringene:

  • Alle filer inneholder nå en tid-{jobID} identifikator i filnavnene.
  • I stedet for indikatoren _success som vanligvis opprettes på utdataplasseringen etter vellykket fullføring av jobben, genereres en ny _committed_{jobID} indikator. Denne indikatoren knytter vellykkede jobb-ID-er til bestemte filnavn.
  • Vi introduserte en ny SQL-kommando som brukere kan kjøre med jevne mellomrom for å administrere lagring og rydde opp i uforpliktende filer. Syntaksen for denne kommandoen er som følger:
    • Slik rydder du opp i en bestemt katalog: CLEANUP ('/path/to/dir') [RETAIN number HOURS];
    • Slik rydder du opp i en bestemt tabell: CLEANUP [db_name.]table_name [RETAIN number HOURS]; I denne syntaksen path/to/dir representerer du plasserings-URI-en der opprydding kreves, og number er en dobbel typeverdi som representerer oppbevaringsperioden. Standard oppbevaringsperiode er satt til sju dager.
  • Vi introduserte et nytt konfigurasjonsalternativ kalt spark.sql.deleteUncommittedFilesWhileListing, som er satt til false som standard. Aktivering av dette alternativet resulterer i automatisk sletting av uforpliktende filer under lesing, men dette scenarioet kan redusere leseoperasjonene. Det anbefales å kjøre oppryddingskommandoen manuelt når klyngen er inaktiv i stedet for å aktivere dette flagget.

Overføringsveiledning fra Runtime 1.1 til Runtime 1.2

Når du overfører fra Runtime 1.1, drevet av Apache Spark 3.3, til Runtime 1.2, drevet av Apache Spark 3.4, kan du se gjennom den offisielle overføringsveiledningen.

Nye funksjoner og forbedringer i Delta Lake 2.4

Delta Lake er et åpen kilde prosjekt som muliggjør bygging av en lakehouse arkitektur på toppen av datainnsjøer. Delta Lake leverer ACID-transaksjoner, skalerbar metadatahåndtering og forener strømming og satsvis databehandling i tillegg til eksisterende datainnsjøer.

Spesielt tilbyr Delta Lake:

  • ACID-transaksjoner på Spark: Serialiserbare isolasjonsnivåer sikrer at leserne aldri ser inkonsekvente data.
  • Skalerbar metadatabehandling: Bruker Spark-distribuert prosessorkraft til å håndtere alle metadataene for petabyte-skalatabeller med milliarder av filer.
  • Strømming og gruppeforening : Et bord i Delta Lake er et partibord og en strømmingskilde og vask. Strømming av datainntak, satsvis historisk etterfylling, interaktive spørringer fungerer bare ut av boksen.
  • Skjemahåndhevelse: Håndterer automatisk skjemavariasjoner for å hindre innsetting av ugyldige poster under inntak.
  • Tidsreiser: Dataversjonering muliggjør tilbakerullinger, fullstendige historiske revisjonsspor og reproduserbare maskinlæringseksperimenter.
  • Upserts og deletes: Støtter sammenslåing, oppdatering og sletting av operasjoner for å aktivere komplekse brukstilfeller som endring-data-capture, sakte endrede dimensjonsoperasjoner (SCD), streaming upserts og så videre.

Les hele versjonen av produktmerknadene for Delta Lake 2.4.

Standardnivåpakker for Java, Scala, Python-biblioteker

Hvis du vil ha en liste over alle standardnivåpakker for Java, Scala, Python og deres respektive versjoner, kan du se produktmerknadene.

Relatert innhold