AWS Glue-Worker-Typen
Übersicht
AWS Glue stellt mehrere Worker-Typen bereit, um unterschiedlichen Workload-Anforderungen gerecht zu werden, von kleinen Streaming-Jobs bis hin zu umfangreichen, arbeitsspeicherintensiven Datenverarbeitungsaufgaben. Dieser Abschnitt enthält umfassende Informationen zu allen verfügbaren Worker-Typen, ihren Spezifikationen und Nutzungsempfehlungen.
Kategorien von Worker-Typen
AWS Glue bietet zwei Hauptkategorien von Worker-Typen:
-
G-Worker-Typen: Allzweck-Datenverarbeitungs-Worker, die für Standard-ETL-Workloads optimiert sind
-
R-Worker-Typen: RAM-optimierte Worker, die für arbeitsspeicherintensive Spark-Anwendungen konzipiert wurden
Data Processing Units (DPUs, Datenverarbeitungseinheiten)
Die auf AWS Glue-Workern verfügbaren Ressourcen werden in DPUs gemessen. Bei einer DPU handelt es sich um ein relatives Maß der Rechenleistung, die aus 4 vCPUs Rechenkapazität und 16 GB Arbeitsspeicher besteht.
RAM-optimierte DPUs (M-DPUs): R-Worker-Typen verwenden M-DPUs, die im Vergleich zu Standard-DPUs die doppelte Speicherzuweisung für eine bestimmte Größe bieten. Das bedeutet, dass eine Standard-DPU 16 GB Arbeitsspeicher bereitstellt, während eine M-DPU in R-Worker-Typen 32 GB Arbeitsspeicher bereitstellt, der für speicherintensive Spark-Anwendungen optimiert ist.
Verfügbare Worker-Typen
G.1X – Standard-Worker
DPU: 1 DPU (4 vCPUs, 16 GB Arbeitsspeicher)
Speicher: 94 GB Festplatte (ca. 44 GB frei)
Anwendungsfall: Datentransformationen, Verknüpfungen und Abfragen – skalierbar und kostengünstig für die meisten Aufträge
G.2X – Standard-Worker
DPU: 2 DPU (8 vCPUs, 32 GB Arbeitsspeicher)
Speicher: 138 GB Festplatte (ca. 78 GB frei)
Anwendungsfall: Datentransformationen, Verknüpfungen und Abfragen – skalierbar und kostengünstig für die meisten Aufträge
G.4X – Großer Worker
DPU: 4 DPU (16 vCPUs, 64 GB Arbeitsspeicher)
Speicher: 256 GB Festplatte (ca. 230 GB frei)
Anwendungsfall: Anspruchsvolle Transformationen, Aggregationen, Zusammenführungen und Abfragen
G.8X – Sehr großer Worker
DPU: 8 DPU (32 vCPUs, 128 GB Arbeitsspeicher)
Speicher: 512 GB Festplatte (ca. 485 GB frei)
Anwendungsfall: Anspruchsvollste Transformationen, Aggregationen, Zusammenführungen und Abfragen
G.12X – Sehr großer Worker*
DPU: 12 DPU (48 vCPUs, 192 GB Arbeitsspeicher)
Speicher: 768 GB Festplatte (ca. 741 GB frei)
Anwendungsfall: Sehr große und ressourcenintensive Workloads, die eine erhebliche Rechenkapazität erfordern
G.16X – Maximaler Worker*
DPU: 16 DPU (64 vCPUs, 256 GB Arbeitsspeicher)
Speicher: 1.024 GB Festplatte (ca. 996 GB frei)
Anwendungsfall: Größte und ressourcenintensivste Workloads, die eine maximale Rechenkapazität erfordern
R.1X – RAM-optimiert klein*
DPU: 1 M-DPU (4 vCPUs, 32 GB Arbeitsspeicher)
Anwendungsfall: Speicherintensive Workloads mit häufigen Fehlern (Out-of-memory, OOM) aufgrund von zu wenig Speicher oder hohen Anforderungen an das Verhältnis von Arbeitsspeicher zu CPU
R.2X – RAM-optimiertes Medium*
DPU: 2 M-DPU (8 vCPUs, 64 GB Arbeitsspeicher)
Anwendungsfall: Speicherintensive Workloads mit häufigen Fehlern (Out-of-memory, OOM) aufgrund von zu wenig Speicher oder hohen Anforderungen an das Verhältnis von Arbeitsspeicher zu CPU
R.4X – RAM-optimiert groß*
DPU: 4 M-DPU (16 vCPUs, 128 GB Arbeitsspeicher)
Anwendungsfall: Große speicherintensive Workloads mit häufigen OOM-Fehlern oder hohen Anforderungen an das Verhältnis von Arbeitsspeicher zu CPU
R.8X – RAM-optimiert, extra groß*
DPU: 8 M-DPU (32 vCPUs, 256 GB Arbeitsspeicher)
Anwendungsfall: Sehr große speicherintensive Workloads mit häufigen OOM-Fehlern oder hohen Anforderungen an das Verhältnis von Arbeitsspeicher zu CPU
* Bei diesen Workern kann es zu einer höheren Startlatenz kommen. Versuchen Sie, das Problem wie folgt zu beheben:
Warten Sie einige Minuten und senden Sie Ihren Auftrag erneut.
Senden Sie einen neuen Auftrag mit einer geringeren Anzahl von Workern.
Senden Sie einen neuen Auftrag mit einem anderen Worker-Typ oder einer anderen Worker-Größe.
Tabelle mit Worker-Typ-Spezifikationen
| Worker-Typ | DPU pro Knoten | vCPU | Speicher (GB) | Festplatte (GB) | Freier Festplattenspeicher (GB) | Spark-Executors pro Knoten |
|---|---|---|---|---|---|---|
| G.1X | 1 | 4 | 16 | 94 | 44 | 1 |
| G.2X | 2 | 8 | 32 | 138 | 78 | 1 |
| G.4X | 4 | 16 | 64 | 256 | 230 | 1 |
| G.8X | 8 | 32 | 128 | 512 | 485 | 1 |
| G.12X | 12 | 48 | 192 | 768 | 741 | 1 |
| G.16X | 16 | 64 | 256 | 1024 | 996 | 1 |
Hinweis: R-Worker-Typen haben RAM-optimierte Konfigurationen mit Spezifikationen, die für speicherintensive Workloads optimiert sind.
Wichtige Überlegungen
Startlatenz
Wichtig
Die Worker-Typen G.12X und G.16X sowie alle R-Worker-Typen (R.1X bis R.8X) haben ggf. eine höhere Startlatenz. Versuchen Sie, das Problem wie folgt zu beheben:
Warten Sie einige Minuten und senden Sie Ihren Auftrag erneut.
Senden Sie einen neuen Auftrag mit einer geringeren Anzahl von Workern.
Senden Sie einen neuen Auftrag mit einem anderen Worker-Typ und einer anderen Worker-Größe.
Auswählen des richtigen Worker-Typs
Für Standard-ETL-Workloads
G.1X oder G.2X: Am kostengünstigsten für typische Datentransformationen, Verknüpfungen und Abfragen
G.4X oder G.8X: Für anspruchsvollere Workloads mit größeren Datensätzen
Für umfangreiche Workloads
G.12X: Sehr große Datensätze, die erhebliche Rechenressourcen erfordern
G.16X: Maximale Rechenkapazität für die anspruchsvollsten Workloads
Für speicherintensive Workloads
R.1X oder R.2X: Kleine bis mittlere speicherintensive Aufträge
R.4X oder R.8X: Große speicherintensive Workloads mit häufigen OOM-Fehlern (Out of Memory)
Überlegungen zur Kostenoptimierung
Standard-G-Worker: Stellen ein ausgewogenes Verhältnis aus Datenverarbeitungs-, Arbeitsspeicher- und Netzwerkressourcen bereit, die dann zu geringeren Kosten für eine Vielzahl unterschiedlicher Workloads verwendet werden können
R-Worker: Spezialisiert auf speicherintensive Aufgaben mit schneller Leistung bei Workloads, die große Datensätze im Arbeitsspeicher verarbeiten
Bewährte Methoden
Richtlinien für die Auswahl von Workern
Beginnen Sie mit Standard-Workern (G.1X, G.2X) für die meisten Workloads
Verwenden Sie R-Worker bei häufigen OOM-Fehlern oder bei Workloads mit speicherintensiven Vorgängen wie Caching, Shuffling und Aggregation
Ziehen Sie die Worker G.12X/G.16X für rechenintensive Workloads in Betracht, die maximale Ressourcen erfordern
Berücksichtigen Sie Kapazitätsengpässe, wenn Sie neue Worker-Typen in zeitkritischen Workflows verwenden
Leistungsoptimierung
Überwachen von CloudWatch CloudWatch-Metriken, um die Ressourcennutzung zu verstehen
Verwenden entsprechender Worker-Anzahlen basierend auf der Datengröße und Komplexität
Erwägen von Strategien zur Datenpartitionierung, um die Effizienz der Worker zu optimieren
