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. # AWS Glue Spark und PySpark Jobs AWS Glue unterstützen Sie Spark und PySpark Jobs. Ein Spark-Job wird in einer Apache Spark-Umgebung ausgeführt, die von verwaltet wird AWS Glue. Er verarbeitet Daten in Batches. Ein Streaming-ETL-Auftrag ähnelt einem Spark-Auftrag, mit der Ausnahme, dass er ETL für Datenstreams ausführt. Er verwendet das Framework Apache Spark Structured Streaming. Einige Features von Spark-Aufträgen sind für Streaming-ETL-Aufträge nicht verfügbar. Die folgenden Abschnitte enthalten Informationen zu AWS Glue Spark und PySpark Jobs. **Topics** + [Konfiguration der Auftragseigenschaften für Spark-Jobs in AWS Glue](add-job.md) + [Spark-Skripte in der AWS Glue-Konsole bearbeiten](edit-script-spark.md) + [Aufgräge (veraltet)](console-edit-script.md) + [Verfolgen von verarbeiteten Daten mit Auftragslesezeichen](monitor-continuations.md) + [Speichern von Spark-Shuffle-Daten](monitor-spark-shuffle-manager.md) + [Überwachung von AWS Glue-Spark-Aufträgen](monitor-spark.md) + [Generative KI-Fehlerbehebung für Apache Spark in AWS Glue](troubleshoot-spark.md) + [Materialisierte Ansichten mit AWS Glue verwenden](materialized-views.md) # Konfiguration der Auftragseigenschaften für Spark-Jobs in AWS Glue Wenn Sie Ihren Job auf der AWS Glue Konsole definieren, geben Sie Werte für Eigenschaften an, um die AWS Glue Laufzeitumgebung zu steuern. ## Definieren von Auftragseigenschaften für Spark-Aufträge Die folgende Liste enthält Beschreibungen der Eigenschaften eines Spark-Auftrags. Informationen zu den Eigenschaften von Python-Shell-Aufträgen finden Sie unter [Definieren von Auftragseigenschaften für Python-Shell-Aufträge](add-job-python.md#create-job-python-properties). Informationen zu den Eigenschaften eines Streaming-ETL-Auftrags finden Sie unter [Definieren von Auftragseigenschaften für einen Streaming-ETL-Auftrag](add-job-streaming.md#create-job-streaming-properties). Die Eigenschaften werden in der Reihenfolge aufgeführt, in der sie im Assistenten zum **Hinzufügen von Jobs** auf der AWS Glue Konsole angezeigt werden. **Name** Geben Sie eine UTF-8-Zeichenfolge mit einer maximalen Länge von 255 Zeichen an. **Description** Geben Sie eine optionale Beschreibung mit bis zu 2.048 Zeichen ein. **IAM Role (IAM-Rolle)** Geben Sie die IAM-Rolle an, die für die Autorisierung von Ressourcen verwendet wird, die für die Ausführung des Auftrags und den Zugriff auf Datenspeicher verwendet werden. Weitere Informationen zu den Berechtigungen für die Ausführung von Jobs in AWS Glue finden Sie unter[Identitäts- und Zugriffsmanagement für AWS Glue](security-iam.md). **Typ** Der Typ des ETL-Auftrags. Dieser wird automatisch basierend auf dem Typ der ausgewählten Datenquellen festgelegt. + Wählen Sie **Spark** aus, um ein Apache-Spark-ETL-Skript mit dem Auftragsbefehl `glueetl` auszuführen. + Wählen Sie **Spark-Streaming** aus, um ein Apache-Spark-Streaming-ETL-Skript mit dem Auftragsbefehl `gluestreaming` auszuführen. Weitere Informationen finden Sie unter [Streaming-ETL-Aufträge in AWS Glue](add-job-streaming.md). + Wählen Sie **Python-Shell** aus, um ein Python-Skript mit dem Auftragsbefehl `pythonshell` auszuführen. Weitere Informationen finden Sie unter [Konfigurieren von Auftragseigenschaften für Python-Shell-Aufträge in AWS Glue](add-job-python.md). **AWS Glue -Version** AWS Glue Version bestimmt die Versionen von Apache Spark und Python, die für den Job verfügbar sind, wie in der folgenden Tabelle angegeben. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/add-job.html) **Sprache** Der Code im ETL-Skript definiert die Logik Ihres Auftrags. Das Skript kann in Python oder Scala programmiert werden. Sie können wählen, ob das Skript, das der Job ausführt, von Ihnen generiert AWS Glue oder bereitgestellt wird. Geben Sie den Skript-Namen und den Speicherort in Amazon Simple Storage Service (Amazon S3) an. Vergewissern Sie sich, dass sich keine Datei mit dem Namen des Skriptverzeichnisses im Pfad befindet. Weitere Informationen zum Schreiben von Skripts finden Sie unter [AWS Glue Leitfaden zur Programmierung](edit-script.md). **Worker type (Worker-Typ)** Die folgenden Worker-Typen sind verfügbar: Die Ressourcen, die den AWS Glue Mitarbeitern zur Verfügung stehen, werden in gemessen DPUs. Eine DPU ist ein relatives Maß für die Rechenleistung, die sich aus 4 V CPUs Rechenkapazität und 16 GB Arbeitsspeicher zusammensetzt. + **G.025X** – Wenn Sie diese Art auswählen, müssen Sie auch einen Wert für die **Anzahl der Worker** angeben. Jeder Worker entspricht 0,25 DPU (2 VCPUs, 4 GB Arbeitsspeicher) mit 84 GB Festplatte (ca. 34 GB freier Speicher). Wir empfehlen diesen Worker-Typ für Streaming-Aufträge mit geringem Volumen. Dieser Worker-Typ ist nur für Streaming-Jobs der AWS Glue Version 3.0 oder höher verfügbar. + **G.1X** – Wenn Sie diese Art auswählen, müssen Sie auch einen Wert für die **Anzahl der Worker** angeben. Jeder Worker ist einer DPU (4 VCPUs, 16 GB Arbeitsspeicher) mit 94 GB Festplatte (ca. 44 GB freier Speicher) zugeordnet. Wir empfehlen diesen Worker-Typ für Workloads wie Datentransformationen, Zusammenführungen und Abfragen. Er bietet eine skalierbare und kostengünstige Möglichkeit, die meisten Aufträge auszuführen. + **G.2X** – Wenn Sie diese Art auswählen, müssen Sie auch einen Wert für die **Anzahl der Worker** angeben. Jeder Worker ordnet 2 DPU (8 VCPUs, 32 GB Arbeitsspeicher) mit 138 GB Festplatte (ca. 78 GB freier Speicherplatz) zu. Wir empfehlen diesen Worker-Typ für Workloads wie Datentransformationen, Zusammenführungen und Abfragen. Er bietet eine skalierbare und kostengünstige Möglichkeit, die meisten Aufträge auszuführen. + **G.4X** – Wenn Sie diese Art auswählen, müssen Sie auch einen Wert für die **Anzahl der Worker** angeben. Jeder Worker ordnet 4 DPU (16 VCPUs, 64 GB Arbeitsspeicher) mit 256 GB Festplatte (ca. 230 GB freier Speicher) zu. Wir empfehlen diesen Worker-Typ für Aufträge, deren Workloads Ihre anspruchsvollsten Transformationen, Aggregationen, Verknüpfungen und Abfragen enthalten. + **G.8X** – Wenn Sie diese Art auswählen, müssen Sie auch einen Wert für die **Anzahl der Worker** angeben. Jeder Worker ordnet 8 DPU (32 VCPUs, 128 GB Arbeitsspeicher) mit 512 GB Festplatte (ca. 485 GB freier Speicher) zu. Wir empfehlen diesen Worker-Typ für Aufträge, deren Workloads Ihre anspruchsvollsten Transformationen, Aggregationen, Verknüpfungen und Abfragen enthalten. + **G.12X** – Wenn Sie diese Art auswählen, müssen Sie auch einen Wert für die **Anzahl der Worker** angeben. Jeder Worker ordnet 12 DPU (48 VCPUs, 192 GB Arbeitsspeicher) mit 768 GB Festplatte (ca. 741 GB freier Speicher) zu. Wir empfehlen diesen Worker-Typ für Aufträge mit sehr großen und ressourcenintensiven Workloads, die eine erhebliche Rechenkapazität erfordern. + **G.16X** – Wenn Sie diese Art auswählen, müssen Sie auch einen Wert für die **Anzahl der Worker** angeben. Jeder Worker ordnet 16 DPU (64 VCPUs, 256 GB Arbeitsspeicher) mit 1024 GB Festplatte (ca. 996 GB frei) zu. Wir empfehlen diesen Worker-Typ für Aufträge mit den größten und ressourcenintensivsten Workloads, die maximale Rechenkapazität erfordern. + **R.1X** – Wenn Sie diese Art auswählen, müssen Sie auch einen Wert für die **Anzahl der Worker** angeben. Jedem Worker ist eine DPU mit speicheroptimierter Konfiguration zugeordnet. Wir empfehlen diesen Workertyp für speicherintensive Workloads, bei denen häufig Fehler auftreten oder bei denen hohe Raten erforderlich sind. out-of-memory memory-to-CPU + **R.2X** – Wenn Sie diese Art auswählen, müssen Sie auch einen Wert für die **Anzahl der Worker** angeben. Jedem Worker sind 2 DPUs mit speicheroptimierter Konfiguration zugeordnet. Wir empfehlen diesen Workertyp für speicherintensive Workloads, bei denen häufig Fehler auftreten out-of-memory oder bei denen hohe Ratio-Werte erforderlich sind. memory-to-CPU + **R.4X** – Wenn Sie diese Art auswählen, müssen Sie auch einen Wert für die **Anzahl der Worker** angeben. Jedem Worker sind 4 DPUs mit speicheroptimierter Konfiguration zugeordnet. Wir empfehlen diesen Workertyp für große speicherintensive Workloads, bei denen häufig Fehler auftreten out-of-memory oder bei denen hohe Ratio-Werte erforderlich sind. memory-to-CPU + **R.8X** – Wenn Sie diese Art auswählen, müssen Sie auch einen Wert für die **Anzahl der Worker** angeben. Jedem Worker sind 8 DPUs mit speicheroptimierter Konfiguration zugeordnet. Wir empfehlen diesen Workertyp für sehr große speicherintensive Workloads, bei denen häufig Fehler auftreten out-of-memory oder bei denen hohe Ratios erforderlich sind. memory-to-CPU **Worker-Typ-Spezifikationen** Die folgende Tabelle enthält detaillierte Spezifikationen für alle verfügbaren G-Worker-Typen: **Spezifikationen für G-Worker-Typen** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/add-job.html) **Wichtig:** Die Worker-Typen G.12X und G.16X sowie alle R-Worker-Typen (R.1X bis R.8X) haben eine höhere Startlatenz. Ihnen wird ein Stundensatz berechnet, der auf der Anzahl der für die Ausführung Ihrer ETL-Jobs DPUs verwendeten Jobs basiert. Weitere Informationen finden Sie in der [AWS Glue Preisliste](https://aws.amazon.com/glue/pricing/). Wenn Sie für Jobs der AWS Glue Version 1.0 oder früher einen Job mithilfe der Konsole konfigurieren und den **Worker-Typ** **Standard** angeben, wird die **maximale Kapazität** festgelegt und die **Anzahl der Worker** wird zum Wert von **Maximale Kapazität** — 1. Wenn Sie das AWS Command Line Interface (AWS CLI) oder AWS SDK verwenden, können Sie den Parameter **Max Capacity** angeben, oder Sie können sowohl den ****Worker-Typ als auch die Anzahl der** Worker** angeben. Für Jobs der AWS Glue Version 2.0 oder höher können Sie keine **maximale Kapazität** angeben. Stattdessen sollten Sie einen **Worker-Typ** und die **Anzahl der Worker** angeben. **G.4X**und **G.8X** Arbeitertypen sind nur für Spark ETL-Jobs der AWS Glue Version 3.0 oder höher in den folgenden AWS Regionen verfügbar: USA Ost (Ohio), USA Ost (Nord-Virginia), USA West (Nordkalifornien), USA West (Oregon), Asien-Pazifik (Mumbai), Asien-Pazifik (Seoul), Asien-Pazifik (Singapur), Asien-Pazifik (Sydney), Asien-Pazifik (Tokio), Kanada (Zentral), Europa (Frankfurt), Europa (Irland), Europa (London), Europa (Spanien), Europa (Stockholm) und Südamerika (São Paulo). **G.12X****G.16X**, und **R.1X** über **R.8X** Worker-Typen sind nur für Spark ETL-Jobs der AWS Glue Version 4.0 oder höher in den folgenden AWS Regionen verfügbar: USA Ost (Nord-Virginia), USA West (Oregon), USA Ost (Ohio), Europa (Irland) und Europa (Frankfurt). Weitere Regionen werden in zukünftigen Versionen unterstützt. **Angeforderte Anzahl der Worker** Für die meisten Worker-Typen müssen Sie die Anzahl der Worker angeben, die bei der Ausführung des Auftrags zugewiesen werden. **Job-Lesezeichen** Geben Sie an, wie Statusinformationen AWS Glue verarbeitet werden, wenn der Job ausgeführt wird. Sie können bereits verarbeitete Daten beibehalten lassen, Statusinformationen aktualisieren oder Statusinformationen ignorieren. Weitere Informationen finden Sie unter [Verfolgen von verarbeiteten Daten mit Auftragslesezeichen](monitor-continuations.md). **Warteschlange für Auftragsausführung** Gibt an, ob Auftragsausführungen in die Warteschlange gestellt werden, um sie später auszuführen, wenn sie aufgrund von Service Quotas nicht sofort ausgeführt werden können. Wenn diese Option aktiviert ist, ist die Warteschlange für Auftragsausführungen aktiviert. Wenn sie nicht aktiviert ist, werden die Auftragsausführungen nicht in die Warteschlange aufgenommen. Stimmt diese Einstellung nicht mit dem Wert überein, der in der Auftragsausführung festgelegt wurde, wird der Wert aus dem Feld für die Auftragsausführung verwendet. **Flexible Ausführung** Wenn Sie einen Job mit AWS Studio oder der API konfigurieren, können Sie eine Standard- oder flexible Jobausführungsklasse angeben. Ihre Aufträge können unterschiedliche Prioritäten und Zeitsensibilität haben. Die Standardausführungsklasse ist ideal für zeitkritische Workloads, die einen schnellen Auftragsstart und dedizierte Ressourcen erfordern. Die flexible Ausführungsklasse eignet sich für nicht dringende Aufträge, deren Start- und Abschlusszeiten variieren können, z. B. für Vorproduktionsaufträge, Tests und einmalige Datenübertragungen. Flexible Auftragsausführungen werden für Jobs unterstützt, die AWS Glue Version 3.0 oder höher und/oder `G.1X` `G.2X` Workertypen verwenden. Die neuen Worker-Typen (`G.12X`, `G.16X` und `R.1X` bis `R.8X`) unterstützen keine flexible Ausführung. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/FnHCoTuDLXU/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/FnHCoTuDLXU) Ausführungen von Flex-Aufträgen werden basierend auf der Anzahl der Worker abgerechnet, die zu einem beliebigen Zeitpunkt ausgeführt werden. Die Anzahl der Worker kann für die Ausführung eines flexiblen Auftrags hinzugefügt oder entfernt werden. Anstatt eine einfache Berechnung von `Max Capacity` \$1 `Execution Time` abzurechnen, trägt jeder Worker für die Zeit bei, die er während der Ausführung des Auftrags ausgeführt hat. Die Rechnung ist die Summe von (`Number of DPUs per worker`\$1`time each worker ran`). Weitere Informationen finden Sie im Hilfebereich in AWS Studio oder [Jobs](aws-glue-api-jobs-job.md) und[Auftragsausführungen](aws-glue-api-jobs-runs.md). **Anzahl der Wiederholungen** Geben Sie an, wie oft (zwischen 0 und 10) der Job automatisch neu gestartet werden AWS Glue soll, falls er fehlschlägt. Aufträge, die das Timeout-Limit erreichen, werden nicht neu gestartet. **Zeitüberschreitung von Aufträgen** Legt die maximale Ausführungszeit in Minuten fest. Die maximale Einstellung beträgt 2.880 Minuten (2 Tage). Andernfalls geben die Aufträge eine Ausnahme aus. Wenn der Wert leer gelassen wird, ist das Timeout standardmäßig auf 2880 Minuten festgelegt. Für alle vorhandenen AWS Glue Jobs mit einem Timeout-Wert von mehr als 7 Tagen wird standardmäßig ein Wert von 7 Tagen verwendet. Wenn Sie beispielsweise ein Timeout von 20 Tagen für einen Batch-Auftrag angegeben haben, wird dieser am 7. Tag gestoppt. **Bewährte Methoden für Auftrags-Timeouts** Jobs werden basierend auf der Ausführungszeit abgerechnet. Um unerwartete Gebühren zu vermeiden, konfigurieren Sie Timeout-Werte, die der erwarteten Ausführungszeit Ihres Auftrags entsprechen. **Erweiterte Eigenschaften** **Skript-Dateiname** Ein eindeutiger Skript-Name für Ihren Auftrag. Kann nicht als **Unbenannter Auftrag** bezeichnet werden. **Skriptpfad** Der Amazon-S3-Objekt-Speicherort des Skripts. Der Pfad muss im Format `s3://bucket/prefix/path/` eingegeben werden. Der Pfad muss mit einem Schrägstrich (`/`) enden und darf keine Dateien enthalten. **Auftragsmetriken** Schalten Sie die Erstellung von CloudWatch Amazon-Metriken ein oder aus, wenn dieser Job ausgeführt wird. Um die Profiling-Daten anzuzeigen, müssen Sie diese Option aktivieren. Weitere Informationen über das Aktivieren und Anzeigen von Metriken finden Sie unter [Auftragsüberwachung und Debugging](monitor-profile-glue-job-cloudwatch-metrics.md). **Kennzahlen zur Jobbeobachtbarkeit** Schalten Sie die Erstellung zusätzlicher CloudWatch Messwerte für die Beobachtbarkeit ein, wenn dieser Job ausgeführt wird. Weitere Informationen finden Sie unter [Überwachung mit AWS Glue-Beobachtbarkeitsmetriken](monitor-observability.md). **Kontinuierliche Protokollierung** Aktivieren Sie die kontinuierliche Protokollierung bei Amazon CloudWatch. Wenn diese Option nicht aktiviert ist, stehen Protokolle erst nach Abschluss des Auftrags zur Verfügung. Weitere Informationen finden Sie unter [Protokollierung für AWS Glue Jobs](monitor-continuous-logging.md). **Spark-Benutzeroberfläche** Aktivieren Sie die Verwendung der Spark-Benutzeroberfläche, um diese Aufgabe zu überwachen. Weitere Informationen finden Sie unter [Aktivieren der Apache-Spark-Webbenutzeroberfläche für AWS Glue-Aufgaben](monitor-spark-ui-jobs.md). **Spark-UI-Protokollpfade** Der Pfad zum Schreiben von Protokollen, wenn die Spark-UI aktiviert ist. **Konfiguration der Protokollierung und Überwachung über Spark-UI** Wählen Sie eine der folgenden Optionen: + *Standard*: Schreiben Sie Protokolle mit der AWS Glue Job-Run-ID als Dateinamen. Schalten Sie die Spark-UI-Überwachung in der AWS Glue Konsole ein. + *Legacy*: Protokolle werden mit „spark-application-\$1Zeitstempel\$1“ als Dateinamen geschrieben. Aktivieren Sie die Spark-UI-Überwachung nicht. + *Standard und Legacy*: Protokolle werden sowohl an den Standard- als auch an den Legacy-Speicherorten geschrieben. Schalten Sie die Spark-UI-Überwachung in der AWS Glue Konsole ein. **Maximale Parallelität** Legt die maximale Anzahl gleichzeitiger Ausführungen fest, die für diese Ausführung zulässig sind. Der Standardwert ist 1. Bei Erreichen dieser Schwelle wird ein Fehler zurückgegeben. Der Höchstwert, den Sie angeben können, wird durch ein Service Limit gesteuert. Wenn beispielsweise beim Starten einer neuen Instance eine vorherige Ausführung läuft, möchten Sie einen Fehler zurückgeben, um zu verhindern, dass zwei Instance desselben Auftrags gleichzeitig ausgeführt werden. **Temporärer Pfad** Geben Sie den Speicherort eines Arbeitsverzeichnisses in Amazon S3 an, in das temporäre Zwischenergebnisse geschrieben werden, wenn das Skript AWS Glue ausgeführt wird. Vergewissern Sie sich, dass sich keine Datei mit dem Namen des temporären Verzeichnis im Pfad befindet. Dieses Verzeichnis wird beim AWS Glue Lesen und Schreiben in Amazon Redshift und bei bestimmten AWS Glue Transformationen verwendet. AWS Glue erstellt einen temporären Bucket für Jobs, falls in einer Region noch kein Bucket vorhanden ist. Dieser Bucket erlaubt möglicherweise den öffentlichen Zugriff. Sie können entweder den Bucket in Amazon S3 ändern, um den öffentlichen Zugriffsblock festzulegen, oder den Bucket später löschen, nachdem alle Aufträge in dieser Region abgeschlossen sind. **Schwellenwert für die Verzögerungsbenachrichtigung (Minuten)** Legt den Schwellenwert (in Minuten) fest, bevor eine Verzögerungsbenachrichtigung gesendet wird. Sie können diesen Schwellenwert festlegen, um Benachrichtigungen zu senden, wenn ein `RUNNING`, `STARTING` oder `STOPPING` Auftragslauf mehr als eine erwartete Anzahl von Minuten andauert. **Security configuration (Sicherheitskonfiguration)** Wählen Sie eine Sicherheitskonfiguration aus der Liste aus. Eine Sicherheitskonfiguration gibt an, wie die Daten am Amazon-S3-Ziel verschlüsselt werden: keine Verschlüsselung, serverseitige Verschlüsselung mit von AWS KMS verwalteten Schlüsseln (SSE-KMS) oder mit von Amazon S3 verwalteten Verschlüsselungsschlüsseln (SSE-S3). **Serverseitige Verschlüsselung** Wenn Sie diese Option wählen, werden die Daten beim Schreiben des ETL-Auftrags nach Amazon S3 im Ruhezustand mit SSE-S3-Verschlüsselung verschlüsselt. Sowohl Ihr Amazon-S3-Datenziel als auch alle Daten, die in ein temporäres Amazon-S3-Verzeichnis geschrieben werden, werden verschlüsselt. Diese Option wird als Auftragsparameter übergeben. Weitere Informationen finden Sie unter [Schützen von Daten mit serverseitiger Verschlüsselung mit Amazon S3-verwalteten Verschlüsselungsschlüsseln (SSE-S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html) im *Benutzerhandbuch von Amazon Simple Storage Service*. Diese Option wird bei Angabe einer Sicherheitskonfiguration ignoriert. **Verwenden des Glue-Datenkatalogs als Hive-Metastore** Wählen Sie diese Option aus, um den AWS Glue Datenkatalog als Hive-Metastore zu verwenden. Die für den Auftrag verwendete IAM-Rolle muss über die `glue:CreateDatabase`-Berechtigung verfügen. Sofern nicht bereits vorhanden, wird im Data Catalog eine Datenbank namens „default“ angelegt. **Verbindungen** Wählen Sie eine VPC-Konfiguration, um auf Amazon-S3-Datenquellen zuzugreifen, die sich in Ihrer Virtual Private Cloud (VPC) befinden. Sie können eine Netzwerkverbindung in AWS Glue erstellen und verwalten. Weitere Informationen finden Sie unter [Herstellen einer Verbindung zu Daten](glue-connections.md). **Bibliotheken** **Python-Bibliothekspfad, abhängiger JARs Pfad und Pfad der referenzierten Dateien** Geben Sie diese Optionen an, wenn Ihr Skript sie benötigt. Sie können die durch Kommas getrennten Amazon-S3-Pfade für diese Optionen definieren, wenn Sie den Auftrag definieren. Sie können diese Pfade bei der Ausführung des Auftrag überschreiben. Weitere Informationen finden Sie unter [Bereitstellen eigener, benutzerdefinierter Skripts](console-custom-created.md). **Job-Parameter** Ein Satz von Schlüssel-Wert-Paaren, die als benannte Parameter an das Skript übergeben werden. Dies sind Standardwerte, die verwendet werden, wenn das Skript ausgeführt wird. Sie können auch in Auslösern oder beim Ausführen der Aufgabe überschrieben werden. Sie müssen dem Schlüsselnamen `--` voranstellen; z. B.: `--myKey`. Sie übergeben Jobparameter als Map, wenn Sie die verwenden AWS Command Line Interface. Beispiele finden Sie unter „Python parameters“ (Python-Parameter) in [Übergeben von und Zugreifen auf Python-Parameter in AWS Glue](aws-glue-programming-python-calling.md#aws-glue-programming-python-calling-parameters). **Tags (Markierungen)** Markieren Sie Ihren Auftrag mit einem **Tag-Schlüssel** und einem optionalen **Tag-Wert**. Nachdem Tag-Schlüssel erstellt wurden, sind sie schreibgeschützt. Verwenden Sie Tags für manche Ressourcen, damit sie leichter zu organisieren und identifizieren sind. Weitere Informationen finden Sie unter [AWS Schlagworte in AWS Glue](monitor-tags.md). ## Einschränkungen für Aufträge, die auf verwaltete Tabellen von Lake Formation zugreifen Beachten Sie die folgenden Hinweise und Einschränkungen, wenn Sie Jobs erstellen, die aus Tabellen lesen oder in Tabellen schreiben, die von verwaltet werden AWS Lake Formation: + Die folgenden Features werden in Aufträgen, die auf Tabellen mit Filtern auf Zellebene zugreifen, nicht unterstützt: + [Auftrags-Lesezeichen](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html) und [Begrenzte Ausführung](https://docs.aws.amazon.com/glue/latest/dg/bounded-execution.html) + [Pushdown-Prädikate](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-partitions.html#aws-glue-programming-etl-partitions-pushdowns) + [Prädikate für Serverseitige Katalogpartitionen](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-partitions.html#aws-glue-programming-etl-partitions-cat-predicates) + [enableUpdateCatalog](https://docs.aws.amazon.com/glue/latest/dg/update-from-job.html) # Spark-Skripte in der AWS Glue-Konsole bearbeiten Ein Skript enthält den Code, der Daten aus Quellen extrahiert, transformiert und in Ziele lädt. AWS Glue führt ein Skript aus, wenn es einen Job startet. ETL-Skripts in AWS Glue können in Python oder Scala codiert werden. Python-Skripte verwenden eine Sprache, die eine Erweiterung des PySpark Python-Dialekts für ETL-Jobs (Extrahieren, Transformieren und Laden) darstellt. Das Skript enthält *erweiterte Konstrukte* für die Verarbeitung von ETL-Transformationen. Wenn Sie die Quellcodelogik für Ihren Auftrag automatisch generieren, wird ein Skript erstellt. Sie können dieses Skript bearbeiten oder Ihr eigenes Skript zur Verarbeitung Ihrer ETL-Vorgänge bereitstellen. Informationen zum Definieren und Bearbeiten von Skripts in AWS Glue finden Sie unter [AWS Glue Leitfaden zur Programmierung](edit-script.md). ## Zusätzliche Bibliotheken oder Dateien Wenn Ihr Skript zusätzliche Bibliotheken oder Dateien erfordert, können Sie sie wie folgt angeben: **Python-Bibliothekspfad** Durch Komma getrennte Amazon Simple Storage Service (Amazon S3)-Pfade zu den Python-Bibliotheken, die das Skript erfordert. Es können nur reine Python-Bibliotheken verwendet werden. Bibliotheken, die auf C-Erweiterungen basieren, wie zum Beispiel die Python Data Analysis Library von Panda , werden noch nicht unterstützt. **Abhängiger Jars-Pfad** Durch Komma getrennte Amazon-S3-Pfade zu JAR-Dateien, die vom Skript benötigt werden. Derzeit können nur reine Java- oder Scala (2.11)-Bibliotheken verwendet werden. **Pfad für referenzierte Dateien** Durch Komma getrennte Amazon-S3-Pfade zu zusätzlichen Dateien (z. B. Konfigurationsdateien), die das Skript erfordert. # Aufgräge (veraltet) Ein Skript enthält den Code, der das Extrahieren, Transformieren und Laden (ETL) ausführt. Sie können Ihr eigenes Skript zur Verfügung stellen, oder AWS Glue kann nach Ihren Anweisungen ein Skript generieren. Informationen zum Erstellen eigener Skripts finden Sie unter [Bereitstellen eigener, benutzerdefinierter Skripts](console-custom-created.md). Sie können ein Skript in der AWS Glue-Konsole bearbeiten. Wenn Sie ein Skript bearbeiten, können Sie Quellen, Ziele und Transformationen hinzufügen. **So bearbeiten Sie ein Skript** 1. Melden Sie sich bei an AWS-Managementkonsole und öffnen Sie die AWS Glue Konsole unter [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/). Wählen Sie anschließend die Registerkarte **Jobs** (Aufträge) aus. 1. Wählen Sie einen Auftrag in der Liste aus, und wählen Sie dann **Action** (Aktion), **Edit script** (Skript bearbeiten) aus, um den Skript-Editor zu öffnen. Sie können den Skript-Editor auch von der Auftrags-Detailseite aus aufrufen. Wählen Sie die Registerkarte **Script** (Skript) und anschließend **Edit script** (Skript bearbeiten) aus. ## Skript-Editor Mit dem Skript-Editor von AWS Glue können Sie Quellen, Ziele und Transformationen in Ihr Skript einfügen, ändern und löschen. Der Skript-Editor zeigt sowohl das Skript als auch ein Diagramm an, um Ihnen die Visualisierung des Datenflusses zu erleichtern. Um ein Diagramm für das Skript zu erstellen, wählen Sie **Generate diagram (Diagramm generieren)** aus. AWS Glue verwendet Kommentarzeilen im Skript, die mit **\$1\$1** beginnen, um das Diagramm zu rendern. Um Ihr Skript im Diagramm korrekt darzustellen, müssen Sie die Parameter in den Kommentaren und die Parameter im Apache-Spark-Code synchron halten. Mit dem Skript-Editor können Sie dort Code-Vorlagen hinzufügen, wo sich der Cursor im Skript befindet. Wählen Sie im oberen Bereich des Editors eine der folgenden Optionen aus: + Um dem Skript eine Quelltabelle hinzuzufügen, wählen Sie **Source** (Quelle) aus. + Um dem Skript eine Zieltabelle hinzuzufügen, wählen Sie **Target** (Ziel) aus. + Um dem Skript einen Zielort hinzuzufügen, wählen Sie **Target location** (Zielort) aus. + Um dem Skript eine Transformation hinzuzufügen, wählen Sie **Transform** (Transformieren) aus. Weitere Informationen über die Funktionen, die in Ihrem Skript aufgerufen werden, finden Sie unter [Programmieren AWS Sie Glue ETL-Skripte in PySpark](aws-glue-programming-python.md). + Um dem Skript eine Spigot-Transformation hinzuzufügen, wählen Sie **Spigot** aus. Ändern Sie im eingefügten Code die `parameters` sowohl in den Kommentaren als auch im Apache-Spark-Code. Wenn Sie z. B. eine **Spigot**-Transformation hinzufügen, vergewissern Sie sich, dass der `path` sowohl in der `@args` Kommentarzeile als auch in der `output` Codezeile ersetzt wird. Auf der Registerkarte **Logs** (Protokolle) werden die Protokolle angezeigt, die Ihrem Auftrag zugeordnet sind, während er ausgeführt wird. Es werden die letzten 1.000 Zeilen angezeigt. Auf der Registerkarte **Schema** wird das Schema der ausgewählten Quellen und Ziele angezeigt, sofern es in Data Catalog verfügbar ist. # Verfolgen von verarbeiteten Daten mit Auftragslesezeichen AWS Glue verfolgt Daten, die bereits während einer früheren Ausführung eines ETL-Auftrags verarbeitet wurden, indem Zustandsinformationen aus der Auftragsausführung persistiert werden. Diese persistierende Zustandsinformation wird als *Auftrags-Lesezeichen* bezeichnet. Auftragslesezeichen helfen AWS Glue bei der Pflege von Zustandsinformationen und verhindern die Wiederaufbereitung alter Daten. Mit Auftragslesezeichen können Sie neue Daten verarbeiten, wenn sie in einem geplanten Intervall erneut ausgeführt werden. Ein Aufgabenlesezeichen besteht aus den Zuständen für verschiedene Elemente von Aufgaben wie Quellen, Transformationen und Zielen. Beispielsweise könnte Ihr ETL-Auftrag neue Partitionen in einer Amazon-S3-Datei lesen. AWS Glue verfolgt, welche Partitionen der Auftrag erfolgreich verarbeitet hat, um die doppelte Verarbeitung und doppelte Daten im Zieldatenspeicher des Auftrags zu verhindern. Aufgabenlesezeichen werden für JDBC-Datenquellen, die Relationalize-Transformation und einige Amazon Simple Storage Service (Amazon S3)-Quellen implementiert. In der folgenden Tabelle sind die Amazon-S3-Quellformate aufgeführt, die AWS Glue für Auftragslesezeichen unterstützt. | AWS Glue-Version | Quellformate für Amazon S3 | | --- | --- | | Version 0.9 | JSON, CSV, Apache Avro, XML | | Version 1.0 und höher | JSON, CSV, Apache Avro, XML, Parquet, ORC | Informationen zu den AWS Glue-Versionen erhalten Sie unter [Definieren von Auftragseigenschaften für Spark-Aufträge](add-job.md#create-job). Die Funktion Job-Lesezeichen bietet zusätzliche Funktionen, wenn sie über AWS Glue Skripts aufgerufen wird. Wenn Sie Ihr generiertes Skript durchsuchen, finden Sie möglicherweise Transformationskontexte, die sich auf dieses Feature beziehen. Weitere Informationen finden Sie unter [Verwenden von Auftragslesezeichen](programming-etl-connect-bookmarks.md). **Topics** + [Verwenden von Auftragslesezeichen in AWS Glue](#monitor-continuations-implement) + [Operative Details des Features Auftragslesezeichen](#monitor-continuations-script) ## Verwenden von Auftragslesezeichen in AWS Glue Beim Start der Aufgabe wird die Aufgabenlesezeichenoption als Parameter übergeben. In der folgenden Tabelle werden die Optionen zum Einrichten von Aufgabenlesezeichen in der AWS Glue-Konsole beschrieben. **** | Job-Lesezeichen | Description | | --- | --- | | Aktivieren | Veranlasst den Auftrag, den Status nach einer Ausführung zu aktualisieren, um die zuvor verarbeiteten Daten zu verfolgen. Wenn Ihr Auftrag eine Quelle mit Unterstützung für Auftragslesezeichen hat, verfolgt er die verarbeiteten Daten, und wenn ein Auftrag ausgeführt wird, verarbeitet er neue Daten seit dem letzten Kontrollpunkt. | | Deaktivieren | Auftragslesezeichen werden nicht verwendet, und der Auftrag verarbeitet immer den gesamten Datensatz. Sie sind für die Verwaltung der Ergebnisse früherer Auftragsausführungen verantwortlich. Dies ist die Standardeinstellung. | | Pause | Verarbeiten Sie inkrementelle Daten seit der letzten erfolgreichen Ausführung oder die Daten in dem durch die folgenden Unteroptionen identifizierten Bereich, ohne den Status des letzten Lesezeichens zu aktualisieren. Sie sind für die Verwaltung der Ausgabe früherer Auftragsausführungen verantwortlich. Die beiden Unteroptionen sind: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitor-continuations.html) Der Auftrags-Lesezeichenstatus wird nicht aktualisiert, wenn dieser Optionssatz angegeben wird. Die Unteroptionen sind optional, aber wenn sie verwendet werden, müssen beide Unteroptionen bereitgestellt werden. | Weitere Details zu den Parametern, die an Aufgaben in der Befehlszeile übergeben werden, und insbesondere zu Aufgabenlesezeichen finden Sie unter [Verwenden von Auftragsparametern in AWS Glue-Jobs](aws-glue-programming-etl-glue-arguments.md). Für Amazon-S3-Eingabequellen überprüfen AWS Glue-Auftragslesezeichen den Zeitpunkt der letzten Änderung der Objekte, um zu überprüfen, welche Objekte erneut verarbeitet werden müssen. Wenn Ihre Eingabedaten seit der letzten Auftragsausführung geändert wurden, werden die Dateien bei der erneuten Ausführung des Auftrags erneut verarbeitet. Für JDBC-Quellen gelten die folgenden Regeln: + Für jede Tabelle verwendet AWS Glue eine oder mehrere Spalten als Lesezeichenschlüssel, um neue und verarbeitete Daten zu bestimmen. Die Lesezeichentasten bilden zusammen einen einzigen zusammengesetzten Schlüssel. + AWS Glue verwendet standardmäßig den Primärschlüssel als Lesezeichenschlüssel, vorausgesetzt, dass er sequentiell erhöht oder verringert wird (ohne Lücken). + Sie können die Spalten angeben, die als Lesezeichenschlüssel in Ihrem AWS Glue Skript verwendet werden sollen. Weitere Hinweise zur Verwendung von Job-Lesezeichen in AWS Glue Skripten finden Sie unter[Verwenden von Auftragslesezeichen](programming-etl-connect-bookmarks.md). + AWS Glue unterstützt nicht die Verwendung von Spalten mit Namen, bei denen die Groß- und Kleinschreibung beachtet wird, als Auftragslesezeichenschlüssel. Ab sofort können Sie Ihre Auftragslesezeichen für Ihre AWS Glue-Spark-ETL-Aufträge zu jeder beliebigen vorherigen Auftragsausführung zurückspulen. Mit der Funktion werden Datenauffüllszenarien vereinfacht. Sie können Auftragslesezeichen zu jeder beliebigen früheren Auftragsausführung zurückspulen, was dazu führt, dass in der nachfolgenden Auftragsausführung nur die Daten aus der mit Lesezeichen versehenen Auftragsausführung erneut verarbeitet werden. Wenn Sie beabsichtigen, alle Daten mit demselben Auftrag erneut zu verarbeiten, setzen Sie das Auftragslesezeichen zurück. Um den Status des Auftragslesezeichens zurückzusetzen, verwenden Sie die AWS Glue-Konsole, die API-Operation [ResetJobBookmark Aktion (Python: reset\$1job\$1bookmark)](aws-glue-api-jobs-runs.md#aws-glue-api-jobs-runs-ResetJobBookmark) oder die AWS CLI. Geben Sie z. B. den folgenden Befehl mit der AWS CLI ein: ``` aws glue reset-job-bookmark --job-name my-job-name ``` Wenn Sie ein Lesezeichen zurückspulen oder zurücksetzen, bereinigt AWS Glue die Zieldateien nicht, da mehrere Ziele vorhanden sind und Ziele nicht mit Auftragslesezeichen verfolgt werden können. Nur Quelldateien werden mit Auftragslesezeichen verfolgt. Beim Zurückspulen und erneuten Verarbeiten der Quelldateien können Sie verschiedene Ausgabeziele erstellen, um doppelte Daten in der Ausgabe zu vermeiden. AWS Glue verfolgt die Auftrags-Lesezeichen nach Auftrag. Wenn Sie einen Auftrag löschen, wird das Auftrags-Lesezeichen gelöscht. In einigen Fällen haben Sie möglicherweise AWS Glue-Auftragslesezeichen aktiviert, aber Ihr ETL-Auftrag verarbeitet Daten, die bereits in einem früheren Lauf verarbeitet wurden. Informationen zur Behebung häufiger Ursachen für diesen Fehler finden Sie unter [Behebung häufiger Einrichtungsfehler bei Glue](glue-troubleshooting-errors.md). ## Operative Details des Features Auftragslesezeichen Dieser Abschnitt beschreibt weitere operative Details zur Verwendung von Auftragslesezeichen. Auftragslesezeichen speichern die Zustände für einen Auftrag. Jede Instance des Status wird durch einen Auftragsnamen und eine Versionsnummer gekennzeichnet. Wenn ein Skript `job.init` aufruft, ruft es seinen Zustand ab und erhält immer die neueste Version. Innerhalb eines Zustands gibt es mehrere Zustandselemente, die für jede Quell-, Transformations- und Speicher-Instance im Skript spezifisch sind. Diese Zustandselemente werden durch einen Transformationskontext identifiziert, der an das entsprechende Element (Quelle, Transformation oder Speicher) im Skript angefügt ist. Die Zustandselemente werden atomar gespeichert, wenn `job.commit` aus dem Benutzerskript aufgerufen wird. Das Skript ruft den Auftragsnamen und die Steuerungsoption für die Auftragslesezeichen aus den Argumenten ab. Die Zustandselemente im Auftragslesezeichen sind quell-, transformations- oder speicherspezifische Daten. Angenommen, Sie möchten beispielsweise inkrementelle Daten aus einem Amazon-S3-Speicherort, an den ständig von einem vorgelagerten Auftrag oder Prozess geschrieben wird, lesen. In diesem Fall muss das Skript feststellen, was bisher verarbeitet wurde. Die Implementierung des Auftragslesezeichens für die Amazon-S3-Quelle speichert Informationen, so dass der Auftrag beim erneuten Ausführen nur die neuen Objekte anhand der gespeicherten Informationen filtern und den Status für den nächsten Durchlauf des Auftrags neu berechnen muss. Ein Zeitstempel wird verwendet, um die neuen Dateien zu filtern. Zusätzlich zu den Zustandselementen haben Auftragslesezeichen eine *Laufnummer*, eine *Versuchsnummer* und eine *Versionsnummer*. Die Laufnummer verfolgt den Lauf des Auftrags, und die Versuchsnummer zeichnet die Versuche für einen Auftragslauf auf. Die Auftragslaufnummer ist eine monoton steigende Zahl, die bei jedem erfolgreichen Lauf erhöht wird. Die Versuchsnummer verfolgt die Versuche für jeden Lauf und wird nur dann erhöht, wenn es nach einem fehlgeschlagenen Versuch einen Lauf gibt. Die Versionsnummer steigt monoton an und verfolgt die Updates eines Auftragslesezeichens. In der AWS Glue Servicedatenbank werden die Lesezeichenstatus für alle Transformationen zusammen als Schlüssel-Wert-Paare gespeichert: ``` { "job_name" : ..., "run_id": ..., "run_number": .., "attempt_number": ... "states": { "transformation_ctx1" : { bookmark_state1 }, "transformation_ctx2" : { bookmark_state2 } } } ``` **Best Practices** Im Folgenden finden Sie bewährte Methoden zur Nutzung von Auftragslesezeichen. + *Ändern Sie die Datenquelleneigenschaft nicht, wenn das Lesezeichen aktiviert ist*. Beispielsweise gibt es eine Datenquelle „datasource0“, die auf einen Eingabepfad A von Amazon S3 verweist, und der Auftrag hat aus einer Quelle gelesen, die mehrere Runden lang mit aktiviertem Lesezeichen ausgeführt wurde. Wenn Sie den Eingabepfad von datasource0 in Amazon S3-Pfad B ändern, ohne das zu ändern`transformation_ctx`, verwendet der AWS Glue Job den alten gespeicherten Lesezeichenstatus. Dies führt dazu, dass Dateien im Eingabepfad B fehlen oder übersprungen werden, da AWS Glue davon ausgegangen wird, dass diese Dateien in früheren Durchläufen verarbeitet wurden. + *Verwenden Sie eine Katalogtabelle mit Lesezeichen für eine bessere Partitionsverwaltung*. Lesezeichen funktionieren sowohl für Datenquellen aus dem Datenkatalog als auch aus Optionen. Es ist jedoch schwierig, remove/add neue Partitionen mit dem From Options Ansatz zu erstellen. Die Verwendung einer Katalogtabelle mit Crawlern kann eine bessere Automatisierung bieten, um die neu hinzugefügten [Partitionen](https://docs.aws.amazon.com/glue/latest/dg/tables-described.html#tables-partition) nachzuverfolgen, und gibt Ihnen die Flexibilität zur Auswahl bestimmter Partitionen mit einem [Pushdown-Prädikat](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-partitions.html). + *Verwenden Sie die [Dateiauflistung von AWS Glue für Amazon S3](https://aws.amazon.com/premiumsupport/knowledge-center/glue-oom-java-heap-space-error/) für große Datensätze*. Ein Lesezeichen listet alle Dateien unter jeder Eingabepartition auf und filtert sie. Wenn sich also zu viele Dateien unter einer einzelnen Partition befinden, kann das Lesezeichen den OOM-Fehler für den Treiber auslösen. Verwenden Sie den AWS Glue Amazon S3 S3-Datei-Lister, um zu vermeiden, dass alle Dateien im Speicher gleichzeitig aufgelistet werden. # Speichern von Spark-Shuffle-Daten Shuffling ist ein wichtiger Schritt in einem Spark-Job, wenn Daten zwischen Partitionen neu angeordnet werden. Dies ist erforderlich, da umfassende Transformationen wie `join`, ` groupByKey`, `reduceByKey` und `repartition` Informationen von anderen Partitionen benötigen, um die Verarbeitung abzuschließen. Spark sammelt die erforderlichen Daten von jeder Partition und kombiniert sie zu einer neuen Partition. Beim Mischen werden Daten auf die Festplatte geschrieben und über das Netzwerk übertragen. Infolgedessen ist der Shuffle-Vorgang an die lokale Festplattenkapazität gebunden. Spark gibt den Fehler `No space left on device` oder den Fehler ` MetadataFetchFailedException` aus, wenn auf dem Executor nicht genügend Speicherplatz übrig ist und keine Wiederherstellung vorliegt. **Anmerkung** AWS Glue Das Spark-Shuffle-Plugin mit Amazon S3 wird nur für AWS Glue ETL-Jobs unterstützt. **Lösung** Mit AWS Glue können Sie nun Amazon S3 zum Speichern von Spark-Shuffle-Daten verwenden. Amazon S3 ist ein Objektspeicherservice, der branchenführende Skalierbarkeit, Datenverfügbarkeit, Sicherheit und Leistung bietet. Diese Lösung teilt Rechenleistung und Speicher für Ihre Spark-Aufträge auf und bietet vollständige Elastizität und kostengünstigen Shuffle-Speicher, sodass Sie Ihre Shuffle-intensiven Workloads zuverlässig ausführen können. ![\[Spark workflow showing Map and Reduce stages using Amazon S3 for shuffle data storage.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/gs-s3-shuffle-diagram.png) Wir stellen ein neues Cloud-Shuffle-Speicher-Plugin für Apache Spark zur Verwendung von Amazon S3 vor. Sie können Amazon-S3-Shuffling aktivieren, um Ihre AWS Glue-Aufträge zuverlässig ohne Fehler auszuführen, wenn bekannt ist, dass sie durch die lokale Festplattenkapazität für große Shufflevorgänge gebunden sind. In einigen Fällen ist das Shuffling zu Amazon S3 geringfügig langsamer als die lokale Festplatte (oder EBS), wenn Sie eine große Anzahl kleiner Partitionen oder Shuffle-Dateien haben, die in Amazon S3 geschrieben wurden. ## Voraussetzungen für die Verwendung des Cloud-Shuffle-Speicher-Plugins Um das Cloud Shuffle Storage Plugin mit AWS Glue ETL-Jobs zu verwenden, benötigen Sie Folgendes: + Ein Amazon-S3-Bucket, der sich in der gleichen Region befindet, in der Ihr Auftrag ausgeführt wird, um die Shuffle- und Ausgabedaten zwischenzuspeichern. Das Amazon-S3-Präfix des Shuffle-Speichers kann wie im folgenden Beispiel mit `--conf spark.shuffle.glue.s3ShuffleBucket=s3://shuffle-bucket/prefix/` angegeben werden: ``` --conf spark.shuffle.glue.s3ShuffleBucket=s3://glue-shuffle-123456789-us-east-1/glue-shuffle-data/ ``` + Legen Sie die Lebenszyklusrichtlinien für den Amazon-S3-Speicher auf das *Präfix* fest (z. B. `glue-shuffle-data`), da der Shuffle-Manager die Dateien nach Abschluss der Aufgabe nicht bereinigt. Die dazwischen liegenden Shuffle- und Ausgabedaten sollten nach Beendigung eines Auftrags gelöscht werden. Benutzer können Richtlinien für einen kurzen Lebenszyklus für das Präfix festlegen. Anweisungen zum Einrichten einer Amazon-S3-Lebenszyklusrichtlinie finden Sie unter [Lebenszykluskonfiguration für einen Bucket festlegen](https://docs.aws.amazon.com//AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html) im Benutzerhandbuch für Amazon Simple Storage Service. ## AWS GlueSpark Shuffle Manager von der Konsole aus verwenden AWS Um den AWS Glue Spark-Shuffle-Manager bei der Konfiguration eines Jobs über die AWS Glue Konsole oder AWS Glue Studio einzurichten: Wählen Sie den Job-Parameter **-- write-shuffle-files-to -s3, um Amazon S3 S3-Shuffling** für den Job zu aktivieren. ![\[Job parameters interface showing --write-shuffle-files- parameter and option to add more.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/gs-s3-shuffle.png) ## Verwendung des AWS Glue-Spark-Shuffle-Plugins Die folgenden Auftragsparameter aktivieren und optimieren die AWS Glue-Shuffle-Manager. Da es sich bei diesen Parametern um Flags handelt, werden die angegebenen Werte nicht berücksichtigt. + `--write-shuffle-files-to-s3` – Der wichtigste Flag, der den AWS Glue-Spark-Shuffle-Manager aktiviert, um Amazon-S3-Buckets zum Schreiben und Lesen von Shuffle-Daten zu verwenden. Wenn das Flag nicht angegeben ist, wird der Shuffle-Manager nicht verwendet. + `--write-shuffle-spills-to-s3` – (Nur von AWS Glue-Version 2.0 unterstützt). Ein optionales Flag, mit dem Sie Ausgabeateien in Amazon-S3-Buckets auslagern können, was zusätzliche Ausfallsicherheit für Ihren Spark-Auftrag bereitstellt. Das ist nur bei großen Workloads erforderlich, bei denen viele Daten unabsichtlich auf der Festplatte landen. Wenn das Flag nicht angegeben ist, werden keine Ausgabe-Zwischendateien geschrieben. + ` --conf spark.shuffle.glue.s3ShuffleBucket=s3://` – Ein weiterer optionaler Parameter, der den Amazon S3 Bucket angibt, in den Sie die Shuffle-Dateien schreiben. Standardmäßig /shuffle-data. `--TempDir` AWS Glue 3.0\$1 unterstützt das Schreiben von Shuffle-Dateien in mehrere Buckets, indem Buckets mit einem Kommatrennzeichen angegeben werden, wie in. `--conf spark.shuffle.glue.s3ShuffleBucket=s3://shuffle-bucket-1/prefix,s3://shuffle-bucket-2/prefix/` Die Verwendung mehrerer Buckets verbessert die Leistung. Sie müssen Sicherheitskonfigurationseinstellungen vornehmen, um die Verschlüsselung im Ruhezustand für die Shuffle-Daten zu aktivieren. Weitere Informationen zu Sicherheitskonfigurationen finden Sie unter[Einrichten der Verschlüsselung in AWS Glue](set-up-encryption.md). AWS Glue unterstützt alle anderen Shuffle-bezogenen Konfigurationen, die von Spark bereitgestellt werden. **Software-Binärdateien für das Cloud-Shuffle-Speicher-Plugin** Sie können auch die Software-Binärdateien des Cloud-Shuffle-Speicher-Plugins für Apache Spark unter der Apache-2.0-Lizenz herunterladen und in jeder Spark-Umgebung ausführen. Das neue Plugin bietet out-of-the Box-Unterstützung für Amazon S3 und kann auch einfach für die Verwendung anderer Formen von Cloud-Speicher wie [Google Cloud Storage und Microsoft Azure Blob Storage](https://github.com/aws-samples/aws-glue-samples/blob/master/docs/cloud-shuffle-plugin/README.md) konfiguriert werden. Weitere Informationen finden Sie unter [Cloud-Shuffle-Speicher-Plugin für Apache Spark](https://docs.aws.amazon.com/glue/latest/dg/cloud-shuffle-storage-plugin.html). **Hinweise und Einschränkungen** Im Folgenden finden Sie Hinweise oder Einschränkungen für den AWS Glue-Shuffle-Manager: + AWS Glue Shuffle Manager löscht die (temporären) Shuffle-Datendateien, die in Ihrem Amazon S3 S3-Bucket gespeichert sind, nicht automatisch, nachdem ein Job abgeschlossen ist. Befolgen Sie zur Gewährleistung des Datenschutzes die Anweisungen in [Voraussetzungen für die Verwendung des Cloud-Shuffle-Speicher-Plugins](#monitor-spark-shuffle-manager-prereqs), bevor Sie das Cloud-Shuffle-Speicher-Plugin aktivieren. + Sie können dieses Feature verwenden, wenn Ihre Daten verzerrt sind. # Cloud-Shuffle-Speicher-Plugin für Apache Spark Das Cloud-Shuffle-Speicher-Plugin ist ein mit der [`ShuffleDataIO`-API](https://github.com/apache/spark/blob/master/core/src/main/java/org/apache/spark/shuffle/api/ShuffleDataIO.java) kompatibles Apache-Spark-Plugin, das das Speichern von Shuffle-Daten auf Cloud-Speichersystemen (wie Amazon S3) ermöglicht. Es hilft Ihnen, die lokale Festplattenspeicherkapazität für große Shuffle-Operationen, die häufig durch Transformationen wie, `groupByKey` und `repartition` in Ihren Spark-Anwendungen ausgelöst werden `join``reduceByKey`, zu ergänzen oder zu ersetzen, wodurch häufige Ausfälle oder price/performance Störungen Ihrer serverlosen Datenanalysejobs und Pipelines reduziert werden. **AWS Glue** In den AWS Glue-Versionen 3.0 und 4.0 ist das Plugin bereits vorinstalliert und ermöglichen das Shuffling zu Amazon S3 ohne zusätzliche Schritte. Weitere Informationen finden Sie unter [AWS Glue-Spark-Shuffle-Plugin mit Amazon S3](https://docs.aws.amazon.com/glue/latest/dg/monitor-spark-shuffle-manager.html) zur Aktivierung des Features für Ihre Spark-Anwendungen. **Andere Spark-Umgebungen** Für das Plugin müssen die folgenden Spark-Konfigurationen in anderen Spark-Umgebungen festgelegt werden: + `--conf spark.shuffle.sort.io.plugin.class=com.amazonaws.spark.shuffle.io.cloud.ChopperPlugin`: Dies informiert Spark, dieses Plugin für Shuffle IO zu verwenden. + `--conf spark.shuffle.storage.path=s3://bucket-name/shuffle-file-dir`: Der Pfad, in dem Ihre Shuffle-Dateien gespeichert werden. **Anmerkung** Das Plugin überschreibt eine Spark-Kernklasse. Daher muss das Plugin-Jar vor den Spark-Jars geladen werden. Sie können dies mit `userClassPathFirst` in On-Premises-YARN-Umgebungen tun, wenn das Plugin außerhalb von AWS Glue verwendet wird. ## Bündeln des Plugins mit Ihren Spark-Anwendungen Sie können das Plugin mit Ihren Spark-Anwendungen und Spark-Verteilungen (Versionen 3.1 und höher) bündeln, indem Sie die Plugin-Abhängigkeit in Ihrem Maven `pom.xml` hinzufügen, während Sie Ihre Spark-Anwendungen lokal entwickeln. Weitere Informationen zu den Plugin- und Spark-Versionen finden Sie unter [Plugin-Versionen](#cloud-shuffle-storage-plugin-versions). ``` ... aws-glue-etl-artifacts https://aws-glue-etl-artifacts.s3.amazonaws.com/release/ ... com.amazonaws chopper-plugin 3.1-amzn-LATEST ``` Sie können die Binärdateien alternativ direkt von AWS Glue Maven-Artefakten herunterladen und sie wie folgt in Ihre Spark-Anwendung integrieren. ``` #!/bin/bash sudo wget -v https://aws-glue-etl-artifacts.s3.amazonaws.com/release/com/amazonaws/chopper-plugin/3.1-amzn-LATEST/chopper-plugin-3.1-amzn-LATEST.jar -P /usr/lib/spark/jars/ ``` Beispiel spark-submit ``` spark-submit --deploy-mode cluster \ --conf spark.shuffle.storage.s3.path=s3:/// \ --conf spark.driver.extraClassPath= \ --conf spark.executor.extraClassPath= \ --class s3:/// \ ``` ## Optionale Konfigurationen Dies sind optionale Konfigurationswerte, die das Amazon-S3-Zufallsverhalten steuern. + `spark.shuffle.storage.s3.enableServerSideEncryption`: Enable/disable S3 SSE für Shuffle- und Spill-Dateien. Der Standardwert ist `true`. + `spark.shuffle.storage.s3.serverSideEncryption.algorithm`: Der zu verwendende SSE-Algorithmus. Der Standardwert ist `AES256`. + `spark.shuffle.storage.s3.serverSideEncryption.kms.key`: Der KMS-Schlüssel-ARN, wenn SSE aws:kms aktiviert ist. Neben diesen Konfigurationen müssen Sie möglicherweise Konfigurationen wie `spark.hadoop.fs.s3.enableServerSideEncryption` und **andere umgebungsspezifische Konfigurationen** festlegen, um sicherzustellen, dass die für Ihren Anwendungsfall geeignete Verschlüsselung angewendet wird. ## Plugin-Versionen Dieses Plugin wird für die Spark-Versionen unterstützt, die jeder AWS Glue Version zugeordnet sind. Die folgende Tabelle zeigt die AWS Glue Version, Spark-Version und die zugehörige Plugin-Version mit Amazon S3 S3-Speicherort für die Software-Binärdatei des Plugins. | AWS Glue-Version | Spark-Version | Plugin-Version | Amazon-S3-Speicherort | | --- | --- | --- | --- | | 3.0 | 3.1 | 3.1-amzn-LATEST | s3://aws-glue-etl-artifacts/release/com/amazonaws/chopper-plugin/3.1-amzn-0/chopper-Plugin-3.1-amzn-latest.jar | | 4,0 | 3.3 | 3.3-amzn-LATEST | s3://aws-glue-etl-artifacts/release/com/amazonaws/chopper-plugin/3.3-amzn-0/chopper-plugin-3.3-amzn-neuest.jar | ## License Die Software-Binärdatei für dieses Plugin ist unter der Apache-2.0-Lizenz lizenziert. # Überwachung von AWS Glue-Spark-Aufträgen **Topics** + [Spark-Metriken verfügbar in AWS Glue Studio](#console-jobs-details-metrics-spark) + [Überwachen von Aufgaben über die Apache-Spark-Webbenutzeroberfläche](monitor-spark-ui.md) + [Überwachung mit Einblicken in die AWS Glue Auftragsausführung](monitor-job-insights.md) + [Überwachung mit Amazon CloudWatch](monitor-cloudwatch.md) + [Auftragsüberwachung und Debugging](monitor-profile-glue-job-cloudwatch-metrics.md) ## Spark-Metriken verfügbar in AWS Glue Studio Die Registerkarte **Metrics (Metriken)** zeigt Metriken, die erfasst werden, wenn ein Auftrag ausgeführt wird und das Profiling aktiviert ist. Die folgenden Diagramme werden in Spark-Aufträgen angezeigt: + ETL-Datenbewegung + Speicherprofil: Treiber und Executors Wählen Sie **View additional metrics (Weitere Metriken anzeigen)**, um die folgenden Graphen anzuzeigen: + ETL-Datenbewegung + Speicherprofil: Treiber und Executors + Datenmischung über Executors hinweg + CPU-Auslastung: Treiber und Executors + Auftragsausführung: Aktive Executors, Abgeschlossen Phasen und maximal benötigte Executors Die Daten für diese Diagramme werden in CloudWatch Metriken übertragen, wenn der Job für die Erfassung von Metriken konfiguriert ist. Weitere Informationen über das Aktivieren von Metriken und die Interpretation der Graphen finden Sie unter [Auftragsüberwachung und Debugging](monitor-profile-glue-job-cloudwatch-metrics.md). **Example Der Graph für die ETL-Datenbewegung** Der Graph für die ETL-Datenbewegung zeigt die folgenden Metriken: + Die Anzahl der von allen Executors von Amazon S3 gelesenen Bytes – [`glue.ALL.s3.filesystem.read_bytes`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) + Die Anzahl der von allen Executors in Amazon S3 geschriebenen Bytes – [`glue.ALL.s3.filesystem.write_bytes`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) ![\[Der Graph für die ETL-Datenbewegung auf der Registerkarte Metrics (Metriken) der AWS Glue-Konsole.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/job_detailed_etl.png) **Example Der Graph für das Speicherprofil** Der Graph für das Speicherprofil zeigt die folgenden Metriken: + Der vom JVM-Heap für diesen Treiber (Skalierung: 0-1) verwendete Speicheranteil – vom Treiber, einem durch *executorId* identifizierten Executor oder allen Executors – + [`glue.driver.jvm.heap.usage`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.jvm.heap.usage) + [`glue.executorId.jvm.heap.usage`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.usage) + [`glue.ALL.jvm.heap.usage`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) ![\[Der Graph für das Speicherprofil auf der Registerkarte Metrics (Metriken) der AWS Glue-Konsole.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/job_detailed_mem.png) **Example Der Graph für die Datenmischung über Executors hinweg** Der Graph für das Mischen der Daten über alle Executors hinweg zeigt die folgenden Metriken: + Die Zahl der von allen Executors gelesenen Bytes, um ihre Daten zu mischen - [`glue.driver.aggregate.shuffleLocalBytesRead`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleLocalBytesRead) + Die Zahl der von allen Executors geschriebenen Bytes, um ihre Daten zu mischen - [`glue.driver.aggregate.shuffleBytesWritten`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleBytesWritten) ![\[Der Graph für die Datenmischung über Executors hinweg auf der Registerkarte Metrics (Metriken) der AWS Glue-Konsole.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/job_detailed_data.png) **Example Der Graph für die CPU-Auslastung** Der Graph für die CPU-Auslastung zeigt die folgenden Metriken: + Der vom Treiber verwendete Anteil der CPU-Systemauslastung (Skalierung: 0-1) – vom Treiber, einem durch *executorId* identifizierten Executor oder allen Executors – + [`glue.driver.system.cpuSystemLoad`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.system.cpuSystemLoad) + [`glue.executorId.system.cpuSystemLoad`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.system.cpuSystemLoad) + [`glue.ALL.system.cpuSystemLoad`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.system.cpuSystemLoad) ![\[Der Graph für die CPU-Auslastung auf der Registerkarte Metrics (Metriken) der AWS Glue-Konsole.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/job_detailed_cpu.png) **Example Der Graph für die Auftragsausführung** Der Graph für die Auftragsausführung zeigt die folgenden Metriken: + Die Anzahl der aktiven Executors - [`glue.driver.ExecutorAllocationManager.executors.numberAllExecutors`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors) + Die Anzahl der abgeschlossenen Phasen - [`glue.aggregate.numCompletedStages`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.numCompletedStages) + Die Anzahl maximal benötigter Executors - [`glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors`](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors) ![\[Der Graph für die Auftragsausführung auf der Registerkarte Metrics (Metriken) der AWS Glue-Konsole.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/job_detailed_exec.png) # Überwachen von Aufgaben über die Apache-Spark-Webbenutzeroberfläche Sie können die Apache-Spark-Webbenutzeroberfläche zum Überwachen und Debuggen von AWS Glue-ETL-Aufträgen verwenden, die auf dem AWS Glue-Aufgabensystem ausgeführt werden, und von Spark-Anwendungen, die auf AWS Glue-Entwicklungsendpunkten ausgeführt werden. Sie können in der Spark-Benutzeroberfläche folgende Punkte für die einzelnen Aufgaben überprüfen: + Ereignis-Zeitplan der einzelnen Spark-Phasen + Ausgerichtetes azyklisches Diagramm (Directed Acyclic Graph, DAG) der Aufgabe + Physische und logische Pläne für SparkSQL-Abfragen + Zugrunde liegende Spark-Umgebungsvariablen für die einzelnen Aufgaben Weitere Informationen zur Verwendung der Spark-Web-UI finden Sie unter [Web-UI](https://spark.apache.org/docs/3.3.0/web-ui.html) in der Spark-Dokumentation. Anleitungen dazu, wie Sie die Ergebnisse der Spark-Benutzeroberfläche interpretieren können, um die Leistung Ihres Jobs zu verbessern, finden Sie unter [Bewährte Methoden zur Leistungsoptimierung AWS Glue für Apache Spark-Jobs](https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-aws-glue-for-apache-spark/introduction.html) in AWS Prescriptive Guidance. Sie können die Spark-Benutzeroberfläche in der AWS Glue Konsole sehen. Dies ist verfügbar, wenn ein AWS Glue Job auf Versionen AWS Glue 3.0 oder höher ausgeführt wird, wobei die Logs im Standardformat (und nicht im Legacy-Format) generiert werden, was der Standard für neuere Jobs ist. Wenn Sie über Protokolldateien mit mehr als 0,5 GB verfügen, können Sie die Unterstützung für fortlaufende Protokolle für Auftragsausführungen in Versionen AWS Glue 4.0 oder höher aktivieren, um die Archivierung, Analyse und Problembehandlung von Protokollen zu vereinfachen. Sie können die Spark-Benutzeroberfläche mithilfe der AWS Glue Konsole oder der AWS Command Line Interface (AWS CLI) aktivieren. Wenn Sie die Spark-Benutzeroberfläche aktivieren, können AWS Glue-ETL-Aufträge und Spark-Anwendungen in AWS Glue-Entwicklungsendpunkten Spark-Ereignisprotokolle an einem Speicherort sichern, den Sie in Amazon Simple Storage Service (Amazon S3) angeben. Die so in Amazon S3 gesicherten Ereignisprotokolle können in der Spark-Benutzeroberfläche in Echtzeit während der Auftragsausführung und nach Abschluss des Auftrags verwendet werden. Die Protokolle verbleiben zwar in Amazon S3, können aber über die Spark-Benutzeroberfläche in der AWS Glue Konsole angezeigt werden. ## Berechtigungen Um die Spark-Benutzeroberfläche in der AWS Glue Konsole zu verwenden, können Sie alle einzelnen Dienste verwenden `UseGlueStudio` oder hinzufügen APIs. Alle APIs sind erforderlich, um die Spark-Benutzeroberfläche vollständig nutzen zu können. Benutzer können jedoch auf die Funktionen von SparkUI zugreifen, indem sie den Dienst APIs zu ihrer IAM-Berechtigung hinzufügen, um einen detaillierten Zugriff zu erhalten. `RequestLogParsing` ist am wichtigsten, weil damit das Parsen von Protokollen möglich ist. Die restlichen Daten APIs dienen zum Lesen der jeweiligen analysierten Daten. `GetStages` bietet beispielsweise Zugriff auf die Daten zu allen Phasen eines Spark-Auftrags. Die Liste der APIs zugewiesenen Spark-UI-Dienste finden `UseGlueStudio` Sie weiter unten in der Beispielrichtlinie. Die folgende Richtlinie gewährt nur Zugriff auf die Verwendung der Features der Spark-Benutzeroberfläche. Informationen zum Hinzufügen weiterer Berechtigungen wie Amazon S3 und IAM finden Sie unter [Erstellen benutzerdefinierter IAM-Richtlinien für](https://docs.aws.amazon.com/glue/latest/dg/getting-started-min-privs.html#getting-started-all-gs-privs.html). AWS Glue Studio Die Liste der APIs zugewiesenen Spark-UI-Services finden Sie weiter unten in der Beispielrichtlinie. `UseGlueStudio` Wenn Sie eine Spark-Benutzeroberfläche-Service-API verwenden, verwenden Sie den folgenden Namespace: `glue:`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowGlueStudioSparkUI", "Effect": "Allow", "Action": [ "glue:RequestLogParsing", "glue:GetLogParsingStatus", "glue:GetEnvironment", "glue:GetJobs", "glue:GetJob", "glue:GetStage", "glue:GetStages", "glue:GetStageFiles", "glue:BatchGetStageFiles", "glue:GetStageAttempt", "glue:GetStageAttemptTaskList", "glue:GetStageAttemptTaskSummary", "glue:GetExecutors", "glue:GetExecutorsThreads", "glue:GetStorage", "glue:GetStorageUnit", "glue:GetQueries", "glue:GetQuery" ], "Resource": [ "*" ] } ] } ``` ------ ## Einschränkungen + Die Spark-Benutzeroberfläche in der AWS Glue Konsole ist für Jobausführungen, die vor dem 20. November 2023 stattfanden, nicht verfügbar, da sie im alten Protokollformat vorliegen. + Die Spark-Benutzeroberfläche in der AWS Glue Konsole unterstützt fortlaufende Logs für AWS Glue 4.0, wie sie beispielsweise standardmäßig bei Streaming-Jobs generiert werden. Die maximale Summe aller generierten Ereignisdateien für fortlaufende Protokolle beträgt 2 GB. Für AWS Glue Jobs ohne Unterstützung für Rolling-Logs beträgt die maximale Größe der Protokollereignisdatei, die für SparkUI unterstützt wird, 0,5 GB. + Die Serverless-Spark-Benutzeroberfläche ist nicht für Spark-Ereignisprotokolle verfügbar, die in einem Amazon-S3-Bucket gespeichert sind und auf die nur Ihre VPC zugreifen kann. ## Beispiel: Web-UI von Apache Spark In diesem Beispiel wird veranschaulicht, wie Sie die Spark-Benutzeroberfläche verwenden, um Ihre Auftragsleistung nachzuvollziehen. Die Screenshots zeigen die Spark-Weboberfläche, wie sie von einem selbstverwalteten Spark History-Server bereitgestellt wird. Die Spark-Benutzeroberfläche in der AWS Glue Konsole bietet ähnliche Ansichten. Weitere Informationen zur Verwendung der Spark-Web-UI finden Sie unter [Web-UI](https://spark.apache.org/docs/3.3.0/web-ui.html) in der Spark-Dokumentation. Im Folgenden finden Sie ein Beispiel für eine Spark-Anwendung, die aus zwei Datenquellen liest, eine Join-Transformation ausführt und diese im Parquet-Format zu Amazon S3 schreibt. ``` import sys from awsglue.transforms import * from awsglue.utils import getResolvedOptions from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job from pyspark.sql.functions import count, when, expr, col, sum, isnull from pyspark.sql.functions import countDistinct from awsglue.dynamicframe import DynamicFrame args = getResolvedOptions(sys.argv, ['JOB_NAME']) sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session job = Job(glueContext) job.init(args['JOB_NAME']) df_persons = spark.read.json("s3://awsglue-datasets/examples/us-legislators/all/persons.json") df_memberships = spark.read.json("s3://awsglue-datasets/examples/us-legislators/all/memberships.json") df_joined = df_persons.join(df_memberships, df_persons.id == df_memberships.person_id, 'fullouter') df_joined.write.parquet("s3://aws-glue-demo-sparkui/output/") job.commit() ``` Die folgende DAG-Visualisierung zeigt die verschiedenen Phasen in dieser Spark-Aufgabe. ![\[Screenshot der Spark-Benutzeroberfläche mit 2 abgeschlossenen Phasen für Aufgabe 0.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/spark-ui1.png) Der folgende Ereigniszeitplan für eine Aufgabe zeigt Start, Ausführung und Beendigung verschiedener Spark-Executors. ![\[Screenshot der Spark-Benutzeroberfläche mit den abgeschlossenen, fehlgeschlagenen und aktiven Phasen verschiedener Spark-Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/spark-ui2.png) Der folgende Bildschirm zeigt die Details der SparkSQL-Abfragepläne: + Geparster logischer Plan + Analysierter logischer Plan + Optimierter logischer Plan + Physischer Plan für die Ausführung ![\[SparkSQL-Abfragepläne: geparster, analysierter und optimierter logischer Plan und physische Pläne für die Ausführung.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/spark-ui3.png) **Topics** + [Berechtigungen](#monitor-spark-ui-limitations-permissions) + [Einschränkungen](#monitor-spark-ui-limitations) + [Beispiel: Web-UI von Apache Spark](#monitor-spark-ui-limitations-example) + [Aktivieren der Apache-Spark-Webbenutzeroberfläche für AWS Glue-Aufgaben](monitor-spark-ui-jobs.md) + [Starten des Spark History-Servers](monitor-spark-ui-history.md) # Aktivieren der Apache-Spark-Webbenutzeroberfläche für AWS Glue-Aufgaben Sie können die Apache-Spark-Webbenutzeroberfläche verwenden, um AWS Glue-ETL-Aufgaben zu überwachen und zu debuggen, die im AWS Glue-Aufgabensystem ausgeführt werden. Sie können die Spark-Benutzeroberfläche über die AWS Glue-Konsole oder die AWS Command Line Interface (AWS CLI) konfigurieren. AWS Glue sichert die Spark-Ereignisprotokolle alle 30 Sekunden zu dem von Ihnen angegebenen Amazon-S3-Pfad. **Topics** + [Konfigurieren der Spark-Benutzeroberfläche (Konsole)](#monitor-spark-ui-jobs-console) + [Konfigurieren der Spark-Benutzeroberfläche (AWS CLI)](#monitor-spark-ui-jobs-cli) + [Konfigurieren der Spark-Benutzeroberfläche für Sitzungen mit Notebooks](#monitor-spark-ui-sessions) + [Aktivieren fortlaufender Protokolle](#monitor-spark-ui-rolling-logs) ## Konfigurieren der Spark-Benutzeroberfläche (Konsole) Gehen Sie wie folgt vor, um die Spark-Benutzeroberfläche über die AWS-Managementkonsole zu konfigurieren. Beim Erstellen eines AWS Glue Jobs ist die Spark-Benutzeroberfläche standardmäßig aktiviert. **Die Spark-Benutzeroberfläche aktivieren, wenn Sie einen Auftrag erstellen oder bearbeiten** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Glue Konsole unter [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/). 1. Wählen Sie im Navigationsbereich die Option **Jobs (Aufträge)** aus. 1. Wählen **Auftrag hinzufügen** oder einen vorhandenen Auftrag aus. 1. Klicken Sie in den **Auftragsdetails** auf **Erweiterte Eigenschaften**. 1. Wählen Sie auf der Registerkarte **Spark-Benutzeroberfläche** die Option **Spark-UI-Protokolle in Amazon S3 schreiben** aus. 1. Geben Sie einen Amazon-S3-Pfad zum Speichern der Spark-Ereignisprotokolle für die Aufgabe an. Beachten Sie, dass die Verschlüsselung auch auf die Protokolldatei der Spark-Benutzeroberfläche angewendet wird, wenn Sie im Auftrag eine Sicherheitskonfiguration verwenden. Weitere Informationen finden Sie unter [Verschlüsselung von Daten, die geschrieben wurden von AWS Glue](encryption-security-configuration.md). 1. Gehen Sie unter **Konfiguration der Protokollierung und Überwachung in der Spark-Benutzeroberfläche** wie folgt vor: + Wählen Sie **Standard** aus, wenn Sie Protokolle zur Anzeige in der AWS Glue Konsole generieren. + Wenn Sie Protokolle zur Anzeige auf einem Spark History-Server generieren, wählen Sie **Legacy** aus. + Sie können auch beide Protokolltypen generieren. ## Konfigurieren der Spark-Benutzeroberfläche (AWS CLI) Um Protokolle für die Anzeige mit der Spark-Benutzeroberfläche zu generieren, verwenden Sie in der AWS Glue Konsole die, AWS CLI um die folgenden Job-Parameter an AWS Glue Jobs zu übergeben. Weitere Informationen finden Sie unter [Verwenden von Auftragsparametern in AWS Glue-Jobs](aws-glue-programming-etl-glue-arguments.md). ``` '--enable-spark-ui': 'true', '--spark-event-logs-path': 's3://s3-event-log-path' ``` Um Protokolle an ihre Legacy-Speicherorte zu verteilen, setzen Sie den Parameter `--enable-spark-ui-legacy-path` auf `"true"`. Wenn Sie keine Protokolle in den beiden Formaten generieren möchten, entfernen Sie den Parameter `--enable-spark-ui`. ## Konfigurieren der Spark-Benutzeroberfläche für Sitzungen mit Notebooks **Warnung** AWS Glue interaktive Sitzungen unterstützen derzeit keine Spark-Benutzeroberfläche in der Konsole. Konfigurieren Sie einen Spark History-Server. Wenn Sie AWS Glue Notebooks verwenden, richten Sie die SparkUI-Konfiguration ein, bevor Sie die Sitzung starten. Verwenden Sie dazu das `%%configure`-Zellen-Magic: ``` %%configure { “--enable-spark-ui”: “true”, “--spark-event-logs-path”: “s3://path” } ``` ## Aktivieren fortlaufender Protokolle Die Aktivierung von SparkUI und das Rolling von Log-Ereignisdateien für AWS Glue Jobs bietet mehrere Vorteile: + Rolling Log Event Files — Wenn die rollierenden Log-Ereignisdateien aktiviert sind, werden separate Protokolldateien für jeden Schritt der Jobausführung AWS Glue generiert, sodass Probleme, die für eine bestimmte Phase oder Transformation spezifisch sind, leichter identifiziert und behoben werden können. + Bessere Protokollverwaltung – Ereignisdateien fortlaufender Protokolle helfen dabei, Protokolldateien effizienter zu verwalten. Anstatt eine einzige, potenziell große Protokolldatei zu haben, werden die Protokolle je nach den Phasen der Auftragsausführung in kleinere, besser verwaltbare Dateien aufgeteilt. Dies kann die Archivierung, Analyse und Problembehandlung von Protokollen vereinfachen. + Verbesserte Fehlertoleranz — Wenn ein AWS Glue Job fehlschlägt oder unterbrochen wird, können die Rolling-Log-Ereignisdateien wertvolle Informationen über die letzte erfolgreiche Phase liefern, sodass es einfacher ist, den Job an diesem Punkt fortzusetzen, anstatt von vorne zu beginnen. + Kostenoptimierung – Durch die Aktivierung von Ereignisdateien fortlaufender Protokolle können Sie die mit Protokolldateien verbundenen Speicherkosten verringern. Statt einer einzelnen, potenziell großen Protokolldatei werden kleinere, besser verwaltbare Protokolldateien gespeichert, was insbesondere bei lang andauernden oder komplexen Aufträgen kostengünstiger sein kann. In einer neuen Umgebung können Benutzer fortlaufende Protokolle explizit wie folgt aktivieren: ``` '—conf': 'spark.eventLog.rolling.enabled=true' ``` oder ``` '—conf': 'spark.eventLog.rolling.enabled=true —conf spark.eventLog.rolling.maxFileSize=128m' ``` Wenn fortlaufende Protokolle aktiviert sind, gibt `spark.eventLog.rolling.maxFileSize` die maximale Größe der Ereignisprotokolldatei an, bevor ein Roll-Over ausgeführt wird. Wenn der Standardwert für diesen optionalen Parameter nicht angegeben wird, wird der Standardwert 128 MB verwendet. Mindestens 10 MB. Die maximale Summe aller generierten Ereignisdateien für fortlaufende Protokolle beträgt 2 GB. Für AWS Glue Jobs ohne Rolling-Log-Unterstützung beträgt die maximale Größe der Protokollereignisdatei, die für SparkUI unterstützt wird, 0,5 GB. Sie können fortlaufende Protokolle für einen Streaming-Auftrag deaktivieren, indem Sie eine zusätzliche Konfiguration übergeben. Beachten Sie, dass die Pflege sehr großer Protokolldateien kostspielig sein kann. Um fortlaufende Protokolle zu deaktivieren, stellen Sie die folgende Konfiguration bereit: ``` '--spark-ui-event-logs-path': 'true', '--conf': 'spark.eventLog.rolling.enabled=false' ``` # Starten des Spark History-Servers Mit einem Spark History-Server können Sie die Spark-Protokolle in Ihrer eigenen Infrastruktur visualisieren. Sie können dieselben Visualisierungen in der AWS Glue Konsole für AWS Glue Jobausführungen auf Versionen AWS Glue 4.0 oder höher sehen, wobei die Logs im Standardformat (und nicht im Legacy-Format) generiert wurden. Weitere Informationen finden Sie unter [Überwachen von Aufgaben über die Apache-Spark-Webbenutzeroberfläche](monitor-spark-ui.md). Sie können den Spark-Verlaufsserver mithilfe einer AWS CloudFormation Vorlage starten, die den Server auf einer EC2-Instance hostet, oder lokal mit Docker starten. **Topics** + [Den Spark-History-Server starten und die Spark-Benutzeroberfläche anzeigen mit AWS CloudFormation](#monitor-spark-ui-history-cfn) + [Starten des Spark History-Servers und Anzeigen der Spark-Benutzeroberfläche über Docker](#monitor-spark-ui-history-local) ## Den Spark-History-Server starten und die Spark-Benutzeroberfläche anzeigen mit AWS CloudFormation Sie können eine AWS CloudFormation Vorlage verwenden, um den Apache Spark-History-Server zu starten und die Spark-Weboberfläche anzuzeigen. Diese Vorlagen sind Beispiele, die Sie entsprechend Ihren Anforderungen anpassen sollten. **Um den Spark-Geschichtsserver zu starten und die Spark-Benutzeroberfläche anzuzeigen, verwenden Sie CloudFormation** 1. Wählen Sie eine der Schaltflächen **Launch Stack (Stack starten)** in der folgenden Tabelle aus. Dadurch wird der Stack auf der CloudFormation Konsole gestartet. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitor-spark-ui-history.html) 1. Wählen Sie auf der Seite **Specify template (Vorlage angeben)** die Option **Next (Weiter)** aus. 1. Geben Sie auf der Seite **Specify stack details (Stack-Details angeben)** den Wert für **Stack name (Stack-Name)** ein. Geben Sie zusätzliche Informationen unter **Parameter** ein. 1. **Konfiguration der Spark-Benutzeroberfläche** Geben Sie die folgenden Informationen ein: + **IP-Adressbereich** – Der IP-Adressbereich, der zum Anzeigen der Spark-Benutzeroberfläche verwendet werden kann. Wenn Sie den Zugriff in Bezug auf einen bestimmten IP-Adressbereich einschränken möchten, sollten Sie einen benutzerdefinierten Wert verwenden. + **History-Server-Port** – Der Port für die Spark-Benutzeroberfläche. Sie können den Standardwert verwenden. + **Ereignisprotokollverzeichnis** – Wählen Sie den Speicherort, an dem die Spark-Ereignisprotokolle gespeichert werden, aus den AWS Glue-Job- oder Entwicklungsendpunkten. Für das Pfadschema der Ereignisprotokolle müssen Sie **s3a://** verwenden. + **Spark-Package-Standort** – Sie können den Standardwert verwenden. + **Keystore-Pfad** — SSL/TLS Keystore-Pfad für HTTPS. Wenn Sie eine benutzerdefinierte Schlüsselspeicherdatei verwenden möchten, können Sie den S3-Pfad `s3://path_to_your_keystore_file` hier angeben. Wenn Sie diesen Parameter leer lassen, wird ein selbstsignierter, zertifikatbasierter Schlüsselspeicher generiert und verwendet. + **KeyStore-Passwort** – Geben Sie SSL/TLS-KeyStore-Passwort für HTTPS ein. 1. **Konfigurieren der EC2-Instance** Geben Sie die folgenden Informationen ein: + **Instance-Typ** – Der Typ der Amazon-EC2-Instance, der den Spark-History-Server hostet. Da diese Vorlage die Amazon-EC2-Instance in Ihrem Konto startet, werden Amazon-EC2-Kosten Ihrem Konto separat in Rechnung gestellt. + **Neueste AMI-ID** – Die AMI-ID von Amazon Linux 2 für die Spark-Verlaufsserver-Instance. Sie können den Standardwert verwenden. + **VPC ID** – Die Virtual Private Cloud (VPC)-ID für die Spark-History-Server-Instance. Sie können alle in Ihrem Konto VPCs verfügbaren Optionen verwenden. Die Verwendung einer Standard-VPC mit einer [Standard-Netzwerk-ACL](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#default-network-acl) wird nicht empfohlen. Weitere Informationen finden Sie unter [Default VPC and Default Subnets (Standard-VPC und Standard-Subnetze)](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html) und unter [Creating a VPC (Erstellen einer VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC) im *Amazon-VPC-Benutzerhandbuch*. + **Subnetz-ID** – Die ID für die Spark-Verlaufsserver-Instance. Sie können jedes Subnetz in Ihrer VPC verwenden. Sie müssen das Subnetz von Ihrem Client aus erreichen können. Wenn Sie über das Internet auf das Subnetz zugreifen möchten, müssen Sie ein öffentliches Subnetz mit dem Internet-Gateway in der Routing-Tabelle verwenden. 1. Wählen Sie **Weiter** aus. 1. Wählen Sie auf der Seite **Stack-Optionen konfigurieren** die Option **Weiter** aus, um anhand der aktuellen Benutzeranmeldedaten zu bestimmen, wie Ressourcen im Stack erstellt, geändert oder gelöscht werden CloudFormation können. Sie können im Abschnitt **Berechtigungen** auch eine Rolle angeben, die anstelle der aktuellen Benutzerberechtigungen verwendet werden soll, und dann **Weiter** wählen. 1. Überprüfen Sie die Vorlage auf der Seite **Review (Prüfen)**. Wählen Sie **Ich bestätige, dass CloudFormation möglicherweise IAM-Ressourcen erstellt** werden, und wählen Sie dann **Stack erstellen** aus. 1. Warten Sie, bis der Stack erstellt wurde. 1. Öffnen Sie die Registerkarte **Outputs (Ausgaben)**. 1. Kopieren Sie die URL von **SparkUiPublicUrl**, wenn Sie ein öffentliches Subnetz verwenden. 1. Kopieren Sie die URL von **SparkUiPrivateUrl**, wenn Sie ein privates Subnetz verwenden. 1. Öffnen Sie einen Webbrowser und fügen Sie die URL ein. Auf diese Weise können Sie über HTTPS auf dem angegebenen Port auf den Server zugreifen. Ihr Browser erkennt möglicherweise nicht das Zertifikat des Servers. In diesem Fall müssen Sie den Schutz des Servers außer Kraft setzen und trotzdem fortfahren. ## Starten des Spark History-Servers und Anzeigen der Spark-Benutzeroberfläche über Docker Wenn Sie den lokalen Zugriff bevorzugen (d. h., keine EC2-Instance für den Apache Spark History-Server verwenden möchten), können Sie auch Docker verwenden, um den Apache Spark History-Server zu starten und die Spark-Benutzeroberfläche lokal anzuzeigen. Diese Dockerfile ist ein Beispiel, das Sie entsprechend Ihren Anforderungen anpassen sollten. **Voraussetzungen** Informationen zum Installieren von Docker auf Ihrem Laptop finden Sie in der [Docker Engine-Community](https://docs.docker.com/install/). **So starten Sie den Spark History-Server und zeigen die Spark-Benutzeroberfläche lokal über Docker an** 1. Laden Sie Dateien herunter von GitHub. Laden Sie die Dockerfile und `pom.xml` aus den [ AWS Glue-Codebeispielen](https://github.com/aws-samples/aws-glue-samples/tree/master/utilities/Spark_UI/) herunter. 1. Bestimmen Sie, ob Sie Ihre Benutzeranmeldeinformationen oder Verbundbenutzeranmeldeinformationen für den Zugriff auf AWS verwenden möchten. + Um die aktuellen Benutzeranmeldedaten für den Zugriff zu verwenden AWS, rufen Sie die Werte ab, die für ` AWS_ACCESS_KEY_ID` und `AWS_SECRET_ACCESS_KEY` im `docker run` Befehl verwendet werden sollen. Weitere Informationen finden Sie unter [Verwalten der Zugriffsschlüssel für IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) im *-IAM-Benutzerhandbuch*. + Um SAML 2.0-Verbundbenutzer für den Zugriff zu verwenden AWS, rufen Sie die Werte für ` AWS_ACCESS_KEY_ID``AWS_SECRET_ACCESS_KEY`, und ab. ` AWS_SESSION_TOKEN` Weitere Informationen finden Sie unter [Anfordern von temporären Sicherheitsanmeldeinformationen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html) 1. Bestimmen Sie den Speicherort Ihres Ereignisprotokollverzeichnisses für die Verwendung im `docker run`-Befehl. 1. Erstellen Sie das Docker-Image mit den Dateien im lokalen Verzeichnis unter Verwendung des Namens` glue/sparkui`, und das Tag`latest`aus. ``` $ docker build -t glue/sparkui:latest . ``` 1. Erstellen und starten Sie den Docker-Container. Verwenden Sie in den folgenden Befehlen die zuvor in den Schritten 2 und 3 beschafften Werte. 1. Verwenden Sie einen Befehl wie den folgenden, um den Docker-Container mit Ihren Benutzeranmeldeinformationen zu erstellen ``` docker run -itd -e SPARK_HISTORY_OPTS="$SPARK_HISTORY_OPTS -Dspark.history.fs.logDirectory=s3a://path_to_eventlog -Dspark.hadoop.fs.s3a.access.key=AWS_ACCESS_KEY_ID -Dspark.hadoop.fs.s3a.secret.key=AWS_SECRET_ACCESS_KEY" -p 18080:18080 glue/sparkui:latest "/opt/spark/bin/spark-class org.apache.spark.deploy.history.HistoryServer" ``` 1. Um den Docker-Container mit temporären Anmeldeinformationen zu erstellen, verwenden Sie ` org.apache.hadoop.fs.s3a.TemporaryAWSCredentialsProvider` als Anbieter und geben Sie die in Schritt 2 beschafften Anmeldeinformationen an. Weitere Informationen finden Sie unter [Using Session Credentials with Temporary AWSCredentials Provider](https://hadoop.apache.org/docs/stable/hadoop-aws/tools/hadoop-aws/index.html#Using_Session_Credentials_with_TemporaryAWSCredentialsProvider) in der Dokumentation *Hadoop: Integration with Amazon Web Services*. ``` docker run -itd -e SPARK_HISTORY_OPTS="$SPARK_HISTORY_OPTS -Dspark.history.fs.logDirectory=s3a://path_to_eventlog -Dspark.hadoop.fs.s3a.access.key=AWS_ACCESS_KEY_ID -Dspark.hadoop.fs.s3a.secret.key=AWS_SECRET_ACCESS_KEY -Dspark.hadoop.fs.s3a.session.token=AWS_SESSION_TOKEN -Dspark.hadoop.fs.s3a.aws.credentials.provider=org.apache.hadoop.fs.s3a.TemporaryAWSCredentialsProvider" -p 18080:18080 glue/sparkui:latest "/opt/spark/bin/spark-class org.apache.spark.deploy.history.HistoryServer" ``` **Anmerkung** Diese Konfigurationsparameter stammen aus dem [ Hadoop-AWS-Modul](https://hadoop.apache.org/docs/stable/hadoop-aws/tools/hadoop-aws/index.html). Sie müssen möglicherweise je nach Anwendungsfall eine spezielle Konfiguration vornehmen. Zum Beispiel: Benutzer in isolierten Regionen müssen den ` spark.hadoop.fs.s3a.endpoint` konfigurieren. 1. Öffnen Sie `http://localhost:18080` in Ihrem Browser, um die Spark-Benutzeroberfläche lokal anzuzeigen. # Überwachung mit Einblicken in die AWS Glue Auftragsausführung AWS Glue Job Run Insights ist eine Funktion AWS Glue , die das Debuggen und die Optimierung von Jobs für Ihre AWS Glue Jobs vereinfacht. AWS Glue bietet die [Spark-Benutzeroberfläche](https://docs.aws.amazon.com/glue/latest/dg/monitor-spark-ui.html) sowie [CloudWatch Protokolle und Metriken](https://docs.aws.amazon.com/glue/latest/dg/monitor-cloudwatch.html) für die Überwachung Ihrer AWS Glue Jobs. Mit dieser Funktion erhalten Sie folgende Informationen über die Ausführung Ihres AWS Glue Jobs: + Zeilennummer Ihres AWS Glue Job-Skripts, bei dem ein Fehler aufgetreten ist. + Spark-Aktion, die zuletzt im Spark-Abfrageplan kurz vor dem Fehler Ihres Auftrags ausgeführt wurde. + Spark-Ausnahmeereignisse im Zusammenhang mit dem Fehler, der in einem zeitgeordneten Protokollstream dargestellt wird. + Ursachenanalyse und empfohlene Maßnahmen (z. B. die Optimierung Ihres Skripts), um das Problem zu beheben. + Häufige Spark-Ereignisse (Protokollmeldungen in Bezug auf eine Spark-Aktion) mit einer empfohlenen Aktion, die die Ursache behandelt. All diese Erkenntnisse stehen Ihnen mithilfe von zwei neuen Log-Streams in den CloudWatch Logs für Ihre AWS Glue Jobs zur Verfügung. ## Voraussetzungen Die Funktion „Einblicke in die AWS Glue Auftragsausführung“ ist für die AWS Glue Versionen 2.0 und höher verfügbar. Sie können dem [Migrationsleitfaden](https://docs.aws.amazon.com/glue/latest/dg/migrating-version-30.html) für Ihre bestehenden Jobs folgen, um sie von älteren AWS Glue Versionen zu aktualisieren. ## Einblicke in die Jobausführung für einen AWS Glue ETL-Job aktivieren Sie können Einblicke in die Jobausführung über AWS Glue Studio oder über die CLI aktivieren. ### AWS Glue Studio Wenn Sie einen Job über erstellen AWS Glue Studio, können Sie die Einblicke in die Jobausführung auf der Registerkarte **Jobdetails** aktivieren oder deaktivieren. Überprüfen Sie, ob das Kontrollkästchen **Auftragserkenntnisse generieren** aktiviert ist. ![\[Aktivieren von Erkenntnissen in Auftragsausführungen in AWS Glue Studio.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-job-run-insights-1.png) ### Befehlszeile Wenn Sie einen Auftrag über die CLI erstellen, können Sie eine Auftragsausführung mit einem einzigen neuen [Auftrags-Parameter](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-glue-arguments.html) starten: `--enable-job-insights = true`. Standardmäßig werden die Protokoll-Streams der Auftragsausführungs-Erkenntnisse unter derselben Standardprotokollgruppe erstellt, die von [Kontinuierliche AWS Glue -Protokollierung](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuous-logging.html), das heißt, `/aws-glue/jobs/logs-v2/` verwendet wird. Sie können benutzerdefinierte Protokollgruppennamen, Protokollfilter und Protokollgruppenkonfigurationen mit denselben Argumenten für die kontinuierliche Protokollierung einrichten. Weitere Informationen finden Sie unter [Kontinuierliche Protokollierung für AWS Glue Jobs aktivieren](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuous-logging-enable.html). ## Beim Zugriff auf den Job Run Insights werden Streams protokolliert in CloudWatch Wenn das Feature „Auftragsausführungs-Erkenntnisse“ aktiviert ist, werden möglicherweise zwei Protokoll-Streams erstellt, wenn eine Auftragsausführung fehlschlägt. Wenn ein Auftrag erfolgreich abgeschlossen ist, wird keiner der Streams generiert. 1. *Protokoll-Stream für Ausnahmeanalyse*: `-job-insights-rca-driver`. Dieser Stream bietet Folgendes: + Zeilennummer Ihres AWS Glue Job-Skripts, das den Fehler verursacht hat. + Spark-Aktion, die zuletzt im Spark-Abfrageplan (DAG) ausgeführt wurde. + Prägnante zeitgeordnete Ereignisse des Spark-Treibers und der Executors, die mit der Ausnahme zusammenhängen. Hier finden Sie Details wie vollständige Fehlermeldungen, die fehlgeschlagene Spark-Aufgabe und deren Executor-ID, die Ihnen helfen, sich bei Bedarf auf den Protokoll-Stream des jeweiligen Executors zu konzentrieren. 1. *Regelbasierter Erkenntnis-Stream*: + Ursachenanalyse und Empfehlungen zur Behebung der Fehler (z. B. Verwendung eines bestimmten Auftrags-Parameters zur Optimierung der Leistung). + Relevante Spark-Ereignisse, die als Grundlage für die Ursachenanalyse und eine empfohlene Aktion dienen. **Anmerkung** Der erste Stream wird nur vorhanden sein, wenn Spark-Ausnahme-Ereignisse für eine fehlgeschlagene Auftragsausführung verfügbar sind und der zweite Stream wird nur vorhanden sein, wenn Erkenntnisse für die fehlgeschlagene Auftragsausführung verfügbar sind. Wenn Ihr Auftrag beispielsweise erfolgreich abgeschlossen ist, wird keiner der Streams generiert. Wenn Ihr Auftrag fehlschlägt, aber keine dienstdefinierte Regel vorhanden ist, die mit Ihrem Fehlerszenario übereinstimmen kann, wird nur der erste Stream generiert. Wenn der Job aus erstellt wurde AWS Glue Studio, sind die Links zu den oben genannten Streams auch auf der Registerkarte Job-Rundetails (Job Run Insights) als „Präzise und konsolidierte Fehlerprotokolle“ und „Fehleranalyse und Anleitung“ verfügbar. ![\[Die Seite „Auftrags-Ausführungsdetails“ mit Links zu den Protokoll-Streams.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-job-run-insights-2.png) ## Beispiel für Einblicke in die AWS Glue Auftragsausführung In diesem Abschnitt stellen wir Ihnen ein Beispiel vor, wie das Feature „Auftragsausführungs-Erkenntnisse“ Ihnen helfen kann, ein Problem in Ihrem fehlgeschlagenen Auftrag zu lösen. In diesem Beispiel hat ein Benutzer vergessen, das erforderliche Modul (Tensorflow) in einen AWS Glue Job zu importieren, um seine Daten zu analysieren und ein Modell für maschinelles Lernen zu erstellen. ``` import sys from awsglue.transforms import * from awsglue.utils import getResolvedOptions from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job from pyspark.sql.types import * from pyspark.sql.functions import udf,col args = getResolvedOptions(sys.argv, ['JOB_NAME']) sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session job = Job(glueContext) job.init(args['JOB_NAME'], args) data_set_1 = [1, 2, 3, 4] data_set_2 = [5, 6, 7, 8] scoresDf = spark.createDataFrame(data_set_1, IntegerType()) def data_multiplier_func(factor, data_vector): import tensorflow as tf with tf.compat.v1.Session() as sess: x1 = tf.constant(factor) x2 = tf.constant(data_vector) result = tf.multiply(x1, x2) return sess.run(result).tolist() data_multiplier_udf = udf(lambda x:data_multiplier_func(x, data_set_2), ArrayType(IntegerType(),False)) factoredDf = scoresDf.withColumn("final_value", data_multiplier_udf(col("value"))) print(factoredDf.collect()) ``` Ohne das Feature „Auftragsausführungs-Erkenntnisse“ wird nur die folgende Nachricht angezeigt, die von Spark ausgelöst wird, da der Auftrag fehlschlägt: `An error occurred while calling o111.collectToPython. Traceback (most recent call last):` Die Nachricht ist mehrdeutig und schränkt Ihre Debugging-Erfahrung ein. In diesem Fall bietet Ihnen diese Funktion zusätzliche Einblicke in zwei CloudWatch Protokollstreams: 1. Der `job-insights-rca-driver`-Protokoll-Stream: + *Ausnahme-Ereignisse*: Dieser Protokoll-Stream bietet Ihnen die Spark-Ausnahmeereignisse im Zusammenhang mit dem Fehler, der vom Spark-Treiber und verschiedenen verteilten Workern gesammelt wurde. Diese Ereignisse helfen Ihnen, die zeitlich geordnete Ausbreitung der Ausnahme zu verstehen, wenn fehlerhafter Code auf Spark-Aufgaben, Executoren und Stages, die über die Worker verteilt sind, ausgeführt wird. AWS Glue + *Zeilennummern*: Dieser Protokoll-Stream identifiziert Zeile 21, die den Aufruf zum Importieren des fehlenden Python-Moduls gemacht hat, das den Fehler verursacht hat; Außerdem wird Zeile 24, der Aufruf von Spark Action `collect()`, als die zuletzt ausgeführte Zeile in Ihrem Skript identifiziert. ![\[Der Log-Stream. job-insights-rca-driver\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-job-run-insights-3.png) 1. Der `job-insights-rule-driver`-Protokoll-Stream: + *Grundursache und Empfehlung*: Neben der Zeilennummer und der zuletzt ausgeführten Zeilennummer für den Fehler in Ihrem Skript zeigt dieser Protokollstream die Ursachenanalyse und die Empfehlung für Sie, dem AWS Glue Dokument zu folgen und die erforderlichen Jobparameter einzurichten, um ein zusätzliches Python-Modul in Ihrem AWS Glue Job zu verwenden. + *Basis-Ereignis*: Dieser Protokoll-Stream zeigt auch das Spark-Ausnahmeereignis an, das mit der vom Service definierten Regel ausgewertet wurde, um die Ursache abzuleiten und eine Empfehlung abzugeben. ![\[Der job-insights-rule-driver Log-Stream.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-job-run-insights-4.png) # Überwachung mit Amazon CloudWatch Sie können die Überwachung AWS Glue mithilfe von Amazon durchführen CloudWatch, das Rohdaten sammelt und AWS Glue in lesbare near-real-time Messwerte umwandelt. Diese Statistiken werden für einen Zeitraum von zwei Wochen aufgezeichnet, damit Sie auf Verlaufsinformationen zugreifen können und einen besseren Überblick über die Performance der Webanwendung oder des Services erhalten. Standardmäßig werden AWS Glue Metrikdaten CloudWatch automatisch an gesendet. Weitere Informationen finden Sie unter [Was ist Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html) im * CloudWatch Amazon-Benutzerhandbuch* und[AWS Glue Metriken](monitoring-awsglue-with-cloudwatch-metrics.md#awsglue-metrics). **Kontinuierliche Protokollierung** AWS Glue unterstützt außerdem die kontinuierliche Echtzeitprotokollierung für AWS Glue-Aufträge. Wenn die kontinuierliche Protokollierung für einen Job aktiviert ist, können Sie die Echtzeitprotokolle auf der AWS Glue Konsole oder im CloudWatch Konsolen-Dashboard einsehen. Weitere Informationen finden Sie unter [Protokollierung für AWS Glue Jobs](monitor-continuous-logging.md). **Beobachtbarkeitsmetriken** Wenn **Job-Observability-Metriken** aktiviert sind, werden zusätzliche Amazon CloudWatch Metriken generiert, wenn der Job ausgeführt wird. Nutzen Sie AWS Glue-Beobachtbarkeitsmetriken, um Einblicke in die Abläufe in AWS Glue zu erhalten. So können Sie die Sichtung und Analyse von Problemen verbessern. **Topics** + [Überwachung AWS Glue anhand von CloudWatch Amazon-Metriken](monitoring-awsglue-with-cloudwatch-metrics.md) + [CloudWatch Amazon-Alarme in AWS Glue Jobprofilen einrichten](monitor-profile-glue-job-cloudwatch-alarms.md) + [Protokollierung für AWS Glue Jobs](monitor-continuous-logging.md) + [Überwachung mit AWS Glue-Beobachtbarkeitsmetriken](monitor-observability.md) # Überwachung AWS Glue anhand von CloudWatch Amazon-Metriken Sie können AWS Glue-Operationen mit dem AWS Glue-Auftrags-Profiler profilieren und überwachen. Es sammelt und verarbeitet Rohdaten von AWS Glue Jobs zu lesbaren, nahezu in Echtzeit gespeicherten Metriken, die in Amazon gespeichert sind CloudWatch. Diese Statistiken werden gespeichert und aggregiert, CloudWatch sodass Sie auf historische Informationen zugreifen können, um einen besseren Überblick über die Leistung Ihrer Anwendung zu erhalten. **Anmerkung** Es können zusätzliche Gebühren anfallen, wenn Sie Job-Metriken aktivieren und CloudWatch benutzerdefinierte Metriken erstellt werden. Weitere Informationen finden Sie unter [ CloudWatch Amazon-Preise](https://aws.amazon.com/cloudwatch/pricing/). ## AWS Glue-Metriken – Übersicht Wenn Sie mit interagierenAWS Glue, sendet es Metriken an CloudWatch. Sie können diese Metriken über die AWS Glue Konsole (die bevorzugte Methode), das CloudWatch Konsolen-Dashboard oder die AWS Command Line Interface (AWS CLI) anzeigen. **Anzeige von Metriken über das Dashboard der AWS Glue-Konsole** Sie können zusammenfassende oder detaillierte Diagramme von Metriken für einen Auftrag oder detaillierte Diagramme für eine Auftragsausführung anzeigen. 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Glue Konsole unter [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/). 1. Wählen Sie im Navigationsbereich **Überwachung der Auftragsausführung** aus. 1. Wählen Sie unter **Auftragsausführungen** die Option **Aktionen**, um einen gerade ausgeführten Auftrag anzuhalten, einen Auftrag anzuzeigen oder ein Auftragslesezeichen zurückzuspulen. 1. Wählen Sie einen Auftrag aus und wählen Sie dann **Details zur Ausführung anzeigen**, um zusätzliche Informationen zur Auftragsausführung anzuzeigen. **Um Metriken über das CloudWatch Konsolen-Dashboard anzuzeigen** Metriken werden zunächst nach dem Service-Namespace und anschließend nach den verschiedenen Dimensionskombinationen in den einzelnen Namespaces gruppiert. 1. Öffnen Sie die CloudWatch Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. Wählen Sie im Navigationsbereich **Metriken** aus. 1. Wählen Sie den Namespace **Glue** aus. **Um Metriken mit dem anzuzeigen AWS CLI** + Geben Sie als Eingabeaufforderung den folgenden Befehl ein. ``` 1. aws cloudwatch list-metrics --namespace Glue ``` AWS Gluemeldet Metriken CloudWatch alle 30 Sekunden, und die CloudWatch Metrik-Dashboards sind so konfiguriert, dass sie jede Minute angezeigt werden. Die AWS Glue-Metriken stellen Deltawerte gegenüber den zuvor gemeldeten Werten dar. Gegebenenfalls aggregieren (summieren) die Metrik-Dashboards die 30-Sekunden-Wertezu einem Wert für die gesamte vergangene Minute. ### AWS Glue Verhalten von Metriken für Spark-Jobs AWS Glue-Metriken werden bei der Initialisierung eines `GlueContext` in einem Skript aktiviert und in der Regel nur am Ende einer Apache-Spark-Aufgabe aktualisiert. Sie stellen die aggregierten Werte in allen abgeschlossenen Spark-Aufgaben dar. Bei den Spark-Metriken, die AWS Glue an weitergegeben CloudWatch werden, handelt es sich jedoch im Allgemeinen um absolute Werte, die den aktuellen Status zum Zeitpunkt der Meldung darstellen. AWS Gluemeldet sie CloudWatch alle 30 Sekunden, und die Metrik-Dashboards zeigen in der Regel den Durchschnitt der in der letzten Minute empfangenen Datenpunkte an. Allen AWS Glue-Metriknamen wird eines der folgenden Präfixe vorangestellt: + `glue.driver.` – Metriken, deren Namen mit diesem Präfix beginnen, stellen entweder AWS Glue-Metriken dar, die von allen Executors beim Spark-Treiber aggregiert werden, oder Spark-Metriken, die dem Spark-Treiber entsprechen. + `glue.`*executorId*`.` – Die *executorId* ist die Nummer eines bestimmten Spark-Executor. Der Wert entspricht den Executors, die in den Protokollen aufgeführt sind. + `glue.ALL.` - Metriken, deren Namen mit diesem Präfix beginnen, aggregierte Werte aus allen Spark Executors. ## AWS Glue Metriken AWS Glue erstellt und sendet CloudWatch alle 30 Sekunden die folgenden Metriken, und das AWS Glue Metrics-Dashboard meldet sie einmal pro Minute: | Metrik | Description | | --- | --- | | `glue.driver.aggregate.bytesRead` | Die Anzahl der Bytes, die von allen abgeschlossenen Spark-Aufgaben von allen Datenquellen gelesen und in allen Executors ausgeführt werden. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Byte Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Diese Metrik kann genauso verwendet werden wie die `glue.ALL.s3.filesystem.read_bytes`-Metrik mit dem Unterschied, dass diese Metrik am Ende einer Spark-Aufgabe aktualisiert wird und auch Nicht-S3-Datenquellen erfasst. | | `glue.driver.aggregate.elapsedTime` | Die ETL verstrichene Zeit in Millisekunden (schließt die Bootstrap-Zeiten des Auftrags nicht ein). Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Millisekunden Kann verwendet werden, um zu ermitteln, wie lange eine Auftragsausführung im Durchschnitt dauert. Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.aggregate.numCompletedStages` | Die Anzahl der abgeschlossenen Phasen im Auftrag. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.aggregate.numCompletedTasks` | Die Anzahl der abgeschlossenen Aufgaben im Auftrag. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.aggregate.numFailedTasks` | Die Anzahl der fehlgeschlagenen Aufgaben. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Die Daten können verwendet werden, um Alarme für erhöhte Ausfälle einzustellen, die Anomalien in Daten, Clustern oder Skripten andeuten könnten. | | `glue.driver.aggregate.numKilledTasks` | Anzahl der abgeschlossenen Aufgaben. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.aggregate.recordsRead` | Die Anzahl der Datensätze, die von allen abgeschlossenen Spark-Aufgaben von allen Datenquellen gelesen und in allen Executors ausgeführt werden. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Diese Metrik kann genauso verwendet werden wie die `glue.ALL.s3.filesystem.read_bytes`-Metrik mit dem Unterschied, dass diese Metrik am Ende einer Spark-Aufgabe aktualisiert wird. | | `glue.driver.aggregate.shuffleBytesWritten` | Die Anzahl der Byte, die seit dem letzten Bericht von allen Executoren geschrieben wurden, um Daten zwischen ihnen zu mischen (aggregiert vom AWS Glue Metrics Dashboard als die Anzahl der Bytes, die zu diesem Zweck in der letzten Minute geschrieben wurden). Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Byte Kann verwendet werden, um Folgendes zu überwachen: Datenmischung in Aufträgen (große Joins, GroupBy, Repartition, Coalesce). Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.aggregate.shuffleLocalBytesRead` | Die Anzahl der Byte, die seit dem letzten Bericht von allen Executoren gelesen wurden, um Daten zwischen ihnen zu mischen (vom AWS Glue Metrics Dashboard als die Anzahl der zu diesem Zweck in der letzten Minute gelesenen Byte aggregiert). Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Einheit: Byte Kann verwendet werden, um Folgendes zu überwachen: Datenmischung in Aufträgen (große Joins, GroupBy, Repartition, Coalesce). Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.BlockManager.disk.diskSpaceUsed_MB` | Die Anzahl der Megabyte an Speicherplatz, die für alle Executoren verwendet werden. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Gauge). Gültige Statistiken: Durchschnitt. Dies ist eine Spark-Metrik, die als absoluter Wert gemeldet wird. Einheit: Megabyte Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.ExecutorAllocationManager.executors.numberAllExecutors` | Die Anzahl der aktiven Auftrags-Executors. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Gauge). Gültige Statistiken: Durchschnitt. Dies ist eine Spark-Metrik, die als absoluter Wert gemeldet wird. Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors` | Die Anzahl der maximalen (aktiv ausgeführten und ausstehenden) Auftrags-Executors, die benötigt werden, um die aktuelle Last zu erfüllen. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Gauge). Gültige Statistiken: Maximum. Dies ist eine Spark-Metrik, die als absoluter Wert gemeldet wird. Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.jvm.heap.usage` `glue.`*executorId*`.jvm.heap.usage` `glue.ALL.jvm.heap.usage` | Den vom JVM-Heap für diesen Treiber (Skalierung: 0-1) verwendeten Speicheranteil – vom Treiber, einem durch executorId identifizierten Executor oder ALLE Executors. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Gauge). Gültige Statistiken: Durchschnitt. Dies ist eine Spark-Metrik, die als absoluter Wert gemeldet wird. Einheit: Prozentsatz Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.jvm.heap.used` `glue.`*executorId*`.jvm.heap.used` `glue.ALL.jvm.heap.used` | Die Anzahl der vom JVM-Heap verwendeten Speicherbytes für den Treiber, der durch *executorId* oder ALLE Executors identifiziert wurde. Gültige Dimensionen: `JobName` (der Name des AWS Glue Job), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Gauge). Gültige Statistiken: Durchschnitt. Dies ist eine Spark-Metrik, die als absoluter Wert gemeldet wird. Einheit: Byte Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.s3.filesystem.read_bytes` `glue.`*executorId*`.s3.filesystem.read_bytes` `glue.ALL.s3.filesystem.read_bytes` | Die Anzahl der Byte, die der Treiber, ein durch die *ExecutorID identifizierter Executor oder ALLE Executoren* seit dem letzten Bericht aus Amazon S3 gelesen haben (aggregiert vom AWS Glue Metrics Dashboard als Anzahl der in der letzten Minute gelesenen Byte). Gültige Dimensionen: `JobName`, `JobRunId` und `Type` (Messung). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Der Bereich unter der Kurve im AWS Glue Metrics Dashboard kann verwendet werden, um die von zwei verschiedenen Jobläufen gelesenen Bytes visuell zu vergleichen. Einheit: Byte. Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Die resultierenden Daten können verwendet werden für: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.s3.filesystem.write_bytes` `glue.`*executorId*`.s3.filesystem.write_bytes` `glue.ALL.s3.filesystem.write_bytes` | Die Anzahl der Byte, die der Treiber, ein durch die *ExecutorID identifizierter Executor oder ALLE Executoren* seit dem letzten Bericht in Amazon S3 geschrieben haben (aggregiert vom AWS Glue Metrics Dashboard als Anzahl der in der letzten Minute geschriebenen Byte). Gültige Dimensionen: `JobName`, `JobRunId` und `Type` (Messung). Gültige Statistiken: Summe Bei dieser Metrik handelt es sich um einen Deltawert gegenüber dem zuletzt gemeldeten Wert. Daher wird im AWS Glue Metrik-Dashboard eine SUM-Statistik für die Aggregation verwendet. Der Bereich unter der Kurve im AWS Glue Metrik-Dashboard kann verwendet werden, um die in zwei verschiedenen Jobläufen geschriebenen Bytes visuell zu vergleichen. Einheit: Byte Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.streaming.numRecords` | Die Anzahl der Datensätze, die in einem Mikrobatch empfangen werden. Diese Metrik ist nur für AWS Glue Streaming-Jobs mit AWS Glue Version 2.0 und höher verfügbar. Gültige Dimensionen: `JobName` (der Name des AWS Glue Jobs), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe, Maximum, Minimum, Durchschnitt, Prozent Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.streaming.batchProcessingTimeInMs` | Die Zeit, die für die Verarbeitung der Batches in Millisekunden benötigt wird. Diese Metrik ist nur für AWS Glue Streaming-Jobs mit AWS Glue Version 2.0 und höher verfügbar. Gültige Dimensionen: `JobName` (der Name des AWS Glue Jobs), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Anzahl). Gültige Statistiken: Summe, Maximum, Minimum, Durchschnitt, Prozent Einheit: Anzahl Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | | `glue.driver.system.cpuSystemLoad` `glue.`*executorId*`.system.cpuSystemLoad` `glue.ALL.system.cpuSystemLoad` | Der vom Treiber verwendete Anteil der CPU-Systemauslastung (Skalierung: 0-1) – ein durch *executorId* identifizierter Executor oder ALLE Executors. Gültige Dimensionen: `JobName` (der Name des AWS Glue Jobs), `JobRunId` (die JobRun ID. oder`ALL`) und `Type` (Gauge). Gültige Statistiken: Durchschnitt. Diese Metrik wird als absoluter Wert gemeldet. Einheit: Prozentsatz Kann für die Überwachung folgender Aspekte verwendet werden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) Einige Möglichkeiten, die Daten zu verwenden: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html) | ## AWS Glue Dimensionen für Metriken AWS Glue Metriken verwenden den AWS Glue Namespace und stellen Metriken für die folgenden Dimensionen bereit: | Dimension | Description | | --- | --- | | `JobName` | Diese Dimension filtert nach Metriken aller Jobausführungen eines bestimmten AWS Glue Jobs. | | `JobRunId` | Diese Dimension filtert nach Metriken eines bestimmten AWS Glue Jobs, der von einer JobRun ID ausgeführt wird, oder`ALL`. | | `Type` | Diese Dimension filtert nach Metriken entweder nach `count` (eine aggregierte Zahl) oder `gauge` (ein Wert zu einem bestimmten Zeitpunkt). | Weitere Informationen finden Sie im [ CloudWatch Amazon-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/). # CloudWatch Amazon-Alarme in AWS Glue Jobprofilen einrichten AWS GlueMetriken sind auch bei Amazon verfügbar CloudWatch. Sie können Alarme zu jeder AWS Glue-Metrik für geplante Aufträge einrichten. Einige häufige Szenarien für das Einrichten von Alarmen: + Aufträge, die nicht mehr über genügend Speicher verfügen (OOM): Richten Sie einen Alarm für den Fall ein, dass der Speicherverbrauch den normalen Durchschnitt für den Treiber oder einen Executor für einen AWS Glue-Auftrag überschreitet. + Wegfall von Executors: Richten Sie einen Alarm für den Fall ein, dass die Anzahl der Executors in einem AWS Glue-Auftrag für lange Zeit unter einen bestimmten Grenzwert fällt. + Datenbestand oder Wiederaufbereitung: Vergleichen Sie die Metriken einzelner Jobs in einem Workflow mithilfe eines CloudWatch mathematischen Ausdrucks. Sie können dann einen Alarm für den resultierenden Ausdruckswert auslösen (z. B. das Verhältnis der von einem Auftrag geschriebenen Bytes zu den von einem nachfolgenden Auftrag gelesenen Bytes). Detaillierte Anweisungen zum Einstellen von Alarmen finden [Sie unter Einen CloudWatch Alarm erstellen oder bearbeiten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) im *[Amazon CloudWatch Events-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/)*. Informationen zum Überwachen und Debuggen von Szenarien mit Hilfe von CloudWatch finden Sie unter[Auftragsüberwachung und Debugging](monitor-profile-glue-job-cloudwatch-metrics.md). # Protokollierung für AWS Glue Jobs In AWS Glue 5.0 verfügen alle Jobs über Funktionen zur Echtzeitprotokollierung. Darüber hinaus können Sie benutzerdefinierte Konfigurationsoptionen angeben, um das Protokollierungsverhalten anzupassen. Zu diesen Optionen gehören das Festlegen des Amazon CloudWatch Protokollgruppennamens, des Amazon CloudWatch Protokollstream-Präfixes (das der ID und driver/executor ID der AWS Glue Auftragsausführung vorangestellt wird) und des Protokollkonvertierungsmusters für Protokollnachrichten. Mit diesen Konfigurationen können Sie Protokolle in benutzerdefinierten Amazon CloudWatch -Protokollgruppen mit unterschiedlichen Ablaufrichtlinien zusammenfassen. Darüber hinaus können Sie die Protokolle effektiver analysieren, indem Sie benutzerdefinierte Protokollstream-Präfixe und Konvertierungsmuster verwenden. Dieser Grad der Anpassung ermöglicht es Ihnen, die Protokollverwaltung und -analyse gemäß Ihren spezifischen Anforderungen zu optimieren. ## Verhalten bei der Protokollierung in 5.0 AWS Glue Standardmäßig werden Systemprotokolle, Spark-Daemon-Protokolle und AWS Glue Benutzer-Logger-Protokolle in Amazon CloudWatch die `/aws-glue/jobs/error` Protokollgruppe geschrieben. Andererseits werden die Benutzerprotokolle stdout (Standardausgabe) und stderr (Standardfehler) standardmäßig in die `/aws-glue/jobs/output`-Protokollgruppe geschrieben. ## Benutzerdefiniertes Protokollieren Sie können die Standardpräfixe für Protokollgruppen und Protokollstreams mithilfe der folgenden Auftragsargumente anpassen: + `--custom-logGroup-prefix`: Ermöglicht es Ihnen, ein benutzerdefiniertes Präfix für die Protokollgruppen `/aws-glue/jobs/error` und `/aws-glue/jobs/output` anzugeben. Wenn Sie ein benutzerdefiniertes Präfix angeben, weisen die Namen der Protokollgruppen das folgende Format auf: + `/aws-glue/jobs/error` wird `/error` sein. + `/aws-glue/jobs/output ` wird `/output` sein. + `--custom-logStream-prefix`: Ermöglicht es Ihnen, ein benutzerdefiniertes Präfix für die Namen der Protokollstreams innerhalb der Protokollgruppen anzugeben. Wenn Sie ein benutzerdefiniertes Präfix angeben, weisen die Namen der Protokollstreams das folgende Format auf: + `jobrunid-driver` wird `-driver` sein. + `jobrunid-executorNum` wird `-executorNum` sein. Validierungsregeln und Einschränkungen für benutzerdefinierte Präfixe: + Der Name des Protokollstreams muss insgesamt zwischen 1 und 512 Zeichen lang sein. + Das benutzerdefinierte Präfix selbst ist auf 400 Zeichen beschränkt. + Das benutzerdefinierte Präfix muss dem regulären Ausdrucksmuster „[^:\$1]\$1“ entsprechen (zulässige Sonderzeichen sind „\$1“, „-“ und „/“). ## Protokollieren von anwendungsspezifischen Meldungen mit dem benutzerdefinierten Skript-Logger Sie können den AWS Glue Logger verwenden, um alle anwendungsspezifischen Meldungen im Skript zu protokollieren, die in Echtzeit an den Treiberprotokollstream gesendet werden. Das folgende Beispiel zeigt ein Python-Skript. ``` from awsglue.context import GlueContext from pyspark.context import SparkContext sc = SparkContext() glueContext = GlueContext(sc) logger = glueContext.get_logger() logger.info("info message") logger.warn("warn message") logger.error("error message") ``` Das folgende Beispiel zeigt ein Scala-Skript. ``` import com.amazonaws.services.glue.log.GlueLogger object GlueApp { def main(sysArgs: Array[String]) { val logger = new GlueLogger logger.info("info message") logger.warn("warn message") logger.error("error message") } } ``` ## Aktivieren des Fortschrittsbalkens zum Anzeigen des Auftragsfortschritts AWS Glue bietet unter dem `JOB_RUN_ID-progress-bar` Protokollstream eine Fortschrittsleiste in Echtzeit, mit der der Status der AWS Glue Auftragsausführung überprüft werden kann. Derzeit unterstützt er nur Aufträge, die `glueContext` initialisieren. Wenn Sie einen reinen Spark-Job ohne Initialisierung ausführen`glueContext`, wird der AWS Glue Fortschrittsbalken nicht angezeigt. Der Fortschrittsbalken wird alle 5 Sekunden aktualisiert. ``` Stage Number (Stage Name): > (numCompletedTasks + numActiveTasks) / totalNumOfTasksInThisStage] ``` ## Sicherheitskonfiguration mit Protokollierung Amazon CloudWatch Wenn eine Sicherheitskonfiguration für Amazon CloudWatch Protokolle aktiviert ist, werden Protokollgruppen mit bestimmten Benennungsmustern AWS Glue erstellt, die den Namen der Sicherheitskonfiguration enthalten. ### Benennung von Protokollgruppen mit Sicherheitskonfiguration Die Standard- und benutzerdefinierten Protokollgruppen lauten wie folgt: + **Standard-Fehlerprotokollgruppe:** `/aws-glue/jobs/Security-Configuration-Name-role/glue-job-role/error` + **Standard-Ausgabeprotokollgruppe:** `/aws-glue/jobs/Security-Configuration-Name-role/glue-job-role/output` + **Benutzerdefinierte Fehlerprotokollgruppe (AWS Glue 5.0):** `custom-log-group-prefix/Security-Configuration-Name-role/glue-job-role/error` + **Benutzerdefinierte Ausgabeloggruppe (AWS Glue 5.0):** `custom-log-group-prefix/Security-Configuration-Name-role/glue-job-role/output` ### Erforderliche IAM-Berechtigungen Sie müssen Ihren IAM-Rollenberechtigungen `logs:AssociateKmsKey`-Berichtigungen hinzufügen, wenn Sie eine Sicherheitskonfiguration mit Amazon CloudWatch  Logs aktivieren. Wenn diese Berechtigung nicht enthalten ist, wird die fortlaufende Protokollierung deaktiviert. Um die Verschlüsselung für die Amazon CloudWatch Logs zu konfigurieren, folgen Sie außerdem den Anweisungen unter [Log Data in Amazon CloudWatch Logs Using verschlüsseln AWS Key Management Service](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html) im Amazon Amazon CloudWatch Logs-Benutzerhandbuch. ### Zusätzliche Informationen Weitere Informationen zum Erstellen von Sicherheitskonfigurationen finden Sie unter [Sicherheitskonfigurationen auf der AWS Glue Konsole verwalten](https://docs.aws.amazon.com/glue/latest/dg/console-security-configurations.html). **Topics** + [Verhalten bei der Protokollierung in 5.0 AWS Glue](#monitor-logging-behavior-glue-50) + [Benutzerdefiniertes Protokollieren](#monitor-logging-custom) + [Protokollieren von anwendungsspezifischen Meldungen mit dem benutzerdefinierten Skript-Logger](#monitor-logging-script) + [Aktivieren des Fortschrittsbalkens zum Anzeigen des Auftragsfortschritts](#monitor-logging-progress) + [Sicherheitskonfiguration mit Protokollierung Amazon CloudWatch](#monitor-security-config-logging) + [Kontinuierliche Protokollierung für Jobs der AWS Glue Version 4.0 und früher aktivieren](monitor-continuous-logging-enable.md) + [Protokolle für AWS Glue Jobs anzeigen](monitor-continuous-logging-view.md) # Kontinuierliche Protokollierung für Jobs der AWS Glue Version 4.0 und früher aktivieren **Anmerkung** In AWS Glue 4.0 und früheren Versionen war die kontinuierliche Protokollierung eine verfügbare Funktion. Mit der Einführung von AWS Glue 5.0 können jedoch alle Jobs in Echtzeit protokolliert werden. Weitere Informationen zu den Protokollierungsfunktionen und Konfigurationsoptionen in AWS Glue 5.0 finden Sie unter [Protokollierung für AWS Glue Jobs](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuous-logging.html). Sie können die kontinuierliche Protokollierung über die AWS Glue Konsole oder über AWS Command Line Interface (AWS CLI) aktivieren. Sie können die kontinuierliche Protokollierung aktivieren, wenn Sie einen neuen Auftrag erstellen oder einen vorhandenen Auftrag bearbeiten bzw. über die AWS CLI aktivieren. Sie können auch benutzerdefinierte Konfigurationsoptionen wie den Namen der Amazon CloudWatch Protokollgruppe, das CloudWatch Protokollstream-Präfix vor der driver/executor ID der AWS Glue Auftragsausführung und das Protokollkonvertierungsmuster für Protokollnachrichten angeben. Diese Konfigurationen helfen Ihnen dabei, aggregierte Protokolle in benutzerdefinierten CloudWatch Protokollgruppen mit unterschiedlichen Ablaufrichtlinien einzurichten und sie mit benutzerdefinierten Logstream-Präfixen und Konvertierungsmustern weiter zu analysieren. **Topics** + [Mit dem AWS-Managementkonsole](#monitor-continuous-logging-enable-console) + [Protokollieren von anwendungsspezifischen Meldungen mit dem benutzerdefinierten Skript-Logger](#monitor-continuous-logging-script) + [Aktivieren des Fortschrittsbalkens zum Anzeigen des Auftragsfortschritts](#monitor-continuous-logging-progress) + [Sicherheitskonfiguration mit kontinuierlicher Protokollierung](#monitor-logging-encrypt-log-data) ## Mit dem AWS-Managementkonsole Gehen Sie wie folgt vor, um mithilfe der Konsole die kontinuierliche Protokollierung beim Erstellen oder Bearbeiten eines AWS Glue Jobs zu aktivieren. **Um einen neuen AWS Glue Job mit kontinuierlicher Protokollierung zu erstellen** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Glue Konsole unter [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/). 1. Wählen Sie im Navigationsbereich die Option **ETL-Aufträge** aus. 1. Wählen Sie **Visual ETL**. 1. Erweitern Sie auf der Registerkarte **Auftragsdetails** den Abschnitt **Erweiterte Eigenschaften**. 1. Wählen Sie unter **Kontinuierliche Protokollierung** die Option **Anmeldungen aktivieren** aus CloudWatch. **Um die kontinuierliche Protokollierung für einen vorhandenen AWS Glue Job zu aktivieren** 1. Öffnen Sie die AWS Glue Konsole unter [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/). 1. Wählen Sie im Navigationsbereich die Option **Jobs (Aufträge)** aus. 1. Wählen Sie einen Auftrag in der Liste **Jobs (Aufträge)** aus. 1. Wählen Sie **Action (Aktion)**, **Edit job (Auftrag bearbeiten)** aus. 1. Erweitern Sie auf der Registerkarte **Auftragsdetails** den Abschnitt **Erweiterte Eigenschaften**. 1. Wählen Sie unter **Kontinuierliche Protokollierung** die Option Anmeldung **aktivieren** aus CloudWatch. ### Verwenden des AWS CLI Um die kontinuierliche Protokollierung zu aktivieren, übergeben Sie Jobparameter an einen AWS Glue Job. Übergeben Sie die folgenden speziellen Job-Parameter, die anderen AWS Glue Job-Parametern ähneln. Weitere Informationen finden Sie unter [Verwenden von Auftragsparametern in AWS Glue-Jobs](aws-glue-programming-etl-glue-arguments.md). ``` '--enable-continuous-cloudwatch-log': 'true' ``` Sie können einen benutzerdefinierten CloudWatch Amazon-Protokollgruppennamen angeben. Sofern nicht angegeben, lautet der Standardname der Protokollgruppe `/aws-glue/jobs/logs-v2`. ``` '--continuous-log-logGroup': 'custom_log_group_name' ``` Sie können ein benutzerdefiniertes CloudWatch Amazon-Logstream-Präfix angeben. Sofern nicht angegeben, ist das standardmäßige Logstream-Präfix die Auftragsausführungs-ID. ``` '--continuous-log-logStreamPrefix': 'custom_log_stream_prefix' ``` Sie können ein benutzerdefiniertes Konvertierungsmuster für die kontinuierliche Protokollierung angeben. Sofern nicht angegeben, ist das Standardkonvertierungsmuster `%d{yy/MM/dd HH:mm:ss} %p %c{1}: %m%n`. Beachten Sie, dass das Konvertierungsmuster nur für Treiberprotokolle und Executor-Protokolle gilt. Dies wirkt sich nicht auf die AWS Glue -Fortschrittsleiste aus. ``` '--continuous-log-conversionPattern': 'custom_log_conversion_pattern' ``` ## Protokollieren von anwendungsspezifischen Meldungen mit dem benutzerdefinierten Skript-Logger Sie können den AWS Glue Logger verwenden, um alle anwendungsspezifischen Meldungen im Skript zu protokollieren, die in Echtzeit an den Treiberprotokollstream gesendet werden. Das folgende Beispiel zeigt ein Python-Skript. ``` from awsglue.context import GlueContext from pyspark.context import SparkContext sc = SparkContext() glueContext = GlueContext(sc) logger = glueContext.get_logger() logger.info("info message") logger.warn("warn message") logger.error("error message") ``` Das folgende Beispiel zeigt ein Scala-Skript. ``` import com.amazonaws.services.glue.log.GlueLogger object GlueApp { def main(sysArgs: Array[String]) { val logger = new GlueLogger logger.info("info message") logger.warn("warn message") logger.error("error message") } } ``` ## Aktivieren des Fortschrittsbalkens zum Anzeigen des Auftragsfortschritts AWS Glue bietet unter dem `JOB_RUN_ID-progress-bar` Protokollstream eine Fortschrittsleiste in Echtzeit, mit der der Status der AWS Glue Auftragsausführung überprüft werden kann. Derzeit unterstützt er nur Aufträge, die `glueContext` initialisieren. Wenn Sie einen reinen Spark-Job ohne Initialisierung ausführen`glueContext`, wird der AWS Glue Fortschrittsbalken nicht angezeigt. Der Fortschrittsbalken wird alle 5 Sekunden aktualisiert. ``` Stage Number (Stage Name): > (numCompletedTasks + numActiveTasks) / totalNumOfTasksInThisStage] ``` ## Sicherheitskonfiguration mit kontinuierlicher Protokollierung Wenn eine Sicherheitskonfiguration für CloudWatch Protokolle aktiviert ist, AWS Glue wird eine Protokollgruppe mit dem folgenden Namen für fortlaufende Protokolle erstellt: ``` - ``` Die Standard- und benutzerdefinierten Protokollgruppen lauten wie folgt: + Die standardmäßige fortlaufende Protokollgruppe lautet `/aws-glue/jobs/error-` + Die benutzerdefinierte fortlaufende Protokollgruppe lautet `-` Sie `logs:AssociateKmsKey` müssen Ihrer IAM-Rollenberechtigungen hinzufügen, wenn Sie eine Sicherheitskonfiguration mit CloudWatch Protokollen aktivieren. Wenn diese Berechtigung nicht enthalten ist, wird die fortlaufende Protokollierung deaktiviert. Um die Verschlüsselung für die CloudWatch Logs zu konfigurieren, folgen Sie außerdem den Anweisungen unter [Log Data in CloudWatch Logs Using verschlüsseln AWS Key Management Service](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html) im *Amazon CloudWatch Logs-Benutzerhandbuch*. Weitere Informationen zum Erstellen einer Sicherheitskonfiguration finden Sie hier: [Verwalten von Sicherheitskonfigurationen in der AWS Glue-Konsole](console-security-configurations.md). **Anmerkung** Es können zusätzliche Gebühren anfallen, wenn Sie die Protokollierung aktivieren und zusätzliche CloudWatch Protokollereignisse erstellt werden. Weitere Informationen finden Sie unter [ CloudWatch Amazon-Preise](https://aws.amazon.com/cloudwatch/pricing/). # Protokolle für AWS Glue Jobs anzeigen Sie können Echtzeitprotokolle über die AWS Glue Konsole oder die CloudWatch Amazon-Konsole anzeigen. **Um Echtzeitprotokolle über das AWS Glue Konsolen-Dashboard anzuzeigen** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Glue Konsole unter [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/). 1. Wählen Sie im Navigationsbereich die Option **Jobs (Aufträge)** aus. 1. Fügen Sie einen Auftrag hinzu oder starten Sie einen vorhandenen Auftrag. Wählen Sie **Action (Aktion)**, **Run job (Auftrag ausführen)** aus. Wenn Sie einen Auftrag starten, navigieren Sie zu einer Seite mit Informationen über den laufenden Auftrag: + Die Registerkarte **Logs (Protokolle)** zeigt die älteren aggregierten Anwendungsprotokolle an. + Die Registerkarte **Protokolle** zeigt einen Echtzeit-Fortschrittsbalken an, wenn der Auftrag ausgeführt wird und `glueContext` initialisiert ist. + Die Registerkarte **Protokolle** enthält auch die **Treiberprotokolle**, in denen Apache Spark-Treiberprotokolle in Echtzeit erfasst werden, und Anwendungsprotokolle aus dem Skript, die mit dem AWS Glue Anwendungslogger protokolliert wurden, während der Job ausgeführt wird. 1. Für ältere Aufträge können Sie auch die Echtzeitprotokolle unter **Job History (Auftragsverlauf)** anzeigen, indem Sie **Jobs (Aufträge)** auswählen. Mit dieser Aktion gelangen Sie zu der CloudWatch Konsole, auf der alle Protokollstreams für Spark-Treiber, Executor und Fortschrittsbalken für diese Jobausführung angezeigt werden. **Um Echtzeitprotokolle über das CloudWatch Konsolen-Dashboard anzuzeigen** 1. Öffnen Sie die CloudWatch Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. Wählen Sie im Navigationsbereich **Log (Protokoll)** aus. 1. Wählen Sie die **Protokollgruppe /aws-glue/jobs/error/**aus. 1. Fügen Sie die Auftragsausführung-ID in das Feld **Filter** ein. Sie können die Treiberprotokolle, die Executor-Protokolle und den Fortschrittsbalken anzeigen (wenn der **Standard filter (Standardfilter)** verwendet wird). # Überwachung mit AWS Glue-Beobachtbarkeitsmetriken **Anmerkung** AWS Glue-Beobachtbarkeitsmetriken sind bei AWS Glue 4.0 und späteren Versionen verfügbar. Nutzen Sie AWS Glue-Beobachtbarkeitsmetriken, um Einblicke in die Abläufe in AWS Glue für Apache Spark zu erhalten. So können Sie die Sichtung und Analyse von Problemen verbessern. Beobachtbarkeitsmetriken werden über Amazon CloudWatch -Dashboards visualisiert und können verwendet werden, um die Ursache von Fehlern zu analysieren und Leistungsengpässe zu diagnostizieren. Sie können den Zeitaufwand für das Debuggen von Problemen reduzieren, sodass Sie sich darauf konzentrieren können, Probleme schneller und effektiver zu lösen. AWS GlueObservability bietet Amazon CloudWatch Metriken, die in die folgenden vier Gruppen unterteilt sind: + **Zuverlässigkeit (d. h. Fehlerklassen)** – Identifizieren Sie ganz einfach die häufigsten Fehlerursachen in einem bestimmten Zeitraum, die Sie möglicherweise beheben möchten. + **Leistung (d. h. Schiefe)** – Identifizieren Sie Leistungsengpässe und wenden Sie Optimierungsmethoden an. Wenn Sie beispielsweise Leistungseinbußen aufgrund von Auftragsschiefe feststellen, können Sie die adaptive Abfrageausführung von Spark aktivieren und den Schwellenwert für schiefe Verknüpfungen anpassen. + **Durchsatz (d. h. pro source/sink Durchsatz)** — Überwachen Sie Trends bei Lese- und Schreibvorgängen von Daten. Sie können auch Amazon CloudWatch Alarme für Anomalien konfigurieren. + **Ressourcenauslastung (d. h. Mitarbeiter, Speicher- und Festplattennutzung)** – Lokalisieren Sie Aufträge mit geringer Kapazitätsauslastung auf effiziente Weise. Für diese Aufträge kann es sinnvoll sein, AWS Glue Auto Scaling zu aktivieren. ## Erste Schritte mit AWS Glue-Beobachtbarkeitsmetriken **Anmerkung** Die neuen Metriken sind standardmäßig in der AWS Glue Studio-Konsole aktiviert. **So konfigurieren Sie Beobachtbarkeitsmetriken in AWS Glue Studio:** 1. Melden Sie sich bei der AWS Glue-Konsole an und wählen Sie im Konsolenmenü die Option **ETL-Aufträge** aus. 1. Klicken Sie im Bereich **Ihre Aufträge** auf den Namen des gewünschten Auftrags. 1. Wählen Sie die Registerkarte **Job details (Auftragsdetails)** aus. 1. Scrollen Sie nach unten, wählen Sie **Erweiterte Eigenschaften** und dann **Metriken zur Auftragsbeobachtbarkeit** aus. ![\[Der Screenshot zeigt die Registerkarte „Erweiterte Eigenschaften“ in den Auftragsdetails. Die Option „Metriken zur Auftragsbeobachtbarkeit“ ist hervorgehoben.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/job-details-observability-metrics.png) **Um AWS Glue Observability-Metriken zu aktivieren, verwenden Sie: AWS CLI** + Fügen Sie der `--default-arguments`-Zuordnung in der JSON-Eingabedatei den folgenden Schlüsselwert hinzu: ``` --enable-observability-metrics, true ``` ## Verwenden der AWS Glue-Beobachtbarkeit Da die AWS Glue Observability-Metriken über bereitgestellt werden Amazon CloudWatch, können Sie die Amazon CloudWatch Konsole, das SDK oder die API verwenden AWS CLI, um die Datenpunkte der Observability-Metriken abzufragen. Ein Anwendungsbeispiel für die Verwendung von AWS Glue-Beobachtbarkeitsmetriken finden Sie unter [Verwenden von Glue-Beobachtbarkeit für die Überwachung der Ressourcennutzung zur Kostensenkung](https://aws.amazon.com/blogs/big-data/enhance-monitoring-and-debugging-for-aws-glue-jobs-using-new-job-observability-metrics/). ### Observability in der Konsole verwenden AWS Glue Amazon CloudWatch **Um Metriken in der Amazon CloudWatch Konsole abzufragen und zu visualisieren:** 1. Öffnen Sie die Amazon CloudWatch Konsole und wählen Sie **Alle Metriken** aus. 1. Wählen Sie unter „Benutzerdefinierte Namespaces“ **AWS Glue** aus. 1. Wählen Sie **„Metriken zur Auftragsbeobachtbarkeit“, „Beobachtbarkeitsmetriken pro Quelle“ oder „Beobachtbarkeitsmetriken pro Senke“** aus. 1. Suchen Sie nach dem gewünschten Metrik- und Auftragsnamen sowie der Auftragsausführungs-ID und wählen Sie sie aus. 1. Konfigurieren Sie auf der Registerkarte **Grafische Metriken** Ihre bevorzugte Statistik, den Zeitraum und andere Optionen. ![\[Der Screenshot zeigt die Amazon CloudWatch Konsole und das Metrikdiagramm.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/cloudwatch-console-metrics.png) **Um eine Observability-Metrik abzufragen, verwenden Sie AWS CLI:** 1. Erstellen Sie eine JSON-Datei mit einer Metrikdefinition und ersetzen Sie `your-Glue-job-name` und `your-Glue-job-run-id` mit Ihren Werten. ``` $ cat multiplequeries.json [ { "Id": "avgWorkerUtil_0", "MetricStat": { "Metric": { "Namespace": "Glue", "MetricName": "glue.driver.workerUtilization", "Dimensions": [ { "Name": "JobName", "Value": "" }, { "Name": "JobRunId", "Value": "" }, { "Name": "Type", "Value": "gauge" }, { "Name": "ObservabilityGroup", "Value": "resource_utilization" } ] }, "Period": 1800, "Stat": "Minimum", "Unit": "None" } }, { "Id": "avgWorkerUtil_1", "MetricStat": { "Metric": { "Namespace": "Glue", "MetricName": "glue.driver.workerUtilization", "Dimensions": [ { "Name": "JobName", "Value": "" }, { "Name": "JobRunId", "Value": "" }, { "Name": "Type", "Value": "gauge" }, { "Name": "ObservabilityGroup", "Value": "resource_utilization" } ] }, "Period": 1800, "Stat": "Minimum", "Unit": "None" } } ] ``` 1. Führen Sie den Befehl `get-metric-data` aus: ``` $ aws cloudwatch get-metric-data --metric-data-queries file: //multiplequeries.json \ --start-time '2023-10-28T18: 20' \ --end-time '2023-10-28T19: 10' \ --region us-east-1 { "MetricDataResults": [ { "Id": "avgWorkerUtil_0", "Label": "", "Timestamps": [ "2023-10-28T18:20:00+00:00" ], "Values": [ 0.06718750000000001 ], "StatusCode": "Complete" }, { "Id": "avgWorkerUtil_1", "Label": "", "Timestamps": [ "2023-10-28T18:50:00+00:00" ], "Values": [ 0.5959183673469387 ], "StatusCode": "Complete" } ], "Messages": [] } ``` ## Beobachtbarkeitsmetriken AWS GlueObservability erstellt Profile und sendet die folgenden Metriken Amazon CloudWatch alle 30 Sekunden. Einige dieser Metriken können auf der Seite „AWS Glue StudioJob Runs Monitoring“ angezeigt werden. | Metrik | Description | Kategorie | | --- | --- | --- | | glue.driver.skewness.stage | Metrikkategorie: job\$1performance Ausführungsschiefe von Spark-Phasen: Diese Metrik gibt an, wie lange die maximale Aufgabendauer in einer bestimmten Phase im Vergleich zur mittleren Aufgabendauer in dieser Phase ist. Diese Metrik erfasst Abweichungen bei der Ausführung, die durch schiefe Eingabedaten oder durch eine Transformation (z. B. schiefe Verknüpfung) verursacht werden. Die Werte dieser Metrik fallen in den Bereich [0, unendlich[, wobei 0 bedeutet, dass der Unterschied zwischen der maximalen und der mittleren Ausführungszeit von Aufgaben in der Phase weniger beträgt als ein bestimmter Phasenabweichungsfaktor. Der Standardschiefefaktor von Phasen ist „5“ und kann mit dieser Spark-Konfiguration überschrieben werden: spark.metrics.conf.driver.source.glue.jobPerformance.skewnessFactor Ein Wert von 1 für die Phasenabweichung bedeutet, dass der Unterschied das Doppelte des Abweichungsfaktors der Phase beträgt. Der Wert für die Phasenschiefe wird alle 30 Sekunden aktualisiert, um die aktuelle Schiefe widerzuspiegeln. Der Wert am Ende der Phase spiegelt die finale Schiefe der Phase wider. Diese Metrik auf Stufenebene wird verwendet, um die Metrik auf Auftragsebene `glue.driver.skewness.job` zu berechnen. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Typ (Gauge) und ObservabilityGroup (job\$1performance) Gültige Statistiken: Durchschnitt, Maximum, Minimum, Prozent Einheit: Anzahl | job\$1performance | | glue.driver.skewness.job | Metrikkategorie: job\$1performance Die Auftragsschiefe ist das Maximum der gewichteten Schiefe aller Phasen. Die Schiefe der Phase (glue.driver.skewness.stage) wird mit der Dauer der Phase gewichtet. Auf diese Weise soll der Ausnahmefall vermieden werden, bei dem eine stark schiefe Phase im Vergleich zu anderen Phasen tatsächlich nur für eine sehr kurze Zeit ausgeführt wird (und ihre Abweichung daher für die gesamte Auftragsleistung nicht signifikant ist und es sich nicht lohnt, diese Abweichung zu beheben). Diese Metrik wird nach Abschluss jeder Phase aktualisiert, sodass der letzte Wert die tatsächliche Gesamtabweichung des Auftrags widerspiegelt. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Typ (Gauge) und ObservabilityGroup (job\$1performance) Gültige Statistiken: Durchschnitt, Maximum, Minimum, Prozent Einheit: Anzahl | job\$1performance | | glue.succeed.ALL | Metrikkategorie: Fehler Gesamtzahl der erfolgreichen Auftragsausführungen, für ein vollständiges Bild der Fehlerkategorien Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Typ (Anzahl) und ObservabilityGroup (Fehler) Gültige Statistiken: SUM Einheit: Anzahl | error | | glue.error.ALL | Metrikkategorie: Fehler Gesamtzahl der Fehler bei Auftragsausführungen, für ein vollständiges Bild der Fehlerkategorien Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Typ (Anzahl) und ObservabilityGroup (Fehler) Gültige Statistiken: SUM Einheit: Anzahl | error | | glue.error.[Fehlerkategorie] | Metrikkategorie: Fehler Dabei handelt es sich um eine Reihe von Metriken, die nur aktualisiert werden, wenn eine Auftragsausführung fehlschlägt. Die Fehlerkategorisierung hilft bei der Analyse und dem Debugging. Wenn eine Auftragsausführung fehlschlägt, wird der Fehler, der dazu geführt hat, kategorisiert und die entsprechende Metrik für die Fehlerkategorie wird auf 1 gesetzt. Dies hilft bei der Durchführung von Fehleranalysen im Zeitverlauf sowie bei der Fehleranalyse für alle Jobs, um die häufigsten Fehlerkategorien zu identifizieren und sie zu beheben. AWS Glue hat 28 Fehlerkategorien, darunter OUT\$1OF\$1MEMORY (Treiber und Executor), PERMISSION, SYNTAX und THROTTLING. Weitere Fehlerkategorien sind unter anderem COMPILATION, LAUNCH und TIMEOUT. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Typ (Anzahl) und ObservabilityGroup (Fehler) Gültige Statistiken: SUM Einheit: Anzahl | error | | glue.driver.workerUtilization | Metrikkategorie: resource\$1utilization Der Prozentsatz der zugewiesenen Arbeitskräfte, die tatsächlich eingesetzt werden. Wenn nicht gut, kann Auto Scaling helfen. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt, Maximum, Minimum, Prozent Einheit: Prozentsatz | resource\$1utilization | | glue.driver.memory.heap.[verfügbar \$1 belegt] | Metrikkategorie: resource\$1utilization Der verfügbare/belegte Heap-Speicher des Treibers während der Auftragsausführung. Dies hilft, Trends bei der Speichernutzung zu verstehen, insbesondere im Zeitverlauf, wodurch potenzielle Ausfälle vermieden werden. Außerdem können Ausfälle im Zusammenhang mit Speicher behoben werden. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Byte | resource\$1utilization | | glue.driver.memory.heap.used.percentage | Metrikkategorie: resource\$1utilization Der belegte Heap-Speicher des Treibers während der Auftragsausführung (in %). Dies hilft, Trends bei der Speichernutzung zu verstehen, insbesondere im Zeitverlauf, wodurch potenzielle Ausfälle vermieden werden. Außerdem können Ausfälle im Zusammenhang mit Speicher behoben werden. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Prozentsatz | resource\$1utilization | | glue.driver.memory.non-heap.[verfügbar \$1 belegt] | Metrikkategorie: resource\$1utilization Der verfügbare/belegte Non-Heap-Speicher des Treibers während der Auftragsausführung. Dies hilft, Trends bei der Speichernutzung zu verstehen, insbesondere im Zeitverlauf, wodurch potenzielle Ausfälle vermieden werden. Außerdem können Ausfälle im Zusammenhang mit Speicher behoben werden. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Byte | resource\$1utilization | | glue.driver.memory.non-heap.used.percentage | Metrikkategorie: resource\$1utilization Der belegte Non-Heap-Speicher des Treibers während der Auftragsausführung (in %). Dies hilft, Trends bei der Speichernutzung zu verstehen, insbesondere im Zeitverlauf, wodurch potenzielle Ausfälle vermieden werden. Außerdem können Ausfälle im Zusammenhang mit Speicher behoben werden. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Prozentsatz | resource\$1utilization | | glue.driver.memory.total.[verfügbar \$1 belegt] | Metrikkategorie: resource\$1utilization Der verfügbare/belegte Gesamtspeicher des Treibers während der Auftragsausführung. Dies hilft, Trends bei der Speichernutzung zu verstehen, insbesondere im Zeitverlauf, wodurch potenzielle Ausfälle vermieden werden. Außerdem können Ausfälle im Zusammenhang mit Speicher behoben werden. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Byte | resource\$1utilization | | glue.driver.memory.total.used.percentage | Metrikkategorie: resource\$1utilization Der belegte Gesamtspeicher des Treibers während der Auftragsausführung (in %). Dies hilft, Trends bei der Speichernutzung zu verstehen, insbesondere im Zeitverlauf, wodurch potenzielle Ausfälle vermieden werden. Außerdem können Ausfälle im Zusammenhang mit Speicher behoben werden. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Prozentsatz | resource\$1utilization | | glue.ALL.memory.heap.[verfügbar \$1 belegt] | Metrikkategorie: resource\$1utilization Der Heap-Speicher der Executoren. available/used ALL bedeutet alle Executoren. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Byte | resource\$1utilization | | glue.ALL.memory.heap.used.percentage | Metrikkategorie: resource\$1utilization Der belegte Heap-Speicher der Executoren (in %). ALL bedeutet alle Executoren. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Prozentsatz | resource\$1utilization | | glue.ALL.memory.non-heap.[verfügbar \$1 belegt] | Metrikkategorie: resource\$1utilization Der Non-Heap-Speicher der Executoren. available/used ALL bedeutet alle Executoren. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Byte | resource\$1utilization | | glue.ALL.memory.non-heap.used.percentage | Metrikkategorie: resource\$1utilization Der belegte Non-Heap-Speicher der Executoren (in %). ALL bedeutet alle Executoren. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Prozentsatz | resource\$1utilization | | glue.ALL.memory.total.[verfügbar \$1 belegt] | Metrikkategorie: resource\$1utilization Der gesamte Arbeitsspeicher der Executer. available/used ALL bedeutet alle Executoren. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Byte | resource\$1utilization | | glue.ALL.memory.total.used.percentage | Metrikkategorie: resource\$1utilization Der belegte Gesamtspeicher der Executoren (in %). ALL bedeutet alle Executoren. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Prozentsatz | resource\$1utilization | | glue.driver.disk.[available\$1GB \$1 used\$1GB] | Metrikkategorie: resource\$1utilization Der available/used Festplattenspeicher des Treibers während der Ausführung des Jobs. Dies hilft, Trends bei der Festplattennutzung zu verstehen, insbesondere im Zeitverlauf, wodurch potenzielle Ausfälle vermieden werden. Außerdem können Ausfälle im Zusammenhang mit zu wenig Festplattenspeicher behoben werden. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Gigabyte | resource\$1utilization | | glue.driver.disk.used.percentage] | Metrikkategorie: resource\$1utilization Der available/used Festplattenspeicher des Treibers während der Ausführung des Jobs. Dies hilft, Trends bei der Festplattennutzung zu verstehen, insbesondere im Zeitverlauf, wodurch potenzielle Ausfälle vermieden werden. Außerdem können Ausfälle im Zusammenhang mit zu wenig Festplattenspeicher behoben werden. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Prozentsatz | resource\$1utilization | | glue.ALL.disk.[available\$1GB \$1 used\$1GB] | Metrikkategorie: resource\$1utilization Der Festplattenspeicher der Executoren. available/used ALL bedeutet alle Executoren. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Gigabyte | resource\$1utilization | | glue.ALL.disk.used.percentage | Metrikkategorie: resource\$1utilization Der Festplattenspeicher (%) der Executorenavailable/used/used. ALL bedeutet alle Executoren. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID. oder ALL), Type (Gauge) und ObservabilityGroup (resource\$1utilization) Gültige Statistiken: Durchschnitt Einheit: Prozentsatz | resource\$1utilization | | glue.driver.bytesRead | Metrikkategorie: Durchsatz Die Anzahl der in dieser Auftragsausführung pro Eingabequelle sowie für ALL-Quellen gelesenen Byte. Dies hilft, das Datenvolumen und seine Veränderungen im Laufe der Zeit besser zu verstehen und Probleme wie Datenabweichungen zu lösen. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Type (Gauge), ObservabilityGroup (resource\$1utilization) und Source (Quelldatenposition) Gültige Statistiken: Durchschnitt Einheit: Byte | Durchsatz | | glue.driver.[recordsRead \$1 filesRead] | Metrikkategorie: Durchsatz Die Anzahl der records/files Lesevorgänge pro Eingabequelle in dieser Auftragsausführung sowie für ALLE Quellen. Dies hilft, das Datenvolumen und seine Veränderungen im Laufe der Zeit besser zu verstehen und Probleme wie Datenabweichungen zu lösen. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Type (Gauge), ObservabilityGroup (resource\$1utilization) und Source (Quelldatenposition) Gültige Statistiken: Durchschnitt Einheit: Anzahl | Durchsatz | | glue.driver.partitionsRead | Metrikkategorie: Durchsatz Die Anzahl der in dieser Auftragsausführung pro Amazon-S3-Eingabequelle sowie für ALL-Quellen gelesenen Partitionen. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Type (Gauge), ObservabilityGroup (resource\$1utilization) und Source (Quelldatenposition) Gültige Statistiken: Durchschnitt Einheit: Anzahl | Durchsatz | | glue.driver.bytesWritten | Metrikkategorie: Durchsatz Die Anzahl der in dieser Auftragsausführung pro Ausgabe-Sink sowie für ALL-Sinks geschriebenen Byte. Dies hilft, das Datenvolumen und seine Entwicklung im Laufe der Zeit besser zu verstehen und Probleme wie Verarbeitungsabweichungen zu lösen. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Type (Gauge), ObservabilityGroup (resource\$1utilization) und Sink (Speicherort der Senkendaten) Gültige Statistiken: Durchschnitt Einheit: Byte | Durchsatz | | glue.driver.[recordsWritten \$1 filesWritten] | Metrikkategorie: Durchsatz Die Anzahl der records/files Schreibvorgänge pro Ausgabesenke in dieser Auftragsausführung sowie für ALLE Senken. Dies hilft, das Datenvolumen und seine Entwicklung im Laufe der Zeit besser zu verstehen und Probleme wie Verarbeitungsabweichungen zu lösen. Gültige Dimensionen: JobName (der Name des AWS Glue Job), JobRunId (die JobRun ID oder ALL), Type (Gauge), ObservabilityGroup (resource\$1utilization) und Sink (Speicherort der Senkendaten) Gültige Statistiken: Durchschnitt Einheit: Anzahl | Durchsatz | ## Fehlerkategorien | Fehlerkategorien | Description | | --- | --- | | COMPILATION\$1ERROR | Bei der Kompilierung von Scala-Code treten Fehler auf. | | CONNECTION\$1ERROR | Beim Herstellen einer Verbindung zu einem service/remote Host-/Datenbankdienst usw. treten Fehler auf. | | DISK\$1NO\$1SPACE\$1ERROR | Wenn auf der Festplatte des Treibers/Executors kein Speicherplatz mehr vorhanden ist, treten Fehler auf. | | OUT\$1OF\$1MEMORY\$1ERROR | Wenn auf dem Speicher des Treibers/Executors kein Speicherplatz mehr vorhanden ist, treten Fehler auf. | | IMPORT\$1ERROR | Beim Import von Abhängigkeiten treten Fehler auf. | | INVALID\$1ARGUMENT\$1ERROR | Wenn die Eingabeargumente ungültig/illegal sind, treten Fehler auf. | | PERMISSION\$1ERROR | Wenn die Genehmigung für Services, Daten usw. fehlt, treten Fehler auf. | | RESOURCE\$1NOT\$1FOUND\$1ERROR | Wenn Daten, Speicherorte usw. nicht existieren, treten Fehler auf. | | QUERY\$1ERROR | Bei der Ausführung von Spark-SQL-Abfragen treten Fehler auf. | | SYNTAX\$1ERROR | Wenn das Skript einen Syntaxfehler enthält, treten Fehler auf. | | THROTTLING\$1ERROR | Wenn die Beschränkung der Parallelität von Services erreicht oder die Beschränkung der Service Quotas überschritten wird, treten Fehler auf. | | DATA\$1LAKE\$1FRAMEWORK\$1ERROR | Aufgrund von nativ AWS Glue-unterstützten Data-Lake-Frameworks wie Hudi, Iceberg usw. treten Fehler auf. | | UNSUPPORTED\$1OPERATION\$1ERROR | Wenn ein Vorgang ausgeführt wird, der nicht unterstützt wird, treten Fehler auf. | | RESOURCES\$1ALREADY\$1EXISTS\$1ERROR | Wenn eine Ressource, die erstellt oder hinzugefügt werden soll, bereits vorhanden ist, treten Fehler auf. | | GLUE\$1INTERNAL\$1SERVICE\$1ERROR | Wenn ein internes Problem mit dem AWS Glue-Service vorliegt, treten Fehler auf. | | GLUE\$1OPERATION\$1TIMEOUT\$1ERROR | Wenn bei einem AWS Glue-Vorgang eine Zeitüberschreitung eintritt, treten Fehler auf. | | GLUE\$1VALIDATION\$1ERROR | Wenn ein erforderlicher Wert nicht für den AWS Glue-Auftrag validiert werden konnte, treten Fehler auf. | | GLUE\$1JOB\$1BOOKMARK\$1VERSION\$1MISMATCH\$1ERROR | Fehler treten auf, wenn derselbe Job denselben Quell-Bucket exoniert und gleichzeitig in das same/different Ziel schreibt (Parallelität >1) | | LAUNCH\$1ERROR | Während der Startphase des AWS Glue-Auftrags treten Fehler auf. | | DYNAMODB\$1ERROR | Generische Fehler entstehen durch den Service. Amazon DynamoDB | | GLUE\$1ERROR | Der AWS Glue-Service ruft generische Fehler hervor. | | LAKEFORMATION\$1ERROR | Generische Fehler entstehen durch AWS Lake Formation den Service. | | REDSHIFT\$1ERROR | Generische Fehler entstehen durch Amazon Redshift den Service. | | S3\$1ERROR | Der Amazon–S3-Service ruft generische Fehler hervor. | | SYSTEM\$1EXIT\$1ERROR | Generischer Fehler beim Beenden des Systems. | | TIMEOUT\$1ERROR | Wenn der Auftrag aufgrund eines Timeouts fehlschlägt, treten generische Fehler auf. | | UNCLASSIFIED\$1SPARK\$1ERROR | Spark ruft generische Fehler hervor. | | UNCLASSIFIED\$1ERROR | Standard-Fehlerkategorie. | ## Einschränkungen **Anmerkung** `glueContext` muss initialisiert werden, um die Metriken zu veröffentlichen. In der Quelldimension ist der Wert je nach Quelltyp entweder ein Amazon-S3-Pfad oder Tabellenname. Wenn es sich bei der Quelle um JDBC handelt und die Abfrageoption verwendet wird, wird die Abfragezeichenfolge außerdem in der Quelldimension festgelegt. Wenn der Wert länger als 500 Zeichen ist, wird er auf 500 Zeichen gekürzt. Für den Wert gelten folgende Einschränkungen: + Nicht-ASCII-Zeichen werden entfernt. + Wenn der Quellname kein ASCII-Zeichen enthält, wird er in umgewandelt. ### Einschränkungen und Überlegungen zu Durchsatzmetriken + DataFrame und DataFrame based DynamicFrame (z. B. JDBC, Lesen von Parquet auf Amazon S3) werden unterstützt, RDD-basiert DynamicFrame (z. B. Lesen von CSV, JSON auf Amazon S3 usw.) wird jedoch nicht unterstützt. Technisch gesehen werden alle Lese- und Schreibvorgänge, die auf der Spark-Benutzeroberfläche sichtbar sind, unterstützt. + Die `recordsRead`-Metrik wird ausgegeben, wenn es sich bei der Datenquelle um eine Katalogtabelle handelt und das Format JSON, CSV, Text oder Iceberg ist. + Die Metriken `glue.driver.throughput.recordsWritten`, `glue.driver.throughput.bytesWritten` und `glue.driver.throughput.filesWritten` sind in JDBC- und Iceberg-Tabellen nicht verfügbar. + Metriken können verzögert sein. Wenn der Job in etwa einer Minute abgeschlossen ist, gibt es unter Metrics möglicherweise keine Durchsatzmetriken. Amazon CloudWatch # Auftragsüberwachung und Debugging Sie können Kennzahlen zu AWS Glue Jobs sammeln und diese auf den CloudWatch Konsolen AWS Glue und Amazon visualisieren, um Probleme zu identifizieren und zu beheben. Die Profilierung Ihrer AWS Glue-Aufträge erfordert die folgenden Schritte: 1. Metriken aktivieren: 1. Aktivieren der Option **Job metrics (Auftragsmetriken)** in der Auftragsdefinition. Sie können die Profilierung in der AWS Glue-Konsole oder als Parameter für den Auftrag aktivieren. Weitere Informationen finden Sie unter [Definieren von Auftragseigenschaften für Spark-Aufträge](add-job.md#create-job) oder [Verwenden von Auftragsparametern in AWS Glue-Jobs](aws-glue-programming-etl-glue-arguments.md). 1. Aktivieren der Option **AWS Glue-Beobachtbarkeitsmetriken** in der Auftragsdefinition. Sie können die Beobachtbarkeit in der AWS Glue-Konsole oder als Parameter für den Auftrag aktivieren. Weitere Informationen finden Sie unter [Überwachung mit AWS Glue-Beobachtbarkeitsmetriken](monitor-observability.md). 1. Vergewissern Sie sich, dass das Auftragsskript einen `GlueContext` initialisiert. Beispiel: Der folgende Skriptausschnitt initialisiert einen `GlueContext` und zeigt, wo der profilierte Code im Skript platziert wird. Dieses allgemeine Format wird in den folgenden Debugging-Szenarien verwendet. ``` import sys from awsglue.transforms import * from awsglue.utils import getResolvedOptions from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job import time ## @params: [JOB_NAME] args = getResolvedOptions(sys.argv, ['JOB_NAME']) sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session job = Job(glueContext) job.init(args['JOB_NAME'], args) ... ... code-to-profile ... ... job.commit() ``` 1. Führen Sie den Auftrag aus. 1. Metriken visualisieren: 1. Sie können die Auftragsmetriken in der AWS Glue-Konsole visualisieren und abnormale Metriken des Treibers oder Executors identifizieren. 1. Überprüfen Sie die Messwerte zur Beobachtbarkeit auf der Seite zur Überwachung von Jobläufen, auf der Seite mit den Details zur Jobausführung oder bei Amazon CloudWatch. Weitere Informationen finden Sie unter [Überwachung mit AWS Glue-Beobachtbarkeitsmetriken](monitor-observability.md). 1. Grenzen Sie die Ursache mithilfe der identifizierten Metrik ein. 1. Optional bestätigen Sie die Ursache mithilfe des Protokollstreams des identifizierten Treibers oder Auftrags-Executors. **Anwendungsfälle für AWS Glue-Beobachtbarkeitsmetriken** + [Debuggen von OOM-Ausnahmen und Auftragsabweichungen](monitor-profile-debug-oom-abnormalities.md) + [Debugging von anspruchsvolle Phasen und Straggler-Aufgaben](monitor-profile-debug-straggler.md) + [Überwachen des Fortschritts mehrerer Aufträge](monitor-debug-multiple.md) + [Überwachung für die DPU-Kapazitätsplanung](monitor-debug-capacity.md) + [ Verwenden der AWS Glue-Beobachtbarkeit zur Überwachung der Ressourcennutzung zur Kostensenkung ](https://aws.amazon.com/blogs/big-data/enhance-monitoring-and-debugging-for-aws-glue-jobs-using-new-job-observability-metrics) # Debuggen von OOM-Ausnahmen und Auftragsabweichungen Sie können Ausnahmen und Jobanomalien in out-of-memory (OOM) debuggen. AWS Glue In den folgenden Abschnitten werden Szenarien für das Debuggen von out-of-memory Ausnahmen des Apache Spark-Treibers oder eines Spark-Executors beschrieben. + [Debuggen einer OOM-Ausnahme für einen Treiber](#monitor-profile-debug-oom-driver) + [Debuggen einer OOM-Ausnahme eines Executors](#monitor-profile-debug-oom-executor) ## Debuggen einer OOM-Ausnahme für einen Treiber In diesem Szenario liest ein Spark-Auftrag eine große Anzahl von kleinen Dateien von Amazon Simple Storage Service (Amazon S3). Er wandelt die Dateien in das Apache-Parquet-Format um und schreibt sie in Amazon S3. Der Spark-Treiber verfügt nicht mehr über genügend Arbeitsspeicher. Die eingegebenen Amazon-S3-Daten umfassen mehr als 1 Million Dateien in verschiedenen Amazon-S3-Partitionen. Der profilierte Code sieht wie folgt aus: ``` data = spark.read.format("json").option("inferSchema", False).load("s3://input_path") data.write.format("parquet").save(output_path) ``` ### Visualisieren Sie die profilierten Metriken auf der Konsole AWS Glue Das folgende Diagramm zeigt die Speicherauslastung als Prozentsatz für den Treiber und Executors. Diese Nutzung wird als ein Datenpunkt dargestellt, gemittelt über die Werte in der letzten Minute. Sie sehen im Speicherprofil des Auftrags, dass der [Speicher für den Treiber](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.jvm.heap.usage) die sichere Schwelle von 50 Prozent Auslastung schnell überschreitet. Zum anderen ist die [durchschnittliche Speicherauslastung](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) für alle Executors nach wie vor kleiner als 4 Prozent. Dies zeigt deutlich Anomalien bei der Treiberausführung in diesem Spark-Auftrag. ![\[Die Speichernutzung in Prozent für den Treiber und Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-memoryprofile.png) Die Auftragsausführung schlägt schnell fehl und der folgende Fehler wird in der AWS Glue-Konsole auf der Registerkarte **History (Verlauf)** angezeigt: Command Failed mit Exit Code 1 (Fehler mit Exit-Code 1 fehlgeschlagen). Diese Fehlermeldung bedeutet, dass der Auftrag aufgrund eines systemischen Fehlers fehlgeschlagen ist. In diesem Fall steht dem Treiber nicht genügend Arbeitsspeicher zur Verfügung. ![\[Die Fehlermeldung auf der AWS Glue-Konsole.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-errorstring.png) Wählen Sie auf der Konsole auf der Registerkarte **Verlauf** den Link **Fehlerprotokolle** aus, um zu bestätigen, dass Sie in den CloudWatch Protokollen den Treiber-OOM gefunden haben. Suchen Sie in den Fehlerprotokollen des Auftrags nach "**Error**" (Fehler), um zu bestätigen, dass es tatsächlich eine OOM-Ausnahme war, aufgrund derer der Auftrag fehlgeschlagen ist: ``` # java.lang.OutOfMemoryError: Java heap space # -XX:OnOutOfMemoryError="kill -9 %p" # Executing /bin/sh -c "kill -9 12039"... ``` Wählen Sie auf der Registerkarte **History (Verlauf)** für den Auftrag die Option **Logs (Protokolle)**. Zu Beginn des Jobs finden Sie in den CloudWatch Protokollen den folgenden Verlauf der Treiberausführung. Der Spark-Treiber versucht, alle Dateien in allen Verzeichnissen aufzulisten, erzeugt einen `InMemoryFileIndex` und startet eine Aufgabe pro Datei. Dies wiederum führt dazu, dass der Spark-Treiber eine große Datenmenge im Arbeitsspeicher halten muss, um den Status aller Aufgaben zu verfolgen. Er speichert die vollständige Liste einer großen Anzahl von Dateien für den In-Memory-Index im Cache, was zu einem OOM-Fehler für den Treiber führt. ### Korrigieren Sie die Verarbeitung von mehreren Dateien unter Verwendung einer Gruppierung Sie können die Verarbeitung mehrerer Dateien korrigieren, indem Sie die *Gruppierungsfeature* in AWS Glue anwenden. Die Gruppierung wird automatisch aktiviert, wenn Sie dynamische Frames verwenden und wenn das Eingabe-Dataset eine große Anzahl von Dateien (mehr als 50.000) enthält. Die Gruppierung ermöglicht es Ihnen, mehrere Dateien zu einer Gruppe zusammenzufassen, und erlaubt es einer Aufgabe, die gesamte Gruppe statt einer einzelnen Datei zu bearbeiten. Infolgedessen speichert der Spark-Treiber deutlich weniger Status im Speicher, um weniger Aufgaben zu verfolgen. Weitere Informationen zum manuellen Aktivieren der Gruppierung für Ihre Datasets finden Sie unter [Zusammenfassen von Eingabedateien in größeren Gruppen beim Lesen](grouping-input-files.md). Um das Speicherprofil des AWS Glue-Auftrags zu überprüfen, müssen Sie den folgenden Code mit aktivierter Gruppierung profilieren: ``` df = glueContext.create_dynamic_frame_from_options("s3", {'paths': ["s3://input_path"], "recurse":True, 'groupFiles': 'inPartition'}, format="json") datasink = glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet", transformation_ctx = "datasink") ``` Sie können das Speicherprofil und die ETL-Datenbewegung im AWS Glue-Auftragsprofil überwachen. Der Treiber wird über die gesamte Laufzeit des AWS Glue-Auftrags unterhalb der Schwelle von 50 Prozent Speicherverbrauch ausgeführt. Die Executors streamen die Daten von Amazon S3, verarbeiten sie und schreiben sie in Amazon S3. Dadurch verbrauchen sie zu jedem Zeitpunkt weniger als 5 Prozent Speicherplatz. ![\[Das Speicherprofil zeigt, dass das Problem behoben ist.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-memoryprofile-fixed.png) Das folgende Datenbewegungsprofil zeigt die Gesamtzahl der Amazon-S3-Bytes, die beim Auftragsfortschritt in der letzten Minute von allen Executors [gelesen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) und [geschrieben](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) wurden. Beide folgen einem ähnlichen Muster, da die Daten über alle Executors gestreamt werden. Der Auftrag verarbeitet alle eine Million Dateien in weniger als drei Stunden. ![\[Das Datenbewegungsprofil zeigt, dass das Problem behoben ist.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-etlmovement.png) ## Debuggen einer OOM-Ausnahme eines Executors In diesem Szenario erfahren Sie, wie Sie OOM-Ausnahmen debuggen, die in Apache Spark Executors auftreten können. Der folgende Code verwendet den Spark MySQL-Reader, um eine große Tabelle mit etwa 34 Millionen Zeilen in einen Spark DataFrame einzulesen. Anschließend schreibt es ihn im Parquet-Format in Amazon S3. Sie können die Verbindungseigenschaften angeben und die Standardkonfigurationen von Spark verwenden, um die Tabelle zu lesen. ``` val connectionProperties = new Properties() connectionProperties.put("user", user) connectionProperties.put("password", password) connectionProperties.put("Driver", "com.mysql.jdbc.Driver") val sparkSession = glueContext.sparkSession val dfSpark = sparkSession.read.jdbc(url, tableName, connectionProperties) dfSpark.write.format("parquet").save(output_path) ``` ### Visualisieren der profilierten Metriken auf der AWS Glue-Konsole Wenn die Steigung des Speicherauslastungsdiagramms positiv ist und 50 Prozent überschreitet und der Auftrag fehlschlägt, bevor die nächste Metrik ausgegeben wird, wird dies wahrscheinlich durch aufgebrauchten Speicher verursacht. Das folgende Diagramm zeigt, dass innerhalb einer Minute der Ausführung die [durchschnittliche Speicherauslastung](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) in allen Executors schnell über 50 Prozent steigt. Die Nutzung erreicht bis zu 92 Prozent und der Container, der den Executor ausführt, wird von Apache Hadoop YARN beendet. ![\[Die durchschnittliche Speicherauslastung in allen Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-2-memoryprofile.png) Wie die folgende Grafik zeigt, wird immer ein [einzelner Executor](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors) ausgeführt, bis der Auftrag fehlschlägt. Dies liegt daran, dass ein neuer Executor gestartet wird, um den beendeten Executor zu ersetzen. Die Lesevorgänge der JDBC-Datenquelle sind standardmäßig nicht parallelisiert, da dies eine Partitionierung der Tabelle für eine Spalte und das Öffnen mehrerer Verbindungen erforderlich machen würde. Dies bewirkt, dass nur ein Executor die vollständige Tabelle sequenziell liest. ![\[Die Auftragsausführung zeigt, dass ein einzelner Executor aktiv ist, bis der Auftrag fehlschlägt.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-2-execution.png) Wie die folgende Grafik zeigt, versucht Spark viermal, eine neue Aufgabe zu starten, bevor der Auftrag fehlschlägt. Sie sehen das [Speicherprofil](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.used) von drei Executors. Jeder Executor verbraucht schnell seinen gesamten Arbeitsspeicher. Der vierte Executor hat nicht mehr genügend Speicherplatz, und der Auftrag schlägt fehl. Aus diesem Grund wird die Metrik nicht sofort gemeldet. ![\[Die Speicherprofile der Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-2-exec-memprofile.png) Sie können anhand der Fehlerzeichenfolge auf der AWS Glue-Konsole bestätigen, dass der Auftrag aufgrund von OOM-Ausnahmen fehlgeschlagen ist, wie im folgenden Bild gezeigt. ![\[Die Fehlermeldung auf der AWS Glue-Konsole.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-2-errorstring.png) **Jobausgabeprotokolle:** Weitere Informationen zur Bestätigung Ihrer Feststellung einer Executor-OOM-Ausnahme finden Sie in den CloudWatch Protokollen. Wenn Sie nach **Error** suchen, finden Sie zuerst die vier Executors, die etwa in denselben Zeitfenstern beendet wurden, wie auf dem Metriken-Dashboard gezeigt. Alle werden von YARN beendet, wenn sie ihre Speicherlimits überschreiten. Executor 1 ``` 18/06/13 16:54:29 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:54:29 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:54:29 ERROR YarnClusterScheduler: Lost executor 1 on ip-10-1-2-175.ec2.internal: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:54:29 WARN TaskSetManager: Lost task 0.0 in stage 0.0 (TID 0, ip-10-1-2-175.ec2.internal, executor 1): ExecutorLostFailure (executor 1 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. ``` Executor 2 ``` 18/06/13 16:55:35 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:55:35 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:55:35 ERROR YarnClusterScheduler: Lost executor 2 on ip-10-1-2-16.ec2.internal: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:55:35 WARN TaskSetManager: Lost task 0.1 in stage 0.0 (TID 1, ip-10-1-2-16.ec2.internal, executor 2): ExecutorLostFailure (executor 2 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. ``` Executor 3 ``` 18/06/13 16:56:37 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:56:37 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:56:37 ERROR YarnClusterScheduler: Lost executor 3 on ip-10-1-2-189.ec2.internal: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:56:37 WARN TaskSetManager: Lost task 0.2 in stage 0.0 (TID 2, ip-10-1-2-189.ec2.internal, executor 3): ExecutorLostFailure (executor 3 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.8 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. ``` Executor 4 ``` 18/06/13 16:57:18 WARN YarnAllocator: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:57:18 WARN YarnSchedulerBackend$YarnSchedulerEndpoint: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:57:18 ERROR YarnClusterScheduler: Lost executor 4 on ip-10-1-2-96.ec2.internal: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. 18/06/13 16:57:18 WARN TaskSetManager: Lost task 0.3 in stage 0.0 (TID 3, ip-10-1-2-96.ec2.internal, executor 4): ExecutorLostFailure (executor 4 exited caused by one of the running tasks) Reason: Container killed by YARN for exceeding memory limits. 5.5 GB of 5.5 GB physical memory used. Consider boosting spark.yarn.executor.memoryOverhead. ``` ### Korrigieren der Einstellung der Abrufgröße unter Verwendung dynamischer AWS Glue-Frames Der Executor hatte beim Lesen der JDBC-Tabelle keinen Speicher mehr zur Verfügung, da die Standardkonfiguration für die Spark JDBC-Abrufgröße Null ist. Dies bedeutet, dass der JDBC-Treiber auf dem Spark Executor versucht, die 34 Millionen Zeilen aus der Datenbank zusammen abzurufen und zwischenzuspeichern, obwohl Spark die Zeilen einzeln durchläuft. Mit Spark können Sie dieses Szenario zu vermeiden, indem Sie den Parameter für die Abrufgröße auf einen Standardwert ungleich Null setzen. Sie können dieses Problem auch beheben, indem Sie stattdessen dynamische AWS Glue-Frames verwenden. Dynamische Frames verwenden standardmäßig eine Abrufgröße von 1.000 Zeilen. Dieser Wert ist in der Regel ausreichend. Dies bewirkt, dass der Executor nicht mehr als 7 Prozent des gesamten Speichers verbraucht. Der AWS Glue-Auftrag wird in weniger als zwei Minuten mit nur einem einzigen Executor ausgeführt. Dies wird während die Verwendung von dynamischen Frames von AWS Glue als Ansatz empfohlen. Es ist aber auch möglich, eine Abrufgröße mit der Apache-Spark-Eigenschaft `fetchsize` festzulegen. Weitere Informationen finden Sie im [Spark SQL DataFrames and Datasets Guide](https://spark.apache.org/docs/2.2.0/sql-programming-guide.html#jdbc-to-other-databases). ``` val (url, database, tableName) = { ("jdbc_url", "db_name", "table_name") } val source = glueContext.getSource(format, sourceJson) val df = source.getDynamicFrame glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet", transformation_ctx = "datasink") ``` **Normal profilierte Metriken:** Der [Executor-Speicher](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.jvm.heap.usage) mit dynamischen AWS Glue-Frames übersteigt nie den sicheren Schwellenwert, wie in der folgenden Abbildung dargestellt. Er streamt die Zeilen aus der Datenbank und speichert jeweils nur 1.000 Zeilen im JDBC-Treiber. Es tritt keine Ausnahme aufgrund von Speichermangel auf. ![\[Die AWS Glue-Konsole zeigt, dass der Executor-Speicher unter der sicheren Schwelle liegt.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-oom-2-memoryprofile-fixed.png) # Debugging von anspruchsvolle Phasen und Straggler-Aufgaben Mit dem AWS Glue-Aufgabenprofiling können Sie anspruchsvolle Phasen und Straggler-Aufgaben in Ihren ETL-Aufträgen (Extrahieren, Transformieren und Laden) identifizieren. Eine Straggler-Aufgabe dauert viel länger als der Rest der Aufgaben in einer Phase eines AWS Glue-Auftrags. Dies bewirkt, dass die Phase länger dauert, was auch die gesamte Ausführungszeit des Auftrags verzögert. ## Zusammenführung von kleinen Eingabedateien zu größeren Ausgabedateien Eine Straggler-Aufgabe kann auftreten, wenn eine uneinheitliche Verteilung der Arbeit auf die verschiedenen Aufgaben gibt, oder wenn eine Datenverzerrung dazu führt, dass eine Aufgabe mehr Daten verarbeiten muss. Sie können den folgenden Code profilieren (ein gemeinsames Muster in Apache Spark), um eine große Anzahl von kleinen Dateien zu größeren Ausgabedateien zusammenzuführen. In diesem Beispiel besteht das Eingabe-Dataset aus 32 GB mit Gzip komprimierten JSON-Dateien. Das Ausgabe-Dataset umfasst ca. 190 GB nicht komprimierte JSON-Dateien. Der profilierte Code sieht wie folgt aus: ``` datasource0 = spark.read.format("json").load("s3://input_path") df = datasource0.coalesce(1) df.write.format("json").save(output_path) ``` ### Visualisieren der profilierten Metriken auf der AWS Glue-Konsole Sie können Ihren Auftrags profilieren, um vier verschiedene Metrik-Gruppen zu überprüfen: + ETL-Datenbewegung + Datenmischung über Executors hinweg + Auftragsausführung + Arbeitsspeicherprofil **ETL-Datenbewegung**: Im Profil **ETL Data Movement (ETL-Datenbewegung)** werden die Bytes von allen Executors in der ersten Phase, die innerhalb der ersten sechs Minuten abgeschlossen wird, relativ schnell [gelesen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes). Die gesamte Auftragsausführung dauert jedoch etwa eine Stunde, vor allem durch die [Schreibvorgänge](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) für die Daten. ![\[Graph, der das Profil der ETL-Datenbewegung zeigt.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-1.png) **Datenmischung über Executors hinweg:** Die Anzahl der [gelesenen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleLocalBytesRead) und [geschriebenen Bytes](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.shuffleBytesWritten) während des Mischens zeigt auch eine hohe Zahl, bevor Phase 2 endet, wie durch die Metriken **Job Execution (Auftragsausführung)** und **Data Shuffle (Datenmischung)** gezeigt. Nachdem die Daten aus allen Executors gemischt wurden, werden die Lese- und Schreiboperationen nur noch von Executor Nummer 3 ausgeführt. ![\[Die Metriken für das Mischen der Daten über alle Executors hinweg.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-2.png) **Auftragsausführung:** Wie im folgenden Graphen gezeigt, sind alle anderen Executors im Leerlauf und werden schließlich zum Zeitpunkt 10:09 aufgegeben. Zu diesem Zeitpunkt verringert sich die Gesamtanzahl der Executors auf nur einen. Dies zeigt deutlich, dass der Executor Nummer 3 aus der Straggler-Aufgabe besteht, die die längste Ausführungszeit benötigt und zum größten Teil zur Auftragsausführungszeit beiträgt. ![\[Die Ausführungs-Metriken für die aktiven Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-3.png) **Speicherprofil:** Nachdem den ersten beiden Phasen verbraucht nur noch [Executor Nummer 3](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.used) aktiv Arbeitsspeicher zur Verarbeitung der Daten. Die restlichen Executors sind einfach im Leerlauf oder wurden kurz nach Abschluss der ersten beiden Phasen aufgegeben. ![\[Die Metriken für das Arbeitsspeicherprofil nach der ersten zwei Phasen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-4.png) ### Beheben von Straggling-Executors unter Verwendung der Gruppierung Mit der *Gruppierungsfeature* in AWS Glue können Sie Straggling-Executors vermeiden. Verwenden Sie die Gruppierung, um die Daten gleichmäßig auf alle Executors zu verteilen und Dateien zu größeren Dateien zusammenzufassen, indem Sie alle verfügbaren Executors auf dem Cluster verwenden. Weitere Informationen finden Sie unter [Zusammenfassen von Eingabedateien in größeren Gruppen beim Lesen](grouping-input-files.md). Um die ETL-Datenbewegungen des AWS Glue-Auftrags zu überprüfen, müssen Sie den folgenden Code mit aktivierter Gruppierung profilieren: ``` df = glueContext.create_dynamic_frame_from_options("s3", {'paths': ["s3://input_path"], "recurse":True, 'groupFiles': 'inPartition'}, format="json") datasink = glueContext.write_dynamic_frame.from_options(frame = df, connection_type = "s3", connection_options = {"path": output_path}, format = "json", transformation_ctx = "datasink4") ``` **ETL-Datenbewegung:** Die Datenschreibvorgänge werden nun parallel zu den Datenlesevorgängen während der gesamten Ausführungszeit des Auftrags gestreamt. Dies bewirkt, dass der Auftrag innerhalb von acht Minuten abgeschlossen wird, viel schneller als zuvor. ![\[Die ETL-Datenbewegungen zeigen, dass das Problem behoben ist.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-5.png) **Datenmischung über Executors hinweg:** Da die Eingabedateien während des Lesens über die Gruppierungsfeature zusammengeführt werden, gibt es nach dem Lesen der Daten keine kostspielige Datenmischung. ![\[Die Metriken zur Datenmischung zeigen, dass das Problem behoben ist.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-6.png) **Auftragsausführung:** Die Auftragsausführungsmetriken zeigen, dass die Gesamtanzahl der aktiven Executors, die ausgeführt werden und Daten verarbeiten, relativ konstant bleibt. Es gibt keine einzelnen Straggler in dem Auftrag. Alle Executors sind aktiv und werden nicht aufgegeben, bis zum der Auftrag abgeschlossen ist. Da es keine zwischenzeitliche Datenmischung zwischen den Executors gibt, gibt es nur eine einzige Phase in dem Auftrag. ![\[Das Widget mit den Metriken für die Auftragsausführung zeigt, dass keine Straggler im Auftrag vorhanden sind.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-7.png) **Speicherprofil:** Die Metriken zeigen die [aktive Speicherbelegung](monitoring-awsglue-with-cloudwatch-metrics.md#glue.executorId.jvm.heap.used) für alle Executors – dies bestätigt, dass Aktivitäten auf allen Executors vorliegen. Da die Daten parallel gestreamt und ausgegeben werden, ist der gesamte Speicherbedarf aller Executors etwa gleich groß und liegt weit unter der sicheren Schwelle für alle Executors. ![\[Die Speicherprofilmetriken zeigen die aktive Speicherbelegung über alle Executors.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-straggler-8.png) # Überwachen des Fortschritts mehrerer Aufträge Sie können mehrere AWS Glue Jobs zusammen profilieren und den Datenfluss zwischen ihnen überwachen. Dies ist ein gängiges Workflow-Muster und erfordert die Überwachung des Fortschritts einzelner Aufträge, des Datenverarbeitungsrückstands, der Datenwiederaufbereitung und der Auftragslesezeichen. **Topics** + [Profilierter Code](#monitor-debug-multiple-profile) + [Visualisieren der profilierten Metriken auf der AWS Glue-Konsole](#monitor-debug-multiple-visualize) + [Korrektur der Dateiverarbeitung](#monitor-debug-multiple-fix) ## Profilierter Code In diesem Workflow haben Sie zwei Aufträge: einen Eingangsauftrag und einen Ausgangsauftrag. Die Ausführung des Eingangsauftrags ist für alle 30 Minuten eingeplant, wofür ein regelmäßiger Auslöser verwendet wird. Die Ausführung des Ausgangsauftrags ist nach jeder erfolgreichen Ausführung des Eingangsauftrags eingeplant. Diese geplanten Aufträge werden unter Verwendung von Auftragsauslöser kontrolliert. ![\[Screenshot der Konsole mit den Auftragsauslösern, die die Einplanung von Eingangs- und Ausgangsaufträgen kontrollieren.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-1.png) **Eingangsauftrag**: Dieser Auftrag liest Daten von einem Amazon Simple Storage Service (Amazon S3)-Speicherort, transformiert sie mit `ApplyMapping` und schreibt sie an einen Amazon-S3-Staging--Speicherort. Der folgende Code ist profilierter Code für den Eingangsauftrag: ``` datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": ["s3://input_path"], "useS3ListImplementation":True,"recurse":True}, format="json") applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [map_spec]) datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": staging_path, "compression": "gzip"}, format = "json") ``` **Ausgangsauftrag**: Dieser Auftrag liest die Ausgabe des Eingangsauftrags vom Staging-Speicherort in Amazon S3, transformiert sie wieder und schreibt sie an ein Ziel: ``` datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [staging_path], "useS3ListImplementation":True,"recurse":True}, format="json") applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [map_spec]) datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": output_path}, format = "json") ``` ## Visualisieren der profilierten Metriken auf der AWS Glue-Konsole Das folgende Dashboard überlagert die geschriebenen Bytes der Amazon-S3-Metrik vom Eingangsauftrag mit den gelesenen Bytes der Amazon-S3-Metrik auf derselben Zeitachse für den Ausgangsauftrag. Die Zeitachse zeigt verschiedenen Auftragsausführungen der Eingangs- und Ausgangsaufträge. Der Eingangsauftrag (rot markiert) startet alle 30 Minuten. Der Ausgangsauftrag (braun dargestellt) beginnt bei Abschluss des Eingangsauftrags mit einer maximalen Nebenläufigkeit von 1. ![\[Graph, der die gelesenen und geschriebenen Daten zeigt.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-4.png) In diesem Beispiel sind die [Auftragslesezeichen](https://docs.aws.amazon.com/glue/latest/dg/monitor-continuations.html) nicht aktiviert. Es werden keine Transformationskontexte verwendet, um Auftragslesezeichen im Skriptcode zu aktivieren. **Job History (Auftragsverlauf)**: Die Eingangs- und Ausgangsaufträge haben mehrere Ausführungen, wie auf der Registerkarte **History (Verlauf)** gezeigt, beginnend um 12:00 PM. Der Eingangsauftrag in der AWS Glue-Konsole sieht wie folgt aus: ![\[Screenshot der Konsole mit der Registerkarte History (Verlauf) des Eingangsauftrags.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-2.png) Das folgende Bild zeigt den Ausgangsauftrag: ![\[Screenshot der Konsole mit der Registerkarte History (Verlauf) des Ausgangsauftrags.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-3.png) **First job runs (Erste Auftragsausführungen)**: Wie im folgenden Graphen für gelesene und geschriebene Datenbytes dargestellt, zeigen die ersten Auftragsausführungen der Eingangs- und Ausgangsaufträge zwischen 12:00 und 12:30 Uhr ungefähr die gleiche Fläche unter den Kurven. Diese Flächen stellen die vom Eingangsauftrag geschriebenen Amazon-S3-Bytes und die vom Ausgangsauftrag gelesenen Amazon-S3-Bytes dar. Diese Daten werden auch durch das Verhältnis von geschriebenen Amazon-S3-Bytes (summiert über 30 Minuten – die Auftragsauslösefrequenz für den Eingangsauftrag) bestätigt. Der Datenpunkt für das Verhältnis für die Eingangsauftragsausführung, die um 12:00 Uhr PM gestartet wurde, ist ebenfalls 1. Der folgende Graph zeigt das Datenflussverhältnis für alle Auftragsausführungen: ![\[Graph, der das Datenflussverhältnis zeigt: geschriebenen Bytes und gelesene Bytes.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-5.png) **Second job runs (Zweite Auftragsausführungen)**: In der zweiten Auftragsausführung gibt es eine klare Differenz zwischen der Anzahl der vom Ausgangsauftrag gelesenen Bytes im Vergleich zu der Anzahl der vom Eingangsauftrag geschriebenen Bytes. (Vergleichen Sie die Fläche unter der Kurve der beiden Auftragsausführungen für den Ausgangsauftrag oder vergleichen Sie die Flächen der zweiten Ausführung der Eingangs- und Ausgangsaufträge.) Das Verhältnis der gelesenen und geschriebenen Bytes zeigt, dass der Ausgangsauftrag in der zweiten Spanne von 30 Minuten von 12:30 bis 13:00 Uhr etwa die 2,5-fache Menge der vom Eingangsauftrag geschriebenen Daten gelesen hat. Der Grund hierfür ist, dass der Ausgangsauftrag die Ausgabe der ersten Auftragsausführung des Eingangsauftrags erneut verarbeitet hat, weil keine Auftragslesezeichen aktiviert waren. Ein Verhältnis von über 1 zeigt, dass es einen zusätzlichen Rückstand an Daten gibt, die von dem Ausgangsauftrag verarbeitet wurde. **Third job runs (Dritte Auftragsausführungen)**: Der Eingangsauftrag ist relativ konsistent in Bezug auf die Anzahl der geschriebenen Bytes (siehe Fläche unter der roten Kurven). Die dritte Auftragsausführung des Eingangsauftrags ist jedoch länger gelaufen als erwartet (siehe langer Auslauf der roten Kurve). Dies hat zur Folge, dass die dritte Auftragsausführung des Ausgangsauftrags zu spät gestartet wurde. Die dritte Auftragsausführung verarbeitet nur ein Bruchteil der akkumulierten Daten am Staging-Speicherort in den verbleibenden 30 Minuten zwischen 13:00 und 13:30 Uhr. Das Verhältnis des Bytestroms zeigt, dass sie nur 0,83 der von der dritten Auftragsausführung des Eingabeauftrags geschriebenen Daten verarbeitet hat (siehe Verhältnis um 13.00 Uhr). **Overlap of Input and Output jobs (Überlappende Eingangs- und Ausgangsaufträge)**: Die vierte Auftragsausführung des Eingangsauftrags startete um 13:30 gemäß den Zeitplan, bevor die dritte Auftragsausführung des Ausgangsauftrags abgeschlossen wurde. Es gibt eine partielle Überschneidung zwischen diesen beiden Auftragsausführungen. Die dritte Auftragsausführung des Ausgangsauftrags erfasst nur die Dateien, die am Staging-Speicherort von Amazon S3 aufgelistet sind, als sie etwa um 13:17 Uhr begonnen hat. Dies umfasst alle Datenausgaben aus den ersten Auftragsausführungen des Eingangsauftrags. Das tatsächliche Verhältnis um 13:30 ist etwa 2,75. Die dritte Auftragsausführung des Ausgangsauftrags hat etwa das 2,75-fache der von der vierten Auftragsausführung von 13:30 bis 14:00 Uhr geschriebenen Daten verarbeitet. Wie diese Bilder zeigen, verarbeitet der Ausgangsauftrag Daten vom Staging-Standort aus allen vorherigen Auftragsausführungen des Eingangsauftrags erneut. Dies hat zur Folge, dass die vierte Auftragsausführung für den Ausgangsauftrag die längste ist und sich mit der gesamten fünften Auftragsausführung des Eingangsauftrags überlappt. ## Korrektur der Dateiverarbeitung Sie sollten sicherstellen, dass der Ausgangsauftrag nur die Dateien verarbeitet, die von den vorherigen Auftragsausführungen des Ausgangsauftrags nicht verarbeitet wurden. Dazu aktivieren Sie die Auftragslesezeichen und legen Sie den Transformationskontext im Ausgangsauftrag wie folgt fest: ``` datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [staging_path], "useS3ListImplementation":True,"recurse":True}, format="json", transformation_ctx = "bookmark_ctx") ``` Bei aktivierten Auftragslesezeichen verarbeitet der Ausgangsauftrag die Daten am Staging-Speicherort aus allen vorherigen Auftragsausführungen des Eingangsauftrags nicht erneut. In der folgenden Abbildung mit den gelesenen und geschriebenen Daten ist die Fläche unter der braunen Kurve relativ konsistent und ähnlich den roten Kurven. ![\[Graph, der die gelesenen und geschriebenen Daten als rote und braune Linien zeigt.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-6.png) Auch die Verhältnisse des Byteflusses bleiben etwa bei 1, da keine zusätzlichen Daten verarbeitet werden. ![\[Graph, der das Datenflussverhältnis zeigt: geschriebenen Bytes und gelesene Bytes\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-7.png) Eine Auftragsausführung für den Ausgangsauftrag startet und erfasst die Dateien am Staging-Speicherort, bevor die nächste Eingangsauftragsausführung gestartet wird, womit weitere Daten am Staging-Standort abgelegt werden. Solange dies fortgesetzt wird, verarbeitet sie nur die Dateien, die von der vorherigen Eingangsauftragsausführung erfasst wurden, und das Verhältnis bleibt etwa 1. ![\[Graph, der das Datenflussverhältnis zeigt: geschriebenen Bytes und gelesene Bytes\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-multiple-7.png) Angenommen, der Eingangsauftrag dauert länger als erwartet, und der Ausgangsauftrag erfasst aus diesem Grund Dateien am Staging-Standort von zwei Eingangsauftragsausführungen. Das Verhältnis wird dann höher als 1 für diese Ausgangsauftragausführung. Die folgenden Auftragsausführungen des Ausgangsauftrags verarbeiten jedoch keine Dateien, die bereits von den vorherigen Auftragsausführungen des Ausgangsauftrags verarbeitet wurden. # Überwachung für die DPU-Kapazitätsplanung Sie können Job-Metriken verwenden AWS Glue , um die Anzahl der Datenverarbeitungseinheiten (DPUs) zu schätzen, die zur Skalierung eines AWS Glue Jobs verwendet werden können. **Anmerkung** Diese Seite trifft nur auf AWS Glue-Versionen 0.9 und 1.0 zu. Spätere Versionen von AWS Glue enthalten Funktionen zur Kosteneinsparung, die zusätzliche Überlegungen bei der Kapazitätsplanung mit sich bringen. **Topics** + [Profilierter Code](#monitor-debug-capacity-profile) + [Visualisieren der profilierten Metriken auf der AWS Glue-Konsole](#monitor-debug-capacity-visualize) + [Bestimmen der optimalen DPU-Kapazität](#monitor-debug-capacity-fix) ## Profilierter Code Das folgende Skript liest eine Amazon Simple Storage Service (Amazon S3)-Partition mit 428 gezippten JSON-Dateien. Das Skript wendet ein Mapping an, um die Feldnamen zu ändern, und konvertiert und schreibt sie in Amazon S3 im Apache-Parquet-Format. Sie stellen 10 DPUs standardmäßig bereit und führen diesen Job aus. ``` datasource0 = glueContext.create_dynamic_frame.from_options(connection_type="s3", connection_options = {"paths": [input_path], "useS3ListImplementation":True,"recurse":True}, format="json") applymapping1 = ApplyMapping.apply(frame = datasource0, mappings = [(map_spec]) datasink2 = glueContext.write_dynamic_frame.from_options(frame = applymapping1, connection_type = "s3", connection_options = {"path": output_path}, format = "parquet") ``` ## Visualisieren der profilierten Metriken auf der AWS Glue-Konsole **Job-Run 1:** In diesem Job-Run zeigen wir, wie Sie herausfinden können, ob DPUs im Cluster zu wenig Provisioning vorhanden ist. Die Auftragsausführungsfunktionalität in AWS Glue zeigt die [Gesamtzahl der aktiven Executors](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberAllExecutors), die [Anzahl der abgeschlossenen Phasen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.aggregate.numCompletedStages) und die [Anzahl der maximal benötigten Executors](monitoring-awsglue-with-cloudwatch-metrics.md#glue.driver.ExecutorAllocationManager.executors.numberMaxNeededExecutors). Die Anzahl der maximal benötigten Executors wird berechnet, indem die Gesamtzahl der laufenden Aufgaben und anstehenden Aufgaben addiert und durch die Aufgaben pro Executor dividiert wird. Dieses Ergebnis ist ein Maß für die Gesamtanzahl der Executors, die erforderlich sind, um die aktuelle Last zu erfüllen. Im Gegensatz dazu misst die Anzahl der aktiven Executors, wie viele aktive Apache-Spark-Aufgaben ausgeführt werden. Im weiteren Verlauf des Auftrags können sich die maximal benötigten Executors ändern und gehen in der Regel gegen Ende des Auftrags zurück, da die Warteschlange der anstehenden Aufgaben abnimmt. Die horizontale rote Linie in der folgenden Grafik zeigt die Anzahl der maximal zugewiesenen Executoren, die von der Anzahl der Executoren abhängt, DPUs die Sie dem Job zuweisen. In diesem Fall weisen Sie dem ausgeführten Job 10 DPUs zu. Eine DPU ist für die Verwaltung reserviert. Neun DPUs führen jeweils zwei Executors aus und ein Executor ist für den Spark-Treiber reserviert. Der Spark-Treiber wird in der primären Anwendung ausgeführt. Die Anzahl der maximalen zugewiesenen Executors ist also 2\$1 9 – 1 = 17 Executors. ![\[Die Auftragsmetriken, die die aktiven Executors und die maximal benötigten Executors zeigen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-capacity-1.png) Wie der Graph zeigt, beginnt die Anzahl der maximal benötigten Executors bei 107 zu Beginn des Auftrags, während die Anzahl der aktiven Executors bei 17 bleibt. Dies entspricht der Anzahl der maximal zugewiesenen Executoren mit 10. DPUs Das Verhältnis zwischen den maximal benötigten Executors und den maximal zugewiesenen Executors (zu beiden wird für den Spark-Treiber 1 addiert) ergibt den Faktor für die zu niedrig ausgelegte Bereitstellung: 108/18 = 6x. Sie können 6 (unter dem Provisioning Ratio) \$19 (aktuelle DPU-Kapazität — 1) \$1 1 DPUs = 55 bereitstellen, um den Job so DPUs zu skalieren, dass er mit maximaler Parallelität ausgeführt und schneller abgeschlossen wird. Die AWS Glue -Konsole zeigt die detaillierten Auftragsmetriken als statische Linie an, die die ursprüngliche Anzahl der maximal zugeteilten Executors darstellt. Die Konsole berechnet die maximal zugeteilten Executors aus der Auftragsdefinition für die Metriken. Im Gegensatz dazu berechnet die Konsole für detaillierte Messwerte zur Auftragsausführung die maximal zugewiesenen Executoren aus der Job-Run-Konfiguration, insbesondere die für die Job-Ausführung zugewiesenen. DPUs Um Metriken für eine einzelne Auftragsausführung anzuzeigen, wählen Sie die Auftragsausführung und anschließend **View run metrics (Ausführungsmetriken anzeigen)** aus. ![\[Die Auftragsmetriken, die die ETL-Datenbewegung zeigen.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-capacity-2.png) Bei der Betrachtung der [gelesenen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.read_bytes) und [geschriebenen](monitoring-awsglue-with-cloudwatch-metrics.md#glue.ALL.s3.filesystem.write_bytes) Amazon-S3-Bytes erkennen Sie, dass der Auftrag alle sechs Minuten parallel Daten aus Amazon S3 streamt und schreibt. Alle Kerne auf den zugewiesenen DPUs Kernen lesen und schreiben in Amazon S3. Die maximale Anzahl an benötigten Executors von 107 entspricht auch der Anzahl der Dateien im Amazon-S3-Eingangspfad 428. Jeder Executor können vier Spark-Aufgaben zur Verarbeitung von vier Eingangsdateien (gezippte JSON-Dateien) starten. ## Bestimmen der optimalen DPU-Kapazität Basierend auf den Ergebnissen der vorherigen Auftragsausführung können Sie die Gesamtzahl der zugewiesenen Aufgaben DPUs auf 55 erhöhen und so die Leistung des Auftrags überprüfen. Der Auftrag wird in weniger als drei Minuten abgeschlossen – der Hälfte der Zeit, die zuvor erforderlich war. Die Auftragsskalierung erfolgt in diesem Fall nicht linear, da es sich um einen kurzen Auftrag handelt.. Jobs mit langlebigen Aufgaben oder einer großen Anzahl von Aufgaben (eine große Anzahl von maximal benötigten Executoren) profitieren von einer close-to-linear DPU-Scale-Out-Leistungssteigerung. ![\[Grafik, die die Zunahme der Gesamtzahl der zugewiesenen Aufgaben zeigt DPUs\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-capacity-3.png) Wie die folgende Abbildung zeigt, erreicht die Gesamtzahl der aktiven Executors die maximale Anzahl zugewiesener Executors107. Ebenso liegt die maximale Anzahl benötigter Executors nie über den maximal zugewiesenen Executors. Die maximale Anzahl erforderlicher Executors wird anhand der Anzahl der aktiven und ausstehenden Aufgaben berechnet, sie könnte also kleiner sein als die Anzahl der aktiven Executors. Dies liegt daran, dass es Executors geben kann, die für einen kurzen Zeitraum teilweise oder vollständig im Leerlauf sind und noch nicht außer Betrieb genommen wurden. ![\[Graph, der die Gesamtzahl aktiver Executors zeigt, die die maximal zugewiesene Anzahl erreicht.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-capacity-4.png) Dieser Auftrag nutzt sechsmal mehr Executors für parallele Lese- und Schreibvorgänge in Amazon S3. Dies hat zur Folge, dass diese Auftragsausführung mehr Amazon-S3-Bandbreite für Lese- und Schreibvorgänge verwendet und schneller fertiggestellt wird. ### Identifizieren Sie übermäßig bereitgestellte DPUs Als Nächstes können Sie feststellen, ob eine weitere Skalierung des Jobs mit 100 DPUs (99 \$1 2 = 198 Executoren) hilfreich ist. Wie der folgende Graph zeigt, dauert die Fertigstellung des Auftrags immer noch drei Minuten. Ebenso kann der Job nicht über 107 Executoren ( DPUsKonfiguration 55) hinaus skaliert werden, und die verbleibenden 91 Executoren sind überprovisioniert und werden überhaupt nicht verwendet. Dies zeigt, dass eine Erhöhung der Anzahl von Executoren DPUs möglicherweise nicht immer zu einer Verbesserung der Leistung führt, wie anhand der maximal benötigten Anzahl von Executoren deutlich wird. ![\[Aus der Grafik geht hervor, dass die Arbeitsleistung nicht immer steigt, wenn die Anzahl der DPUs\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/monitor-debug-capacity-5.png) ### Vergleich von Zeitunterschieden Die drei in der folgenden Tabelle aufgeführten Auftragsausführungen fassen die Ausführungszeiten für 10 DPUs DPUs, 55 und 100 DPUs Jobs zusammen. Sie finden die DPU-Kapazität zur Verbesserung der Auftragsausführungszeit unter Verwendung der Schätzungen, die Sie bei der Überwachung der ersten Auftragsausführung eingerichtet haben. | Auftrags-ID | Anzahl der DPUs | Execution time (Ausführungszeit) | | --- | --- | --- | | jr\$1c894524c8ef5048a4d9... | 10 | 6 Minuten | | jr\$11a466cf2575e7ffe6856... | 55 | 3 Minuten | | jr\$134fa1ed4c6aa9ff0a814... | 100 | 3 Minuten | # Generative KI-Fehlerbehebung für Apache Spark in AWS Glue Generative KI-Fehlerbehebung für Apache Spark-Jobs in AWS Glue ist eine neue Funktion, mit der Dateningenieure und Wissenschaftler Probleme in ihren Spark-Anwendungen mühelos diagnostizieren und beheben können. Mithilfe von Machine Learning und Technologien für generative KI analysiert dieses Feature Probleme in Spark-Aufträgen und bietet eine detaillierte Ursachenanalyse sowie umsetzbare Empfehlungen zur Lösung dieser Probleme. Die generative KI-Fehlerbehebung für Apache Spark ist für Jobs verfügbar, die auf AWS Glue Version 4.0 und höher ausgeführt werden. | | | --- | | Transformieren Sie Ihre Apache Spark-Fehlerbehebung mit unserem KI-gestützten Troubleshooting-Agenten, der jetzt alle wichtigen Bereitstellungsmodi unterstützt, darunter AWS Glue, Amazon EMR-EC2, Amazon EMR-Serverless und Amazon AI Notebooks. SageMaker Dieser leistungsstarke Agent macht komplexe Debugging-Prozesse überflüssig, indem er Interaktionen in natürlicher Sprache, Workload-Analysen in Echtzeit und intelligente Codeempfehlungen zu einem nahtlosen Erlebnis kombiniert. Einzelheiten zur Implementierung finden Sie unter [Was ist der Apache Spark Troubleshooting Agent for Amazon EMR.](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/spark-troubleshoot.html) Sehen Sie sich die zweite Demonstration unter Beispiele [zur Fehlerbehebung mit dem Troubleshooting-Agenten](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/spark-troubleshooting-using-troubleshooting-agent.html) für AWS Glue an. | ## Wie funktioniert die Fehlerbehebung mit generativer KI für Apache Spark? Für Ihre fehlgeschlagenen Spark-Jobs analysiert Generative AI Troubleshooting die Job-Metadaten und die genauen Metriken und Protokolle, die mit der Fehlersignatur Ihres Jobs verknüpft sind, um eine Ursachenanalyse zu erstellen, und empfiehlt spezifische Lösungen und bewährte Methoden zur Behebung von Jobfehlern. ## Einrichten der Fehlerbehebung mit generativer KI für Apache Spark für Ihre Aufträge ### Konfigurieren von IAM-Berechtigungen Um Benutzern, die von Spark Troubleshooting für Ihre Jobs in AWS Glue APIs verwendet werden, Berechtigungen zu gewähren, sind entsprechende IAM-Berechtigungen erforderlich. Sie können Berechtigungen erhalten, indem Sie Ihrer IAM-Identität (z. B. einem Benutzer, einer Rolle oder einer Gruppe) die folgende benutzerdefinierte AWS Richtlinie zuordnen. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:StartCompletion", "glue:GetCompletion" ], "Resource": [ "arn:aws:glue:*:*:completion/*", "arn:aws:glue:*:*:job/*" ] } ] } ``` ------ **Anmerkung** Die folgenden beiden APIs werden in der IAM-Richtlinie verwendet, um diese Erfahrung über die AWS Glue Studio-Konsole zu aktivieren: `StartCompletion` und`GetCompletion`. ### Zuweisen von Berechtigungen Um Zugriff zu gewähren, fügen Sie Ihren Benutzern, Gruppen oder Rollen Berechtigungen hinzu: + Für Benutzer und Gruppen in IAM Identity Center: Erstellen Sie einen Berechtigungssatz. Befolgen Sie die Anweisungen unter [Erstellen eines Berechtigungssatzes](https://docs.aws.amazon.com/singlesignon/latest/userguide/howtocreatepermissionset.html) im IAM-Identity-Center-Benutzerhandbuch. + Für Benutzer, die in IAM über einen Identitätsanbieter verwaltet werden: Erstellen Sie eine Rolle für den Identitätsverbund. Befolgen Sie die Anweisungen unter [Erstellen einer Rolle für einen externen Identitätsanbieter (Verbund)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) im IAM-Benutzerhandbuch. + Für IAM-Benutzer: Erstellen Sie eine Rolle, die Ihr Benutzer annehmen kann. Folgen Sie den Anweisungen unter [Erstellen einer Rolle für einen IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) im IAM-Benutzerhandbuch. ## Durchführen einer Fehlerbehebungsanalyse von einer fehlgeschlagenen Auftragsausführung Sie können über mehrere Pfade in der AWS Glue-Konsole auf die Fehlerbehebungsfunktion zugreifen. So machen Sie die ersten Schritte: ### Option 1: Von der Seite mit der Auftragsliste 1. Öffnen Sie die AWS Glue-Konsole unter [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/). 1. Wählen Sie im Navigationsbereich die Option **ETL-Aufträge** aus. 1. Suchen Sie Ihren fehlgeschlagenen Auftrag in der Auftragsliste. 1. Wählen Sie die Registerkarte **Ausführungen** im Abschnitt mit den Auftragsdetails. 1. Klicken Sie auf die fehlgeschlagene Auftragsausführung, die Sie analysieren möchten. 1. Wählen Sie **Fehlerbehebung mit KI** aus, um die Analyse zu starten. 1. Wenn die Analyse zur Fehlerbehebung abgeschlossen ist, können Sie die Ursachenanalyse und die Empfehlungen auf der Registerkarte **Fehlerbehebungsanalyse** am unteren Bildschirmrand anzeigen. ![\[Das GIF stellt die durchgängige Implementierung einer fehlgeschlagenen Ausführung mit ausgeführtem KI-Feature dar.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/troubleshoot_spark_option_1_jobs_list.gif) ### Option 2: Verwenden der Seite „Überwachung der Auftragsausführung“ 1. Navigieren Sie zur Seite zur **Überwachung der Auftragsausführung**. 1. Suchen Sie nach der fehlgeschlagenen Auftragsausführung. 1. Wählen Sie die Dropdown-Liste **Aktionen** aus. 1. Wählen Sie **Problembehandlung mit KI** aus. ![\[Das GIF stellt die durchgängige Implementierung einer fehlgeschlagenen Ausführung mit ausgeführtem KI-Feature dar.\]](http://docs.aws.amazon.com/de_de/glue/latest/dg/images/troubleshoot_spark_option_2_job_monitoring.gif) ### Option 3: Von der Seite mit den Details der Auftragsausführung 1. Navigieren Sie zur Detailseite der fehlgeschlagenen Auftragsausführung, indem Sie entweder auf der Registerkarte **Ausführungen** auf **Details anzeigen** zu einer fehlgeschlagenen Ausführung klicken oder die Auftragsausführung auf der Seite **Überwachung der Auftragsausführung** auswählen. 1. Suchen Sie auf der Seite mit den Details der Auftragsausführung die Registerkarte **Fehlerbehebungsanalyse**. ## Unterstützte Kategorien zur Fehlerbehebung Dieser Service konzentriert sich auf drei Hauptkategorien von Problemen, auf die Dateningenieure und Entwickler in ihren Spark-Anwendungen häufig stoßen: + **Fehler bei der Einrichtung und beim Zugriff auf Ressourcen:** Beim Ausführen von Spark-Anwendungen in AWS Glue gehören Fehler bei der Einrichtung und beim Zugriff auf Ressourcen zu den häufigsten, aber schwierig zu diagnostizierenden Problemen. Diese Fehler treten häufig auf, wenn Ihre Spark-Anwendung versucht, mit AWS Ressourcen zu interagieren, aber auf Berechtigungsprobleme, fehlende Ressourcen oder Konfigurationsprobleme stößt. + **Speicherprobleme mit Spark-Treibern und -Executors:** Speicherbezogene Fehler in Apache-Spark-Aufträgen können komplex zu diagnostizieren und zu beheben sein. Diese Fehler treten häufig auf, wenn Ihre Datenverarbeitungsanforderungen die verfügbaren Speicherressourcen überschreiten, entweder im Treiberknoten oder in den Executor-Knoten. + **Probleme mit der Spark-Festplattenkapazität:** Speicherbedingte Fehler in AWS Glue Spark-Jobs treten häufig bei Shuffle-Vorgängen, beim Verschütten von Daten oder bei umfangreichen Datentransformationen auf. Diese Fehler können besonders problematisch sein, weil sie möglicherweise erst auftreten, wenn Ihr Auftrag eine Weile ausgeführt wurde, wodurch möglicherweise wertvolle Rechenzeit und Ressourcen verschwendet werden. + **Fehler bei der Ausführung von Abfragen:** Abfragefehler in Spark SQL und DataFrame Vorgängen können schwierig zu beheben sein, da Fehlermeldungen möglicherweise nicht eindeutig auf die Ursache hinweisen und Abfragen, die mit kleinen Datensätzen einwandfrei funktionieren, plötzlich in großem Umfang fehlschlagen können. Diese Fehler werden noch schwieriger, wenn sie tief in komplexen Transformationspipelines auftreten, wo das eigentliche Problem eher auf Datenqualitätsprobleme in früheren Phasen als auf die Abfragelogik selbst zurückzuführen sein kann. **Anmerkung** Bevor Sie vorgeschlagene Änderungen in Ihrer Produktionsumgebung implementieren, sollten Sie die vorgeschlagenen Änderungen sorgfältig prüfen. Der Service bietet Empfehlungen, die auf Mustern und bewährten Methoden basieren. Ihr spezieller Anwendungsfall erfordert jedoch möglicherweise zusätzliche Überlegungen. ## Unterstützte -Regionen Generative KI-Fehlerbehebung für Apache Spark ist in den folgenden Regionen verfügbar: + **Afrika**: Kapstadt (af-south-1) + **Asien-Pazifik**: Hongkong (ap-east-1), Tokio (ap-northeast-1), Seoul (ap-northeast-2), Osaka (ap-northeast-3), Mumbai (ap-south-1), Singapur (ap-southeast-1), Sydney (ap-southeast-2) und Jakarta (ap-southeast-3) + **Europa**: Frankfurt (eu-central-1), Stockholm (eu-nord-1), Mailand (eu-south-1), Irland (eu-west-1), London (eu-west-2) und Paris (eu-west-3) + **Naher Osten**: Bahrain (me-south-1) und VAE (me-central-1) + **Nordamerika**: Kanada (ca-central-1) + **Südamerika**: São Paulo (sa-east-1) + **Vereinigte Staaten**: Nord-Virginia (us-east-1), Ohio (us-east-2), Nordkalifornien (US-West-1) und Oregon (US-West-2) # Materialisierte Ansichten mit AWS Glue verwenden AWS Glue Version 5.1 und höher unterstützt die Erstellung und Verwaltung materialisierter Apache Iceberg-Ansichten im AWS Glue-Datenkatalog. Eine materialisierte Ansicht ist eine verwaltete Tabelle, die das vorberechnete Ergebnis einer SQL-Abfrage im Apache Iceberg-Format speichert und schrittweise aktualisiert wird, wenn sich die zugrunde liegenden Quelltabellen ändern. Sie können materialisierte Ansichten verwenden, um Pipelines zur Datentransformation zu vereinfachen und die Abfrageleistung für komplexe analytische Workloads zu beschleunigen. Wenn Sie mit Spark in AWS Glue eine materialisierte Ansicht erstellen, werden die Ansichtsdefinition und die Metadaten im AWS Glue-Datenkatalog gespeichert. Die vorberechneten Ergebnisse werden als Apache Iceberg-Tabellen in Amazon S3 S3-Tabelles-Buckets oder Amazon S3 S3-Allzweck-Buckets in Ihrem Konto gespeichert. Der AWS Glue-Datenkatalog überwacht automatisch Quelltabellen und aktualisiert materialisierte Ansichten mithilfe einer verwalteten Recheninfrastruktur. **Topics** + [So funktionieren materialisierte Ansichten mit Glue AWS](#materialized-views-how-they-work) + [Voraussetzungen](#materialized-views-prerequisites) + [Konfiguration von Spark für die Verwendung materialisierter Ansichten](#materialized-views-configuring-spark) + [Erstellen von materialisierten Ansichten](#materialized-views-creating) + [Abfragen materialisierter Ansichten](#materialized-views-querying) + [Aktualisieren materialisierter Ansichten](#materialized-views-refreshing) + [Materialisierte Ansichten verwalten](#materialized-views-managing) + [Berechtigungen für materialisierte Ansichten](#materialized-views-permissions) + [Überwachung von Materialized View-Vorgängen](#materialized-views-monitoring) + [Beispiel: Vollständiger Workflow](#materialized-views-complete-workflow) + [Überlegungen und Einschränkungen](#materialized-views-considerations-limitations) ## So funktionieren materialisierte Ansichten mit Glue AWS Materialisierte Ansichten lassen sich über die Iceberg-Unterstützung von Apache Spark in AWS Glue-Jobs und AWS Glue Studio-Notebooks in AWS Glue integrieren. Wenn Sie Ihre Spark-Sitzung für die Verwendung des AWS Glue-Datenkatalogs konfigurieren, können Sie materialisierte Ansichten mithilfe der Standard-SQL-Syntax erstellen. Der Spark-Optimierer kann Abfragen automatisch so umschreiben, dass sie materialisierte Ansichten verwenden, wenn sie eine bessere Leistung bieten, sodass der Anwendungscode nicht manuell geändert werden muss. Der AWS Glue-Datenkatalog behandelt alle betrieblichen Aspekte der Wartung von Materialized Views, einschließlich: + Erkennung von Änderungen in Quelltabellen mithilfe der Metadatenebene von Apache Iceberg + Planung und Ausführung von Aktualisierungsvorgängen mithilfe von Managed Spark Compute + Feststellen, ob eine vollständige oder eine inkrementelle Aktualisierung auf der Grundlage der Datenänderungen durchgeführt werden soll + Speichern vorberechneter Ergebnisse im Apache Iceberg-Format für den Zugriff mit mehreren Engines Sie können materialisierte Ansichten von AWS Glue mit denselben Spark-SQL-Schnittstellen abfragen, die Sie für normale Tabellen verwenden. Auf die vorberechneten Daten kann auch von anderen Diensten wie Amazon Athena und Amazon Redshift aus zugegriffen werden. ## Voraussetzungen Um materialisierte Ansichten mit AWS Glue zu verwenden, benötigen Sie: + Ein -Konto + AWS Glue Version 5.1 oder höher + Quelltabellen im Apache Iceberg-Format, registriert im AWS Glue Data Catalog + AWS Lake Formation für Quelltabellen und Zieldatenbanken konfigurierte Berechtigungen + Ein S3-Tabelles-Bucket oder ein S3-Allzweck-Bucket, bei dem AWS Lake Formation zum Speichern von Materialized View-Daten registriert ist + Eine IAM-Rolle mit Berechtigungen für den Zugriff auf AWS Glue Data Catalog und Amazon S3 ## Konfiguration von Spark für die Verwendung materialisierter Ansichten Um materialisierte Ansichten in AWS Glue zu erstellen und zu verwalten, konfigurieren Sie Ihre Spark-Sitzung mit den erforderlichen Iceberg-Erweiterungen und Katalogeinstellungen. Die Konfigurationsmethode hängt davon ab, ob Sie Glue-Jobs oder AWS AWS Glue Studio-Notizbücher verwenden. ### Konfiguration von AWS Glue-Jobs Wenn Sie einen AWS Glue-Job erstellen oder aktualisieren, fügen Sie die folgenden Konfigurationsparameter als Job-Parameter hinzu: #### Für S3-Tabellen-Buckets ``` job = glue.create_job( Name='materialized-view-job', Role='arn:aws:iam::111122223333:role/GlueServiceRole', Command={ 'Name': 'glueetl', 'ScriptLocation': 's3://amzn-s3-demo-bucket/scripts/mv-script.py', 'PythonVersion': '3' }, DefaultArguments={ '--enable-glue-datacatalog': 'true', '--conf': 'spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions ' '--conf spark.sql.catalog.glue_catalog=org.apache.iceberg.spark.SparkCatalog ' '--conf spark.sql.catalog.glue_catalog.type=glue ' '--conf spark.sql.catalog.glue_catalog.warehouse=s3://amzn-s3-demo-bucket/warehouse ' '--conf spark.sql.catalog.glue_catalog.glue.region=us-east-1 ' '--conf spark.sql.catalog.glue_catalog.glue.id=111122223333 ' '--conf spark.sql.catalog.glue_catalog.glue.account-id=111122223333 ', '--conf spark.sql.catalog.glue_catalog.glue.lakeformation-enabled=true ', '--conf spark.sql.catalog.s3t_catalog=org.apache.iceberg.spark.SparkCatalog ' '--conf spark.sql.catalog.s3t_catalog.type=glue ' '--conf spark.sql.catalog.s3t_catalog.glue.id=111122223333:s3tablescatalog/my-table-bucket ', '--conf spark.sql.catalog.s3t_catalog.glue.account-id=111122223333 ', '--conf spark.sql.catalog.s3t_catalog.glue.lakeformation-enabled=true ', '--conf spark.sql.catalog.s3t_catalog.warehouse=s3://amzn-s3-demo-bucket/mv-warehouse ' '--conf spark.sql.catalog.s3t_catalog.glue.region=us-east-1 ' '--conf spark.sql.defaultCatalog=s3t_catalog ' '--conf spark.sql.optimizer.answerQueriesWithMVs.enabled=true ' '--conf spark.sql.materializedViews.metadataCache.enabled=true' }, GlueVersion='5.1' ) ``` #### Für S3-Allzweck-Buckets ``` job = glue.create_job( Name='materialized-view-job', Role='arn:aws:iam::111122223333:role/GlueServiceRole', Command={ 'Name': 'glueetl', 'ScriptLocation': 's3://amzn-s3-demo-bucket/scripts/mv-script.py', 'PythonVersion': '3' }, DefaultArguments={ '--enable-glue-datacatalog': 'true', '--conf': 'spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions ' '--conf spark.sql.catalog.glue_catalog=org.apache.iceberg.spark.SparkCatalog ' '--conf spark.sql.catalog.glue_catalog.type=glue ' '--conf spark.sql.catalog.glue_catalog.warehouse=s3://amzn-s3-demo-bucket/warehouse ' '--conf spark.sql.catalog.glue_catalog.glue.region=us-east-1 ' '--conf spark.sql.catalog.glue_catalog.glue.id=111122223333 ', '--conf spark.sql.catalog.glue_catalog.glue.account-id=111122223333 ', '--conf spark.sql.catalog.glue_catalog.glue.lakeformation-enabled=true ', '--conf spark.sql.defaultCatalog=glue_catalog ' '--conf spark.sql.optimizer.answerQueriesWithMVs.enabled=true ' '--conf spark.sql.materializedViews.metadataCache.enabled=true' }, GlueVersion='5.1' ) ``` ### Konfiguration von AWS Glue Studio-Notebooks Konfigurieren Sie in AWS Glue Studio-Notizbüchern Ihre Spark-Sitzung mit dem Befehl %%configure magic am Anfang Ihres Notizbuchs: ``` %%configure { "conf": { "spark.sql.extensions": "org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions", "spark.sql.catalog.glue_catalog": "org.apache.iceberg.spark.SparkCatalog", "spark.sql.catalog.glue_catalog.type": "glue", "spark.sql.catalog.glue_catalog.warehouse": "s3://amzn-s3-demo-bucket/warehouse", "spark.sql.catalog.glue_catalog.glue.region": "us-east-1", "spark.sql.catalog.glue_catalog.glue.id": "111122223333", "spark.sql.catalog.glue_catalog.glue.account-id": "111122223333", "spark.sql.catalog.glue_catalog.glue.lakeformation-enabled": "true", "spark.sql.defaultCatalog": "glue_catalog", "spark.sql.optimizer.answerQueriesWithMVs.enabled": "true", "spark.sql.materializedViews.metadataCache.enabled": "true" } } ``` ### Aktivierung der inkrementellen Aktualisierung Um die inkrementelle Aktualisierungsoptimierung zu aktivieren, fügen Sie Ihren Jobparametern oder Ihrer Notebook-Konfiguration die folgenden Konfigurationseigenschaften hinzu: ``` --conf spark.sql.optimizer.incrementalMVRefresh.enabled=true --conf spark.sql.optimizer.incrementalMVRefresh.deltaThresholdCheckEnabled=false ``` ### Konfigurationsparameter Die folgenden Konfigurationsparameter steuern das Verhalten der materialisierten Ansicht: + `spark.sql.extensions`— Aktiviert Iceberg Spark-Sitzungserweiterungen, die für die Unterstützung von Materialized Views erforderlich sind. + `spark.sql.optimizer.answerQueriesWithMVs.enabled`— Ermöglicht das automatische Umschreiben von Abfragen zur Verwendung materialisierter Ansichten. Auf true setzen, um diese Optimierung zu aktivieren. + `spark.sql.materializedViews.metadataCache.enabled`— Ermöglicht das Zwischenspeichern von Metadaten der materialisierten Ansicht zur Abfrageoptimierung. Auf „true“ setzen, um die Leistung beim Umschreiben von Abfragen zu verbessern. + `spark.sql.optimizer.incrementalMVRefresh.enabled`— Aktiviert die inkrementelle Aktualisierungsoptimierung. Auf true setzen, um nur geänderte Daten während Aktualisierungsvorgängen zu verarbeiten. + `spark.sql.optimizer.answerQueriesWithMVs.decimalAggregateCheckEnabled`— Steuert die Validierung von dezimalen Aggregatoperationen beim Umschreiben von Abfragen. Auf „false“ setzen, um bestimmte Prüfungen auf Dezimalüberlauf zu deaktivieren. ## Erstellen von materialisierten Ansichten Sie erstellen materialisierte Ansichten mit der SQL-Anweisung CREATE MATERIALIZED VIEW in AWS Glue-Jobs oder -Notebooks. Die View-Definition spezifiziert die Transformationslogik als eine SQL-Abfrage, die auf eine oder mehrere Quelltabellen verweist. ### Erstellen einer grundlegenden materialisierten Ansicht in AWS Glue-Jobs Das folgende Beispiel zeigt die Erstellung einer materialisierten Ansicht in einem AWS Glue-Job-Skript, wobei vollqualifizierte Tabellennamen mit dreiteiliger Benennungskonvention in der Ansichtsdefinition verwendet werden: ``` from awsglue.context import GlueContext from pyspark.context import SparkContext sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session # Create materialized view spark.sql(""" CREATE MATERIALIZED VIEW customer_orders AS SELECT customer_name, COUNT(*) as order_count, SUM(amount) as total_amount FROM glue_catalog.sales.orders GROUP BY customer_name """) ``` ### Erstellen einer materialisierten Ansicht mit automatischer Aktualisierung Um die automatische Aktualisierung zu konfigurieren, geben Sie bei der Erstellung der Ansicht einen Aktualisierungszeitplan an. Verwenden Sie dabei vollqualifizierte Tabellennamen mit dreiteiliger Benennungskonvention in der Ansichtsdefinition: ``` spark.sql(""" CREATE MATERIALIZED VIEW customer_orders SCHEDULE REFRESH EVERY 1 HOUR AS SELECT customer_name, COUNT(*) as order_count, SUM(amount) as total_amount FROM glue_catalog.sales.orders GROUP BY customer_name """) ``` ### Erstellen einer materialisierten Ansicht mit katalogübergreifenden Verweisen Wenn sich Ihre Quelltabellen in einem anderen Katalog als Ihre materialisierte Ansicht befinden, verwenden Sie vollqualifizierte Tabellennamen mit dreiteiliger Benennungskonvention sowohl im Ansichtsnamen als auch in der Ansichtsdefinition: ``` spark.sql(""" CREATE MATERIALIZED VIEW s3t_catalog.analytics.customer_summary AS SELECT customer_name, COUNT(*) as order_count, SUM(amount) as total_amount FROM glue_catalog.sales.orders GROUP BY customer_name """) ``` ### Materialisierte Ansichten in AWS Glue Studio-Notizbüchern erstellen In AWS Glue Studio-Notizbüchern können Sie den magischen Befehl %%sql verwenden, um materialisierte Ansichten zu erstellen, wobei Sie vollqualifizierte Tabellennamen mit dreiteiliger Benennungskonvention in der Ansichtsdefinition verwenden: ``` %%sql CREATE MATERIALIZED VIEW customer_orders AS SELECT customer_name, COUNT(*) as order_count, SUM(amount) as total_amount FROM glue_catalog.sales.orders GROUP BY customer_name ``` ## Abfragen materialisierter Ansichten Nachdem Sie eine materialisierte Ansicht erstellt haben, können Sie sie wie jede andere Tabelle mit Standard-SQL-SELECT-Anweisungen in Ihren AWS Glue-Jobs oder -Notizbüchern abfragen. ### Abfragen in AWS Glue-Jobs ``` from awsglue.context import GlueContext from pyspark.context import SparkContext sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session # Query materialized view result = spark.sql("SELECT * FROM customer_orders") result.show() ``` ### Abfragen in AWS Glue Studio-Notizbüchern ``` %%sql SELECT * FROM customer_orders ``` ### Automatisches Umschreiben von Abfragen Wenn das automatische Umschreiben von Abfragen aktiviert ist, analysiert der Spark-Optimierer Ihre Abfragen und verwendet automatisch materialisierte Ansichten, wenn diese die Leistung verbessern können. Wenn Sie beispielsweise die folgende Abfrage ausführen: ``` result = spark.sql(""" SELECT customer_name, COUNT(*) as order_count, SUM(amount) as total_amount FROM orders GROUP BY customer_name """) ``` Der Spark-Optimierer schreibt diese Abfrage automatisch neu, sodass sie die materialisierte Ansicht customer\$1orders verwendet, anstatt die Tabelle mit den Basisbestellungen zu verarbeiten, vorausgesetzt, die materialisierte Ansicht ist aktuell. ### Überprüfung des automatischen Umschreibens von Abfragen Verwenden Sie den Befehl EXPLAIN EXTENDED, um zu überprüfen, ob eine Abfrage das automatische Umschreiben von Abfragen verwendet: ``` spark.sql(""" EXPLAIN EXTENDED SELECT customer_name, COUNT(*) as order_count, SUM(amount) as total_amount FROM orders GROUP BY customer_name """).show(truncate=False) ``` Suchen Sie im Ausführungsplan nach dem Namen der materialisierten Ansicht in der BatchScan Operation. Wenn der Plan BatchScan glue\$1catalog.analytics.customer\$1orders statt glue\$1catalog.sales.orders anzeigt, wurde die Abfrage automatisch so umgeschrieben, dass sie die BatchScan materialisierte Ansicht verwendet. Beachten Sie, dass das automatische Umschreiben von Abfragen einige Zeit in Anspruch nimmt, bis der Spark-Metadatencache gefüllt ist, nachdem eine materialisierte Ansicht erstellt wurde. Dieser Vorgang ist in der Regel innerhalb von 30 Sekunden abgeschlossen. ## Aktualisieren materialisierter Ansichten Sie können materialisierte Ansichten mit zwei Methoden aktualisieren: vollständige Aktualisierung oder inkrementelle Aktualisierung. Bei der vollständigen Aktualisierung wird die gesamte materialisierte Ansicht anhand aller Basistabellendaten neu berechnet, während bei der inkrementellen Aktualisierung nur die Daten verarbeitet werden, die sich seit der letzten Aktualisierung geändert haben. ### Manuelle vollständige Aktualisierung von AWS Glue-Jobs So führen Sie eine vollständige Aktualisierung einer materialisierten Ansicht durch: ``` spark.sql("REFRESH MATERIALIZED VIEW customer_orders FULL") # Verify updated results result = spark.sql("SELECT * FROM customer_orders") result.show() ``` ### Manuelles inkrementelles Aktualisieren von AWS Glue-Jobs Um eine inkrementelle Aktualisierung durchzuführen, stellen Sie sicher, dass die inkrementelle Aktualisierung in Ihrer Spark-Sitzungskonfiguration aktiviert ist, und führen Sie dann Folgendes aus: ``` spark.sql("REFRESH MATERIALIZED VIEW customer_orders") # Verify updated results result = spark.sql("SELECT * FROM customer_orders") result.show() ``` Der AWS Glue-Datenkatalog bestimmt anhand der Ansichtsdefinition und der Menge der geänderten Daten automatisch, ob eine inkrementelle Aktualisierung möglich ist. Wenn eine inkrementelle Aktualisierung nicht möglich ist, wird der Vorgang auf eine vollständige Aktualisierung zurückgesetzt. ### Aktualisierung in AWS Glue Studio-Notizbüchern Verwenden Sie in Notizbüchern den magischen Befehl %%sql: ``` %%sql REFRESH MATERIALIZED VIEW customer_orders FULL ``` ### Die Ausführung der inkrementellen Aktualisierung wird überprüft Um zu bestätigen, dass die inkrementelle Aktualisierung erfolgreich ausgeführt wurde, aktivieren Sie die Debug-Protokollierung in Ihrem AWS Glue-Job: ``` from awsglue.context import GlueContext from pyspark.context import SparkContext import logging sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session # Enable debug logging logger = logging.getLogger('org.apache.spark.sql') logger.setLevel(logging.DEBUG) # Execute refresh spark.sql("REFRESH MATERIALIZED VIEW customer_orders") ``` Suchen Sie in den AWS Glue-Jobprotokollen nach der folgenden Meldung: ``` DEBUG RefreshMaterializedViewExec: Executed Incremental Refresh ``` ## Materialisierte Ansichten verwalten AWS Glue bietet SQL-Befehle für die Verwaltung des Lebenszyklus materialisierter Ansichten in Ihren Jobs und Notizbüchern. ### Beschreibung einer materialisierten Ansicht So zeigen Sie Metadaten zu einer materialisierten Ansicht an, einschließlich ihrer Definition, ihres Aktualisierungsstatus und des Zeitstempels der letzten Aktualisierung: ``` spark.sql("DESCRIBE EXTENDED customer_orders").show(truncate=False) ``` ### Eine materialisierte Ansicht ändern So ändern Sie den Aktualisierungszeitplan einer vorhandenen materialisierten Ansicht: ``` spark.sql(""" ALTER MATERIALIZED VIEW customer_orders ADD SCHEDULE REFRESH EVERY 2 HOURS """) ``` Um die automatische Aktualisierung zu entfernen: ``` spark.sql(""" ALTER MATERIALIZED VIEW customer_orders DROP SCHEDULE """) ``` ### Löschen einer materialisierten Ansicht Um eine materialisierte Ansicht zu löschen: ``` spark.sql("DROP MATERIALIZED VIEW customer_orders") ``` Dieser Befehl entfernt die Definition der materialisierten Ansicht aus dem AWS Glue-Datenkatalog und löscht die zugrunde liegenden Iceberg-Tabellendaten aus Ihrem S3-Bucket. ### Materialisierte Ansichten auflisten Um alle materialisierten Ansichten in einer Datenbank aufzulisten: ``` spark.sql("SHOW VIEWS FROM analytics").show() ``` ## Berechtigungen für materialisierte Ansichten Um materialisierte Ansichten zu erstellen und zu verwalten, müssen Sie Berechtigungen konfigurieren AWS Lake Formation . Die IAM-Rolle, die die materialisierte Ansicht erstellt (die Definer-Rolle), erfordert spezielle Berechtigungen für Quelltabellen und Zieldatenbanken. ### Erforderliche Berechtigungen für die Definer-Rolle Die Definiererrolle muss über die folgenden Lake Formation Formation-Berechtigungen verfügen: + Für Quelltabellen — SELECT- oder ALL-Berechtigungen ohne Zeilen-, Spalten- oder Zellenfilter + In der Zieldatenbank — CREATE\$1TABLE-Berechtigung + Über den AWS Glue-Datenkatalog — GetTable und CreateTable API-Berechtigungen Wenn Sie eine materialisierte Ansicht erstellen, wird der ARN der Definiererrolle in der Ansichtsdefinition gespeichert. Der AWS Glue-Datenkatalog übernimmt diese Rolle bei der Ausführung automatischer Aktualisierungsvorgänge. Wenn die Definer-Rolle den Zugriff auf Quelltabellen verliert, schlagen Aktualisierungsvorgänge fehl, bis die Berechtigungen wiederhergestellt sind. ### IAM-Berechtigungen für AWS Glue-Jobs Für die IAM-Rolle Ihres AWS Glue-Jobs sind die folgenden Berechtigungen erforderlich: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetCatalog", "glue:GetCatalogs", "glue:GetTable", "glue:GetTables", "glue:CreateTable", "glue:UpdateTable", "glue:DeleteTable", "glue:GetDatabase", "glue:GetDatabases", "cloudwatch:PutMetricData" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket" ] }, { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:*:*:*:/aws-glue/*" ] }, { "Effect": "Allow", "Action": [ "lakeformation:GetDataAccess" ], "Resource": "*" } ] } ``` Die Rolle, die Sie für die automatische Aktualisierung von Materialized View verwenden, muss über die iam: PassRole -Berechtigung für die Rolle verfügen. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ "arn:aws:iam::111122223333:role/materialized-view-role-name" ] } ] } ``` Damit Glue die materialisierte Ansicht automatisch für Sie aktualisiert, muss die Rolle außerdem über die folgende Vertrauensrichtlinie verfügen, die es dem Dienst ermöglicht, die Rolle zu übernehmen. ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ "arn:aws:iam::111122223333:role/materialized-view-role-name" ] } ] } ``` Wenn die Materialized View in S3 Tables Buckets gespeichert ist, müssen Sie der Rolle außerdem die folgende Berechtigung hinzufügen. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3tables:PutTableMaintenanceConfiguration" ], "Resource": "arn:aws:s3tables:*:123456789012:*" } ] } ``` ### Zugriff auf materialisierte Ansichten gewähren Um anderen Benutzern Zugriff auf die Abfrage einer materialisierten Ansicht zu gewähren, verwenden Sie, AWS Lake Formation um die SELECT-Berechtigung für die Materialized View-Tabelle zu gewähren. Benutzer können die Materialized View abfragen, ohne direkten Zugriff auf die zugrunde liegenden Quelltabellen zu benötigen. Ausführliche Informationen zur Konfiguration von Lake Formation Formation-Berechtigungen finden Sie unter Erteilen und Widerrufen von Berechtigungen für Datenkatalogressourcen im AWS Lake Formation Entwicklerhandbuch. ## Überwachung von Materialized View-Vorgängen Der AWS Glue-Datenkatalog veröffentlicht Metriken und Protokolle für Aktualisierungsvorgänge von Materialized Views auf Amazon CloudWatch. Sie können den Aktualisierungsstatus, die Dauer und das verarbeitete Datenvolumen anhand von CloudWatch Metriken überwachen. ### Job-Logs anzeigen So zeigen Sie Logs für AWS Glue-Jobs an, die materialisierte Ansichten erstellen oder aktualisieren: 1. Öffnen Sie die AWS Glue-Konsole. 1. Wählen Sie im Navigationsbereich Jobs aus. 1. Wählen Sie Ihren Job aus und wählen Sie Läufe aus. 1. Wählen Sie einen bestimmten Lauf aus und wählen Sie Protokolle, um die CloudWatch Protokolle anzuzeigen. ### Alarme einrichten Um Benachrichtigungen zu erhalten, wenn Aktualisierungsvorgänge fehlschlagen oder die erwartete Dauer überschreiten, erstellen Sie CloudWatch Alarme für Materialized View-Metriken. Sie können EventBridge Amazon-Regeln auch so konfigurieren, dass automatische Antworten auf Aktualisierungsereignisse ausgelöst werden. ## Beispiel: Vollständiger Workflow Das folgende Beispiel zeigt einen vollständigen Arbeitsablauf für die Erstellung und Verwendung einer materialisierten Ansicht in AWS Glue. ### Beispiel für ein AWS Glue-Jobskript ``` import sys from awsglue.transforms import * from awsglue.utils import getResolvedOptions from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job args = getResolvedOptions(sys.argv, ['JOB_NAME']) sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session job = Job(glueContext) job.init(args['JOB_NAME'], args) # Create database and base table spark.sql("CREATE DATABASE IF NOT EXISTS sales") spark.sql("USE sales") spark.sql(""" CREATE TABLE IF NOT EXISTS orders ( id INT, customer_name STRING, amount DECIMAL(10,2), order_date DATE ) """) # Insert sample data spark.sql(""" INSERT INTO orders VALUES (1, 'John Doe', 150.00, DATE('2024-01-15')), (2, 'Jane Smith', 200.50, DATE('2024-01-16')), (3, 'Bob Johnson', 75.25, DATE('2024-01-17')) """) # Create materialized view spark.sql(""" CREATE MATERIALIZED VIEW customer_summary AS SELECT customer_name, COUNT(*) as order_count, SUM(amount) as total_amount FROM glue_catalog.sales.orders GROUP BY customer_name """) # Query the materialized view print("Initial materialized view data:") spark.sql("SELECT * FROM customer_summary").show() # Insert additional data spark.sql(""" INSERT INTO orders VALUES (4, 'Jane Smith', 350.00, DATE('2024-01-18')), (5, 'Bob Johnson', 100.25, DATE('2024-01-19')) """) # Refresh the materialized view spark.sql("REFRESH MATERIALIZED VIEW customer_summary FULL") # Query updated results print("Updated materialized view data:") spark.sql("SELECT * FROM customer_summary").show() job.commit() ``` ### Beispiel für ein AWS Glue Studio-Notizbuch ``` %%configure { "conf": { "spark.sql.extensions": "org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions", "spark.sql.catalog.glue_catalog": "org.apache.iceberg.spark.SparkCatalog", "spark.sql.catalog.glue_catalog.type": "glue", "spark.sql.catalog.glue_catalog.warehouse": "s3://amzn-s3-demo-bucket/warehouse", "spark.sql.catalog.glue_catalog.glue.region": "us-east-1", "spark.sql.catalog.glue_catalog.glue.id": "111122223333", "spark.sql.catalog.glue_catalog.glue.account-id": "111122223333", "spark.sql.catalog.glue_catalog.glue.lakeformation-enabled": "true", "spark.sql.defaultCatalog": "glue_catalog", "spark.sql.optimizer.answerQueriesWithMVs.enabled": "true", "spark.sql.materializedViews.metadataCache.enabled": "true" } } ``` ``` %%sql CREATE DATABASE IF NOT EXISTS sales ``` ``` %%sql USE sales ``` ``` %%sql CREATE TABLE IF NOT EXISTS orders ( id INT, customer_name STRING, amount DECIMAL(10,2), order_date DATE ) ``` ``` %%sql INSERT INTO orders VALUES (1, 'John Doe', 150.00, DATE('2024-01-15')), (2, 'Jane Smith', 200.50, DATE('2024-01-16')), (3, 'Bob Johnson', 75.25, DATE('2024-01-17')) ``` ``` %%sql CREATE MATERIALIZED VIEW customer_summary AS SELECT customer_name, COUNT(*) as order_count, SUM(amount) as total_amount FROM glue_catalog.sales.orders GROUP BY customer_name ``` ``` %%sql SELECT * FROM customer_summary ``` ``` %%sql INSERT INTO orders VALUES (4, 'Jane Smith', 350.00, DATE('2024-01-18')), (5, 'Bob Johnson', 100.25, DATE('2024-01-19')) ``` ``` %%sql REFRESH MATERIALIZED VIEW customer_summary FULL ``` ``` %%sql SELECT * FROM customer_summary ``` ## Überlegungen und Einschränkungen Beachten Sie Folgendes, wenn Sie materialisierte Ansichten mit AWS Glue verwenden: + Materialisierte Ansichten erfordern AWS Glue Version 5.1 oder höher. + Quelltabellen müssen Apache Iceberg-Tabellen sein, die im AWS Glue-Datenkatalog registriert sind. Apache Hive-, Apache Hudi- und Delta Lake-Tabellen der Linux Foundation werden beim Start nicht unterstützt. + Quelltabellen müssen sich in derselben Region und demselben Konto wie die materialisierte Ansicht befinden. + Alle Quelltabellen müssen von gesteuert werden. AWS Lake Formation Reine IAM-Berechtigungen und hybrider Zugriff werden nicht unterstützt. + Materialisierte Ansichten können nicht auf AWS Glue Data Catalog-Ansichten, Multidialektansichten oder andere materialisierte Ansichten als Quelltabellen verweisen. + Die Rolle des View Definers muss vollen Lesezugriff (SELECT- oder ALL-Berechtigung) auf alle Quelltabellen haben, ohne dass Zeilen-, Spalten- oder Zellfilter angewendet werden. + Materialisierte Ansichten stimmen letztendlich mit Quelltabellen überein. Während des Aktualisierungsfensters können Abfragen veraltete Daten zurückgeben. Führen Sie die manuelle Aktualisierung aus, um sofortige Konsistenz zu gewährleisten. + Das minimale automatische Aktualisierungsintervall beträgt eine Stunde. + Die inkrementelle Aktualisierung unterstützt eine eingeschränkte Teilmenge von SQL-Vorgängen. Die Viewdefinition muss ein einzelner SELECT-FROM-WHERE-GROUP BY-HAVING-Block sein und darf keine Mengenoperationen, Unterabfragen, das DISTINCT-Schlüsselwort in SELECT oder Aggregatfunktionen, Fensterfunktionen oder Joins außer INNER JOIN enthalten. + Die inkrementelle Aktualisierung unterstützt keine benutzerdefinierten Funktionen oder bestimmte integrierte Funktionen. Nur eine Teilmenge der integrierten Funktionen von Spark SQL wird unterstützt. + Beim automatischen Umschreiben von Abfragen werden nur materialisierte Ansichten berücksichtigt, deren Definitionen zu einer eingeschränkten SQL-Teilmenge gehören, ähnlich den Beschränkungen für inkrementelle Aktualisierungen. + Bezeichner, die andere Sonderzeichen als alphanumerische Zeichen und Unterstriche enthalten, werden in CREATE MATERIALIZED VIEW-Abfragen nicht unterstützt. Dies gilt für alle Bezeichnertypen, einschließlich catalog/namespace/table Namen, Spalten- und Strukturfeldnamen sowie Aliase. CTEs + Spalten in materialisierten Ansichten, die mit dem Präfix \$1\$1ivm beginnen, sind für die Verwendung durch das System reserviert. Amazon behält sich das Recht vor, diese Spalten in future Versionen zu ändern oder zu entfernen. + Die Klauseln SORT BY, LIMIT, OFFSET, CLUSTER BY und ORDER BY werden in Definitionen von Materialized View nicht unterstützt. + Regions- und kontenübergreifende Quelltabellen werden nicht unterstützt. + Für Tabellen, auf die in der View-Abfrage verwiesen wird, muss eine dreiteilige Benennungskonvention verwendet werden (z. B. glue\$1catalog.my\$1db.my\$1table), da bei der automatischen Aktualisierung keine standardmäßigen Katalog- und Datenbankeinstellungen verwendet werden. + Vollständige Aktualisierungsvorgänge überschreiben die gesamte Tabelle und sorgen dafür, dass vorherige Snapshots nicht mehr verfügbar sind. + Nichtdeterministische Funktionen wie rand () oder current\$1timestamp () werden in Definitionen materialisierter Ansichten nicht unterstützt.