Cloud Data Fusion hat standardmäßig Autoscaling als Compute-Profil verwendet. Es ist schwierig, die beste Anzahl von Cluster-Workern (Knoten) für eine Arbeitslast zu schätzen, und eine einzelne Clustergröße für eine gesamte Pipeline ist oft nicht ideal. Dataproc-Autoscaling bietet einen Mechanismus zur Automatisierung der Verwaltung von Clusterressourcen und aktiviert die automatische Skalierung der Cluster-Worker-VM. Weitere Informationen finden Sie unter Autoscaling.
Auf der Seite Compute-Konfiguration, in der Sie eine Liste der Profile sehen, befindet sich die Spalte Kerne insgesamt, die die maximale v CPUs enthält, auf die das Profil skaliert werden kann, z. B. Up to 84.
Wenn Sie das Dataproc Compute-Profil verwenden möchten , können Sie die Clustergrößen auf der Grundlage 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 in sitzungsspezifischen Clustern ausführen, verwenden Sie 2 CPUs und 8 GB Arbeitsspeicher für die Masterknoten. Wenn Sie nichtflüchtige Cluster verwenden, benötigen Sie möglicherweise größere Masterknoten, um mit dem Workflow Schritt zu halten. Wenn Sie wissen möchten, ob Sie größere Masterknoten benötigen, können Sie die Arbeitsspeicher- und CPU-Nutzung auf dem Knoten überwachen. 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 einen größeren Arbeitsspeicher 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 Größenanpassung von Worker-Knoten beschrieben.
CPU und Arbeitsspeicher
Wir empfehlen, die Größe der Worker-Knoten mit mindestens 2 CPUs und 8 GB Arbeitsspeicher festzulegen. Wenn Sie Ihre Pipelines so konfiguriert haben, dass sie einen größeren Arbeitsspeicher nutzen, verwenden Sie größere Worker. Bei einem Worker-Knoten mit 4 CPUs und 15 GB stehen jedem Worker beispielsweise 4 CPUs und 12 GB zum Ausführen von YARN-Containern zur Verfügung. Wenn die Pipeline so konfiguriert ist, dass sie Executors mit 1 CPU und 8 GB ausführt, kann YARN nicht mehr als einen Container pro Worker-Knoten ausführen. Jeder Worker-Knoten hätte zusätzliche 3 CPUs und 4 GB, die verschwendet werden, da er nicht zum Ausführen von etwas verwendet werden kann. Um die Ressourcennutzung in Ihrem Cluster zu maximieren, sollten der YARN-Arbeitsspeicher und die YARN-CPUs ein exaktes Vielfaches der pro Spark-Executor benötigten Menge sein. Anhand des Attributs yarn.nodemanager.resource.memory-mb in YARN können Sie prüfen, wie viel Arbeitsspeicher jeder Worker für YARN reserviert hat.
Wenn Sie Dataproc verwenden, beträgt der für YARN-Container verfügbare Arbeitsspeicher etwa 75% des VM-Arbeitsspeichers. Die Mindestgröße des YARN-Containers 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) | Min. YARN-Speicherzuordnung (MB) |
|---|---|---|---|
| 1 | 4 | 3 | 256 |
| 2 | 8 | 6 | 512 |
| 4 | 16 | 12 | 1.024 |
| 8 | 32 | 24 | 1.024 |
| 16 | 64 | 51 | 1.024 |
Beachten Sie, dass Spark mehr Speicher anfordert, als der für die Pipeline festgelegte Executor-Arbeitsspeicher ist, und dass YARN diesen angeforderten Betrag aufrunden. Angenommen, Sie haben den Speicher für den Executor auf 2.048 MB festgelegt und keinen Wert für spark.yarn.executor.memoryOverhead angegeben. Dies bedeutet, dass der Standardwert von 384 MB verwendet wird. Das bedeutet, dass Spark 2048 MB + 384 MB für jeden Executor anfordert, was YARN auf ein exaktes Vielfaches der YARN-Mindestzuweisung aufgerundet. Da die YARN-Mindestzuweisung 512 MB beträgt, wird bei der Ausführung auf einem Worker-Knoten mit 8 GB auf 2, 5 GB aufgerundet. Das bedeutet, dass jeder Worker zwei Container ausführen kann und dabei alle verfügbaren CPUs beansprucht, aber 1 GB YARN-Arbeitsspeicher (6 GB - 2,5 GB - 2,5 GB) ungenutzt lässt. Das bedeutet, dass der Worker-Knoten etwas kleiner sein kann oder die Executors etwas mehr Arbeitsspeicher erhalten können.
Bei der Ausführung auf einem Worker-Knoten mit 16 GB werden 2.048 MB + 1.024 MB auf 3 GB gerundet, da die YARN-Mindestzuweisung 1.024 MB beträgt.
Das bedeutet, dass jeder Worker-Knoten vier Container ausführen kann, wobei alle CPUs und alle YARN-Arbeitsspeicher verwendet werden.
Als Hilfe zum Kontext enthält die folgende Tabelle empfohlene Worker-Größen unter Berücksichtigung einiger gängiger Executor-Größen.
| Executor-CPU | Arbeitsspeicher des Executors (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 entspricht beispielsweise 20 GB Arbeitsspeicher, der zum Ausführen von YARN-Containern verwendet werden kann. Bei einem Executor-Arbeitsspeicher von 4 GB wird 1 GB als Overhead hinzugefügt, was 5 GB YARN-Container für jeden Executor bedeutet. Auf diese Weise kann der Worker vier Container ausführen, 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, funktioniert auch ein Worker mit 8 CPUs und 52 GB Arbeitsspeicher gut. Bei Compute Engine-VMs wird anhand der Anzahl der Kerne beschränkt, wie viel Arbeitsspeicher die VM haben kann. Beispielsweise muss eine VM mit vier Kernen mindestens 7, 25 GB Arbeitsspeicher und höchstens 26 GB Arbeitsspeicher haben. Dies bedeutet, dass ein Executor, der für die Verwendung von 1 CPU und 8 GB Arbeitsspeicher festgelegt 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 Spark nicht mehr genügend Arbeitsspeicher hat und Daten an das Laufwerk übergeben muss. Bei diesen Pipelines haben die Laufwerksgröße und der Typ des Laufwerks in der Regel keine großen Auswirkungen auf die Leistung. Wenn Ihre Pipeline viele Daten nach dem Zufallsprinzip verteilt, macht die Laufwerksleistung einen Unterschied. Wenn Sie Dataproc verwenden, sollten Sie mindestens eine Laufwerksgröße von 1 TB verwenden, da die Laufwerksleistung mit der Laufwerksgröße zunimmt. Informationen zur Laufwerksleistung finden Sie unter Laufwerke konfigurieren, um Leistungsanforderungen zu erfüllen.
Anzahl der Worker
Sorgen Sie dafür, dass Ihr Cluster groß genug ist, um so viel wie möglich parallel auszuführen, um die Ausführungszeit zu minimieren. Wenn Ihre Pipelinequelle beispielsweise Daten mit 100 Splits liest, sollten Sie dafür sorgen, dass der Cluster groß genug ist, um 100 Executors gleichzeitig auszuführen.
Wenn Sie sich den ausstehenden YARN-Arbeitsspeicher im Zeitverlauf ansehen, können Sie am einfachsten feststellen, ob Ihr Cluster zu groß ist. Wenn Sie Dataproc verwenden, finden Sie auf der Detailseite des Clusters ein Diagramm.
Wenn der ausstehende Arbeitsspeicher über einen längeren Zeitraum hoch ist, können Sie die Anzahl der Worker erhöhen, um Ihrem Cluster diese zusätzliche Kapazität hinzuzufügen. Im vorherigen Beispiel sollte der Cluster um etwa 28 GB erhöht werden, um das maximale Parallelitätsniveau zu erreichen.
Modus für verbesserte Flexibilität (Enhanced Flexibility Mode, EFM)
Mit EFM können Sie festlegen, dass nur primäre Worker-Knoten an der Datenumverteilung nach dem Zufallsprinzip beteiligt sind. Da sekundäre Worker nicht mehr für die Shuffle-Zwischendaten verantwortlich sind, treten bei Spark-Jobs beim Entfernen aus einem Cluster keine Verzögerungen oder Fehler auf. Da primäre Worker nie herunterskaliert werden, wird der Cluster mit mehr Stabilität und Effizienz herunterskaliert. Wenn Sie Pipelines mit Shuffles in einem statischen Cluster ausführen, wird die Verwendung von EFM empfohlen.
Weitere Informationen zu EFM finden Sie unter Erweiterter Flexibilitätsmodus von Dataproc.