Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
AWS Glue jenis pekerja
Gambaran Umum
AWS Glue menyediakan beberapa jenis pekerja untuk mengakomodasi kebutuhan beban kerja yang berbeda, mulai dari pekerjaan streaming kecil hingga tugas pemrosesan data skala besar dan intensif memori. Bagian ini memberikan informasi lengkap tentang semua jenis pekerja yang tersedia, spesifikasinya, dan rekomendasi penggunaannya.
Kategori tipe pekerja
AWS Glue menawarkan dua kategori utama jenis pekerja:
-
Jenis Pekerja G: Pekerja komputasi tujuan umum yang dioptimalkan untuk beban kerja ETL standar
-
Jenis R Worker: Pekerja yang dioptimalkan untuk memori yang dirancang untuk aplikasi Spark intensif memori
Unit Pengolahan Data (DPUs)
Sumber daya yang tersedia pada AWS Glue pekerja diukur dalam DPUs. DPU adalah ukuran relatif daya pemrosesan yang terdiri dari 4 v CPUs kapasitas komputasi dan memori 16 GB.
Memory-Optimized DPUs (M-DPUs): Pekerja tipe R menggunakan M-DPUs, yang menyediakan alokasi memori dua kali lipat untuk ukuran tertentu dibandingkan dengan standar. DPUs Ini berarti bahwa sementara DPU standar menyediakan 16 GB memori, M-DPU pada pekerja tipe R menyediakan memori 32GB yang dioptimalkan untuk aplikasi Spark intensif memori.
Jenis pekerja yang tersedia
G.1X - Pekerja Standar
DPU: 1 DPU (4 vCPUs, memori 16 GB)
Penyimpanan: 94GB disk (sekitar 44GB gratis)
Kasus Penggunaan: Data mengubah, bergabung, dan kueri - skalabel dan hemat biaya untuk sebagian besar pekerjaan
G.2X - Pekerja Standar
DPU: 2 DPU (8 vCPUs, memori 32 GB)
Penyimpanan: 138GB disk (sekitar 78GB gratis)
Kasus Penggunaan: Data mengubah, bergabung, dan kueri - skalabel dan hemat biaya untuk sebagian besar pekerjaan
G.4X - Pekerja Besar
DPU: 4 DPU (16 vCPUs, memori 64 GB)
Penyimpanan: 256GB disk (sekitar 230GB gratis)
Kasus Penggunaan: Menuntut transformasi, agregasi, gabungan, dan kueri
G.8X - Pekerja Ekstra Besar
DPU: 8 DPU (memori 32 vCPUs, 128 GB)
Penyimpanan: 512GB disk (sekitar 485GB gratis)
Kasus Penggunaan: Transformasi, agregasi, gabungan, dan kueri yang paling menuntut
G.12X - Pekerja Sangat Besar*
DPU: 12 DPU (48 vCPUs, memori 192 GB)
Penyimpanan: 768GB disk (sekitar 741GB gratis)
Kasus Penggunaan: Beban kerja yang sangat besar dan padat sumber daya yang membutuhkan kapasitas komputasi yang signifikan
G.16X - Pekerja Maksimum*
DPU: 16 DPU (64 vCPUs, memori 256 GB)
Penyimpanan: 1024GB disk (sekitar 996GB gratis)
Kasus Penggunaan: Beban kerja terbesar dan paling padat sumber daya yang membutuhkan kapasitas komputasi maksimum
R.1X - Kecil yang Dioptimalkan Memori*
DPU: 1 M-DPU (4 vCPUs, memori 32 GB)
Kasus Penggunaan: Beban kerja intensif memori dengan out-of-memory kesalahan yang sering terjadi atau persyaratan rasio tinggi memory-to-CPU
R.2X - Media yang Dioptimalkan Memori*
DPU: 2 M-DPU (8 vCPUs, memori 64 GB)
Kasus Penggunaan: Beban kerja intensif memori dengan out-of-memory kesalahan yang sering terjadi atau persyaratan rasio tinggi memory-to-CPU
R.4X - Memori-Dioptimalkan Besar*
DPU: 4 M-DPU (memori 16 vCPUs, 128 GB)
Kasus Penggunaan: Beban kerja intensif memori besar dengan out-of-memory kesalahan yang sering terjadi atau persyaratan rasio tinggi memory-to-CPU
R.8X - Dioptimalkan Memori Ekstra Besar*
DPU: 8 M-DPU (memori 32 vCPUs, 256 GB)
Kasus Penggunaan: Beban kerja intensif memori yang sangat besar dengan out-of-memory kesalahan yang sering terjadi atau persyaratan rasio tinggi memory-to-CPU
* Anda mungkin mengalami latensi startup yang lebih tinggi dengan para pekerja ini. Untuk mengatasi masalah ini, coba lakukan hal berikut:
Tunggu beberapa menit dan kemudian kirimkan pekerjaan Anda lagi.
Kirim pekerjaan baru dengan jumlah pekerja yang berkurang.
Kirim pekerjaan baru menggunakan jenis atau ukuran pekerja yang berbeda.
Tabel spesifikasi tipe pekerja
| Jenis Pekerja | DPU per Node | vCPU | Memori (GB) | Disk (GB) | Ruang Disk Gratis (GB) | Pelaksana Spark untuk Node |
|---|---|---|---|---|---|---|
| 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 |
Catatan: Jenis pekerja R memiliki konfigurasi yang dioptimalkan untuk memori dengan spesifikasi yang dioptimalkan untuk beban kerja intensif memori.
Pertimbangan penting
Latensi startup
penting
Jenis pekerja G.12X dan G.16X, serta semua tipe pekerja R (R.1X hingga R.8X), mungkin mengalami latensi startup yang lebih tinggi. Untuk mengatasi masalah ini, coba lakukan hal berikut:
Tunggu beberapa menit dan kemudian kirimkan pekerjaan Anda lagi.
Kirim pekerjaan baru dengan jumlah pekerja yang berkurang.
Kirim pekerjaan baru menggunakan jenis dan ukuran pekerja yang berbeda.
Memilih jenis pekerja yang tepat
Untuk beban kerja ETL standar
G.1X atau G.2X: Paling hemat biaya untuk transformasi, penggabungan, dan kueri data tipikal
G.4X atau G.8X: Untuk beban kerja yang lebih menuntut dengan kumpulan data yang lebih besar
Untuk beban kerja skala besar
G.12X: Kumpulan data yang sangat besar yang membutuhkan sumber daya komputasi yang signifikan
G.16X: Kapasitas komputasi maksimum untuk beban kerja yang paling menuntut
Untuk beban kerja yang intensif memori
R.1X atau R.2X: Pekerjaan intensif memori kecil hingga menengah
R.4X atau R.8X: Beban kerja intensif memori besar dengan kesalahan OOM yang sering
Pertimbangan Optimalisasi Biaya
Pekerja G standar: Menyediakan keseimbangan sumber daya komputasi, memori, dan jaringan, dan dapat digunakan untuk berbagai beban kerja yang beragam dengan biaya lebih rendah
Pekerja R: Khusus untuk tugas intensif memori dengan kinerja cepat untuk beban kerja yang memproses kumpulan data besar dalam memori
Praktik terbaik
Pedoman pemilihan pekerja
Mulailah dengan pekerja standar (G.1X, G.2X) untuk sebagian besar beban kerja
Gunakan pekerja R saat sering mengalami out-of-memory kesalahan atau beban kerja dengan operasi intensif memori seperti caching, shuffling, dan agregasi
Pertimbangkan G.12X/G.16X untuk beban kerja intensif komputasi yang membutuhkan sumber daya maksimum
Memperhitungkan kendala kapasitas saat menggunakan tipe pekerja baru dalam alur kerja yang sensitif terhadap waktu
Optimalisasi kinerja
Pantau CloudWatch metrik untuk memahami pemanfaatan sumber daya
Gunakan jumlah pekerja yang sesuai berdasarkan ukuran dan kompleksitas data
Pertimbangkan strategi partisi data untuk mengoptimalkan efisiensi pekerja
