Intern körningsmotor för Fabric Data Engineering

Den ursprungliga exekveringsmotorn är en banbrytande förbättring för Apache Spark-jobbkörningar i Microsoft Fabric. Den här vektoriserade motorn optimerar prestanda och effektivitet för dina Spark-frågor genom att köra dem direkt på lakehouse-infrastrukturen. Motorns sömlösa integrering innebär att den inte kräver några kodändringar utan att skapa beroende av leverantören. Den stöder Apache Spark-API:er och är kompatibel med Runtime 1.3 (Apache Spark 3.5) och Runtime 2.0 (Apache Spark 4.1) och fungerar med Parquet-, Delta- och CSV-format. Oavsett var dina data befinner sig i OneLake, eller om du kommer åt data via genvägar, maximerar den inbyggda körningsmotorn effektivitet och prestanda.

Den infödda körningsmotorn förbättrar frågeprestandan avsevärt samtidigt som driftskostnaderna sänks. Faktiska resultat varierar beroende på arbetsbelastningens egenskaper och konfiguration. Motorn är skicklig på att hantera en mängd olika databearbetningsscenarier, allt från rutinmässig datainmatning, batchjobb och ETL-uppgifter (extrahera, transformera, läsa in) till komplexa datavetenskapsanalyser och dynamiska interaktiva frågor. Användarna drar nytta av snabbare bearbetningstider, ökat dataflöde och optimerad resursanvändning.

Den interna körningsmotorn baseras på två viktiga OSS-komponenter: Velox, ett C++-databasaccelerationsbibliotek som introducerades av Meta och Apache Gluten (inkubering), ett mellanlager som ansvarar för att avlasta JVM-baserade SQL-motorers körning till inbyggda motorer som introducerades av Intel.

Operatorer som stöds avlastas från JVM-baserade Spark till en vektoriserad körningsväg i C++, som möjliggör kolumnbaserad, SIMD-accelererad bearbetning med inbyggt stöd för Parquet- och Delta-format. Den inhemska motorn bibehåller viktiga Fabric Spark-frågeoptimeringar, inklusive adaptiv frågekörning (AQE), kostnadsbaserade omskrivningar, kolumnbeskärning och predikat-nedtryckning, så att dessa optimeringsbeteenden förblir helt aktiva när operatorerna avlastas. Motorn stöder även parallell inläsning av Delta-snapshots och påskyndar åtgärder som drar nytta av Z-ordering och Liquid Clustering i Delta tables, vilket ger ytterligare prestandaförbättringar för strukturerade datalayouts.

När du ska använda den inbyggda körningsmotorn

Den interna körningsmotorn erbjuder en lösning för att köra frågor på storskaliga datauppsättningar. den optimerar prestanda med hjälp av de inbyggda funktionerna i underliggande datakällor och minimerar de omkostnader som vanligtvis associeras med dataflytt och serialisering i traditionella Spark-miljöer. Motorn stöder olika operatorer och datatyper, inklusive rollup-hashaggregation, broadcast nested loop join (BNLJ) och precisa tidsstämpelformat. Men för att dra full nytta av motorns funktioner bör du överväga dess optimala användningsfall:

• Motorn är effektiv när den arbetar med data i Parquet- och Delta-format, som den kan bearbeta nativt och effektivt.
• Frågor som omfattar invecklade omvandlingar och sammansättningar drar stor nytta av motorns funktioner för kolumnbearbetning och vektorisering.
• Prestandaförbättringar är mest anmärkningsvärda i scenarier där frågorna inte utlöser återställningsmekanismen genom att undvika funktioner eller uttryck som inte stöds.
• Motorn passar bra för frågor som är beräkningsintensiva snarare än enkla eller I/O-bundna.

Information om operatorer och funktioner som stöds av den interna körningsmotorn finns i Dokumentation om Apache Gluten.

Aktivera den inbyggda körningsmotorn

