Freigeben über

Parallelitätsgrenzwerte und Warteschlangen in Apache Spark für Microsoft Fabric

Gilt für:✅ Datentechnik und Data Science in Microsoft Fabric

Microsoft Fabric ermöglicht die Zuordnung von Compute-Einheiten über Kapazität. Dabei handelt es sich um dedizierte Ressourcen, die zu einem bestimmten Zeitpunkt zur Verwendung verfügbar sind. Kapazität definiert, ob es einer Ressource möglich ist, eine Aktivität auszuführen oder eine Ausgabe zu erzeugen. Verschiedene Elemente verbrauchen zu einem bestimmten Zeitpunkt unterschiedliche Kapazitäten. Microsoft Fabric stellt Kapazität über die Fabric-SKUs und Testversionen bereit. Weitere Informationen finden Sie unter Was bedeutet Kapazität?.

Wenn Benutzer*innen eine Microsoft Fabric-Kapazität in Azure erstellen, können sie eine Kapazitätsgröße basierend auf der Größe ihrer Analyseworkloads auswählen. In Apache Spark haben Benutzer*innen zwei virtuelle Apache Spark-Kerne für jede Kapazitätseinheit, die sie im Rahmen ihrer SKU reservieren.

Eine Kapazitätseinheit = zwei virtuelle Spark-Kerne

Nachdem die Kapazität erworben wurde, können Administrator*innen Arbeitsbereiche innerhalb der Kapazität in Microsoft Fabric erstellen. Die der Kapazität zugeordneten virtuellen Spark-Kerne werden für alle Apache Spark-basierten Elemente gemeinsam genutzt, z. B. Notebooks, Apache Spark-Auftragsdefinitionen und in diesen Arbeitsbereichen erstellte Lakehouses.

Parallelitätsdrosselung und Warteschlangen

Spark für Fabric erzwingt einen kernbasierten Einschränkungs- und Warteschlangenmechanismus, bei dem Benutzende Aufträge basierend auf den erworbenen Fabric-Kapazitäts-SKUs übermitteln dürfen. Der Warteschlangenmechanismus ist eine einfache FIFO-basierte Warteschlange, die nach verfügbaren Auftragsslots sucht und die Aufträge automatisch wiederholt, sobald die Kapazität verfügbar ist.

Wenn Benutzer Notizbuch- oder Lakehouse-Aufträge (z. B. Load to Table) übermitteln und die Kapazität aufgrund gleichzeitiger Aufträge mit allen Spark VCores maximal genutzt wird, wird die folgende Fehlermeldung angezeigt:

HTTP Response code 430: This Spark job can't be run because you have hit a Spark compute or API rate limit. To run this Spark job, cancel an active Spark job through the Monitoring hub, or choose a larger capacity SKU or try again later.

Wenn die Warteschlange aktiviert ist, werden Notizbuchaufträge, die aus Pipelines, Auftragsplaner und Spark-Auftragsdefinitionen ausgelöst werden, der Warteschlange hinzugefügt und automatisch erneut versucht, wenn die Kapazität verfügbar wird.

Hinweis

Der Ablauf der Warteschlange wird auf 24 Stunden ab der Übermittlungszeit des Auftrags festgelegt. Nach diesem Zeitraum werden Aufträge aus der Warteschlange entfernt und müssen manuell erneut übermittelt werden.

Fabric-Kapazitäten sind auch mit Platzenaktiviert, sodass Sie bis zu 3 verbrauchen können× die Anzahl der Spark VCores, die Sie gekauft haben. Dieser Schub trägt dazu bei, die Parallelität zu verbessern, indem mehr Aufträge parallel ausgeführt werden können.

Hinweis

Der Platzungsfaktor erhöht die Gesamtanzahl von Spark VCores für Parallelität und kann von einem einzelnen Auftraggenutzt werden, wenn der Spark-Pool mit einer höheren Kernanzahl konfiguriert ist.
Anders ausgedrückt bestimmt die Poolkonfiguration die maximalen Kerne, die ein Auftrag verwenden kann – nicht nur die Basis-SKU-Zuordnung.

Beispiel

Wenn Sie über eine F64-SKU mit 384 Max Spark VCores mit Burst-Faktorverfügen:

  • Sie können einen benutzerdefinierten oder Starterpool mit bis zu 384 Spark VCores konfigurieren.
  • Wenn ein Arbeitsbereichsadministrator einen solchen Pool erstellt, kann ein einzelner Spark-Auftrag (z. B. ein Notizbuch, eine Auftragsdefinition oder einen Lakehouse-Auftrag) alle 384 VCores verwenden.
  • Beispiel: Ein Pool mit Medium Knoten (jeweils 8 VCores) und 48 max. Knoten = 384 VCores.

Tipp

Um die Auftragsleistung zu maximieren, vergewissern Sie sich, dass Ihr Arbeitsbereichspool mit ausreichender Knotengröße und -anzahl konfiguriert ist.

SKU-Grenzwerte für Spark-Kapazität

Fabric-Kapazitäts-SKU Entsprechende Power BI-SKU Spark VCores Max. virtuelle Spark-Kerne mit Burst-Faktor Warteschlangenlimit
F2 - 4 20 4
F4 - 8 24 4
F8 - 16 48 8
F16 - 32 96 16
F32 - 64 192 32
F64 P1 128 384 64
F128 P2 256 768 128
F256 Seite 3 512 1536 256
F512 P4 1024 3072 512
F1024 - 2048 6144 1024
F2048 - 4096 12.288 2048
Testkapazität P1 128 128 Nicht verfügbar

