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 Typen von Arbeitern
Übersicht
AWS Glue bietet mehrere Arbeitstypen, um unterschiedlichen Workload-Anforderungen gerecht zu werden, von kleinen Streaming-Jobs bis hin zu umfangreichen, speicherintensiven 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 Mitarbeitertypen:
-
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
Datenverarbeitungseinheiten (DPUs)
Die den AWS Glue Arbeitnehmern zur Verfügung stehenden Ressourcen 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.
Speicheroptimiert DPUs (M-DPUs): Worker vom Typ R verwenden M-DPUs, wodurch im Vergleich zum Standard die doppelte Speicherzuweisung für eine bestimmte Größe bereitgestellt wird. DPUs 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
DPU: 1 DPU (4 VCPUs, 16 GB Speicher)
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
DPU: 2 DPU (8 VCPUs, 32 GB Speicher)
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
DPU: 4 DPU (16 VCPUs, 64 GB Speicher)
Speicher: 256 GB Festplatte (ca. 230 GB frei)
Anwendungsfall: Anspruchsvolle Transformationen, Aggregationen, Zusammenführungen und Abfragen
G.8X
DPU: 8 DPU (32 VCPUs, 128 GB Speicher)
Speicher: 512 GB Festplatte (ca. 485 GB frei)
Anwendungsfall: Anspruchsvolle Transformationen, Aggregationen, Zusammenführungen und Abfragen
G.12X
DPU: 12 DPU (48 VCPUs, 192 GB Speicher)
Speicher: 768 GB Festplatte (ca. 741 GB frei)
Anwendungsfall: Sehr große und ressourcenintensive Workloads, die eine erhebliche Rechenkapazität erfordern
G.16X
DPU: 16 DPU (64 VCPUs, 256 GB Speicher)
Speicher: 1.024 GB Festplatte (ca. 996 GB frei)
Anwendungsfall: Größte und ressourcenintensivste Workloads, die eine maximale Rechenkapazität erfordern
R.1X — Speicheroptimiert*
DPU: 1 M-DPU (4 V, 32 GB Speicher) CPUs
Anwendungsfall: Speicherintensive Workloads mit häufigen Fehlern oder hohen Ratio-Anforderungen out-of-memory memory-to-CPU
R.2X — Speicheroptimiert*
DPU: 2 M-DPU (8 V, 64 GB Speicher) CPUs
Anwendungsfall: Speicherintensive Workloads mit häufigen Fehlern oder hohen Ratio-Anforderungen out-of-memory memory-to-CPU
R.4X — Speicheroptimiert*
DPU: 4 M-DPU (16 V, 128 GB Speicher) CPUs
Anwendungsfall: Große speicherintensive Workloads mit häufigen Fehlern oder hohen Verhältnisanforderungen out-of-memory memory-to-CPU
R.8X — Speicheroptimiert*
DPU: 8 M-DPU (32 V, 256 GB Speicher) CPUs
Anwendungsfall: Sehr große speicherintensive Workloads mit häufigen Fehlern oder hohen Verhältnisanforderungen out-of-memory memory-to-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) | Ungefährer 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 |
| R 1X | 1 | 4 | 32 | 94 | 44 | 1 |
| R 2X | 2 | 8 | 64 | 138 | 78 | 1 |
| R 4X | 4 | 16 | 128 | 256 | 230 | 1 |
| R 8 X | 8 | 32 | 256 | 512 | 485 | 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 out-of-memory Fehlern oder Workloads mit speicherintensiven Vorgängen wie Zwischenspeichern, Mischen und Aggregieren
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
CloudWatch Überwachen Sie Kennzahlen, um die Ressourcennutzung besser 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