För att kunna använda de fullständiga funktionerna i den inbyggda körningsmotorn under förhandsversionsfasen krävs specifika konfigurationer. Följande procedurer visar hur du aktiverar den här funktionen för notebook-filer, Spark-jobbdefinitioner och hela miljöer.

Aktivera på miljönivå

För att säkerställa en enhetlig prestandaförbättring aktiverar du den inbyggda körningsmotorn för alla jobb och notebook-filer som är associerade med din miljö:

1. Navigera till arbetsytan som innehåller din miljö och välj miljön. Om du inte har skapat någon miljö kan du se Skapa, konfigurera och använda en miljö i Fabric.

2. Under Spark-beräkning väljer du Acceleration.

3. Markera kryssrutan Aktivera inbyggd körningsmotor.

4. Spara och publicera ändringarna.

   

När den är aktiverad på miljönivå ärver alla efterföljande arbeten och anteckningsböcker inställningen. Denna ärvning säkerställer att alla nya sessioner eller resurser som skapas i miljön automatiskt drar nytta av de förbättrade exekveringsmöjligheterna.

Aktivera för en notebook- eller Spark-jobbdefinition

Du kan också aktivera den inbyggda körningsmotorn för en enda notebook- eller Spark-jobbdefinition; du måste infoga de nödvändiga konfigurationerna i början av ditt körningsskript.

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

För notebook-filer infogar du nödvändiga konfigurationskommandon i den första cellen. För Spark-jobbdefinitioner inkluderar du konfigurationerna i frontlinjen för din Spark-jobbdefinition. Den interna körningsmotorn är integrerad med livepooler, så när du har aktiverat funktionen träder den i kraft omedelbart utan att du behöver starta en ny session.

Kontroll på frågenivå

Mekanismerna för att aktivera den interna körningsmotorn på klient-, arbetsytans och miljöns nivåer, sömlöst integrerade med användargränssnittet, är under aktiv utveckling. Under tiden kan du inaktivera den interna körningsmotorn för specifika frågor, särskilt om de omfattar operatorer som för närvarande inte stöds (se begränsningar). Om du vill inaktivera anger du Spark-konfigurationen spark.native.enabled till false för den specifika cell som innehåller din fråga.

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

%%pyspark
spark.conf.set('spark.native.enabled', 'false')   

%%spark  
spark.conf.set("spark.native.enabled", "false")   

%%sparkr
library(SparkR)
sparkR.conf("spark.native.enabled", "false")

När du har kört frågan där den nativa körmotorn är inaktiverad måste du återaktivera den för efterföljande celler genom att ange spark.native.enabled till true. Det här steget är nödvändigt eftersom Spark kör kodceller sekventiellt.

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

%%pyspark
spark.conf.set('spark.native.enabled', 'true')   

%%spark  
spark.conf.set("spark.native.enabled", "true")   

%%sparkr
library(SparkR)
sparkR.conf("spark.native.enabled", "true")

Identifiera åtgärder som körs av motorn

Det finns flera metoder för att avgöra om en operator i ditt Apache Spark-job kördes med den inbyggda exekveringsmotorn.

Spark-användargränssnitt och Spark-historikserver

Gå till Spark-användargränssnittet eller Spark-historikservern för att hitta den fråga som du behöver inspektera. För att komma åt Sparks webbgränssnitt, navigera till din Spark-jobbdefinition och kör den. På fliken Kör väljer du ... bredvid Programnamn och väljer Öppna Spark-webbgränssnittet. Du kan också komma åt Spark-användargränssnittet från fliken Övervaka på arbetsytan. Välj anteckningsboken eller pipelinen, på övervakningssidan finns det en direktlänk till Spark-användargränssnittet för aktiva jobb.

I frågeplanen som visas i Gränssnittet för Spark letar du efter eventuella nodnamn som slutar med suffixet Transformer, *NativeFileScan eller VeloxColumnarToRowExec. Suffixet anger att den inbyggda körningsmotorn utförde operationen. Noder kan till exempel märkas som RollUpHashAggregateTransformer, ProjectExecTransformer, BroadcastHashJoinExecTransformer, ShuffledHashJoinExecTransformer eller BroadcastNestedLoopJoinExecTransformer. För CSV-datakällor kan inbyggda genomsökningar visas som inbyggda filgenomsöknings- eller transformeringsnoder i Spark-användargränssnittet, liknande noder för Parquet- och Delta-skanning.

