本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# AWS Glue 工作者類型
<a name="worker-types"></a>

## 概觀
<a name="worker-types-overview"></a>

AWS Glue 提供多種工作者類型，以因應不同的工作負載需求，從小型串流任務到大規模的記憶體密集型資料處理任務。本節提供有關所有可用工作者類型、其規格和用法建議的完整資訊。

### 工作者類型類別
<a name="worker-type-categories"></a>

AWS Glue 提供兩種主要類別的工作者類型：
+ **G 工作者類型**：針對標準 ETL 工作負載最佳化的一般用途運算工作者
+ **R 工作者類型**：專為記憶體密集型 Spark 應用程式而設計的記憶體最佳化工作者

### 資料處理單位 (DPU)
<a name="data-processing-units"></a>

 AWS Glue 工作者可用的資源是以 DPUs測量。DPU 是處理能力的相對測量，包含 4 個 vCPUs的運算容量和 16 GB 的記憶體。

**記憶體最佳化 DPU (M-DPU)**：R 類型工作者使用 M-DPU，相較於標準 DPU，在指定大小下可提供兩倍的記憶體分配。這表示雖然標準 DPU 可提供 16 GB 的記憶體，但 R 類型工作者中的 M-DPU 可提供專為記憶體密集型 Spark 應用程式最佳化的 32GB 記憶體。

## 可用的工作者類型
<a name="available-worker-types"></a>

### G.1X
<a name="g1x-standard-worker"></a>
+ **DPU**：1 個 DPU (4 個 vCPU、16 GB 記憶體)
+ **儲存**：94GB 磁碟 (大約 44GB 可用)
+ **使用案例**：資料轉換、聯結和查詢 - 可擴展且符合成本效益，適合大多數任務

### G.2X
<a name="g2x-standard-worker"></a>
+ **DPU**：2 個 DPU (8 個 vCPU、32 GB 記憶體)
+ **儲存**：138GB 磁碟 (大約 78GB 可用)
+ **使用案例**：資料轉換、聯結和查詢 - 可擴展且符合成本效益，適合大多數任務

### G.4X
<a name="g4x-large-worker"></a>
+ **DPU**：4 個 DPU (16 個 vCPU、64 GB 記憶體)
+ **儲存**：256GB 磁碟 (大約 230GB 可用)
+ **使用案例**：嚴苛的轉換、彙總、聯結和查詢

### G.8X
<a name="g8x-extra-large-worker"></a>
+ **DPU**：8 個 DPU (32 個 vCPU、128 GB 記憶體)
+ **儲存**：512GB 磁碟 (大約 485GB 可用)
+ **使用案例**：嚴苛的轉換、彙總、聯結和查詢

### G.12X
<a name="g12x-very-large-worker"></a>
+ **DPU**：12 個 DPU (48 個 vCPU、192 GB 記憶體)
+ **儲存**：768GB 磁碟 (大約 741GB 可用)
+ **使用案例**：需要大量運算容量的超大型且資源密集型工作負載

### G.16X
<a name="g16x-maximum-worker"></a>
+ **DPU**：16 個 DPU (64 個 vCPU、256 GB 記憶體)
+ **儲存**：1024GB 磁碟 (大約 996GB 可用)
+ **使用案例**：需要最大運算容量的最大且資源密集型工作負載

### R.1X - 記憶體最佳化\$1
<a name="r1x-memory-optimized-small"></a>
+ **DPU**：1 個 M-DPU (4 個 vCPU，32 GB 記憶體)
+ **使用案例**：記憶體密集型工作負載，經常出現記憶體不足錯誤或者記憶體與 CPU 比率要求較高

### R.2X - 記憶體最佳化\$1
<a name="r2x-memory-optimized-medium"></a>
+ **DPU**：2 個 M-DPU (8 個 vCPU，64 GB 記憶體)
+ **使用案例**：記憶體密集型工作負載，經常出現記憶體不足錯誤或者記憶體與 CPU 比率要求較高

