Metadata E-MapReduce (EMR) mencakup informasi inti terkait penyimpanan data, struktur data, dan izin akses dari kluster EMR. EMR memungkinkan Anda menyimpan metadata di Data Lake Formation (DLF), ApsaraDB RDS for MySQL, atau MySQL bawaan. Topik ini menjelaskan perbedaan antara layanan metadata tersebut sehingga Anda dapat menentukan pilihan berdasarkan kebutuhan bisnis.
Perbedaan di antara layanan metadata
Item | |||
Penyimpanan backend | Data disimpan di DLF. | Data disimpan di instance ApsaraDB RDS for MySQL. Anda harus membeli instance ApsaraDB RDS for MySQL terlebih dahulu dan mengonfigurasi lingkungan jaringan. | Data disimpan di instance MySQL dari kluster EMR. |
Lingkungan yang sesuai | Lingkungan pengujian dan produksi. | Lingkungan pengujian dan produksi. | Pengujian proof of concept (POC) untuk kluster tunggal. Catatan Disarankan untuk tidak menggunakan MySQL bawaan karena basis data lokal ditempatkan pada satu node kluster EMR. Hal ini dapat menyebabkan masalah stabilitas dan ketersediaan tinggi tidak dapat dijamin. |
Berbagi metadata lintas kluster | Didukung. | Didukung. | Tidak didukung. |
Kompatibilitas mesin | Hive, Spark, Presto, MaxCompute, dan Hologres didukung. |
|
|
Manajemen metadata | Retrieval metadata tervisualisasi, manajemen metadata, manajemen multi-versi, statistik data, dan manajemen siklus hidup didukung. | Tidak tersedia. | Tidak tersedia. |
Ketersediaan tinggi (HA) | Disaster recovery primer/sekunder didukung. | Disaster recovery primer/sekunder didukung. | Disaster recovery tidak didukung. |
Biaya O&M | Auto scaling didukung. Tidak diperlukan operasi O&M manual. | Operasi O&M seperti peningkatan dan skala keluar harus dilakukan secara manual. ApsaraDB RDS Mandiri cocok untuk skenario fleksibel dan mendetail dalam mengelola kluster EMR. | Basis data MySQL lokal ditempatkan pada satu node kluster EMR, meningkatkan biaya peningkatan. |
Penagihan | Saat ini, DLF gratis. Untuk informasi lebih lanjut tentang penagihan DLF, lihat Penagihan. | Biaya dasar instance ApsaraDB RDS mencakup biaya sumber daya komputasi dan penyimpanan. Untuk informasi lebih lanjut, lihat Item yang dapat ditagih. | Tidak ada biaya tambahan. |
Saat memilih layanan metadata, pastikan wilayah yang mendukung setiap layanan telah dipertimbangkan. Untuk informasi tentang wilayah yang didukung oleh DLF, lihat Wilayah dan titik akhir yang didukung.
Arsitektur penerapan layanan metadata
Arsitektur penerapan DLF
Metadata disimpan di DLF. DLF mendukung berbagi metadata di antara beberapa kluster. SDK klien DLF menyediakan API yang kompatibel dengan Hive Metastores, sehingga mesin tertentu dapat langsung menggunakan SDK klien DLF untuk mengakses metadata di DLF. Pengguna juga dapat menggunakan klien DLF untuk mengakses metadata. Untuk informasi lebih lanjut, lihat topik dalam direktori Pengenalan Produk.
Arsitektur penerapan DLF dalam kluster tunggal | Arsitektur penerapan DLF dalam beberapa kluster |
Arsitektur penerapan ApsaraDB RDS Mandiri
Metadata disimpan di instance ApsaraDB RDS for MySQL. ApsaraDB RDS Mandiri mendukung berbagi metadata di antara beberapa kluster, serta akses melalui Hive Metastores di kluster tersebut.
Arsitektur penerapan ApsaraDB RDS Mandiri dalam kluster tunggal | Arsitektur penerapan ApsaraDB RDS Mandiri dalam beberapa kluster |
Arsitektur penerapan MySQL Bawaan
Metadata disimpan di MySQL. Instance MySQL Server ditempatkan di kluster EMR, biasanya pada Node master. Metadata tidak dapat dibagikan di antara beberapa kluster karena setiap kluster memiliki basis data MySQL sendiri.
Nama pengguna untuk masuk ke MySQL bawaan adalah root, dengan kata sandi EMRroot1234.
Arsitektur penerapan MySQL Bawaan dalam kluster tunggal | Arsitektur penerapan MySQL Bawaan dalam beberapa kluster |
Referensi
Untuk informasi tentang cara mengubah tipe penyimpanan metadata kluster EMR, lihat Gunakan DLF untuk penyimpanan metadata terpadu.
Jika Anda menggunakan ApsaraDB RDS Mandiri sebagai layanan metadata, konfigurasikan basis data ApsaraDB RDS for MySQL mandiri. Untuk informasi lebih lanjut, lihat konfigurasikan RDS mandiri.