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.
Wie AWS Glue Entwicklungsendpunkte funktionieren mit Notebooks SageMaker
Eine der häufigsten Möglichkeiten, auf Ihre Entwicklungsendpunkte zuzugreifen, ist die Verwendung von Jupyter
Im folgenden Textfluss wird die Funktionsweise der einzelnen Komponenten erläutert:
AWS Glue SageMaker Notizbuch: (Jupyter → SparkMagic) → (Netzwerk) → AWS Glue Entwicklungsendpunkt: (Apache Livy → Apache Spark)
Sobald Sie Ihr in jedem Absatz geschriebenes Spark-Skript auf einem Jupyter-Notizbuch ausgeführt haben, wird der Spark-Code über SparkMagic an den Livy-Server übermittelt. Anschließend wird ein Spark-Job mit dem Namen „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 ein einzelnes verwenden AWS Glue Entwicklungsendpunkt mit mehreren SageMaker Notebook-Instanzen. Sie können in jeder Notebook-Instanz mehrere SageMaker Notebook-Dateien erstellen. Wenn Sie jede Notebook-Datei öffnen und die Absätze ausführen, wird eine Livy-Sitzung pro Notebook-Datei auf dem Spark-Cluster über SparkMagic gestartet. Jede Livy-Sitzung entspricht einem einzelnen Spark-Auftrag.
Standardverhalten für AWS Glue Entwicklungsendpunkte und Notebooks SageMaker
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. Im AWS Glue Entwicklungsendpunkte, die Cluster-Konfiguration hängt 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.