E-MapReduce:Migrasi kluster Hadoop ke kluster DataLake

Informasi latar belakang

Konsol E-MapReduce (EMR) Next-Gen adalah platform big data open-source cloud-native generasi berikutnya dari EMR. Platform ini menghadirkan pengalaman pengguna, platform pengembangan, model resource, dan skenario analitik yang baru. Untuk detail fitur-fiturnya, lihat Pengumuman: Konsol EMR Next-Gen kini tersedia.

EMR on ECS, salah satu model resource utama EMR, mencakup berbagai pembaruan fungsional. Secara khusus, Konsol EMR Next-Gen memperkenalkan skenario kluster baru—DataLake, Dataflow, OLAP, dan Custom—yang secara signifikan meningkatkan efisiensi manajemen kluster dan performa engine dibandingkan skenario kluster lama (seperti Hadoop dan Data Science). Kluster DataLake merupakan versi peningkatan dari kluster data lake berbasis Hadoop lama. Setelah ditingkatkan ke kluster DataLake, Anda memperoleh berbagai manfaat. Untuk perbandingan fitur lengkap, lihat Kluster DataLake.

Persiapan

Tinjau arsitektur kluster lama

Tinjau arsitektur big data Anda saat ini, klarifikasi skenario aplikasi kluster lama, dan catat hal-hal berikut:

• Cakupan dan versi layanan: Catat layanan dan versinya yang berjalan di setiap kluster lama untuk mengevaluasi kompatibilitas upgrade dan kebutuhan pembaruan fitur.

• Tipe metadata: Konfirmasi tipe metadata yang digunakan oleh kluster lama (DLF atau RDS yang dikelola sendiri) untuk merencanakan strategi integrasi dan migrasi sistem manajemen metadata pada arsitektur baru.

• Arsitektur penyimpanan data: Analisis arsitektur penyimpanan data kluster lama (HDFS lokal, OSS, atau mode blok JindoFS) untuk menentukan desain jalur migrasi data.

• Arsitektur otentikasi & otorisasi pengguna: Konfirmasi apakah layanan seperti OpenLDAP, Ranger, atau Kerberos digunakan agar arsitektur baru dapat mewarisi mekanisme keamanan yang ada secara mulus.

• Sistem penjadwalan: Konfirmasi sistem pengembangan dan penjadwalan Anda saat ini untuk menjaga penjadwalan tugas yang konsisten dan lancar selama migrasi.

Jika Anda memiliki beberapa kluster lama yang perlu ditingkatkan, migrasikan satu per satu untuk memastikan kelangsungan bisnis dan stabilitas. Berdasarkan kebutuhan dan prioritas bisnis aktual, buat urutan dan rencana migrasi yang praktis guna melakukan transisi kluster lama ke kluster baru secara lancar.

Tinjau detail kluster lama

• Lihat informasi konfigurasi instans kluster

  Saat membuat kluster baru di platform baru, Anda dapat menggunakan kembali informasi dasar instans dari kluster lama. Untuk detailnya, lihat Buat kluster baru. Selain konfigurasi perangkat lunak dan keras—yang memerlukan perhatian khusus—Anda dapat menggunakan pengaturan identik untuk parameter lain di kedua kluster (lama dan baru).

  Di halaman Basic Information dan Nodes kluster EMR on ECS lama, tinjau konfigurasi kluster dan grup node, dengan fokus pada hal-hal berikut:

  Tipe konfigurasi	Nama konfigurasi	Detail yang perlu ditinjau
  Konfigurasi perangkat lunak	Versi kluster Versi layanan Daftar komponen yang benar-benar digunakan Tipe metadata Hive	Daftar layanan yang saat ini digunakan di kluster beserta versi masing-masing.
  Konfigurasi perangkat keras	Zona tempat kluster berada Tipe instans dan metode penagihan untuk setiap grup node	Zona kluster dan spesifikasi perangkat keras untuk setiap grup node—misalnya, CPU, memori, disk sistem, dan disk data.

