Dataproc Serverless für Spark-Autoscaling

Wenn Sie Ihre Spark-Arbeitslast senden, kann Dataproc Serverless for Spark Arbeitslastressourcen wie die Anzahl der Executors dynamisch skalieren, um Ihre Arbeitslast effizient auszuführen. Das serverlose Autoscaling in Dataproc ist das Standardverhalten. Mit der dynamischen Spark-Ressourcenzuweisung wird bestimmt, ob, wie und wann Ihre Arbeitslast skaliert werden soll.

Serverloses Dataproc-Autoscaling V2

Version 2 (V2) des serverlosen Autoscalings von Dataproc enthält Features und Verbesserungen der Standardversion 1 (V1), mit denen Sie Dataproc Serverless-Arbeitslasten verwalten, die Arbeitslastleistung verbessern und Kosten sparen können:

  • Asynchrones Herunterskalieren von Knoten: Autoscaling V2 ersetzt das synchrone Herunterskalieren von V1 durch das asynchrone Herunterskalieren. Mithilfe der asynchronen Herunterskalierung skaliert Dataproc Serverless Arbeitslastressourcen, ohne darauf warten zu müssen, dass alle Knoten die Shuffle-Migration abgeschlossen haben. Das bedeutet, dass Longtail-Knoten, die langsam herunterskalieren, das Hochskalieren nicht blockieren.
  • Intelligente Knotenauswahl für das Herunterskalieren: Autoscaling V2 ersetzt die zufällige Knotenauswahl von V1 durch einen intelligenten Algorithmus, der die besten Knoten für die zuerst Herunterskalierung ermittelt. Dieser Algorithmus berücksichtigt Faktoren wie die Shuffle-Datengröße des Knotens und die Leerlaufzeit.
  • Konfigurierbares Verhalten bei der ordnungsgemäßen Außerbetriebnahme von Spark und der Shuffle-Migration: Mit Autoscaling V2 können Sie Spark-Standardattribute verwenden, um die ordnungsgemäße Außerbetriebnahme von Spark und die Shuffle-Migration zu konfigurieren. Mit diesem Feature können Sie die Migrationskompatibilität mit Ihren benutzerdefinierten Spark-Attributen aufrechterhalten.

Serverlose Autoscaling-Features in Dataproc

Funktion Serverloses Dataproc-Autoscaling V1 Serverloses Dataproc-Autoscaling V2
Knoten-Herunterskalierung Synchron Asynchron
Knotenauswahl für Herunterskalierung Zufällig Intelligent
Spark-Außerbetriebnahme und Shuffle-Migration Nicht konfigurierbar Konfigurierbar

Attribute der dynamischen Zuordnung für Spark

In der folgenden Tabelle sind die Attribute für Spark Dynamic Allocation aufgeführt, die Sie beim Senden einer Batcharbeitslast zur Steuerung des Autoscalings festlegen können. Weitere Informationen finden Sie unter Spark-Attribute festlegen.

Attribut Beschreibung Standard
spark.dataproc.scaling.version Die Autoscaling-Version von Dataproc Serverless Spark. Geben Sie Version 1 oder 2 an (siehe Dataproc Serverless Autoscaling V2). 1
spark.dynamicAllocation.enabled Gibt an, ob die dynamische Ressourcenzuweisung verwendet wird, die die Anzahl der Executors je nach Arbeitslast hoch- und herunterskaliert. Wenn Sie den Wert auf false festlegen, wird das Autoscaling für die Arbeitslast deaktiviert. Standardeinstellung: true true
spark.dynamicAllocation.initialExecutors Die anfängliche Anzahl von Executors, die der Arbeitslast zugewiesen sind. Nachdem die Arbeitslast gestartet wurde, kann sich die Anzahl der aktiven Executors durch Autoscaling ändern. Der Mindestwert ist 2, der Höchstwert ist 500. 2
spark.dynamicAllocation.minExecutors Die Mindestanzahl von Executors, auf die die Arbeitslast herunterskaliert werden soll. Der Mindestwert beträgt 2. 2
spark.dynamicAllocation.maxExecutors Die maximale Anzahl von Executors, bis zu der die Arbeitslast skaliert werden kann. Der Höchstwert beträgt 2000. 1000
spark.dynamicAllocation.executorAllocationRatio Passt das Hochskalieren der Spark-Arbeitslast an. Akzeptiert einen Wert zwischen 0 und 1. Der Wert 1.0 ermöglicht eine maximale Hochskalierung und sorgt für maximale Parallelität. Durch den Wert 0.5 werden Hochskalierungsfunktion und Parallelität auf die Hälfte des Maximalwerts festgelegt. 0.3
spark.reducer.fetchMigratedShuffle.enabled Wenn dieser Wert auf true gesetzt ist, wird das Abrufen des Shuffle-Ausgabespeicherorts vom Spark-Treiber aktiviert, nachdem ein Abruf fehlgeschlagen ist, der aufgrund der dynamischen Spark-Zuweisung außer Betrieb genommen wurde. Dadurch werden ExecutorDeadException-Fehler reduziert, die durch die Shuffle-Blockmigration von außer Betrieb genommenen Executors zu Live-Executors verursacht werden. Außerdem werden Wiederholungsversuche bei Phasen reduziert, die durch FetchFailedException-Fehler verursacht werden (siehe FetchFailedException durch ExecutorDeadException). Dieses Attribut ist in den Spark-Laufzeitversionen 1.1.12 und höher sowie 2.0.20 und höher von Dataproc Serverless verfügbar. false

Spark-Messwerte für die dynamische Zuordnung

Spark-Batcharbeitslasten generieren die unten aufgeführten Messwerte für die dynamische Spark-Ressourcenzuweisung. Weitere Informationen zu Spark-Messwerten finden Sie unter Monitoring und Instrumentierung.

Messwert Beschreibung
maximum-needed Die maximale Anzahl von Executors, die unter der aktuellen Auslastung erforderlich sind, um alle laufenden und ausstehenden Aufgaben zu erfüllen.
running Die Anzahl der ausgeführten Executors, die Aufgaben ausführen.

Probleme und Lösungen für die dynamische Zuordnung lösen

  • FetchFailedException verursacht durch ExecutorDeadException

    Ursache: Wenn die dynamische Spark-Zuweisung einen Executor herunterskaliert, wird die Shuffle-Datei zu Live-Executors migriert. Da die Spark-Reducer-Aufgabe für einen Executor jedoch die Shuffle-Ausgabe von dem vom Spark-Treiber beim Start der Reducer-Aufgabe festgelegten Speicherort abruft, kann der Reducer bei der Migration einer Shuffle-Datei weiterhin versuchen, die Shuffle-Ausgabe von einem außer Betrieb genommenen Executor abzurufen. Dies führt zu ExecutorDeadException- und FetchFailedException-Fehlern.

    Lösung: Aktivieren Sie das erneute Abrufen von Shuffle-Standorten. Dazu setzen Sie spark.reducer.fetchMigratedShuffle.enabled auf true, wenn Sie die Batcharbeitslast von Dataproc Serverless for Spark ausführen (siehe Spark-Batch-Arbeitslastattribute festlegen). Wenn dieses Attribut aktiviert ist, ruft die Reducer-Aufgabe den Speicherort der Shuffle-Ausgabe vom Treiber noch einmal ab, nachdem ein Abruf von einem außer Betrieb genommenen Executor fehlschlägt.