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 Workertypen, 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 Workertypen, ihren Spezifikationen und Verwendungsempfehlungen.
Kategorien der Arbeitnehmertypen
AWS Glue bietet zwei Hauptkategorien von Arbeitnehmertypen:
-
G-Worker-Typen: Allzweck-Computing-Worker, die für Standard-ETL-Workloads optimiert sind
-
R-Worker-Typen: Speicheroptimierte Worker, die für speicherintensive 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 Speicher bereitstellt, während eine M-DPU in Workern vom Typ R 32 GB Speicher bereitstellt, der für speicherintensive Spark-Anwendungen optimiert ist.
Verfügbare Worker-Typen
G.1X - Standardarbeiter
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 Aufgaben
G.2X — Standardarbeiter
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 Aufgaben
G.4X — Großer Arbeiter
DPU: 4 DPU (16 VCPUs, 64 GB Speicher)
Speicher: 256 GB Festplatte (ca. 230 GB frei)
Anwendungsfall: Anspruchsvolle Transformationen, Aggregationen, Verknüpfungen und Abfragen
G.8X — Sehr großer Arbeiter
DPU: 8 DPU (32 VCPUs, 128 GB Speicher)
Speicher: 512 GB Festplatte (ca. 485 GB frei)
Anwendungsfall: Die anspruchsvollsten Transformationen, Aggregationen, Verknüpfungen und Abfragen
G.12X — Sehr großer Arbeiter*
DPU: 12 DPU (48 V, 192 GB Speicher) CPUs
Speicher: 768 GB Festplatte (ca. 741 GB frei)
Anwendungsfall: Sehr große und ressourcenintensive Workloads, die eine erhebliche Rechenkapazität erfordern
G.16X — Maximaler Mitarbeiter*
DPU: 16 DPU (64 V, 256 GB Speicher) CPUs
Speicher: 1024 GB Festplatte (ca. 996 GB frei)
Anwendungsfall: Größte und ressourcenintensivste Workloads, die maximale Rechenkapazität erfordern
R.1X — Speicheroptimiert klein*
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 — Speicheroptimiertes Medium*
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 groß*
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, extra groß*
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 ein paar Minuten und reichen Sie Ihren Job dann erneut ein.
Reichen Sie einen neuen Job mit einer reduzierten Anzahl von Mitarbeitern ein.
Reichen Sie einen neuen Job mit einem anderen Arbeitnehmertyp oder einer anderen Mitarbeitergröße ein.
Tabelle mit Spezifikationen für den Arbeitnehmertyp
| Art des Arbeitnehmers | DPU pro Knoten | vCPU | Speicher (GB) | Festplatte (GB) | Freier Festplattenspeicher (GB) | Spark-Executoren 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 |
| G12X | 12 | 48 | 192 | 768 | 741 | 1 |
| G.16X | 16 | 64 | 256 | 1024 | 996 | 1 |
Hinweis: R-Worker-Typen verfügen über speicheroptimierte Konfigurationen mit Spezifikationen, die für speicherintensive Workloads optimiert sind.
Wichtige Überlegungen
Latenz beim Start
Wichtig
Bei den Workertypen G.12X und G.16X sowie bei allen R-Workertypen (R.1X bis R.8X) kann es zu einer höheren Startlatenz kommen. Versuchen Sie, das Problem wie folgt zu beheben:
Warten Sie ein paar Minuten und reichen Sie Ihren Job dann erneut ein.
Reichen Sie einen neuen Job mit einer reduzierten Anzahl von Mitarbeitern ein.
Reichen Sie einen neuen Job mit einem anderen Mitarbeitertyp und einer anderen Mitarbeitergröße ein.
Auswahl des richtigen Arbeitnehmertyps
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 Jobs
R.4X oder R.8X: Große speicherintensive Workloads mit häufigen OOM-Fehlern
Überlegungen zur Kostenoptimierung
Standard G-Worker: Stellen ein ausgewogenes Verhältnis von Rechen-, Arbeitsspeicher- und Netzwerkressourcen bereit und können für eine Vielzahl unterschiedlicher Workloads zu geringeren Kosten eingesetzt werden
R-Worker: Spezialisiert auf speicherintensive Aufgaben mit schneller Leistung für Workloads, die große Datenmengen im Speicher verarbeiten
Bewährte Methoden
Richtlinien für die Auswahl von Arbeitnehmern
Beginnen Sie für die meisten Workloads mit Standardarbeitern (G.1X, G.2X)
Verwenden Sie R-Worker bei häufigen out-of-memory Fehlern oder Workloads mit speicherintensiven Vorgängen wie Zwischenspeichern, Mischen und Aggregieren
Ziehen Sie G.12X/G.16X für rechenintensive Workloads in Betracht, die maximale Ressourcen erfordern
Berücksichtigen Sie Kapazitätsengpässe, wenn Sie neue Mitarbeitertypen in zeitkritischen Workflows verwenden
Leistungsoptimierung
Überwachen Sie CloudWatch Kennzahlen, um die Ressourcennutzung besser zu verstehen
Verwenden Sie je nach Datengröße und Komplexität eine angemessene Anzahl von Mitarbeitern
Erwägen Sie Strategien zur Datenpartitionierung, um die Effizienz der Mitarbeiter zu optimieren