• (Opsional) Ekspor konfigurasi komponen layanan kluster

  Selama operasi dan pemeliharaan rutin, pengguna sering menyesuaikan konfigurasi default komponen layanan atau menambahkan pengaturan kustom sesuai kebutuhan tertentu. Untuk melakukan migrasi konfigurasi tersebut secara efisien antar kluster, gunakan fitur ekspor konfigurasi EMR untuk mengekspor semua pengaturan konfigurasi dari kluster lama secara batch. Kemudian, selama inisialisasi kluster baru, impor pengaturan tersebut secara batch untuk mereplikasi konfigurasi komponen layanan dengan cepat. Alternatifnya, setelah kluster baru berhasil diluncurkan, Anda dapat menyesuaikan manual setiap konfigurasi layanan di antarmuka manajemen layanan.

  1. Ekspor konfigurasi layanan.

     Lihat Ekspor dan impor konfigurasi layanan untuk mengekspor file konfigurasi komponen layanan target hanya dengan satu klik.

     Catatan

     • Select Configuration Files: Pilih hanya file konfigurasi yang telah diedit. Beberapa pilihan diperbolehkan.

     • Export Mode: Kluster Hadoop saat ini tidak mendukung exporting only custom or modified configurations.

     • Export Format: Pilih format JSON agar mudah diimpor ke kluster baru.

     Parameter file konfigurasi yang diekspor dijelaskan dalam tabel berikut.

     Parameter	Deskripsi
     ApplicationName	Nama layanan.
     ConfigFileName	Nama file konfigurasi.
     ConfigItemKey	Nama item konfigurasi.
     ConfigItemValue	Nilai spesifik yang ditetapkan untuk item konfigurasi.

  2. Edit file konfigurasi.

     Tinjau dengan cermat informasi konfigurasi yang diekspor, pertahankan hanya item yang diperlukan untuk lingkungan baru, dan hapus konfigurasi yang tidak diperlukan.

     • Saat menyesuaikan parameter resource terkait YARN, sesuaikan erat dengan spesifikasi perangkat keras aktual kluster. Pastikan nilai parameter yang diimpor masuk akal untuk kluster baru.

     • Jika terdapat konfigurasi terkait JindoFS (misalnya, Credential Provider), sesuaikan sesuai konfigurasi OSS/OSS-HDFS. Untuk detailnya, lihat Konfigurasi OSS/OSS-HDFS Credential Provider.

  3. Terapkan file konfigurasi yang telah diedit ke (Opsional) Custom software configuration sebagai konfigurasi preset untuk kluster baru.

• (Opsional) Tinjau tindakan bootstrap

  Selama fase Lihat informasi konfigurasi instans kluster, periksa apakah kluster lama memiliki skrip bootstrap yang dikonfigurasi. Jika terdapat tindakan bootstrap, evaluasi fungsi setiap skrip secara hati-hati untuk menentukan apakah skrip tersebut harus digunakan kembali di kluster baru.

  Untuk skrip yang diperlukan di kluster baru, sesuaikan sebagai berikut agar dapat dieksekusi dengan benar:

  • Perbarui nama dan path paket JAR yang terkait dengan versi komponen open-source. Untuk path file di platform lama dan baru, lihat Path file umum.

  • Jika skrip mengunduh file dari OSS, perbarui perintah OSS yang sesuai. Untuk detailnya, lihat Skrip eksekusi tindakan bootstrap.

  Setelah memodifikasi skrip, unggah ke OSS dan masukkan alamat OSS yang diperbarui saat membuat kluster baru.

  Penting

  Sebelum menerapkan skrip bootstrap ke kluster produksi, verifikasi terlebih dahulu di lingkungan staging.

• (Opsional) Tinjau aturan Auto Scaling kluster lama

  Jika aturan Auto Scaling dikonfigurasi untuk kluster lama, tinjau aturan tersebut—dengan fokus pada jumlah instans maksimum, jumlah instans minimum, graceful shutdown, metode pemicu, dan aturan pemicu—lalu konfigurasi ulang Auto Scaling setelah membuat kluster baru. Untuk detailnya, lihat Buat kebijakan Auto Scaling kustom.

  1. Buka halaman Auto Scaling.

     1. Login ke Konsol E-MapReduce.

     2. Klik nama kluster target.

     3. Klik tab Auto Scaling.

  2. Tinjau aturan Auto Scaling.

     Di tab Auto Scaling, klik Configure Rule di kolom Actions untuk grup node yang memiliki aturan Auto Scaling yang dikonfigurasi. Fokus pada hal-hal berikut:

     • Jumlah instans maksimum

     • Jumlah instans minimum

     • Graceful shutdown

     • Metode pemicu

     • Aturan pemicu (scale-out, scale-in)

  Catatan

  Parameter seperti metode pemilihan instans, tipe penagihan, tipe instans, dan graceful shutdown dikonfigurasi di panel properti grup node di kluster baru. Untuk detailnya, lihat Kelola grup node.