DataFrame-förklaring

Alternativt kan du köra df.explain()-kommandot i din anteckningsbok för att visa körningsplanen. Leta efter samma Transformer, *NativeFileScan eller VeloxColumnarToRowExec suffixer i utdata. Den här metoden ger ett snabbt sätt att bekräfta om specifika åtgärder hanteras av den inbyggda exekveringsmotorn.

Fabric Spark Advisor larm

Fabric Spark Advisor ger realtidsinsikt vid fallback under körning av notebook-celler. När en operatör eller ett plansegment återgår till JVM-baserade Spark i stället för den interna sökvägen, visas en avisering direkt i notebook-cellens utdata, vilket hjälper dig att snabbt identifiera operatorer eller konfigurationer som inte stöds utan att lämna notebook-filen. Du kan använda dessa aviseringar för att diagnostisera när intern avlastning inte tillämpas och för att bestämma om du vill justera din fråga eller konfiguration.

Reservmekanism

I vissa fall kanske den inbyggda körningsmotorn inte kan köra en fråga på grund av att vissa funktioner inte stöds. I dessa fall återgår åtgärden till den traditionella Spark-motorn. Den här automatiska återställningsmekanismen säkerställer att arbetsflödet inte avbryts.

Övervaka frågor och dataramar som körs av motorn

För att bättre förstå hur körningsmotorn för lokal körning tillämpas på SQL-frågor och DataFrame-åtgärder, och för att utforska steg- och operatornivåerna djupare, kan du hänvisa till mer detaljerad information om körning av den lokala motorn i Spark-användargränssnittet och Spark History Server.

Fliken Infödd körningsmotor

Du kan gå till den nya fliken Gluten SQL/DataFrame för att visa information om Gluten-kompilering och frågekörning. Tabellen Frågor ger insikter om antalet noder som körs på den inbyggda motorn och de som faller tillbaka till JVM för varje fråga.

Diagram över frågeexekvering

Du kan också välja på frågebeskrivningen för visualiseringen av Apache Spark-frågeutförandeplanen. Exekveringsgrafen innehåller inhemska exekveringsdetaljer över faser och deras respektive operationer. Bakgrundsfärger skiljer körningsmotorerna åt: grönt representerar den interna körningsmotorn, medan ljusblå anger att åtgärden körs på JVM-standardmotorn.

Begränsningar

Även om den inbyggda exekveringsmotorn (NEE) i Fabric avsevärt ökar prestandan för Apache Spark-jobb, har den för närvarande följande begränsningar. Flera korrekthetsrelaterade element som gällde för Runtime 1.3 (Apache Spark 3.5) löses i Runtime 2.0 (Apache Spark 4.1); Varje objekt noterar den körtid det gäller för.

Befintliga begränsningar

• Inkompatibla Spark-funktioner (alla körtider): Den inbyggda exekveringsmotorn stöder för närvarande inte strukturerad streaming. Om du använder icke-stödda funktioner antingen direkt eller via importerade bibliotek, återgår Spark till sin standardmotor. Den inbyggda exekveringsmotorn stödjer nu Python UDF, Scala UDF och komplexa datatyper (arrayer, kartor, structs). Mer information finns i Python UDF:er, Scala UDF:er och komplexa datatyper i den interna körningsmotorn.

• Ej stödda filformat (alla körningar): Den inbyggda exekveringsmotorn accelererar inte frågor mot JSON och XML formaterar. Dessa format återgår som standard till den vanliga Spark JVM-motorn för exekvering. Den vektoriserade CSV-parsern stödjer nu CSV.

