Native Ausführungsengine für Fabric Spark
Die native Ausführungsengine ist eine bahnbrechende Erweiterung für Apache Spark-Auftragsausführungen in Microsoft Fabric. Diese vektorisierte Engine optimiert die Leistung und Effizienz Ihrer Spark-Abfragen, indem sie direkt in Ihrer Lakehouse-Infrastruktur ausgeführt werden. Die nahtlose Integration der Engine bedeutet, dass keine Codeänderungen erforderlich sind und die Anbietereinsperrung vermieden wird. Es unterstützt Apache Spark-APIs und ist mit Runtime 1.3 (Apache Spark 3.5) kompatibel und funktioniert sowohl mit Parquet- als auch mit Delta-Formaten. Unabhängig vom Standort Ihrer Daten in OneLake oder wenn Sie über Verknüpfungen auf Daten zugreifen, maximiert die native Ausführungsengine Effizienz und Leistung.
Die native Ausführungsengine erhöht die Abfrageleistung erheblich und minimiert gleichzeitig die Betriebskosten. Es bietet eine bemerkenswerte Geschwindigkeitsverbesserung und erreicht eine bis zu vierfach schnellere Leistung im Vergleich zu herkömmlichen OSS (Open Source Software) Spark, die durch den TPC-DS 1-TB-Benchmark validiert wird. Die Engine verfügt über die Verwaltung einer Vielzahl von Datenverarbeitungsszenarien, von Routinedatenaufnahme, Batchaufträgen und ETL-Aufgaben (Extrahieren, Transformieren, Laden) bis hin zu komplexen Datenanalysen und reaktionsfähigen interaktiven Abfragen. Benutzer profitieren von beschleunigten Verarbeitungszeiten, erhöhter Durchsatz und optimierter Ressourcenverwendung.
Das native Execution Engine basiert auf zwei wichtigen OSS-Komponenten: Velox, einer von Meta eingeführten C++-Datenbankbeschleunigungsbibliothek und Apache Gluten (Inkubating), einer mittleren Ebene, die für das Entladen der Ausführung von JVM-basierten SQL-Engines an systemeigene Engines verantwortlich ist, die von Intel eingeführt wurden.
Hinweis
Die native Ausführungsengine ist zurzeit als Public Preview verfügbar. Weitere Informationen finden Sie unter den aktuellen Einschränkungen. Wir empfehlen Ihnen, die native Ausführungsengine für Ihre Workloads ohne zusätzliche Kosten zu aktivieren. So profitieren Sie von einer schnelleren Auftragsausführung, ohne mehr zu bezahlen – effektiv zahlen Sie weniger für dieselbe Arbeit.
Wann die native Ausführungsengine verwendet werden soll
Die native Ausführungsengine bietet eine Lösung zum Ausführen von Abfragen auf großen Datasets; Es optimiert die Leistung, indem die nativen Funktionen zugrunde liegender Datenquellen verwendet werden, und der Mehraufwand, der normalerweise mit der Datenverschiebung und Serialisierung in herkömmlichen Spark-Umgebungen verbunden ist, minimiert wird. Die Engine unterstützt verschiedene Operatoren und Datentypen, einschließlich Rolluphashaggregat, übertragener Join geschachtelter Schleifen (BNLJ) und präzise Zeitstempelformate. Um jedoch vollständig von den Funktionen der Engine zu profitieren, sollten Sie die optimalen Anwendungsfälle berücksichtigen:
- Die Engine ist effektiv beim Arbeiten mit Daten in Parquet- und Delta-Formaten, die es nativ und effizient verarbeiten kann.
- Abfragen, die komplexe Transformationen und Aggregationen umfassen, profitieren erheblich von den Spaltenverarbeitungs- und Vektorisierungsfunktionen der Engine.
- Leistungsverbesserungen sind in Szenarien besonders wichtig, in denen die Abfragen den Fallbackmechanismus nicht auslösen, indem nicht unterstützte Features oder Ausdrücke vermieden werden.
- Die Engine eignet sich gut für Abfragen, die rechenintensiv sind, anstatt einfach oder E/A-gebunden.
Informationen zu den Operatoren und Funktionen, die von der nativen Ausführungsengine unterstützt werden, finden Sie in der Apache Gluten-Dokumentation.
Aktivieren der nativen Ausführungsengine
Um die vollständigen Funktionen der nativen Ausführungsengine während der Vorschauphase zu nutzen, sind bestimmte Konfigurationen erforderlich. Die folgenden Verfahren zeigen, wie Sie dieses Feature für Notebooks, Spark-Auftragsdefinitionen und ganze Umgebungen aktivieren.
Wichtig
Das Native Execution Engine unterstützt die neueste allgemein verfügbare Runtime-Version Runtime 1.3 (Apache Spark 3.5, Delta Lake 3.2). Mit der Veröffentlichung des Native Execution Engines in Runtime 1.3 wurde die Unterstützung für die vorherige Version –Runtime 1.2 (Apache Spark 3.4, Delta Lake 2.4) – eingestellt. Wir empfehlen allen Kunden, ein Upgrade auf die neueste Runtime 1.3 durchzuführen. Beachten Sie, dass bei Verwendung des Native Execution Engine auf Runtime 1.2 die systemeigene Beschleunigung bald deaktiviert wird.
Aktivieren auf Umgebungsebene
Um eine einheitliche Leistungsverbesserung sicherzustellen, aktivieren Sie die native Ausführungsengine für alle Aufträge und Notebooks, die Ihrer Umgebung zugeordnet sind:
Navigieren Sie zu den Umgebungseinstellungen
Gehen Sie zu Spark-Compute.
Wechseln Sie zur Registerkarte Beschleunigung.
Aktivieren Sie die Option Native Ausführungsengine aktivieren.
Speichern und veröffentlichen Sie die Änderungen.
Wenn sie auf Umgebungsebene aktiviert sind, erben alle nachfolgenden Aufträge und Notebooks die Einstellung. Diese Vererbung stellt sicher, dass alle in der Umgebung erstellten neuen Sitzungen oder Ressourcen automatisch von den erweiterten Ausführungsfunktionen profitieren.
Wichtig
Zuvor wurde das Native Execution Engine über Spark-Einstellungen in der Umgebungskonfiguration aktiviert. Mit unserem neuesten Update (Rollout im Gange) haben wir dies vereinfacht, indem wir auf der Registerkarte „Beschleunigung“ der Umgebungseinstellungen eine Umschaltfläche einführen. Aktivieren Sie das Native Execution Engine erneut, indem Sie den neuen Umschalter verwenden. Um weiterhin das Native Execution Engine zu verwenden, wechseln Sie in den Umgebungseinstellungen zur Registerkarte „Beschleunigung“, und aktivieren Sie es über die Umschaltfläche. Die neue Umschalteinstellung in der Benutzeroberfläche hat jetzt Vorrang vor allen vorherigen Spark-Eigenschaftskonfigurationen. Wenn Sie das Native Execution Engine zuvor über Spark-Einstellungen aktiviert haben, wird es bis zur erneuten Aktivierung über die Benutzeroberflächen-Umschaltfläche deaktiviert.
Im Einklang mit der Richtlinie zum Sperren von Azure-Bereitstellungen von Microsoft während der Feiertage „Thanksgiving“ und „Black Friday“ haben wir den Rollout für die Region USA, Norden-Mitte bis zum 6. Dezember und die Region USA, Osten bis zum 9. Dezember neu geplant. Wir danken Ihnen für Ihr Verständnis und Ihre Geduld in dieser arbeitsreichen Zeit.
Für ein Notebook oder eine Spark-Auftragsdefinition aktivieren
Um die native Ausführungsengine für ein einzelnes Notebookz oder eine Spark-Auftragsdefinition zu aktivieren, müssen Sie die erforderlichen Konfigurationen am Anfang des Ausführungsskripts integrieren:
%%configure
{
"conf": {
"spark.native.enabled": "true",
}
}
Fügen Sie für Notebooks die erforderlichen Konfigurationsbefehle in die erste Zelle ein. Fügen Sie für Spark-Auftragsdefinitionen die Konfigurationen in die Frontlinie Ihrer Spark-Auftragsdefinition ein. Die native Ausführungsengine ist in Livepools integriert. Sobald Sie das Feature aktiviert haben, wird es sofort wirksam, ohne dass Sie eine neue Sitzung initiieren müssen.
Wichtig
Die Konfiguration der nativen Ausführungsengine muss vor der Initiierung der Spark-Sitzung erfolgen. Nachdem die Spark-Sitzung gestartet wurde, wird die spark.shuffle.manager-Einstellung unveränderlich und kann nicht geändert werden. Stellen Sie sicher, dass diese Konfigurationen innerhalb des %%configure-Blocks in Notebooks oder im Spark-Sitzungs-Generator für Spark-Auftragsdefinitionen festgelegt sind.
Steuerelement auf der Abfrageebene
Die Mechanismen zur Aktivierung der nativen Ausführungsengine auf Mandanten-, Arbeitsbereichs- und Umgebungsebenen, die nahtlos in die Benutzeroberfläche integriert sind, befinden sich in der aktiven Entwicklung. Du kannst in der Zwischenzeit die native Ausführungsengine für bestimmte Abfragen deaktivieren, insbesondere, wenn sie Operatoren einbeziehen, die derzeit nicht unterstützt werden (siehe Einschränkungen). Legen Sie zum Deaktivieren die Spark-Konfiguration spark.native.enabled für die bestimmte Zelle, die Ihre Abfrage enthält, auf „false“ fest.
%%sql
SET spark.native.enabled=FALSE;
Nachdem Sie die Abfrage ausgeführt haben, in der die native Ausführungsengine deaktiviert ist, müssen Sie sie für nachfolgende Zellen erneut aktivieren, indem Sie spark.native.enabled auf „true“ festlegen. Dieser Schritt ist erforderlich, da Spark Codezellen sequenziell ausführt.
%%sql
SET spark.native.enabled=TRUE;
Identifizieren von Vorgängen, die von der Engine ausgeführt werden
Es gibt mehrere Methoden, um zu ermitteln, ob ein Operator in Ihrem Apache Spark-Auftrag mithilfe der nativen Ausführungsengine verarbeitet wurde.
Spark-UI- und Spark-Verlaufsserver
Greifen Sie auf die Spark-UI oder den Spark-Verlaufsserver zu, um die Abfrage zu finden, die Sie überprüfen müssen. Suchen Sie im Abfrageplan, der innerhalb der Schnittstelle angezeigt wird, nach knotennamen, die mit dem Suffix Transformer, NativeFileScan oder VeloxColumnarToRowExec enden. Das Suffix gibt an, dass die native Ausführungsengine den Vorgang ausgeführt hat. Beispielsweise können Knoten als RollUpHashAggregateTransformer, ProjectExecTransformer, BroadcastHashJoinExecTransformer, ShuffledHashJoinExecTransformer oder BroadcastNestedLoopJoinExecTransformer bezeichnet werden.
Erläutern von DataFrame
Alternativ können Sie den df.explain()-Befehl in Ihrem Notebook ausführen, um den Ausführungsplan anzuzeigen. Suchen Sie in der Ausgabe nach den gleichen Suffixen Transformer, NativeFileScan oder VeloxColumnarToRowExec. Diese Methode bietet eine schnelle Möglichkeit, zu überprüfen, ob bestimmte Vorgänge von der nativen Ausführungsengine behandelt werden.
Fallbackmechanismus
In einigen Fällen kann die native Ausführungsengine aufgrund von Gründen wie nicht unterstützten Features möglicherweise keine Abfrage ausführen. In diesen Fällen fällt der Vorgang auf die herkömmliche Spark-Engine zurück. Mit diesem automatischen Fallbackmechanismus wird sichergestellt, dass der Workflow nicht unterbrochen wird.
Überwachen von Abfragen und DataFrames, die von der Engine ausgeführt werden
Um besser zu verstehen, wie die native Ausführungsengine für SQL-Abfragen und DataFrame-Vorgänge angewendet wird, und um einen Drilldown zu den Stage- und Operatorebenen durchzuführen, können Sie den Spark UI- und Spark History-Server verwenden, um ausführlichere Informationen zur nativen Ausführungsengine zu erhalten.
Registerkarte Native Ausführungsengine
Sie können zur neuen Registerkarte „Gluten SQL / DataFrame“ navigieren, um die Gluten-Buildinformationen und Ausführungsdetails zur Abfrage anzuzeigen. Die Tabelle „Abfragen“ bietet Einblicke in die Anzahl der Knoten, die in der nativen Engine ausgeführt werden, und diejenigen, die für jede Abfrage auf die JVM zurückfallen.
Graph zur Abfrageausführung
Sie können auch auf die Beschreibung der Abfrage klicken, um den Apache Spark-Ausführungsplan der Abfrage anzuzeigen. Der Graph bietet Details zur nativen Ausführung über Phasen und deren jeweilige Vorgänge hinweg. Die Hintergrundfarben unterscheiden die Engines: Grün stellt die native Ausführungsengine dar, während hellblau angibt, dass der Vorgang mit der Standard-JVM-Engine ausgeführt wird.
Begrenzungen
Während die native Ausführungsengine die Leistung für Apache Spark-Aufträge verbessert, beachten Sie die aktuellen Einschränkungen.
- Einige Delta-spezifische Vorgänge werden (noch) nicht unterstützt (weil wir aktiv daran arbeiten), einschließlich Zusammenführungsvorgänge, Prüfpunktüberprüfungen und Löschvektoren.
- Bestimmte Spark-Features und Ausdrücke sind nicht mit der nativen Ausführungsenginel kompatibel, z. B. benutzerdefinierte Funktionen (UDFs) und die
array_containsFunktion sowie strukturierter Spark-Stream. Die Verwendung dieser inkompatiblen Vorgänge oder Funktionen als Teil einer importierten Bibliothek führt auch zu Fallbacks für das Spark-Modul. - Scans von Speicherlösungen, die private Endpunkte nutzen, werden (noch) nicht unterstützt (weil wir aktiv daran arbeiten).
- Die Engine unterstützt den ANSI-Modus nicht, sodass er durchsucht und sobald der ANSI-Modus aktiviert ist, fällt es automatisch auf Vanille Spark zurück.
Bei der Verwendung von Datumsfiltern in Abfragen ist es wichtig, sicherzustellen, dass die Datentypen auf beiden Seiten des Vergleichs übereinstimmen, um Leistungsprobleme zu vermeiden. Nicht übereinstimmende Datentypen bringen möglicherweise keine Herauftrieb der Abfrageausführung und erfordern möglicherweise eine explizite Umwandlung. Stellen Sie immer sicher, dass die Datentypen der linken Seite (LHS) und der rechten Seite (RHS) eines Vergleichs identisch sind, da nicht übereinstimmende Typen nicht immer automatisch umgewandelt werden. Wenn ein Typkonflikt unvermeidbar ist, verwenden Sie explizite Umwandlungen, um den Datentypen zu entsprechen, z. B. CAST(order_date AS DATE) = '2024-05-20'. Abfragen mit nicht übereinstimmenden Datentypen, die eine Umwandlung erfordern, werden nicht von der nativen Ausführungsengine beschleunigt, sodass die Typkonsistenz für Standard nachhaltige Leistung von entscheidender Bedeutung ist. Anstatt z. B. order_date = '2024-05-20', wobei order_date DATETIME ist und die Zeichenfolge DATE ist, wird order_date explizit in DATE umgewandelt, umkonsistente Datentypen sicherzustellen und die Leistung zu verbessern.