Mit Pipelines können Sie die CPUs und den Arbeitsspeicher angeben, die dem Treiber und jedem Executor zugewiesen werden sollen. Sie können Ressourcen in den Pipelinekonfigurationen von Cloud Data Fusion Studio konfigurieren. Weitere Informationen finden Sie unter Pipelinekonfigurationen verwalten.
Auf dieser Seite finden Sie Richtlinien dazu, wie viele Treiber- und Executor-Ressourcen Sie für Ihren Anwendungsfall konfigurieren sollten.
Treiber
Da der Treiber nur wenig Arbeit hat, reicht der Standardwert von 1 CPU und 2 GB Arbeitsspeicher im Allgemeinen aus, um die meisten Pipelines auszuführen. Möglicherweise müssen Sie den Speicher für Pipelines erhöhen, die viele Phasen oder große Schemas enthalten. Wie bereits unter Parallele Verarbeitung von JOINs erwähnt, müssen die In-Memory-Datasets in den Arbeitsspeicher des Treibers passen, wenn in der Pipeline In-Memory-Joins ausgeführt werden.
Executor
Beachten Sie die folgenden Richtlinien für CPU- und Arbeitsspeicherressourcen.
CPU
Die Anzahl der CPUs, die einem Executor zugewiesen sind, bestimmt die Anzahl der Aufgaben, die der Executor parallel ausführen kann. Für jede Datenpartition ist eine Aufgabe zur Verarbeitung erforderlich. In den meisten Fällen ist es am einfachsten, die Anzahl der CPUs auf „1“ festzulegen und sich stattdessen auf die Anpassung des Arbeitsspeichers zu konzentrieren.
Speicher
Für die meisten Pipelines reichen 4 GB Arbeitsspeicher des Executors aus, um die Pipeline auszuführen. Stark verzerrte Joins mit mehreren Terabyte wurden mit 4 GB Executor-Speicher abgeschlossen. Die Ausführungsgeschwindigkeit lässt sich durch eine Erhöhung des Arbeitsspeichers verbessern. Dazu ist jedoch ein umfassendes Verständnis Ihrer Daten und Ihrer Pipeline erforderlich.
Spark unterteilt den Arbeitsspeicher in mehrere Bereiche. Ein Bereich ist für die interne Nutzung von Spark reserviert, ein anderer für die Ausführung und Speicherung.
Standardmäßig nimmt der Speicher- und Ausführungsbereich etwa 60% des gesamten Arbeitsspeichers ein. Dieser Prozentsatz wird durch die Spark-Eigenschaft spark.memory.fraction configuration (Standardwert: 0,6) gesteuert. Dieser Wert eignet sich für die meisten Arbeitslasten und muss normalerweise nicht angepasst werden.
Der Bereich „Speicher und Ausführung“ ist weiter in separate Bereiche für Speicher und Ausführung unterteilt. Standardmäßig haben diese Bereiche dieselbe Größe.Sie können sie jedoch anpassen, indem Sie spark.memory.storageFraction (Standardwert: 0,5) festlegen, um zu steuern, welcher Prozentsatz des Bereichs für den Speicher reserviert ist.
Im Speicherplatz werden zwischengespeicherte Daten gespeichert. Im Ausführungsbereich werden Daten für Zufallsmix, Join, Sortierung und Aggregation gespeichert. Wenn im Ausführungsbereich zusätzlicher Speicherplatz vorhanden ist, kann Spark einen Teil davon für Speicherdaten verwenden. Ausführungsdaten belegen jedoch nie Speicherplatz.
Wenn Sie wissen, dass in Ihrer Pipeline keine Daten im Cache gespeichert werden, können Sie den Speicheranteil reduzieren, um mehr Platz für die Ausführungsanforderungen zu schaffen.
Hinweis: YARN-Containerspeicher
Mit der Einstellung für den Executor-Speicher wird die Menge des Heap-Speichers festgelegt, die den Executors zugewiesen wird. Spark fügt zusätzlichen Speicher für den Off-Heap-Speicher hinzu, der über die Einstellung spark.executor.memoryOverhead gesteuert wird. Die Standardeinstellung ist 384 MiB. Das bedeutet, dass die Menge an Arbeitsspeicher, die YARN für jeden Executor reserviert, höher ist als die in der Konfiguration der Pipeline-Ressourcen festgelegte Zahl. Wenn Sie beispielsweise den Arbeitsspeicher des Executors auf 2.048 MB festlegen, fügt Spark dieser Zahl 384 MB hinzu und fordert bei YARN einen Container mit 2.432 MB an. Außerdem rundet YARN die Anzahl der Anfragen auf ein Vielfaches von yarn.scheduler.increment-allocation-mb auf, wobei standardmäßig der Wert yarn.scheduler.minimum-allocation-mb verwendet wird. Wenn der Wert auf 512 gesetzt ist, rundet YARN 2.432 m auf 2.560 m auf. Wenn der Wert auf 1024 festgelegt ist, rundet YARN 2432 MiB auf 3072 MiB auf. Dieser Punkt ist nützlich, wenn Sie die Größe der einzelnen Worker-Knoten in Ihrem Cluster bestimmen.