Wichtig

Die Tabelle gilt nur für Spark-Aufträge, die auf Fabric Capacity ausgeführt werden. Wenn die Abrechnung mit Autoskalierung aktiviert ist, werden Spark-Aufträge getrennt von der Fabric-Kapazität ausgeführt, sodass Bursting oder Glätten vermieden werden. Die Gesamtanzahl virtueller Spark-Kerne ist doppelt so hoch wie die maximalen Kapazitätseinheiten, die in Einstellungen zur Autoskalierung festgelegt sind.

Beispielberechnung

  • Eine F64-SKU bietet 128 Spark VCores.
  • Mit einem Burst-Faktor von 3 unterstützt es bis zu 384 Spark VCores für die gleichzeitige Ausführung.
  • Wenn ein Pool mit den vollständigen 384 VCores konfiguriert ist, kann ein einzelner Auftrag alle verwenden, vorausgesetzt, keine anderen Aufträge verbrauchen Kapazität.
  • Beispiel: 3 Aufträge mit 128 VCores können jeweils gleichzeitig oder 1 Auftrag mit 384 VCores ausgeführt werden.

Hinweis

Die Aufträge haben einen Warteschlangenablaufzeitraum von 24 Stunden, nach dem sie abgebrochen werden und Benutzende sie erneut zur Auftragsausführung übermitteln müssen.

Die Spark für Fabric-Drosselung weist keine auftragsbasierten Grenzwerte auf, die erzwungen und willkürlich sind, und die Drosselung basiert nur auf der Anzahl der Kerne, die für die erworbene Fabric-Kapazitäts-SKU zulässig sind. Die Zulassung von Arbeitsplätzen ist standardmäßig eine optimistische Zulassungskontrolle, bei der Arbeitsplätze basierend auf ihren Mindestkernanforderungen zugelassen werden. Weitere Informationen: Job Admission and Management.

Wenn die Standardpooloption (Startpool) für den Arbeitsbereich ausgewählt ist, werden in der folgenden Tabelle die maximalen Grenzwerte für den Parallelitätsauftrag aufgelistet.

Weitere Informationen: Konfigurieren von Starterpools.

Administratoren können ihre Apache Spark-Pools so konfigurieren, dass die maximal verfügbaren Spark-VCores in der Kapazität genutzt werden, einschließlich des Burstfaktors von 3×, den Fabric für die gleichzeitige Ausführung bietet. Ein Arbeitsbereichsadministrator mit einer F64 Fabric-Kapazität kann z. B. seinen Spark-Pool (Starterpool oder benutzerdefinierter Pool) so konfigurieren, dass er bis zu 384 Spark-VCores verwendet:

Festlegen der maximalen Knoten des Starterpools auf 48 (mit mittleren Knoten = jeweils 8 VCores) oder

Konfigurieren eines benutzerdefinierten Pools mit größeren Knoten (z. B. XXLarge = 64 VCores jeweils) mit einer entsprechenden Knotenanzahl, um die gewünschte Kapazität zu erreichen.

Mit dieser Konfiguration kann ein einzelner Spark-Auftrag die gesamte Burst-Kapazität nutzen, was ideal für die Verarbeitung großer Datenmengen ist, die auf Leistung setzen.

Neu: Job-Level-Bursting-Kontrolle über das Verwaltungsportal. Kapazitätsadministratoren haben jetzt die Kontrolle über das Aktivieren oder Deaktivieren von Job-Level-Bursting durch eine neue Einstellung im Verwaltungsportal.

Navigieren Sie zum Verwaltungsportal → Registerkarte "Kapazitätseinstellungen" → Registerkarte "Data Engineering/Science"

Verwenden Sie den neuen Schalter "Deaktivierung Job-Level Bursting", um zu verhindern, dass ein einzelner Spark-Auftrag die gesamte verfügbare Burst-Kapazität verbraucht.

Hinweis

Wenn das Bursting auf Auftragsebene deaktiviert ist, erzwingt die Spark-Engine, dass kein einzelner Auftrag die gesamte verfügbare Kapazität (einschließlich Burst-Kerne) nutzen kann. Dadurch wird sichergestellt, dass die Kapazität für gleichzeitige Aufträge verfügbar bleibt, um den Durchsatz und die Parallelität mehrerer Benutzer zu verbessern.

Dieses Feature ist besonders in Umgebungen mit mehreren Mandanten oder in Umgebungen mit hoher Parallelität nützlich, in denen Arbeitsauslastungen über mehrere Teams und Pipelines hinweg ausgeglichen werden müssen. Administratoren können diese Einstellung darauf abstimmen, ob die Kapazität für maximalen Auftragsdurchsatz (Bursting aktiviert) oder für höhere Parallelität und Fairness optimiert ist (Bursting deaktiviert).

Beispielszenarien mit aktiviertem Bursting (Standard): Ein großer Batch-Notizbuchauftrag kann alle 384 Spark VCores in einer F64-Kapazität nutzen, sofern keine anderen Aufträge ausgeführt werden.

Bursting deaktiviert: Ein Auftrag kann auf das Basis-Core-Limit (z.B. 128 Spark VCores für F64) begrenzt werden, um Raum für andere Aufträge zu schaffen, die gleichzeitig gestartet werden können.

Tipp

Für Teams mit unterschiedlichen Jobtypen (ETL, ML, Adhoc) kann das Deaktivieren des Burstens auf Jobebene dazu beitragen, Kapazitätsmonopolisierung zu verhindern und Verzögerungen in der Jobwarteschlange zu verringern.

Zugehöriger Inhalt