Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Funktionsweise von AWS Glue-Entwicklungsendpunkten mit SageMaker Notebooks
Für den Zugriff auf Ihre Entwicklungsendpunkte können Sie Jupyter
Im folgenden Textfluss wird die Funktionsweise der einzelnen Komponenten erläutert:
AWS Glue SageMaker Notebook: (Jupyter → SparkMagic) → (Netzwerk) → AWS Glue-Entwicklungsendpunkt: (Apache Livy → Apache Spark)
Sobald Sie Ihr Spark-Skript ausgeführt haben, das in jeden Abschnitt eines Jupyter Notebooks geschrieben wurde, wird der Spark-Code über SparkMagic an den Livy-Server gesendet. Anschließend wird ein Spark-Auftrag namens „livy-session-N“ auf dem Spark-Cluster ausgeführt. Dieser Auftrag wird als Livy-Sitzung bezeichnet. Der Spark-Auftrag wird ausgeführt, während die Notebook-Sitzung aktiv ist. Der Spark-Auftrag wird beendet, wenn Sie den Jupyter-Kernel im Notebook herunterfahren oder die Sitzung abgelaufen ist. Pro Notebook-Datei (mit der Endung .ipynb) wird ein Spark-Auftrag gestartet.
Sie können einen einzelnen AWS Glue-Entwicklungs-Endpunkt mit mehreren SageMaker-Notebook-Instances verwenden. Sie können in jeder SageMaker-Notebook-Instance mehrere Notebook-Dateien erstellen. Wenn Sie jede Notebook-Datei öffnen und die Absätze ausführen, wird auf dem Spark-Cluster über SparkMagic pro Notebook-Datei je eine Livy-Sitzung gestartet. Jede Livy-Sitzung entspricht einem einzelnen Spark-Auftrag.
Standardverhalten für AWS Glue-Entwicklungsendpunkte und SageMaker Notebooks
Die Spark-Aufträge werden auf der Grundlage der Spark-Konfiguration
Standardmäßig weist Spark einer Livy-Sitzung Clusterressourcen auf der Grundlage der Spark-Clusterkonfiguration zu. In den AWS Glue-Entwicklungsendpunkten hängt die Clusterkonfiguration vom Worker-Typ ab. In dieser Tabelle werden die gängigen Konfigurationen pro Worker-Typ erläutert.
| Standard | G.1X | G.2X | |
|---|---|---|---|
spark.driver.memory
|
5G | 10G | 20G |
spark.executor.memory
|
5G | 10G | 20G |
spark.executor.cores
|
4 | 8 | 16 |
spark.dynamicAllocation.enabled
|
TRUE | TRUE | TRUE |
Die maximale Anzahl von Spark-Executors wird automatisch anhand einer Kombination aus DPU (oder NumberOfWorkers) und Worker-Typ berechnet.
| Standard | G.1X | G.2X | |
|---|---|---|---|
| Maximale Anzahl der Spark-Executors |
(DPU - 1) * 2 - 1
|
(NumberOfWorkers - 1)
|
(NumberOfWorkers - 1)
|
Wenn Ihr Entwicklungsendpunkt beispielsweise 10 Worker aufweist und der Worker-Typ
G.1X ist, haben Sie 9 Spark-Executors und der gesamte Cluster hat 90G Executor-Speicher, da jeder Executor 10G Speicher haben wird.
Unabhängig vom angegebenen Worker-Typ wird die dynamische Ressourcenzuweisung von Spark aktiviert. Wenn ein Datensatz groß genug ist, kann Spark alle Executors einer einzelnen Livy-Sitzung zuweisen, da spark.dynamicAllocation.maxExecutors nicht standardmäßig festgelegt ist. Das bedeutet, dass andere Livy-Sitzungen auf demselben Entwicklungsendpunkt warten, um neue Executors zu starten. Ist der Datensatz klein, können Executors mehreren Livy-Sitzungen gleichzeitig zugewiesen werden.
Anmerkung
Weitere Informationen dazu, wie Ressourcen in verschiedenen Anwendungsfällen zugewiesen werden und wie Sie eine Konfiguration festlegen, um das Verhalten zu ändern, finden Sie unter Erweiterte Konfiguration: Freigeben von Entwicklungsendpunkten unter mehreren Benutzern.
