Wilayah dan arsitektur penyimpanan merupakan dua keputusan paling berdampak yang harus Anda ambil sebelum membuat kluster E-MapReduce (EMR). Pemilihan wilayah yang tepat menghilangkan biaya transfer lintas wilayah dan mengurangi latensi. Arsitektur penyimpanan yang tepat menentukan cara kluster Anda diskalakan, biayanya, serta apakah data Anda tetap tersimpan setelah kluster dihentikan.
Pilih wilayah
Sebarkan kluster EMR Anda di wilayah yang sama dengan data Anda. Misalnya, jika data sumber Anda berada di bucket Object Storage Service (OSS) atau instans ApsaraDB RDS di China (Shanghai), buat kluster Anda di China (Shanghai). Jika Anda juga menulis output ke OSS, buat bucket tersebut di wilayah yang sama. Menempatkan kluster dan datanya dalam satu wilayah menghilangkan biaya transfer lintas wilayah dan mengurangi latensi.
Selain lokasi data, pertimbangkan faktor-faktor berikut saat memilih wilayah.
| Faktor | Yang perlu diperiksa |
|---|---|
| Ketersediaan layanan EMR | Pastikan EMR tersedia di wilayah tersebut. Beberapa layanan—seperti OSS-HDFS dan Data Lake Formation (DLF)—tidak tersedia di semua wilayah. Tipe instans dengan SSD lokal juga bersifat spesifik per wilayah. |
| Harga instans ECS | Harga instans Elastic Compute Service (ECS) bervariasi tergantung wilayah. Gunakan ECS Price Calculator untuk membandingkan biaya sebelum melakukan komitmen. |
| Topologi layanan | Tempatkan EMR di wilayah yang sama dengan layanan dependen—seperti Virtual Private Cloud (VPC), Server Load Balancer (SLB), dan database—untuk menghindari biaya operasi lintas wilayah. Untuk penyebaran cloud hibrid, pilih wilayah yang paling dekat dengan titik akses pusat data Anda. |
Wilayah yang didukung
| Geografi | Wilayah |
|---|---|
| Asia Pasifik - China | China (Hangzhou), China (Shanghai), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Ulanqab), China (Shenzhen), China (Chengdu), China (Hong Kong) |
| Asia Pasifik - lainnya | Jepang (Tokyo), Singapura, Malaysia (Kuala Lumpur), Indonesia (Jakarta) |
| Eropa dan Amerika | Jerman (Frankfurt), Inggris (London), AS (Silicon Valley), AS (Virginia) |
| Timur Tengah | UEA (Dubai) |
Rencanakan penyimpanan
Pilih arsitektur penyimpanan
EMR mendukung dua arsitektur penyimpanan: pemisahan compute-storage dan integrasi compute-storage.
HDFS bersifat sementara. Semua data yang disimpan di HDFS akan dihapus secara permanen ketika kluster EMR dilepas. Jika Anda menggunakan HDFS, cadangkan data kritis ke OSS atau OSS-HDFS sebelum melepas kluster.
| Pemisahan Komputasi dan Penyimpanan (OSS-HDFS atau OSS) | Integrasi compute-storage (HDFS) | |
|---|---|---|
| Gunakan saat | Arsitektur data lake; analisis data dingin | Diperlukan pembacaan dan penulisan berlatensi rendah |
| Persistensi data | Data tetap tersimpan setelah kluster dilepas | Data dihapus saat kluster dilepas |
| Ketahanan data | 99,9999999999% (dua belas angka sembilan) | Mengandalkan mekanisme replika; tidak memiliki disaster recovery lintas wilayah |
| Keandalan data | OSS mendukung locally redundant storage (LRS) dan zone-redundant storage (ZRS), menyediakan keandalan tinggi lintas zona | Tiga replika untuk disk lokal, dua replika untuk disk cloud; replika terbatas pada kluster |
| Scaling | Tambahkan node compute (CN) secara independen tanpa menyentuh penyimpanan | Harus menskalakan compute dan penyimpanan secara bersamaan; penghapusan node dilakukan secara berurutan dan memerlukan penyeimbangan ulang |
| Biaya penyimpanan | USD 0,0170 per GB-bulan (penyimpanan OSS Standard). OSS-HDFS juga menghasilkan data tambahan, yang menimbulkan biaya penyimpanan OSS tambahan. Lihat penagihan OSS dan harga OSS. | USD 0,051 per GiB-bulan. Lihat penagihan penyimpanan blok EBS dan harga ECS. |
| O&M | CN bersifat stateless dan dapat diganti dengan cepat; kapasitas penyimpanan bertambah tanpa perlu penyesuaian manual pada kluster | Kegagalan DataNode memerlukan penyeimbangan ulang manual; pengubahan ukuran kluster memerlukan intervensi manual |
| Akses | oss://bucket-name.endpoint/path/to/data. Lihat Memulai. |
Kluster HA: hdfs://namespace/path; kluster non-HA: hdfs://namenode-host:port/path |
Pilih tipe disk
Setiap node dalam kluster EMR memiliki sistem disk dan opsional satu atau beberapa data disk.
| Disk | Tujuan | Jenis yang didukung |
|---|---|---|
| System disk | Menginstal sistem operasi; tidak menyimpan data bisnis | Hanya cloud disk |
| Data disk | Menyimpan data, log lokal, dan data shuffle | Cloud disk dan local disk |
Dengan kapasitas penyimpanan yang sama, Anda dapat mengonfigurasi beberapa data disk untuk meningkatkan ketersediaan layanan. Jika Anda mengonfigurasi beberapa data disk, layanan tertentu dapat menyediakan kemampuan toleransi kesalahan, dan fungsi keseluruhan data disk tidak terpengaruh jika terjadi kegagalan disk.
Disk cloud
Disk cloud menggunakan mekanisme triplicate terdistribusi dan menyediakan keandalan data 99,9999999% (sembilan angka sembilan). EMR mendukung tiga tipe disk cloud.
| Tipe disk | Latensi | IOPS dan throughput | Gunakan saat |
|---|---|---|---|
| ESSD | 0,2 ms | Tinggi; mendukung tingkat kinerja PL0 hingga PL3. Lihat ESSD. | Workload sensitif latensi atau intensif I/O: database OLTP skala besar, database NoSQL, Elasticsearch |
| Standard SSD | 0,5–2 ms | Relatif tinggi | Aplikasi intensif I/O; database relasional dan NoSQL skala kecil hingga menengah |
| Ultra disk | 1–3 ms | Menengah | Pengembangan dan pengujian; sistem disk |
Untuk perbandingan detail performa disk cloud dan disk lokal, lihat Performa penyimpanan blok.
Disk lokal
Disk lokal terpasang secara fisik pada server host dan menyediakan latensi sangat rendah serta throughput tinggi untuk penyimpanan data skala besar.
Di Konsol EMR, disk lokal dipasang saat Anda mengatur Type grup node menjadi Big Data atau Local SSD.
Disk lokal hanya didukung pada node core dan task, bukan pada node master.
Data pada disk lokal dapat hilang jika terjadi kegagalan perangkat keras host. Konfigurasikan kebijakan pencadangan saat menggunakan disk lokal untuk data bisnis.
Evaluasi kapasitas penyimpanan
Setelah memilih arsitektur penyimpanan, perkirakan kapasitas disk yang dibutuhkan berdasarkan volume data dan tren pertumbuhannya. Rencanakan minimal untuk pertumbuhan data selama enam bulan ke depan.
| Jenis data | Deskripsi | Perhitungan |
|---|---|---|
| Data mentah | Data yang dihasilkan langsung oleh bisnis Anda, seperti log | Ruang yang dibutuhkan = volume data mentah |
| Data antara | Data sementara yang dihasilkan selama pemrosesan, seperti hasil ETL | Ruang yang dibutuhkan = volume data mentah × 1,5 (sesuaikan berdasarkan kompleksitas workload) |
| Data hasil | Output akhir yang harus disimpan | Ruang yang dibutuhkan = volume data mentah × 10%–50% (sesuaikan berdasarkan kebutuhan retensi) |
Integrasi compute-storage (HDFS): Tambahkan overhead replika ke total. HDFS secara default menggunakan tiga replika untuk disk lokal dan dua replika untuk disk cloud.
Pemisahan compute-storage (OSS-HDFS atau OSS): Data disk hanya perlu menampung hasil komputasi sementara, log lokal, dan data shuffle. Data bisnis disimpan secara tahan lama di OSS.