• ANSI-läge (endast Runtime 1.3): På Runtime 1.3 (Apache Spark 3.5) stöder inte den inbyggda exekveringsmotorn ANSI SQL-läge. Om du aktiverar ANSI SQL-läge faller exekveringen tillbaka på den vanliga Spark-motorn. På Runtime 2.0 (Apache Spark 4.1) stöds ANSI SQL-läge: operatörer avlastar till den inbyggda motorn och ANSI-felsemantik (till exempel division med noll och ogiltiga kast) upprätthålls konsekvent med JVM Spark.

• Datumfiltertyp-mismatcher (alla körtider): För att dra nytta av den inbyggda exekveringsmotorns acceleration, se till att båda sidor av en datumjämförelse matchar i datatyp. I stället för att till exempel jämföra kolumnen DATETIME med en strängliteral, konverterar du den explicit enligt följande:

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

Andra överväganden och begränsningar

• Decimal till Float kastningsmismatch (Runtime 1.3; löst i Runtime 2.0): När man kastar från DECIMAL till FLOATbevarar Spark precisionen genom att konvertera till en sträng och tolka den. På Runtime 1.3 utför NEE (via Velox) en direkt casting från den interna int128_t representationen, vilket kan resultera i avrundningsavvikelser.

• Tidszonkonfigurationsfel (Runtime 1.3; löst i Runtime 2.0): På Runtime 1.3 leder inställning av en okänd tidszon i Spark till att jobbet misslyckas under NEE, medan Spark JVM hanterar det smidigt. Till exempel:

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

• Inkonsekvent avrundningsbeteende (Runtime 1.3; löst i Runtime 2.0): På Runtime 1.3 beter sig funktionen round() annorlunda i NEE på grund av beroende av std::round, vilket inte replikerar Sparks avrundningslogik. Denna skillnad kan leda till numeriska inkonsekvenser i avrundningsresultaten.

• Saknad dubbelknappskontroll i map() funktionen (Runtime 1.3; löst i Runtime 2.0): När spark.sql.mapKeyDedupPolicy är satt till EXCEPTION, ger Spark ett felmeddelande för dubblettnycklar. På Runtime 1.3 hoppar NEE över denna kontroll och tillåter att frågan lyckas felaktigt. På Runtime 2.0 höjs DUPLICATED_MAP_KEY NEE konsekvent med JVM Spark.
  Exempel:

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

• Ordningsvarians i collect_list() med sortering (Runtime 1.3; löst i Runtime 2.0): När och används DISTRIBUTE BY bevarar SORT BYSpark elementordningen i collect_list(). På Runtime 1.3 kan NEE returnera värden i en annan ordning på grund av blandningsskillnader, vilket kan resultera i felaktiga förväntningar på ordningskänslig logik.

• Intermediär typmismatch för collect_list() / collect_set() (Runtime 1.3; löst i Runtime 2.0): På Runtime 1.3 använder BINARY Spark som mellantyp för dessa aggregeringar, medan NEE använder ARRAY. Det här matchningsfelet kan leda till kompatibilitetsproblem vid frågeplanering eller körning.

• Hanterade privata endpoints som krävs för lagringsåtkomst (alla körtider): När Native Execution Engine (NEE) är aktiverad, och om spark-jobb försöker komma åt ett lagringskonto via en hanterad privat endpoint, måste du konfigurera separata hanterade privata endpoints för både Blob (blob.core.windows.net) och DFS / File System (dfs.core.windows.net), även om de pekar på samma lagringskonto. Du kan inte återanvända en enda endpoint för båda. Denna begränsning kan kräva ytterligare nätverkskonfiguration när man aktiverar en inbyggd exekveringsmotor i en arbetsyta som har hanterade privata endpoints till lagringskonton.

Relaterat innehåll

• Översikt över Delta Lake in Fabric
• Python-UDF:er, Scala-UDF:er och komplexa datatyper i den inbyggda körningsmotorn
• Effektiv nedskalning och fjärrhanterare för shuffle
• Apache Spark Runtimes på plattformen
• Vad innebär autotuning av Apache Spark-konfigurationer i Fabric?