Opprinnelig utførelsesmotor for Fabric Data Engineering

Den opprinnelige utførelsesmotoren er en banebrytende forbedring for Apache Spark-jobbkjøringer i Microsoft Fabric. Denne vektoriserte motoren optimaliserer ytelsen og effektiviteten til Spark-spørringene dine ved å kjøre dem direkte på infrastrukturen i lakehouse. Motorens sømløse integrasjon betyr at den ikke krever kodeendringer og unngår leverandørlåsing. Den støtter Apache Spark API-er og er kompatibel med Runtime 1.3 (Apache Spark 3.5) og Runtime 2.0 (Apache Spark 4.1), og fungerer med Parquet-, Delta- og CSV-formater. Uavhengig av dataenes plassering i OneLake, eller hvis du får tilgang til data via snarveier, maksimerer den opprinnelige kjøringsmotoren effektiviteten og ytelsen.

Den opprinnelige kjøringsmotoren øker spørringsytelsen betydelig, samtidig som driftskostnadene minimeres. De faktiske resultatene varierer etter arbeidsmengdens egenskaper og konfigurasjon. Motoren er flink til å administrere en rekke databehandlingsscenarioer, alt fra rutinemessig datainntak, satsvise jobber og ETL-oppgaver (trekk ut, transformer, last inn) til komplekse datavitenskapsanalyser og responsive interaktive spørringer. Brukere drar nytte av akselerert behandlingstid, økt gjennomstrømming og optimalisert ressursutnyttelse.

Den opprinnelige kjøringsmotoren er basert på to viktige OSS-komponenter: Velox, et C++ databaseakselerasjonsbibliotek introdusert av Meta, og Apache Gluten (inkubating), et mellomlag som er ansvarlig for å avlaste JVM-baserte SQL-motorers utførelse til opprinnelige motorer introdusert av Intel.

Støttede operatører lastes ut fra JVM-basert Spark til en vektorisert C++-kjøringsvei, noe som gir kolonneformet, SIMD-akselerert prosessering med innebygd støtte for Parquet- og Delta-formater. Den innebygde motoren bevarer viktige Fabric Spark-spørringsoptimaliseringer, inkludert adaptiv spørringsutførelse (AQE), kostnadsbaserte omskrivinger, kolonnebeskjæring og predikatpushdown, slik at disse optimaliseringsatferdene forblir fullt aktive når operatørene blir avlastet. Motoren støtter også parallell Delta-snapshot-lasting og akselererer operasjoner som drar nytte av Z-ordering og Liquid Clustering på Delta-tabeller, noe som gir ytterligere ytelsesforbedringer for organiserte dataoppsett.

Når du skal bruke den opprinnelige kjøringsmotoren

Den opprinnelige kjøringsmotoren tilbyr en løsning for å kjøre spørringer på datasett i stor skala. den optimaliserer ytelsen ved hjelp av de opprinnelige egenskapene til underliggende datakilder og minimerer overhead som vanligvis er knyttet til databevegelse og serialisering i tradisjonelle Spark-miljøer. Motoren støtter ulike operatorer og datatyper, inkludert hash-aggregat for beregnet verdi, kringkast nestet løkkekobling (BNLJ) og nøyaktige tidsstempelformater. Hvis du imidlertid vil dra nytte av motorens egenskaper fullt ut, bør du vurdere de optimale brukstilfellene:

  • Motoren er effektiv når du arbeider med data i Parquet- og Delta-formater, som den kan behandle opprinnelig og effektivt.
  • Spørringer som involverer intrikate transformasjoner og aggregasjoner, drar betydelig nytte av den kolonnebaserte behandlings- og vektoriseringsfunksjonen til motoren.
  • Ytelsesforbedring er mest bemerkelsesverdig i scenarioer der spørringene ikke utløser tilbakefallsmekanismen ved å unngå funksjoner eller uttrykk som ikke støttes.
  • Motoren er godt egnet for spørringer som er beregningskrevende, i stedet for enkel eller I/O-bundet.

Hvis du vil ha informasjon om operatorene og funksjonene som støttes av den opprinnelige kjøringsmotoren, kan du se Apache Gluten-dokumentasjon.

Aktiver den opprinnelige kjøringsmotoren

Hvis du vil bruke de fullstendige funksjonene til den opprinnelige kjøringsmotoren i forhåndsvisningsfasen, er det nødvendig med bestemte konfigurasjoner. Følgende fremgangsmåter viser hvordan du aktiverer denne funksjonen for notatblokker, Spark-jobbdefinisjoner og hele miljøer.

Viktig

