Migrasikan beban kerja Anda dari kluster Hadoop (Konsol EMR lama) ke kluster DataLake (Konsol EMR baru). Konsol EMR baru merupakan platform data besar open source generasi berikutnya yang cloud-native dan menyediakan tipe kluster baru: DataLake, Dataflow, OLAP, dan kustom. Kluster DataLake merupakan versi peningkatan dari kluster Hadoop. Jalur migrasi ditentukan oleh tiga faktor: versi kluster, tipe penyimpanan metadata, dan metode penyimpanan data.
Prasyarat
Sebelum memulai, pastikan Anda telah:
-
Mengakses Konsol EMR lama dan Konsol EMR baru
-
Memiliki izin untuk membuat dan melepas kluster
-
Mengidentifikasi tipe penyimpanan metadata, arsitektur penyimpanan data, dan sistem penjadwalan yang digunakan di kluster lama Anda
Persiapan
Analisis kluster lama
Analisis arsitektur data besar Anda saat ini sebelum migrasi. Identifikasi dan catat hal-hal berikut:
-
Services and versions: Buat daftar setiap layanan yang berjalan di kluster lama beserta versinya. Informasi ini menentukan kompatibilitas peningkatan dan pembaruan fitur yang diperlukan.
-
Metadata storage type: Tentukan apakah kluster lama menggunakan Data Lake Formation (DLF) atau database ApsaraDB RDS yang dikelola sendiri. Hal ini menentukan jalur migrasi metadata.
-
Data storage architecture: Identifikasi apakah data disimpan di Hadoop Distributed File System (HDFS) lokal, Object Storage Service (OSS), atau JindoFS dalam mode blok. Hal ini menentukan metode migrasi data.
-
User authentication: Periksa apakah OpenLDAP, Ranger, atau Kerberos telah diterapkan. Rencanakan bagaimana kluster baru mewarisi konfigurasi keamanan tersebut.
-
Scheduling system: Identifikasi platform pengembangan dan penjadwalan untuk menjaga kelangsungan tugas selama migrasi.
Jika Anda melakukan migrasi beberapa kluster lama, lakukan satu per satu untuk menjaga kelangsungan bisnis.
Kumpulkan konfigurasi instans
Lihat konfigurasi perangkat keras dan perangkat lunak kluster lama pada tab Basic Information dan Nodes kluster Anda di halaman EMR on ECS. Catat hal-hal berikut:
| Configuration type | Items to record | Purpose |
|---|---|---|
| Software | Versi kluster, versi layanan, komponen yang digunakan, tipe penyimpanan metadata Hive | Menentukan versi yang kompatibel untuk kluster baru |
| Hardware | Zona, spesifikasi grup node, dan metode penagihan | Mereplikasi atau mengoptimalkan perangkat keras di kluster baru |
(Opsional) Ekspor konfigurasi layanan
Jika kluster lama Anda memiliki konfigurasi layanan kustom, ekspor konfigurasi tersebut agar dapat diterapkan ke kluster baru saat pembuatan, bukan dikonfigurasi ulang secara manual setelahnya.
-
Ekspor konfigurasi. Ikuti Export and import service configurations untuk mengekspor file konfigurasi. File yang diekspor berisi parameter berikut:
Saat mengekspor, perhatikan batasan berikut: - Select Configuration Files: Pilih hanya file yang telah diedit. - Export Mode: Tidak dapat diatur ke Export Only Custom or Modified Configurations untuk kluster Hadoop. - Export Format: Pilih JSON agar dapat langsung diimpor ke kluster baru.
Parameter Description ApplicationName Nama layanan ConfigFileName Nama file konfigurasi ConfigItemKey Kunci item konfigurasi ConfigItemValue Nilai item konfigurasi -
Tinjau dan bersihkan file yang diekspor. Hapus konfigurasi yang tidak berlaku di lingkungan baru:
-
YARN resource parameters: Sesuaikan nilai agar sesuai dengan spesifikasi perangkat keras aktual kluster baru.
-
JindoFS credential providers: Ganti pengaturan kredensial khusus JindoFS dengan konfigurasi OSS atau OSS-HDFS. Lihat Configure a credential provider for OSS or OSS-HDFS.
-
-
Gunakan file konfigurasi yang telah dibersihkan sebagai konfigurasi awal saat membuat kluster baru. Lihat (Optional) Custom software configuration di bagian panduan ini.
(Opsional) Tinjau tindakan bootstrap
Periksa apakah kluster lama memiliki skrip tindakan bootstrap yang dikonfigurasi. Jika iya, evaluasi setiap skrip sebelum menggunakannya di kluster baru:
-
Perbarui nama dan path paket JAR agar sesuai dengan lokasi file di konsol baru. Lihat Paths of frequently used files.
-
Perbarui perintah OSS apa pun yang digunakan dalam skrip. Lihat Manage bootstrap actions.
Setelah diperbarui, unggah skrip ke OSS dan rujuk path baru saat membuat kluster.
Validasi semua skrip tindakan bootstrap di lingkungan pengujian sebelum menerapkannya ke kluster produksi.
(Opsional) Tinjau aturan penskalaan otomatis
Jika penskalaan otomatis dikonfigurasi di kluster lama, catat parameter berikut sebelum membuat kluster baru, lalu konfigurasi ulang setelah kluster baru siap:
-
Di Konsol EMR lama, buka EMR on ECS, buka kluster, lalu klik tab Auto Scaling.
-
Klik Configure Rule untuk grup penskalaan otomatis terkait dan catat:
-
Maximum Number of Instances
-
Minimum Number of Instances
-
Graceful Shutdown
-
Trigger Mode
-
Trigger Rule (Scale Out dan Scale In)
-
Untuk konfigurasi ulang di kluster baru, lihat Add auto scaling rules.
Di kluster baru, Anda juga dapat mengonfigurasi Instance Type Selection Mode, Billing Method, Instance Type, dan Graceful Shutdown di panel Configure Auto Scaling. Lihat Manage node groups.
(Opsional) Evaluasi beban kluster
Sebelum menentukan ukuran kluster baru, tinjau pemanfaatan sumber daya di kluster lama:
-
Service metrics: Lihat penggunaan sumber daya YARN dan HDFS. Lihat View service metrics.
-
EMR Doctor daily reports: Tinjau distribusi sumber daya komputasi, penjadwalan YARN, dan penyimpanan HDFS. Lihat View daily cluster reports and analysis results in the reports.
Aktifkan EMR Doctor sebelum menggunakannya di konsol lama. Lihat Activate EMR Doctor (Hadoop clusters).
Rencanakan migrasi
Berdasarkan evaluasi Anda, tentukan hal-hal berikut sebelum melanjutkan:
-
Versi produk dan layanan: Tentukan layanan dan versi yang akan diterapkan di kluster baru. Lihat Select the product version and optional services di Langkah 1.
-
Penyimpanan metadata: Pilih DLF Unified Metadata atau RDS yang dikelola sendiri.
Built-in MySQL hanya untuk lingkungan pengujian dan tidak boleh digunakan di produksi.
-
Penyimpanan data: Pilih OSS-HDFS atau OSS.
Langkah 1: Buat kluster di Konsol EMR baru
Buat kluster baru
Ikuti Create a cluster dan terapkan konfigurasi yang telah Anda kumpulkan. Perhatikan pengaturan berikut.
Versi produk dan layanan opsional (pilih minimal satu)
Pilih layanan dan versi berdasarkan kompatibilitas dengan kluster lama Anda.
Kompatibilitas layanan
Saat komunitas open source merilis versi yang lebih baru, beberapa layanan di kluster DataLake berada pada versi yang lebih mutakhir dibandingkan di kluster Hadoop. Tabel berikut menunjukkan rentang kompatibilitas mundur. Dalam setiap rentang, versi yang lebih baru dapat membaca data yang dihasilkan oleh versi yang lebih lama.
| Service | Range 1 | Range 2 | Range 3 | Range 4 |
|---|---|---|---|---|
| Spark | 2.X | 3.X | — | — |
| Hive | 2.X | 3.X | — | — |
| Tez | All versions compatible | — | — | — |
| Delta Lake | 0.6.X | 0.8.0–1.1.0 | — | — |
| Iceberg | 0.12.X | 0.13.X | — | — |
| Hudi | 0.6.X | 0.8.X | 0.9.X | 0.10.X |
| Sqoop | All versions compatible | — | — | — |
| Ranger | 1.X | 2.X | — | — |
| OpenLDAP | All versions compatible | — | — | — |
Informasi kompatibilitas hanya sebagai referensi. Verifikasi terhadap dokumentasi resmi setiap layanan.
Beberapa layanan yang tersedia di konsol lama tidak didukung di konsol baru, termasuk Hue, Zeppelin, dan Oozie. Migrasikan layanan tersebut ke EMR Notebook atau EMR Workflow, atau terapkan engine ekuivalen di kluster baru.
Versi produk
Pilih seri versi EMR berdasarkan versi kluster lama. Dalam skenario data lake, EMR menyediakan dua seri: EMR V3.X dan EMR V5.X.
| Versi kluster lama | Seri versi kluster baru |
|---|---|
| EMR V3.35.0 (YARN 2.8.5, HDFS 2.8.5, Hive 2.3.7, Spark 2.4.7) | Seri EMR V3.X |
| EMR V5.6.0 (YARN 3.2.1, HDFS 3.2.1, Hive 3.1.2, Spark 3.2.1) | Seri EMR V5.X |
Saat persyaratan versi perangkat lunak terpenuhi, pilih versi EMR terbaru yang tersedia untuk mengakses fitur-fitur terbaru.
Pilih HDFS atau OSS-HDFS
Mulai dari EMR V5.12.1 dan EMR V3.46.1, Anda dapat memilih HDFS atau OSS-HDFS sebagai penyimpanan dasar dari layanan opsional.
Pilih layanan opsional berdasarkan solusi penyimpanan yang direncanakan:
| Penyimpanan di konsol baru | Layanan yang dipilih |
|---|---|
| OSS | OSS-HDFS |
| OSS-HDFS | OSS-HDFS |
Jika Anda memilih OSS-HDFS, konfigurasikan parameter Root Storage Directory of Cluster untuk menentukan bucket dengan OSS-HDFS yang diaktifkan sebagai path penyimpanan root kluster.
Metadata
| Metadata storage type | Description |
|---|---|
| DLF Unified Metadata (direkomendasikan) | Metadata disimpan di DLF. Jika kluster lama sudah menggunakan DLF, atur DLF Catalog ke nilai yang sama — metadata akan dibagi secara otomatis dan tidak perlu migrasi. |
| Self-managed RDS | Metadata disimpan di database ApsaraDB RDS yang Anda kelola. Konfigurasikan parameter database yang ada. Lihat Configure a self-managed ApsaraDB RDS for MySQL database. |
| Built-in MySQL | Metadata disimpan di database MySQL lokal pada kluster. Hanya untuk lingkungan pengujian. |
(Opsional) Konfigurasi perangkat lunak kustom
Jika Anda mengekspor konfigurasi layanan dari kluster lama, aktifkan Custom Software Configuration saat membuat kluster baru dan tempel konten konfigurasi ke dalam kolom tersebut. Lihat Customize software configurations.
Konfigurasi perangkat keras
Pilih perangkat keras untuk node master, core, dan task berdasarkan data pemanfaatan sumber daya yang telah Anda kumpulkan:
-
Gunakan keluarga instans ECS terbaru dan tipe disk cloud untuk mengakses kemampuan perangkat keras terbaru.
-
Tambahkan grup node dengan peran yang sama setelah pembuatan kluster jika diperlukan.
-
Assign Public Network IP: Aktifkan sakelar ini untuk grup node master jika Anda memerlukan akses Internet ke node master atau ke antarmuka web komponen open source.
(Opsional) Buat gateway
Jika Anda menggunakan gateway di konsol lama untuk mengirim pekerjaan dan mengisolasi kluster, terapkan gateway di lingkungan baru menggunakan EMR-CLI. Tool ini menerapkan gateway pada instans ECS yang ada dan secara otomatis menyinkronkan konfigurasi kluster. Lihat Use EMR-CLI to deploy a gateway.
Langkah 2: Migrasi dan verifikasi data
Dengan kluster baru yang berjalan, migrasikan metadata, data, dan pekerjaan dari kluster lama.
Migrasi metadata
Pilih metode migrasi berdasarkan mode manajemen metadata di kluster lama dan baru. DLF Unified Metadata sangat direkomendasikan untuk kluster baru.
| Old metadata mode | New metadata mode | Migration method |
|---|---|---|
| DLF | DLF | Tidak perlu migrasi. Atur katalog DLF yang sama di kluster baru. |
| Unified metabase | DLF | Lihat Migration of EMR metadata. |
| Local MySQL | DLF | Lihat Migrasikan metadata. |
| Self-managed ApsaraDB RDS | DLF | Lihat Migrate metadata. |
Migrasi data
Pilih metode migrasi berdasarkan mode penyimpanan di kluster lama dan baru.
| Old storage | New storage | Migration method |
|---|---|---|
| OSS | OSS | Tidak perlu migrasi. |
| OSS | OSS-HDFS | Gunakan Jindo DistCp. |
| JindoFS in block mode | OSS-HDFS | Gunakan Jindo DistCp. |
| HDFS | OSS-HDFS | Gunakan Jindo DistCp. |
Verifikasi data
Lewati langkah ini jika tidak diperlukan migrasi data.
Setelah migrasi, verifikasi kebenaran data HDFS serta data di database dan tabel Hive. Jika ditemukan ketidakkonsistenan, jalankan ulang tugas yang terpengaruh atau tambahkan data yang hilang segera.
| Requirement | Verification method |
|---|---|
| File verification | Hitung nilai checksum sebelum dan sesudah migrasi lalu bandingkan untuk memastikan tidak ada perubahan atau korupsi data. |
| Rough data verification | Periksa statistik tingkat tabel — jumlah baris, jumlah dan rata-rata kolom numerik, serta nilai minimum dan maksimum — untuk mengevaluasi konsistensi secara keseluruhan. |
| Detailed data verification | Bandingkan setiap baris data untuk memastikan semua catatan tetap utuh setelah migrasi. |
Migrasi pekerjaan
Migrasikan pekerjaan berdasarkan lingkungan penjadwalan Anda:
-
EMR Data Platform (konsol lama): Migrasikan ke EMR Workflow. Lihat Announcement on the migration of data from EMR Data Platform in the old EMR console.
-
DataWorks atau platform yang dikelola sendiri: Ikuti dokumentasi migrasi untuk platform Anda. Perbarui konfigurasi penting seperti titik akhir kluster komputasi agar mengarah ke kluster baru.
Langkah 3: Jalankan verifikasi paralel
Sebelum beralih trafik, jalankan pekerjaan secara simultan di kedua kluster (lama dan baru) untuk memverifikasi konsistensi data dan akurasi bisnis. Pendekatan ini kadang disebut verifikasi double-run.
Pendekatan spesifik bergantung pada arsitektur bisnis, kebutuhan pemrosesan data, dan toleransi risiko Anda. Rancang rencana eksekusi paralel yang sesuai dengan skenario Anda. Tujuannya adalah memastikan kluster baru menghasilkan hasil identik dengan kluster lama sebelum Anda melakukan alih sistem.
Langkah 4: Alih sistem dan lepas kluster lama
Setelah verifikasi paralel mengonfirmasi bahwa kluster baru menangani semua beban kerja dengan benar, jadwalkan jendela pemeliharaan dan lakukan alih sistem:
-
Alihkan pekerjaan secara bertahap dari kluster lama ke kluster baru.
-
Tingkatkan volume pemrosesan pekerjaan di kluster baru secara bertahap.
-
Monitor kluster baru hingga semua pekerjaan berjalan stabil.
Setelah semua data bisnis berjalan di kluster baru dan tidak ada beban kerja yang tersisa di kluster lama, lepaskan kluster lama mengikuti Release a cluster.