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 die Richtlinien dazu, wie viele Treiber- und Executor-Ressourcen für Ihren Anwendungsfall konfiguriert werden sollen.
Treiber
Da der Treiber nicht viel Arbeit macht, sind standardmäßig 1 CPU und 2 GB Arbeitsspeicher ausreichend, um die meisten Pipelines auszuführen. Möglicherweise müssen Sie den Arbeitsspeicher für Pipelines erhöhen, die viele Phasen oder große Schemas enthalten. Wie unter Parallele Verarbeitung von JOINs erwähnt, müssen die speicherinternen Datasets auch in den Arbeitsspeicher des Treibers passen, wenn die Pipeline In-Memory-Joins ausführt.
Executor
Beachten Sie die folgenden Richtlinien zu CPU- und Arbeitsspeicherressourcen.
CPU
Die Anzahl der einem Executor zugewiesenen CPUs bestimmt die Anzahl der Aufgaben, die der Executor parallel ausführen kann. Für jede Datenpartition muss eine Aufgabe verarbeitet werden. In den meisten Fällen ist es am einfachsten, die Anzahl der CPUs auf eine zu setzen und sich stattdessen auf die Anpassung des Arbeitsspeichers zu konzentrieren.
Arbeitsspeicher
Für die meisten Pipelines sind 4 GB Executor-Arbeitsspeicher ausreichend, um die Pipeline erfolgreich auszuführen. Stark verzerrte Joins mit mehreren Terabyte wurden mit 4 GB Executor-Arbeitsspeicher abgeschlossen. Sie können die Ausführungsgeschwindigkeit verbessern, indem Sie den Arbeitsspeicher erhöhen. Dazu ist jedoch ein fundiertes Verständnis Ihrer Daten und Ihrer Pipeline erforderlich.
Spark teilt den Speicher in mehrere Abschnitte auf. Ein Abschnitt ist für die interne Verwendung in Spark reserviert, ein anderer zum Ausführen und Speichern.
Standardmäßig beträgt der Speicher- und Ausführungsbereich etwa 60% des Gesamtspeichers. Das Attribut spark.memory.fraction configuration von Spark (standardmäßig 0,6) steuert diesen Prozentsatz. Dieser Wert eignet sich für die meisten Arbeitslasten und muss in der Regel nicht angepasst werden.
Der Abschnitt „Speicherung und Ausführung“ ist in separate Bereiche zur Speicherung und Ausführung unterteilt. Standardmäßig haben diese Gruppenbereiche die gleiche Größe.Sie können sie aber anpassen, indem Sie spark.memory.storageFraction (Standardeinstellung: 0,5) festlegen, um zu steuern, welcher Prozentsatz des Speicherplatzes für den Speicher reserviert ist.
Im Speicherplatz werden Daten im Cache gespeichert. Im Ausführungsbereich werden Shuffle-, Join-, Sortier- und Aggregationsdaten gespeichert. Wenn im Ausführungsbereich zusätzlicher Speicherplatz vorhanden ist, kann Spark einen Teil davon zum Speichern von Daten verwenden. Ausführungsdaten werden jedoch niemals den gesamten Speicherplatz belegen.
Wenn Sie wissen, dass Ihre Pipeline keine Daten im Cache speichert, können Sie den Speicheranteil reduzieren, um mehr Platz für Ausführungsanforderungen zu lassen.
Wichtiger Hinweis: YARN-Containerarbeitsspeicher
Die Einstellung für den Executor-Speicher steuert die Größe des Heap-Speichers, der den Executors zugeteilt wird. Spark fügt zusätzlichen Arbeitsspeicher für den Nicht-Heap-Speicher hinzu. Dies wird über die Einstellung spark.executor.memoryOverhead gesteuert, die standardmäßig 384 m beträgt. Das bedeutet, dass die von YARN reservierte Arbeitsspeichermengen für jeden Executor höher sind als die in der Konfiguration der Pipelineressourcen festgelegte Anzahl. Wenn Sie beispielsweise den Executor-Arbeitsspeicher auf 2.048 m festlegen, fügt Spark dieser Zahl 384 m hinzu und fordert YARN für einen 2.432 m großen Container an. Außerdem rundet YARN die Anfragenummer auf ein Vielfaches von yarn.scheduler.increment-allocation-mb, das standardmäßig auf den Wert yarn.scheduler.minimum-allocation-mb eingestellt ist. Wenn es auf 512 gesetzt ist, rundet YARN die 2.432 m bis 2.560 m. Wenn der Wert auf 1.024 festgelegt ist, rundet YARN die Zahl 2.432 m auf 3.072 m auf. Es ist hilfreich, diesen Punkt bei der Bestimmung der Größe der einzelnen Worker-Knoten in Ihrem Cluster zu berücksichtigen.