Den innebygde kjøremotoren støtter Runtime 1.3 (Apache Spark 3.5, Delta Lake 3.2) og Runtime 2.0 (Apache Spark 4.1, Delta Lake 4.1).

Aktiver på miljønivå

Aktiver den opprinnelige kjøringsmotoren på tvers av alle jobber og notatblokker som er knyttet til miljøet, for å sikre ensartede ytelsesforbedringer:

  1. Gå til arbeidsområdet som inneholder miljøet, og velg miljøet. Hvis du ikke har opprettet et miljø, kan du se Opprette, konfigurere og bruke et miljø i Fabric.

  2. Under Spark-databehandling velger du Akselerasjon.

  3. Merk av for Aktiver opprinnelig kjøringsmotor.

  4. Lagre og publiser endringene.

    Skjermbilde som viser hvordan du aktiverer den opprinnelige kjøringsmotoren i miljøelementet.

Når den er aktivert på miljønivå, arver alle etterfølgende jobber og notatblokker innstillingen. Denne arven sikrer at eventuelle nye økter eller ressurser som opprettes i miljøet, automatisk drar nytte av de forbedrede utførelsesfunksjonene.

Viktig

Tidligere ble den opprinnelige kjøringsmotoren aktivert via Spark-innstillinger i miljøkonfigurasjonen. Den opprinnelige kjøringsmotoren kan nå aktiveres enklere ved hjelp av en veksleknapp i Akselerasjon-fanen i miljøinnstillingene. Hvis du vil fortsette å bruke den, går du til Akselerasjon-fanen og slår på veksleknappen. Du kan også aktivere den via Spark-egenskaper hvis du foretrekker det.

Aktiver for en notatblokk eller spark-jobbdefinisjon

Du kan også aktivere den opprinnelige kjøringsmotoren for én enkelt notatblokk eller Spark-jobbdefinisjon, du må innlemme de nødvendige konfigurasjonene i begynnelsen av kjøringsskriptet:

%%configure 
{ 
   "conf": {
       "spark.native.enabled": "true", 
   } 
}

Sett inn de nødvendige konfigurasjonskommandoene i den første cellen for notatblokker. For Spark-jobbdefinisjoner kan du inkludere konfigurasjonene i frontlinjen i Spark-jobbdefinisjonen. Den opprinnelige kjøringsmotoren er integrert med live-bassenger, så når du aktiverer funksjonen, trer den i kraft umiddelbart uten å kreve at du starter en ny økt.

Kontroll på spørringsnivå

Mekanismene for å aktivere den opprinnelige kjøringsmotoren på leier-, arbeidsområde- og miljønivå, sømløst integrert med brukergrensesnittet, er under aktiv utvikling. I mellomtiden kan du deaktivere den opprinnelige kjøringsmotoren for bestemte spørringer, spesielt hvis de involverer operatorer som for øyeblikket ikke støttes (se begrensninger). Hvis du vil deaktivere, angir du Spark-konfigurasjonen spark.native.enabled til usann for den bestemte cellen som inneholder spørringen.

%%sql 
SET spark.native.enabled=FALSE;

Skjermbilde som viser hvordan du deaktiverer den opprinnelige kjøringsmotoren i en notatblokk.

Når du har utført spørringen der den opprinnelige kjøringsmotoren er deaktivert, må du aktivere den på nytt for etterfølgende celler ved å angi spark.native.enabled til sann. Dette trinnet er nødvendig fordi Spark kjører kodeceller sekvensielt.

%%sql 
SET spark.native.enabled=TRUE;

Identifiser operasjoner utført av motoren

Det finnes flere metoder for å finne ut om en operatør i Apache Spark-jobben ble behandlet ved hjelp av den opprinnelige kjøringsmotoren.

Spark UI- og Spark-loggserver

Få tilgang til Spark-brukergrensesnittet eller Spark-loggserveren for å finne spørringen du må undersøke. For å få tilgang til Spark-webgrensesnittet, naviger til din Spark-jobbdefinisjon og kjør den. Velg ... ved siden av Programnavn- på fanen Kjører, og velg Åpne Spark web UI. Du kan også få tilgang til Spark-brukergrensesnittet fra fanen Overvåke i arbeidsområdet. Velg notatblokken eller samlebåndet, fra overvåkingssiden, det er en direkte kobling til Spark UI- for aktive jobber.

Skjermbilde som viser hvordan du navigerer til Spark Web UI.