• (Opsional) Tinjau metrik beban kluster lama

  Tinjau metrik beban resource kluster untuk mengamati penggunaan resource harian di kluster lama dan menilai kebutuhan perangkat keras untuk kluster baru. Atau, lakukan migrasi lancar dengan awalnya mencocokkan spesifikasi perangkat keras kluster lama secara tepat, lalu sesuaikan konfigurasi perangkat keras kluster baru nanti berdasarkan pemanfaatan resource aktual.

  • Metode 1: Lihat pemantauan kluster

    Periksa metrik beban kluster, dengan fokus pada penggunaan YARN dan HDFS. Untuk detailnya, lihat Lihat metrik pemantauan layanan.

  • Metode 2: Lihat laporan harian EMR Doctor

    Laporan harian EMR Doctor memberikan analisis global terhadap resource komputasi, resource penjadwalan YARN, dan resource penyimpanan HDFS. Anda dapat meninjau total volume data, distribusi data panas/dingin, dan distribusi tugas komputasi. Untuk detailnya, lihat Lihat laporan harian dan analisis kluster.

    Catatan

    EMR Doctor harus diinstal pada kluster lama. Untuk detailnya, lihat Aktifkan EMR Doctor (tipe kluster Hadoop).

Tentukan rencana dan jadwal migrasi

Berdasarkan workload big data Anda saat ini dan konfigurasi setiap kluster lama, tentukan target migrasi akhir dan klarifikasi poin-poin utama berikut. Gunakan informasi ini untuk merencanakan sumber daya manusia dan jadwal secara sesuai.

• Versi produk kluster baru dan cakupan layanan. Untuk kompatibilitas layanan, lihat Versi produk dan layanan opsional.

• Opsi metadata kluster baru (DLF atau RDS yang dikelola sendiri)

• Solusi penyimpanan kluster baru (OSS-HDFS atau OSS)

Langkah 1: Bangun kluster lingkungan baru

Buat kluster baru

Untuk langkah-langkah detail dan deskripsi parameter, lihat Buat kluster. Isi parameter berdasarkan detail konfigurasi kluster yang dikumpulkan selama Lihat informasi konfigurasi instans kluster. Berikan perhatian khusus pada parameter berikut.

