Dela via

Intern körningsmotor för Infrastrukturdatateknik

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. Det stöder Apache Spark-API:er och är kompatibelt med Runtime 1.3 (Apache Spark 3.5) och fungerar med både Parquet- och Delta-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. Det ger en anmärkningsvärd hastighetsförbättring och ger upp till fyra gånger snabbare prestanda jämfört med traditionell OSS (programvara med öppen källkod) Spark, vilket verifieras av TPC-DS 1 TB-benchmark. 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.

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.

Viktigt!

Den interna körningsmotorn stöder den senaste GA-körningsversionen, som är Runtime 1.3 (Apache Spark 3.5, Delta Lake 3.2). Med lanseringen av den inbyggda körningsmotorn i Runtime 1.3 upphör stödet för den tidigare versionen, Runtime 1.2 (Apache Spark 3.4, Delta Lake 2.4). Vi rekommenderar att alla kunder uppgraderar till den senaste Runtime 1.3. Om du använder den nativa körningsmotorn på Runtime 1.2 kommer den nativa accelerationen att inaktiveras.

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.

    Skärmbild som visar hur du aktiverar den interna körningsmotorn i miljöobjektet.

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.

Viktigt!

Tidigare aktiverades den inbyggda körningsmotorn via Spark-inställningar i miljökonfigurationen. Den inbyggda körningsmotorn kan nu aktiveras enklare med hjälp av en växlingsknapp på fliken Acceleration i miljöinställningarna. Om du vill fortsätta använda den går du till fliken Acceleration och aktiverar växlingsknappen. Du kan också aktivera det via Spark-egenskaper om du vill.

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;

Skärmbild som visar hur du inaktiverar den infödda exekveringsmotorn i en anteckningsbok.

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;

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. Om du vill komma åt Spark-webbgränssnittet går du till Spark-jobbdefinitionen och kör det. 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.

Skärmbild som visar hur du navigerar till Spark-webbgränssnittet.

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.

Skärmbild som visar hur du kontrollerar DAG-visualisering som slutar med suffixet Transformer.

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.

Skärmbild som visar hur du kontrollerar den fysiska planen för din fråga och ser att frågan kördes av den inbyggda körmotorn.

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.

Skärmbild som visar återställningsmekanismen.

Skärmbild som visar hur du kontrollerar loggar som är associerade med återställningsmekanismen.

Ö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.

Skärmbild som visar fliken inbyggd exekveringsmotor.

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.

Skärmbild som visar diagram över sökfrågekörning.

Begränsningar

Även om den interna körningsmotorn (NEE) i Microsoft Fabric avsevärt ökar prestandan för Apache Spark-jobb, har den för närvarande följande begränsningar:

Befintliga begränsningar

  • Inkompatibla Spark-funktioner: Den native motorn stöder för närvarande inte användardefinierade funktioner (UDF), array_contains-funktionen eller strukturerad strömning. Om dessa funktioner eller funktioner som inte stöds används antingen direkt eller via importerade bibliotek återgår Spark till standardmotorn.

  • Filformat som inte stöds: Frågor mot JSON, XML, och CSV format accelereras inte av den inbyggda körmotorn. Som standard återgår dessa till den vanliga Spark JVM-motorn för körning.

  • ANSI-läge stöds inte: Den interna körningsmotorn stöder inte ANSI SQL-läge. Om det är aktiverat återgår körningen till standard Spark-motorn.

  • Typfel i datumfilter: För att dra nytta av den inbyggda exekveringsmotorens acceleration, se till att båda sidor av en datumjämförelse har samma 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

  • Skillnad vid typomvandling från Decimal till Flyttal: Vid omvandling från DECIMAL till FLOAT bevarar Spark precisionen genom att konvertera till en sträng och analysera den. NEE (via Velox) utför en direkt gjutning från den interna int128_t representationen, vilket kan resultera i avrundningsavvikelser.

  • Tidszonskonfigurationsfel : Om du anger en okänd tidszon i Spark misslyckas jobbet under NEE, medan Spark JVM hanterar det korrekt. Till exempel:

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

  • Inkonsekvent avrundningsbeteende: Funktionen round() fungerar annorlunda i NEE på std::roundgrund av beroendet av , som inte replikerar Sparks avrundningslogik. Detta kan leda till numeriska inkonsekvenser i avrundningsresultat.

  • Saknad kontroll av duplicerade nycklar i map()-funktionen: När spark.sql.mapKeyDedupPolicy är inställt på UNDANTAG kastar Spark ett fel för dubblettnycklar. NEE hoppar för närvarande över den här kontrollen och tillåter att sökfrågan lyckas på ett felaktigt sätt.
    Exempel:

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

  • Orderavvikelse i collect_list() med sortering: När du använder DISTRIBUTE BY och SORT BYbevarar Spark elementordningen i collect_list(). NEE kan returnera värden i en annan ordning på grund av blandningsskillnader, vilket kan resultera i felmatchade förväntningar på ordningskänslig logik.

  • Matchningsfel av mellanliggande typ för collect_list() / collect_set(): Spark använder BINARY som mellanliggande typ för dessa aggregeringar, medan NEE använder .ARRAY Det här matchningsfelet kan leda till kompatibilitetsproblem vid frågeplanering eller körning.

Titta på den här videon om Fabric espresso och den ursprungliga körningsmotorn

Relaterat innehåll

  • Last updated on