Se etter eventuelle nodenavn som slutter med suffikset Transformer, *NativeFileScan eller VeloxColumnarToRowExeci spørringsplanen som vises i Spark UI-grensesnittet. Suffikset indikerer at den opprinnelige kjøringsmotoren utførte operasjonen. Noder kan for eksempel være merket som RollUpHashAggregateTransformer, ProjectExecTransformer, BroadcastHashJoinExecTransformer, ShuffledHashJoinExecTransformer eller BroadcastNestedLoopJoinExecTransformer. For CSV-datakilder kan native skanninger vises som native filskannings- eller transformatornoder i Spark UI, på samme måte som Parquet- og Delta-skannnoder.

Skjermbilde som viser hvordan du kontrollerer DAG-visualisering som slutter med suffikstransformatoren.

DataFrame-forklaring

Alternativt kan du utføre df.explain() kommandoen i notatblokken for å vise utførelsesplanen. Se etter samme Transformer, *NativeFileScan eller VeloxColumnarToRowExec suffikser i utdataene. Denne metoden gir en rask måte å bekrefte om bestemte operasjoner håndteres av den opprinnelige kjøringsmotoren.

Skjermbilde som viser hvordan du kontrollerer den fysiske planen for spørringen, og ser at spørringen ble utført av den opprinnelige kjøringsmotoren.

Fabric Spark Advisor-varsler

Fabric Spark Advisor gir sanntids fallback-synlighet under kjøring av bærbare datamaskinceller. Når et operatør- eller plansegment faller tilbake til JVM-basert Spark i stedet for den opprinnelige stien, viser Advisor et varsel direkte i notatbokens celleutdata, noe som hjelper deg raskt å identifisere ikke-støttede operatører eller konfigurasjoner uten å forlate notatboken. Du kan bruke disse varslene til å diagnostisere når native offload ikke er implementert, og for å avgjøre om du skal justere spørringen eller konfigurasjonen.

Tilbakefallsmekanisme

I noen tilfeller kan det hende at den opprinnelige kjøringsmotoren ikke kan kjøre en spørring på grunn av årsaker som funksjoner som ikke støttes. I disse tilfellene faller operasjonen tilbake til den tradisjonelle Spark-motoren. Denne automatiske tilbakefallsmekanismen sikrer at det ikke er noen avbrudd i arbeidsflyten.

Skjermbilde som viser tilbakefallsmekanismen.

Skjermbilde som viser hvordan du kontrollerer logger som er knyttet til tilbakefallsmekanismen.

Overvåk spørringer og datarammer utført av motoren

Hvis du vil forstå hvordan den opprinnelige kjøringsmotoren brukes på SQL-spørringer og DataFrame-operasjoner, og for å drille ned til fase- og operatornivåene, kan du se Spark UI og Spark History Server for mer detaljert informasjon om den opprinnelige kjøringen av motoren.

Fanen Opprinnelig kjøringsmotor

Du kan gå til den nye fanen Gluten SQL /DataFrame for å vise informasjon om glutenbygg og kjøring av spørringer. Spørringer-tabellen gir innsikt i antall noder som kjører på den opprinnelige motoren, og de som faller tilbake til JVM for hver spørring.

Skjermbilde som viser den opprinnelige kjøringsmotorfanen.

Spørringskjøringsdiagram

Du kan også velge spørringsbeskrivelsen for visualiseringen av Kjøringsplan for Apache Spark-spørringen. Utføringsdiagrammet gir opprinnelige utførelsesdetaljer på tvers av faser og deres respektive operasjoner. Bakgrunnsfarger skiller ut kjøringsmotorene: grønn representerer den opprinnelige kjøringsmotoren, mens lyseblå angir at operasjonen kjører på standard JVM-motor.

Skjermbilde som viser spørringskjøringsdiagram.

Begrensninger

Selv om den innebygde kjøringsmotoren (NEE) i Fabric øker ytelsen betydelig for Apache Spark-jobber, har den for øyeblikket følgende begrensninger. Flere korrekthetsrelaterte elementer som gjaldt Runtime 1.3 (Apache Spark 3.5) løses i Runtime 2.0 (Apache Spark 4.1); Hvert element noterer kjøretiden det gjelder for.