• Versi produk dan layanan opsional

  Berdasarkan daftar layanan yang dikumpulkan selama Lihat informasi konfigurasi instans kluster, konsultasikan informasi kompatibilitas untuk memilih cakupan dan versi layanan yang sesuai untuk kluster baru.

  • Catatan kompatibilitas komponen

    Karena evolusi layanan komunitas open-source, beberapa layanan dalam skenario DataLake menggunakan versi lebih tinggi daripada yang ada di Hadoop. Tabel berikut menunjukkan rentang kompatibilitas mundur. Gunakan versi perangkat lunak kluster lama bersama tabel ini untuk menentukan versi layanan kluster baru.

    Layanan kluster lama	Rentang kompatibilitas mundur 1	Rentang kompatibilitas mundur 2	Rentang kompatibilitas mundur 3	Rentang kompatibilitas mundur 4
    Spark	2.x	3.x	-	-
    Hive	2.x	3.x	-	-
    Tez	Fully compatible across all versions	-	-	-
    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	Fully compatible across all versions	-	-	-
    Ranger	1.x	2.x	-	-
    OpenLDAP	Fully compatible across all versions	-	-	-

    Catatan

    • Rentang kompatibilitas mundur menunjukkan bahwa dalam rentang ini, versi yang lebih tinggi kompatibel dengan versi yang lebih rendah.

    • Informasi kompatibilitas di atas hanya untuk referensi. Rujuk dokumentasi resmi komunitas open-source untuk detail otoritatif.

    • Karena perubahan aktivitas komunitas open-source dan evolusi teknologi, beberapa layanan open-source tidak lagi didukung di platform EMR baru.

      Misalnya, Hue, Zeppelin, dan Oozie. Migrasikan ke EMR Notebook atau EMR Workflow, atau deploy engine yang sesuai secara manual di kluster.

  • Pilih versi produk yang sesuai

    Penting

    Jika persyaratan versi perangkat lunak terpenuhi, pilih versi produk EMR terbaru untuk mengakses fitur yang lebih lengkap.

    Dalam skenario DataLake, Alibaba Cloud EMR menawarkan dua seri: EMR-3.x dan EMR-5.x. Setiap seri mencakup beberapa versi produk dengan layanan dan versi terintegrasi yang berbeda. Saat membangun kluster baru, pilih versi produk berdasarkan skenario aplikasi data lake Anda dan persyaratan kompatibilitas layanan target. Tabel berikut menunjukkan pemetaan antara versi platform lama dan baru.

    Versi kluster lama	Versi kluster baru yang sesuai
    EMR-3.35.0: YARN 2.8.5, HDFS 2.8.5, Hive 2.3.7, Spark 2.4.7	Seri EMR-3.x
    EMR-5.6.0: YARN 3.2.1, HDFS 3.2.1, Hive 3.1.2, Spark 3.2.1	Seri EMR-5.x

  • Catatan pemilihan HDFS & OSS-HDFS

    Pada versi EMR 5.12.1 ke atas dan 3.46.1 ke atas, Anda dapat memilih HDFS atau OSS-HDFS sebagai metode penyimpanan kluster dalam layanan opsional.

    Berdasarkan solusi penyimpanan yang ditentukan dalam Tentukan rencana dan jadwal migrasi, pilih layanan yang sesuai saat mengonfigurasi layanan opsional selama pembuatan kluster baru.

    Metode penyimpanan kluster platform baru	Pemilihan layanan
    OSS	OSS-HDFS
    OSS-HDFS	OSS-HDFS

    Catatan

    Saat Anda memilih OSS-HDFS di parameter Optional Services, konfigurasikan Root Storage Directory of Cluster dengan memilih Bucket yang telah diaktifkan OSS-HDFS sebagai path penyimpanan root kluster.

• Pilih metadata

  Platform EMR baru mendukung opsi penyimpanan metadata berikut. Pilih berdasarkan solusi penyimpanan metadata yang ditentukan dalam Tentukan rencana dan jadwal migrasi. Jika migrasi metadata diperlukan, lihat Migrasi metadata setelah membuat kluster baru.

  Metode penyimpanan metadata	Deskripsi
  Metadata DLF terpadu (direkomendasikan)	Metadata disimpan di Data Lake Formation (DLF). Jika platform lama sudah menggunakan DLF, konfigurasikan DLF data catalog yang sama. Kluster baru akan secara otomatis terhubung ke metadata yang sama setelah dibuat, sehingga tidak perlu migrasi.
  RDS yang dikelola sendiri	Gunakan instans Alibaba Cloud RDS yang dikelola sendiri sebagai database metadata. Saat memilih opsi ini, konfigurasikan parameter RDS yang ada. Untuk detailnya, lihat Konfigurasi RDS yang dikelola sendiri.
  MySQL bawaan	Metadata disimpan di database MySQL lokal pada kluster. Penting Opsi ini hanya untuk pengujian. Jangan gunakan di lingkungan produksi.

• (Opsional) Konfigurasi perangkat lunak kustom

  Jika Anda mengekspor konfigurasi layanan dari kluster lama atau berencana melakukan pra-konfigurasi selama pembuatan kluster, aktifkan konfigurasi perangkat lunak kustom dalam alur pembuatan kluster baru dan tempel konfigurasi yang telah diedit ke dalam kotak input. Untuk detailnya, lihat Konfigurasi perangkat lunak kustom.

• Konfigurasi perangkat keras

  Selama fase Lihat informasi konfigurasi instans kluster, Anda dapat memahami sepenuhnya konfigurasi perangkat keras untuk setiap node. Untuk tipe node yang berbeda—Master, Core, dan Task—pilih resource perangkat keras yang sesuai berdasarkan kebutuhan bisnis.

  • Saat membuat kluster baru, gunakan keluarga instans ECS terbaru dan tipe cloud disk terbaru untuk memanfaatkan fitur perangkat keras yang lebih baru.

  • Untuk menambahkan lebih banyak grup node dengan peran yang sama, gunakan fitur tambah grup node setelah kluster dibuat.

  • Attach public network: Aktifkan ini per grup node. Setelah diaktifkan, semua node dalam grup akan menerima alamat IP publik.

    Aktifkan koneksi jaringan publik untuk kelompok node master agar Anda dapat mengakses node master melalui jaringan publik, atau gunakan tautan akses dan fitur pemetaan port EMR.

