Del via

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 fungerer med både Parquet- og Delta-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. Den leverer en bemerkelsesverdig hastighetsforbedring, og oppnår opptil fire ganger raskere ytelse sammenlignet med tradisjonell OSS-programvare (åpen kildekode-programvare) Spark, som validert av TPC-DS 1-TB-referansen. 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.

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 opprinnelige utførelsesmotoren støtter den nyeste GA runtime-versjonen, som er Runtime 1.3 (Apache Spark 3.5, Delta Lake 3.2). Med utgivelsen av den opprinnelige kjøringsmotoren i Runtime 1.3 er støtten for den forrige versjonen – Runtime 1.2 (Apache Spark 3.4, Delta Lake 2.4) – avviklet. Vi oppfordrer alle kunder til å oppgradere til den nyeste Runtime 1.3. Hvis du bruker den opprinnelige kjøringsmotoren på kjøretid 1.2, deaktiveres opprinnelig akselerasjon.

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. Hvis du vil ha tilgang til Spark Web UI, går du til Spark Job Definition og kjører det. 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.

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.

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 opprinnelige kjøringsmotoren (NEE) i Microsoft Fabric øker ytelsen betydelig for Apache Spark-jobber, har den for øyeblikket følgende begrensninger:

Eksisterende begrensninger

  • Inkompatible Spark-funksjoner: Opprinnelig kjøringsmotor støtter for øyeblikket ikke brukerdefinerte funksjoner (UDF-er), array_contains funksjonen eller strukturert strømming. Hvis disse funksjonene eller funksjonene som ikke støttes, brukes direkte eller via importerte biblioteker, går Spark tilbake til standardmotoren.

  • Filformater som ikke støttes: Spørringer mot JSON, XMLog CSV formater akselereres ikke av opprinnelig kjøringsmotor. Disse går som standard tilbake til den vanlige Spark JVM-motoren for kjøring.

  • ANSI-modus støttes ikke: Opprinnelig kjøringsmotor støtter ikke ANSI SQL-modus. Hvis den er aktivert, faller kjøringen tilbake til vanilje Spark-motoren.

  • Samsvar mellom datofiltertyper: Hvis du vil dra nytte av den opprinnelige kjøringsmotorens akselerasjon, må du sørge for at begge sider av en datosammenligning samsvarer med datatypen. 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

  • Desimal til Flytavstøpningskonflikt: Når du kaster fra DECIMAL til FLOAT, bevarer Spark presisjon ved å konvertere til en streng og analysere den. NEE (via Velox) utfører en direkteavstøpning fra den interne int128_t representasjonen, noe som kan resultere i avrundingsavvik.

  • Tidssonekonfigurasjonsfeil : Hvis du angir en ukjent tidssone i Spark, vil jobben mislykkes under NEE, mens Spark JVM håndterer den på en grasiøs måte. Eksempel:

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

  • Inkonsekvent avrundingsatferd: Funksjonen round() oppfører seg annerledes i NEE på grunn av avhengighet av std::round, som ikke replikerer Sparks avrundingslogikk. Dette kan føre til numeriske inkonsekvenser i avrundingsresultater.

  • Mangler duplikatnøkkelinnsjekkingsfunksjonmap(): Når spark.sql.mapKeyDedupPolicy er satt til UNNTAK, utløses en feil for dupliserte taster. NEE hopper over denne kontrollen og lar spørringen lykkes feil.
    Eksempel:

    SELECT map(1, 'a', 1, 'b'); -- Should fail, but returns {1: 'b'}

  • Rekkefølgevarians i collect_list() med sortering: Når du bruker DISTRIBUTE BY og SORT BY, bevarer Spark elementrekkefølgen i collect_list(). NEE kan returnere verdier i en annen rekkefølge på grunn av tilfeldige forskjeller, noe som kan føre til uoverensstemmende forventninger til ordresensitiv logikk.

  • Mellomliggende typekonflikt for collect_list() / collect_set(): Spark bruker BINARY som mellomliggende type for disse aggregasjonene, mens NEE bruker .ARRAY Denne uoverensstemmelsen kan føre til kompatibilitetsproblemer under spørringsplanlegging eller -kjøring.

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

Relatert innhold

  • Last updated on