Systeemeigen uitvoeringsengine voor Fabric Spark
De systeemeigen uitvoeringsengine is een baanbrekende verbetering voor uitvoeringen van Apache Spark-taken in Microsoft Fabric. Deze vectorized engine optimaliseert de prestaties en efficiëntie van uw Spark-query's door ze rechtstreeks op uw Lakehouse-infrastructuur uit te voeren. De naadloze integratie van de engine betekent dat er geen codewijzigingen nodig zijn en dat de vergrendeling van de leverancier wordt vermeden. Het ondersteunt Apache Spark-API's en is compatibel met Runtime 1.3 (Apache Spark 3.5) en werkt met zowel Parquet- als Delta-indelingen. Ongeacht de locatie van uw gegevens in OneLake of als u toegang hebt tot gegevens via snelkoppelingen, maximaliseert de systeemeigen uitvoeringsengine de efficiëntie en prestaties.
De systeemeigen uitvoeringsengine verhoogt de queryprestaties aanzienlijk en minimaliseert de operationele kosten. Het biedt een opmerkelijke snelheidsverbetering, waardoor de prestaties maximaal vier keer sneller zijn in vergelijking met traditionele OSS-spark (opensource-software), zoals gevalideerd door de TPC-DS benchmark van 1 TB. De engine is geschikt voor het beheren van een breed scala aan scenario's voor gegevensverwerking, variërend van routinegegevensopname, batchtaken en ETL-taken (extraheren, transformeren, laden) tot complexe analyse van gegevenswetenschap en responsieve interactieve query's. Gebruikers profiteren van versnelde verwerkingstijden, verhoogde doorvoer en geoptimaliseerd resourcegebruik.
De systeemeigen uitvoeringsengine is gebaseerd op twee belangrijke OSS-onderdelen: Velox, een C++ databaseversnellingsbibliotheek die is geïntroduceerd door Meta en Apache Gluten (incubating), een middelste laag die verantwoordelijk is voor het offloaden van op JVM gebaseerde SQL-engines voor de uitvoering van systeemeigen engines die door Intel zijn geïntroduceerd.
Notitie
De systeemeigen uitvoeringsengine is momenteel beschikbaar als openbare preview. Zie de huidige beperkingen voor meer informatie. We raden u aan om de systeemeigen uitvoeringsengine zonder extra kosten in te schakelen voor uw workloads. U profiteert van snellere uitvoering van taken zonder meer te betalen, u betaalt minder voor hetzelfde werk.
Wanneer moet u de systeemeigen uitvoeringsengine gebruiken
De systeemeigen uitvoeringsengine biedt een oplossing voor het uitvoeren van query's op grootschalige gegevenssets; het optimaliseert de prestaties door gebruik te maken van de systeemeigen mogelijkheden van onderliggende gegevensbronnen en de overhead te minimaliseren die doorgaans samenhangt met gegevensverplaatsing en serialisatie in traditionele Spark-omgevingen. De engine ondersteunt verschillende operators en gegevenstypen, waaronder samengetelde hashaggregatie, broadcast geneste loop join (BNLJ) en nauwkeurige tijdstempelindelingen. Als u echter volledig wilt profiteren van de mogelijkheden van de engine, moet u rekening houden met de optimale gebruiksvoorbeelden:
- De engine is effectief bij het werken met gegevens in Parquet- en Delta-indelingen, die systeemeigen en efficiënt kunnen worden verwerkt.
- Query's die complexe transformaties en aggregaties omvatten, profiteren aanzienlijk van de mogelijkheden voor kolomverwerking en vectorisatie van de engine.
- Prestatieverbeteringen zijn het belangrijkst in scenario's waarin de query's het terugvalmechanisme niet activeren door niet-ondersteunde functies of expressies te voorkomen.
- De engine is zeer geschikt voor query's die rekenintensief zijn, in plaats van eenvoudig of I/O-gebonden.
Zie de Apache Gluten-documentatie voor informatie over de operators en functies die worden ondersteund door de systeemeigen uitvoeringsengine.
De systeemeigen uitvoeringsengine inschakelen
Voor het gebruik van de volledige mogelijkheden van de systeemeigen uitvoeringsengine tijdens de preview-fase zijn specifieke configuraties nodig. In de volgende procedures ziet u hoe u deze functie activeert voor notebooks, Spark-taakdefinities en volledige omgevingen.
Belangrijk
De systeemeigen uitvoeringsengine ondersteunt de nieuwste ga-runtimeversie, runtime 1.3 (Apache Spark 3.5, Delta Lake 3.2). Met de release van de systeemeigen uitvoeringsengine in Runtime 1.3 is de ondersteuning voor de vorige versie( Runtime 1.2 (Apache Spark 3.4, Delta Lake 2.4)) stopgezet. We raden alle klanten aan om een upgrade uit te voeren naar de nieuwste runtime 1.3. Als u de systeemeigen uitvoeringsengine op Runtime 1.2 gebruikt, wordt systeemeigen versnelling binnenkort uitgeschakeld.
Inschakelen op omgevingsniveau
Om een uniforme prestatieverbetering te garanderen, schakelt u de systeemeigen uitvoeringsengine in voor alle taken en notebooks die aan uw omgeving zijn gekoppeld:
Navigeer naar uw omgevingsinstellingen.
Ga naar Spark-rekenproces.
Ga naar het tabblad Versnelling .
Schakel het selectievakje in met het label Systeemeigen uitvoeringsengine inschakelen.
Sla de wijzigingen op en publiceer deze.
Wanneer deze optie is ingeschakeld op omgevingsniveau, nemen alle volgende taken en notebooks de instelling over. Deze overname zorgt ervoor dat nieuwe sessies of resources die in de omgeving zijn gemaakt, automatisch profiteren van de verbeterde uitvoeringsmogelijkheden.
Belangrijk
Voorheen werd de systeemeigen uitvoeringsengine ingeschakeld via Spark-instellingen binnen de omgevingsconfiguratie. Met onze nieuwste update (implementatie wordt uitgevoerd) hebben we dit vereenvoudigd door een wisselknop te introduceren op het tabblad Versnelling van de omgevingsinstellingen. Schakel de systeemeigen uitvoeringsengine opnieuw in met behulp van de nieuwe wisselknop: als u de systeemeigen uitvoeringsengine wilt blijven gebruiken, gaat u naar het tabblad Versnelling in de omgevingsinstellingen en schakelt u deze in via de wisselknop. De nieuwe wisselknopinstelling in de gebruikersinterface heeft nu voorrang op eventuele eerdere Configuraties van Spark-eigenschappen. Als u de systeemeigen uitvoeringsengine eerder hebt ingeschakeld via Spark-instellingen, wordt deze uitgeschakeld totdat deze opnieuw is ingeschakeld via de wisselknop voor de gebruikersinterface.
Inschakelen voor een notebook- of Spark-taakdefinitie
Als u de systeemeigen uitvoeringsengine voor één notebook of Spark-taakdefinitie wilt inschakelen, moet u de benodigde configuraties aan het begin van uw uitvoeringsscript opnemen:
%%configure
{
"conf": {
"spark.native.enabled": "true",
}
}
Voeg voor notebooks de vereiste configuratieopdrachten in de eerste cel in. Neem voor Spark-taakdefinities de configuraties op in de frontlijn van uw Spark-taakdefinitie. De systeemeigen uitvoeringsengine is geïntegreerd met livepools, dus zodra u de functie inschakelt, wordt deze onmiddellijk van kracht zonder dat u een nieuwe sessie hoeft te starten.
Belangrijk
De configuratie van de systeemeigen uitvoeringsengine moet worden uitgevoerd voordat de Spark-sessie wordt gestart. Nadat de Spark-sessie is gestart, wordt de spark.shuffle.manager instelling onveranderbaar en kan deze niet meer worden gewijzigd. Zorg ervoor dat deze configuraties zijn ingesteld in het %%configure blok in notebooks of in de Spark-sessiebouwer voor Spark-taakdefinities.
Besturingselement op queryniveau
De mechanismen voor het inschakelen van de systeemeigen uitvoeringsengine op tenant-, werkruimte- en omgevingsniveaus, naadloos geïntegreerd met de gebruikersinterface, zijn in actieve ontwikkeling. In de tussentijd kunt u de systeemeigen uitvoeringsengine uitschakelen voor specifieke query's, met name als deze operators omvatten die momenteel niet worden ondersteund (zie beperkingen). Als u dit wilt uitschakelen, stelt u de Spark-configuratie spark.native.enabled in op false voor de specifieke cel met uw query.
%%sql
SET spark.native.enabled=FALSE;
Nadat u de query hebt uitgevoerd waarin de systeemeigen uitvoeringsengine is uitgeschakeld, moet u deze opnieuw inschakelen voor volgende cellen door spark.native.enabled in te stellen op true. Deze stap is nodig omdat Spark codecellen opeenvolgend uitvoert.
%%sql
SET spark.native.enabled=TRUE;
Bewerkingen identificeren die door de engine worden uitgevoerd
Er zijn verschillende methoden om te bepalen of een operator in uw Apache Spark-taak is verwerkt met behulp van de systeemeigen uitvoeringsengine.
Spark-gebruikersinterface en Spark-geschiedenisserver
Open de Spark-gebruikersinterface of spark-geschiedenisserver om de query te vinden die u moet inspecteren. Als u toegang wilt krijgen tot de Spark-webgebruikersinterface, gaat u naar uw Spark-taakdefinitie en voert u deze uit. Selecteer op het tabblad Uitvoeringen de ... naast de applicatienaam en selecteer Open Spark-webgebruikersinterface. U hebt ook toegang tot de Spark-gebruikersinterface via het tabblad Bewaken in de werkruimte. Selecteer het notebook of de pijplijn. Op de bewakingspagina is er een directe koppeling naar de Spark-gebruikersinterface voor actieve taken.
Zoek in het queryplan dat wordt weergegeven in de Spark UI-interface naar knooppuntnamen die eindigen op het achtervoegsel Transformer, *NativeFileScan of VeloxColumnarToRowExec. Het achtervoegsel geeft aan dat de systeemeigen uitvoeringsengine de bewerking heeft uitgevoerd. Knooppunten kunnen bijvoorbeeld worden gelabeld als RollUpHashAggregateTransformer, ProjectExecTransformer, BroadcastHashJoinExecTransformer, ShuffledHashJoinExecTransformer of BroadcastNestedLoopJoinExecTransformer.
Uitleg van DataFrame
U kunt de df.explain() opdracht ook uitvoeren in uw notebook om het uitvoeringsplan weer te geven. Zoek in de uitvoer naar dezelfde Transformer, *NativeFileScan, of VeloxColumnarToRowExec achtervoegsels. Deze methode biedt een snelle manier om te controleren of specifieke bewerkingen worden verwerkt door de systeemeigen uitvoeringsengine.
Terugvalmechanisme
In sommige gevallen kan de systeemeigen uitvoeringsengine mogelijk geen query uitvoeren vanwege redenen zoals niet-ondersteunde functies. In deze gevallen valt de bewerking terug op de traditionele Spark-engine. Dit automatische terugvalmechanisme zorgt ervoor dat uw werkstroom niet wordt onderbroken.
Query's en DataFrames bewaken die door de engine worden uitgevoerd
Als u beter wilt weten hoe de engine voor systeemeigen uitvoering wordt toegepast op SQL-query's en DataFrame-bewerkingen en inzoomt op de fase- en operatorniveaus, kunt u verwijzen naar de Spark-gebruikersinterface en Spark History Server voor gedetailleerdere informatie over de uitvoering van de systeemeigen engine.
Tabblad Systeemeigen uitvoeringsengine
U kunt naar het nieuwe tabblad Gluten SQL/DataFrame navigeren om de informatie over de glutenbuild weer te geven en details over de uitvoering van query's weer te geven. De tabel Query's biedt inzicht in het aantal knooppunten dat wordt uitgevoerd op de systeemeigen engine en de knooppunten die voor elke query terugvallen op de JVM.
Queryuitvoeringsgrafiek
U kunt ook de querybeschrijving selecteren voor de visualisatie van het Apache Spark-queryuitvoeringsplan. De uitvoeringsgrafiek biedt systeemeigen uitvoeringsdetails in fasen en hun respectieve bewerkingen. Achtergrondkleuren onderscheiden de uitvoeringsengines: groen vertegenwoordigt de systeemeigen uitvoeringsengine, terwijl lichtblauw aangeeft dat de bewerking wordt uitgevoerd op de standaard-JVM-engine.
Beperkingen
Hoewel de systeemeigen uitvoeringsengine de prestaties voor Apache Spark-taken verbetert, moet u rekening houden met de huidige beperkingen.
- Sommige Delta-specifieke bewerkingen worden niet ondersteund (terwijl we er actief aan werken), waaronder samenvoegbewerkingen, controlepuntscans en verwijderingsvectoren.
- Bepaalde Spark-functies en -expressies zijn niet compatibel met de systeemeigen uitvoeringsengine, zoals door de gebruiker gedefinieerde functies (UDF's) en de
array_containsfunctie, evenals spark-gestructureerde streaming. Het gebruik van deze incompatibele bewerkingen of functies als onderdeel van een geïmporteerde bibliotheek veroorzaakt ook een terugval naar de Spark-engine. - Scans van opslagoplossingen die gebruikmaken van privé-eindpunten worden nog niet ondersteund, hoewel we daar actief aan werken.
- De engine biedt geen ondersteuning voor de ANSI-modus, dus zoekt deze en zodra de ANSI-modus is ingeschakeld, valt deze automatisch terug op vanille Spark.
Wanneer u datumfilters gebruikt in query's, is het essentieel om ervoor te zorgen dat de gegevenstypen aan beide zijden van de vergelijking overeenkomen om prestatieproblemen te voorkomen. Niet-overeenkomende gegevenstypen brengen mogelijk geen boost voor query-uitvoering en vereisen mogelijk expliciete cast-conversie. Zorg er altijd voor dat de gegevenstypen van de linkerkant (LHS) en rechterkant (RHS) van een vergelijking identiek zijn, omdat verschillende typen niet automatisch worden omgezet. Als een type niet overeenkomt onvermijdelijk is, gebruikt u expliciete cast-conversie om overeen te komen met de gegevenstypen, zoals CAST(order_date AS DATE) = '2024-05-20'. Query's met onverenigbare gegevenstypen die casting vereisen, worden niet versneld door de Native Execution Engine, dus het waarborgen van typeconsistentie is cruciaal voor het behouden van prestaties. In plaats van order_date = '2024-05-20' waar order_date is DATETIME en de tekenreeks DATEbijvoorbeeld, wordt expliciet gecast order_date om consistente gegevenstypen te DATE garanderen en de prestaties te verbeteren.