In Cloud Data Fusion wurde standardmäßig „Autoscale“ als Compute-Profil verwendet. Das Schätzen der besten Anzahl von Cluster-Workern (Knoten) für eine Arbeitslast ist schwierig und eine einzelne Clustergröße für eine gesamte Pipeline ist oft nicht ideal. Das Autoscaling des Managed Service for Apache Spark bietet einen Mechanismus zur Automatisierung der Clusterressourcenverwaltung und ermöglicht das Autoscaling von Cluster-Worker-VMs. Weitere Informationen finden Sie unter Autoscaling.
Auf der Seite Compute-Konfiguration, auf der eine Liste von Profilen angezeigt wird, gibt es die Spalte
Gesamtzahl der Kerne mit der maximalen Anzahl von vCPUs, auf die das Profil
skaliert werden kann, z. B. Up to 84.
Wenn Sie das Compute-Profil des Managed Service for Apache Spark verwenden möchten , können Sie die Clustergrößen basierend auf der Pipelinegröße verwalten.
Masterknoten
Masterknoten verwenden Ressourcen, die der Anzahl der Pipelines oder zusätzlichen Anwendungen proportional entsprechen, die auf dem Cluster ausgeführt werden. Wenn Sie Pipelines auf sitzungsspezifischen Clustern ausführen, verwenden Sie 2 CPUs und 8 GB Arbeitsspeicher für die Master knoten. Wenn Sie nichtflüchtige Cluster verwenden, benötigen Sie möglicherweise größere Masterknoten, um mit dem Workflow Schritt zu halten. Sie können die Speicher- und CPU-Auslastung auf dem Knoten überwachen, um festzustellen, ob Sie größere Masterknoten benötigen. Wir empfehlen, die Größe Ihrer Worker-Knoten mit mindestens 2 CPUs und 8 GB Arbeitsspeicher festzulegen. Wenn Sie Ihre Pipelines so konfiguriert haben, dass sie größere Speichermengen verwenden, müssen Sie größere Worker verwenden.
Achten Sie darauf, dass Ihr Cluster genügend Knoten hat, um eine möglichst parallele Verarbeitung zu ermöglichen, um die Ausführungszeit zu minimieren.
Worker
In den folgenden Abschnitten werden Aspekte der Dimensionierung von Worker-Knoten beschrieben.
CPU und Arbeitsspeicher
Wir empfehlen, die Größe Ihrer Worker-Knoten mit mindestens 2 CPUs und 8 GB Arbeitsspeicher festzulegen. Wenn Sie Ihre Pipelines so konfiguriert haben, dass sie größere Speichermengen verwenden, müssen Sie größere Worker verwenden. Bei einem Worker-Knoten mit 4 CPUs und 15 GB Arbeitsspeicher hat jeder Worker beispielsweise 4 CPUs und 12 GB zur Ausführung von YARN-Containern zur Verfügung. Wenn Ihre Pipeline für die Ausführung von 1 CPU und 8 GB Executors konfiguriert ist, kann YARN nicht mehr als einen Container pro Worker-Knoten ausführen. Jeder Worker-Knoten hätte 3 zusätzliche CPUs und 4 GB Arbeitsspeicher, die nicht genutzt werden können. Um die Ressourcennutzung in Ihrem Cluster zu maximieren, sollten
der YARN-Arbeitsspeicher und die CPUs ein genaues Vielfaches der pro
Spark-Executor benötigten Menge sein. Sie können in YARN prüfen, wie viel Arbeitsspeicher jeder Worker für YARN reserviert hat. Dazu müssen Sie die Property yarn.nodemanager.resource.memory-mb prüfen.
Wenn Sie den Managed Service for Apache Spark verwenden, sind etwa 75% des VM-Arbeitsspeichers für YARN-Container verfügbar. Die Mindestgröße für YARN-Container wird auch an die Größe der Worker-VMs angepasst. In der folgenden Tabelle sind einige gängige Worker-Größen und die entsprechenden YARN-Einstellungen aufgeführt.
| Worker-CPU | Worker-Arbeitsspeicher (GB) | YARN-Knotenarbeitsspeicher (GB) | YARN-Mindestzuweisungsspeicher (MB) |
|---|---|---|---|
| 1 | 4 | 3 | 256 |
| 2 | 8 | 6 | 512 |
| 4 | 16 | 12 | 1.024 |
| 8 | 32 | 24 | 1.024 |
| 16 | 64 | 51 | 1.024 |
Spark fordert mehr Arbeitsspeicher an als der für die Pipeline festgelegte Executor-Arbeitsspeicher und YARN rundet die angeforderte Menge auf. Angenommen, Sie haben den Executor-Arbeitsspeicher auf 2.048 MB festgelegt und keinen Wert für spark.yarn.executor.memoryOverhead angegeben. In diesem Fall wird der Standardwert von 384 MB verwendet. Das bedeutet, dass Spark 2.048 MB + 384 MB für jeden Executor anfordert, was von YARN auf ein genaues Vielfaches der YARN-Mindestzuweisung aufgerundet wird. Bei der Ausführung auf einem Worker-Knoten mit 8 GB wird der Wert auf 2, 5 GB aufgerundet, da die YARN-Mindestzuweisung 512 MB beträgt. Das bedeutet, dass jeder Worker zwei Container ausführen kann, wobei alle verfügbaren CPUs verwendet werden, aber 1 GB YARN-Arbeitsspeicher (6 GB – 2,5 GB – 2,5 GB) ungenutzt bleibt. Das bedeutet, dass der Worker-Knoten etwas kleiner dimensioniert oder den Executors etwas mehr Arbeitsspeicher zugewiesen werden kann.
Bei der Ausführung auf einem Worker-Knoten mit 16 GB wird 2.048 MB + 1.024 MB auf 3 GB aufgerundet, da die YARN-Mindestzuweisung 1.024 MB beträgt.
Das bedeutet, dass jeder Worker-Knoten vier Container ausführen kann, wobei alle CPUs
und der gesamte YARN-Arbeitsspeicher verwendet werden.
Die folgende Tabelle enthält empfohlene Worker-Größen für einige gängige Executor-Größen.
| Executor-CPU | Executor-Arbeitsspeicher (MB) | Worker-CPU | Worker-Arbeitsspeicher ( GB) |
|---|---|---|---|
| 1 | 2.048 | 4 | 15 |
| 1 | 3.072 | 4 | 21 |
| 1 | 4.096 | 4 | 26 |
| 2 | 8.192 | 4 | 26 |
Ein Worker-Knoten mit 26 GB Arbeitsspeicher bedeutet beispielsweise 20 GB Arbeitsspeicher, die für die Ausführung von YARN-Containern verwendet werden können. Wenn der Executor-Arbeitsspeicher auf 4 GB festgelegt ist, werden 1 GB als Overhead hinzugefügt, was 5 GB YARN-Container für jeden Executor bedeutet. Das bedeutet, dass der Worker vier Container ausführen kann, ohne dass zusätzliche Ressourcen übrig bleiben. Sie können auch die Größe der Worker multiplizieren. Wenn der Executor-Arbeitsspeicher beispielsweise auf 4.096 GB festgelegt ist, würde auch ein Worker mit 8 CPUs und 52 GB Arbeitsspeicher gut funktionieren. Bei Compute Engine-VMs wird die maximale Arbeitsspeichermenge der VM basierend auf der Anzahl der Kerne begrenzt. Eine VM mit 4 Kernen muss beispielsweise mindestens 7, 25 GB und maximal 26 GB Arbeitsspeicher haben. Das bedeutet, dass ein Executor , der für die Verwendung von 1 CPU und 8 GB Arbeitsspeicher konfiguriert ist, 2 CPUs und 26 GB Arbeitsspeicher auf der VM verwendet. Wenn Executors stattdessen für die Verwendung von 2 CPUs und 8 GB Arbeitsspeicher konfiguriert sind, werden alle CPUs genutzt.
Laufwerk
Laufwerke sind für einige Pipelines wichtig, aber nicht für alle. Wenn Ihre Pipeline keine Shuffles enthält, wird das Laufwerk nur verwendet, wenn der Arbeitsspeicher von Spark nicht ausreicht und Daten auf das Laufwerk ausgelagert werden müssen. Bei diesen Arten von Pipelines haben Laufwerksgröße und -typ in der Regel keine großen Auswirkungen auf die Leistung. Wenn Ihre Pipeline viele Daten mischt, macht sich die Laufwerksleistung bemerkbar. Wenn Sie den Managed Service for Apache Spark verwenden, empfehlen wir Laufwerksgrößen von mindestens 1 TB, da die Laufwerksleistung mit der Laufwerksgröße skaliert. Informationen zur Laufwerksleistung finden Sie unter Laufwerke so konfigurieren, dass sie die Leistungsanforderungen erfüllen.
Anzahl der Worker
Um die Ausführungszeit zu minimieren, sollte Ihr Cluster groß genug sein, um so viel wie möglich parallel auszuführen. Wenn Ihre Pipeline-Quelle beispielsweise Daten mit 100 Splits liest, muss der Cluster groß genug sein, um 100 Executors gleichzeitig auszuführen.
Am einfachsten lässt sich feststellen, ob Ihr Cluster zu klein ist, indem Sie den ausstehenden YARN-Arbeitsspeicher im Zeitverlauf beobachten. Wenn Sie den Managed Service for Apache Spark verwenden, finden Sie auf der Seite mit den Clusterdetails ein Diagramm.
Wenn der ausstehende Arbeitsspeicher über längere Zeiträume hoch ist, können Sie die Anzahl der Worker erhöhen, um Ihrem Cluster so viel zusätzliche Kapazität hinzuzufügen. Im vorherigen Beispiel sollte der Cluster um etwa 28 GB vergrößert werden, um die maximale Parallelität zu erreichen.
Modus für verbesserte Flexibilität (Enhanced Flexibility Mode, EFM)
Im EFM können Sie festlegen, dass nur primäre Worker-Knoten beim Mischen von Daten verwendet werden. Da sekundäre Worker nicht mehr für die Zwischen-Shuffle-Daten verantwortlich sind, kommt es bei Spark-Jobs nicht zu Verzögerungen oder Fehlern, wenn sie aus einem Cluster entfernt werden. Da die primären Worker nie herunterskaliert werden, wird der Cluster stabiler und effizienter herunterskaliert. Wenn Sie Pipelines mit Shuffles in einem statischen Cluster ausführen, empfehlen wir die Verwendung des EFM.
Weitere Informationen zum EFM finden Sie unter Modus für verbesserte Flexibilität des Managed Service for Apache Spark.