### R.4X - 記憶體最佳化\$1
<a name="r4x-memory-optimized-large"></a>
+ **DPU**：4 個 M-DPU (16 個 vCPU，128 GB 記憶體)
+ **使用案例**：大型記憶體密集型工作負載，經常出現記憶體不足錯誤或者記憶體與 CPU 比率要求較高

### R.8X - 記憶體最佳化\$1
<a name="r8x-memory-optimized-extra-large"></a>
+ **DPU**：8 個 M-DPU (32 個 vCPU，256 GB 記憶體)
+ **使用案例**：超大型記憶體密集型工作負載，經常出現記憶體不足錯誤或者記憶體與 CPU 比率要求較高

**\$1** 使用這些工作者時，可能會遇到較高的啟動延遲。若要解決問題，請嘗試下列方法：
+ 等候幾分鐘，然後再次提交您的任務。
+ 提交減少工作者數目的新任務。
+ 使用不同的工作者類型或大小提交新任務。

## 工作者類型規格表
<a name="worker-type-specifications"></a>


**工作者類型規格**  

| 工作者類型 | 每個節點的 DPU | vCPU | 記憶體 (GB) | 磁碟 (GB) | 大約可用磁碟空間 (GB) | 每個節點的 Spark 執行器 | 
| --- | --- | --- | --- | --- | --- | --- | 
| 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.8X | 8 | 32 | 256 | 512 | 485 | 1 | 

*注意*：R 工作者類型具有記憶體最佳化組態，其規格已針對記憶體密集型工作負載進行了最佳化。

## 重要考量
<a name="important-considerations"></a>

### 啟動延遲
<a name="startup-latency"></a>

**重要**  
G.12X 和 G.16X 工作者類型，以及所有 R 工作者類型 (R.1X 到 R.8X)，可能會遇到較高的啟動延遲。若要解決問題，請嘗試下列方法：  
等候幾分鐘，然後再次提交您的任務。
提交減少工作者數目的新任務。
使用不同的工作者類型和大小提交新任務。

## 選擇正確的工作者類型
<a name="choosing-right-worker-type"></a>

### 對於標準 ETL 工作負載
<a name="standard-etl-workloads"></a>
+ **G.1X 或 G.2X**：對於典型的資料轉換、聯結和查詢最具成本效益
+ **G.4X 或 G.8X**：適用於具有較大資料集的更嚴苛工作負載

### 適用於大規模工作負載
<a name="large-scale-workloads"></a>
+ **G.12X**：需要大量運算資源的超大型資料集
+ **G.16X**：最嚴苛工作負載的最大運算能力

### 對於記憶體密集型工作負載
<a name="memory-intensive-workloads"></a>
+ **R.1X 或 R.2X**：中小型記憶體密集型任務
+ **R.4X 或 R.8X**：經常發生 OOM 錯誤的大型記憶體密集型工作負載

## 成本最佳化考量
<a name="cost-optimization-considerations"></a>
+ **標準 G 工作者**：可平衡運算、記憶體和聯網資源，用於成本較低的各種工作負載
+ **R 工作者**：專門用於具有快速效能的記憶體密集型任務，適用於在記憶體中處理大型資料集的工作負載

## 最佳實務
<a name="best-practices"></a>

### 工作者選擇準則
<a name="worker-selection-guidelines"></a>

1. 對於大多數工作負載，**從標準工作者開始** (G.1X、G.2X)

1. 當頻繁出現記憶體不足錯誤或工作負載具有快取、隨機播放和彙總等記憶體密集型操作時，**使用 R 工作者**

1. 對於需要最大資源的運算密集型工作負載，**請考慮 G.12X/G.16X** 

1. 在時間敏感型工作流程中使用新的工作者類型時，**考慮容量限制** 

### 效能最佳化
<a name="performance-optimization"></a>
+ 監控 CloudWatch 指標以了解資源使用率
+ 根據資料大小和複雜性，使用適當的工作者計數
+ 考慮資料分區策略，以最佳化工作者效率