(Opsional) Buat Gateway baru

Gateway terutama digunakan untuk mengirimkan pekerjaan ke kluster komputasi dan menyediakan isolasi. Jika Anda menggunakan kluster Gateway di platform lama, buat Gateway di platform baru sebagai berikut.

Platform baru menawarkan opsi deployment Gateway yang lebih fleksibel, memungkinkan Anda untuk menerapkan Gateway pada instans ECS yang sudah ada dengan sinkronisasi otomatis konfigurasi kluster komputasi. Untuk menyederhanakan deployment Gateway, EMR menyediakan tool bernama EMR-CLI, yang membantu Anda dengan mudah menyiapkan Gateway pada instans Alibaba Cloud ECS yang sudah ada. Untuk detailnya, lihat Gunakan EMR-CLI untuk menyesuaikan deployment Gateway.

Langkah 2: Migrasi dan validasi

Setelah membangun lingkungan kluster baru, migrasikan metadata, data, dan pekerjaan dari kluster lama.

Migrasi metadata

Baik platform EMR lama maupun baru mendukung tiga metode manajemen metadata: RDS yang dikelola sendiri, DLF, dan MySQL bawaan. Untuk platform baru, kami sangat merekomendasikan penggunaan layanan metadata DLF. Berdasarkan metode manajemen metadata yang digunakan di kluster lama dan baru, gunakan pendekatan migrasi berikut.

Migrasi data

Setelah membuat kluster baru, gunakan metode migrasi berikut berdasarkan perbedaan penyimpanan antara kluster lama dan baru untuk memastikan migrasi data yang akurat dan sukses.

Validasi kebenaran data

Setelah menyelesaikan migrasi data, validasi kebenaran data HDFS dan database/tabel Hive. Jika terdeteksi ketidakkonsistenan data, segera ambil tindakan—seperti menjalankan ulang pekerjaan yang terpengaruh atau memulihkan data yang hilang.

Pilih metode validasi berdasarkan kebutuhan spesifik Anda.

Migrasi pekerjaan

Untuk memastikan pekerjaan kluster lama berjalan dengan benar di kluster baru, terapkan strategi migrasi berikut berdasarkan sistem penjadwalan dan lingkungan Anda:

• Jika Anda menggunakan EMR legacy Data Studio, migrasikan ke EMR Workflow. Untuk detailnya, lihat Pengumuman: Migrasi dari EMR legacy Data Studio.

• Jika Anda menggunakan lingkungan pengembangan lain (misalnya, Alibaba Cloud DataWorks atau platform yang dibangun sendiri), ikuti panduan migrasi yang disediakan oleh lingkungan tersebut.

  Rujuk dengan cermat dokumentasi migrasi spesifik untuk platform Anda dan sesuaikan konfigurasi—seperti mengganti informasi kluster komputasi—untuk memastikan pekerjaan dijadwalkan dan dieksekusi dengan benar di kluster baru.

Langkah 3: Validasi dual-run paralel

Untuk meminimalkan potensi dampak pada operasi bisnis selama migrasi kluster, lakukan validasi dual-run antara kluster lama dan baru. Ini melibatkan replikasi trafik live ke kluster baru dan menjalankan pekerjaan secara simultan untuk memvalidasi secara komprehensif konsistensi data dan kebenaran bisnis.

Karena metode validasi dual-run bervariasi berdasarkan lingkungan pengembangan, karakteristik bisnis, dan kebutuhan pemrosesan data Anda, kami sangat merekomendasikan untuk merancang rencana validasi dual-run yang fleksibel yang disesuaikan dengan skenario dan kebutuhan spesifik Anda.

Langkah 4: Nonaktifkan kluster lama

Setelah berhasil memvalidasi data dan operasi bisnis, lanjutkan dengan cutover. Secara bertahap alihkan beban kerja pekerjaan dari kluster lama ke kluster baru, tingkatkan volume pemrosesan di kluster baru secara bertahap hingga semua operasi bisnis berjalan stabil di sana.

Setelah semua operasi bisnis sepenuhnya dimigrasikan dan kluster lama tidak digunakan lagi, nonaktifkan dengan aman dengan mengikuti prosedur Release cluster.