Eksisterende begrensninger

  • Inkompatible Spark-funksjoner (alle kjøretider): Den native kjøremotoren støtter for øyeblikket ikke strukturert strømming. Hvis du bruker ikke-støttede funksjoner enten direkte eller gjennom importerte biblioteker, går Spark tilbake til sin standardmotor. Den innebygde kjøremotoren støtter nå Python UDF-er, Scala UDF-er og komplekse datatyper (arrays, kart, strukturer). For mer informasjon, se Python UDF-er, Scala UDF-er og komplekse datatyper i den opprinnelige kjøringsmotoren.

  • Ustøttede filformater (alle kjøretider): Den native kjøremotoren akseler ikke spørringer mot JSON og XML formatering. Disse formatene går som standard tilbake til den vanlige Spark JVM-motoren for kjøring. Den vektoriserte CSV-parseren støtter nå CSV.

  • ANSI-modus (kun Runtime 1.3): På Runtime 1.3 (Apache Spark 3.5) støtter ikke den native kjøremotoren ANSI SQL-modus. Hvis du aktiverer ANSI SQL-modus, faller kjøringen tilbake til den vanlige Spark-motoren. På kjøretid 2.0 (Apache Spark 4.1) støttes ANSI SQL-modus: operatører laster ut til den native motoren og ANSI-feilsemantikk (for eksempel divisjon med null og ugyldige kast) håndheves konsekvent med JVM Spark.

  • Datofiltertype-mismatcher (alle kjøretider): For å dra nytte av akselerasjonen til den native kjøringsmotoren, sørg for at begge sider av en datosammenligning matcher i datatype. I stedet for å sammenligne en DATETIME kolonne med en strenglitteral, kan du for eksempel konvertere den eksplisitt som vist:

    CAST(order_date AS DATE) = '2024-05-20'

Andre hensyn og begrensninger

Bemerkning

Desimal-kasting, tidssone, round()duplikatnøkkel map() og collect_list()collect_set()/elementer i denne seksjonen gjelder for Runtime 1.3 (Apache Spark 3.5) og løses i Runtime 2.0 (Apache Spark 4.1). De beholdes for brukere som fortsatt kjører på Runtime 1.3.

  • Desimal-til-flyt kastemismatch (Runtime 1.3; løst i Runtime 2.0): Når man kaster fra DECIMAL til FLOAT, bevarer Spark presisjon ved å konvertere til en streng og parse den. På kjøretid 1.3 utfører NEE (via Velox) en direkte kast fra den interne int128_t representasjonen, noe som kan føre til avrundingsavvik.

  • Tidssonekonfigurasjonsfeil (Runtime 1.3; løst i Runtime 2.0): På Runtime 1.3 fører innstilling av en ukjent tidssone i Spark til at jobben feiler under NEE, mens Spark JVM håndterer det elegant. Eksempel:

    "spark.sql.session.timeZone": "-08:00"  // May cause failure under NEE on Runtime 1.3

  • Inkonsistent avrundingsoppførsel (Runtime 1.3; løst i Runtime 2.0): På Runtime 1.3 oppfører funksjonen seg annerledes round() i NEE på grunn av avhengighet av std::round, som ikke replikerer Sparks avrundingslogikk. Denne forskjellen kan føre til numeriske inkonsistenser i avrundingsresultatene.

  • Manglende sjekk av duplikattaster i map() funksjonen (Runtime 1.3; løst i Runtime 2.0): Når spark.sql.mapKeyDedupPolicy er satt til UNNTAK, gir Spark en feil for dupliserte nøkler. På Runtime 1.3 hopper NEE over denne sjekken og lar spørringen lykkes feil. På Runtime 2.0 øker DUPLICATED_MAP_KEY NEE jevnlig med JVM Spark.
    Eksempel:

    SELECT map(1, 'a', 1, 'b'); -- Should fail with duplicate keys

  • Ordensvarians i collect_list() med sortering (Runtime 1.3; løst i Runtime 2.0): Når man bruker DISTRIBUTE BY og SORT BY, bevarer Spark elementrekkefølgen i collect_list(). På kjøretid 1.3 kan NEE returnere verdier i en annen rekkefølge på grunn av forskjeller i stokking, noe som kan føre til uoverensstemmende forventninger for ordrefølsom logikk.

  • Intermediær typemismatch for collect_list() / collect_set() (Runtime 1.3; løst i Runtime 2.0): På Runtime 1.3 bruker BINARY Spark som mellomtype for disse aggregeringene, mens NEE bruker ARRAY. Denne uoverensstemmelsen kan føre til kompatibilitetsproblemer under spørringsplanlegging eller -kjøring.

  • Administrerte private endepunkter som kreves for lagringstilgang (alle kjøretider): Når Native Execution Engine (NEE) er aktivert, og hvis spark-jobber prøver å få tilgang til en lagringskonto ved å bruke et administrert privat endepunkt, må du konfigurere separate administrerte private endepunkter for både Blob (blob.core.windows.net) og DFS / File System (dfs.core.windows.net), selv om de peker til samme lagringskonto. Du kan ikke gjenbruke ett enkelt endepunkt for begge. Denne begrensningen kan kreve ekstra nettverkskonfigurasjon når man aktiverer native kjøringsmotor i et arbeidsområde som har administrerte private endepunkter til lagringskontoer.

Se denne Fabric espresso video på opprinnelige kjøring motor

Relatert innhold

  • Last updated on