Topik ini menjelaskan cara memigrasikan data secara efisien dari kluster Hadoop ke kluster DataLake. Kluster Hadoop dibuat di konsol E-MapReduce (EMR) lama dan disebut sebagai kluster lama. Kluster DataLake dibuat di konsol EMR baru dan disebut sebagai kluster baru. Faktor-faktor berikut dari kluster lama harus dipertimbangkan untuk migrasi: versi, jenis penyimpanan metadata, dan metode penyimpanan. Kebijakan dan langkah-langkah migrasi bervariasi berdasarkan faktor-faktor tersebut.
Informasi latar belakang
Konsol EMR baru adalah platform big data open source cloud-native generasi berikutnya yang dirilis oleh EMR. Platform ini menyediakan pengguna dengan alat pengembangan baru, bentuk sumber daya baru, dan skenario analisis baru, yang membantu meningkatkan pengalaman pengguna. Untuk informasi lebih lanjut tentang fitur yang disediakan oleh konsol EMR baru, lihat Pengumuman Konsol EMR Baru.
EMR on ECS adalah salah satu bentuk sumber daya utama EMR dan menyediakan fitur yang ditingkatkan di konsol EMR baru. Konsol EMR baru menyediakan jenis kluster berikut: DataLake, Dataflow, pemrosesan analitik online (OLAP), dan kustom. Dibandingkan dengan jenis kluster yang disediakan oleh konsol EMR lama, seperti Hadoop dan Data Science, jenis kluster yang disediakan oleh konsol EMR baru membantu meningkatkan efisiensi manajemen kluster dan kinerja mesin secara signifikan. Kluster DataLake adalah versi yang ditingkatkan dari kluster Hadoop. Anda dapat memperoleh manfaat dari beberapa fitur kluster DataLake. Untuk informasi lebih lanjut, lihat Kluster DataLake.
Persiapan
Urutkan arsitektur keseluruhan kluster lama
Urutkan arsitektur bisnis big data saat ini, identifikasi skenario penggunaan kluster lama, dan catat item-item berikut:
Layanan dan Versi Layanan: Catat layanan yang berjalan di kluster lama dan versi layanannya. Ini membantu mengevaluasi kompatibilitas peningkatan dan persyaratan pembaruan fitur.
Jenis Penyimpanan Metadata: Konfirmasikan jenis penyimpanan metadata yang digunakan di kluster lama, dan rencanakan kebijakan koneksi dan migrasi untuk sistem manajemen metadata di arsitektur baru. Jenis penyimpanan metadata yang digunakan di kluster lama bisa berupa Data Lake Formation (DLF) atau ApsaraDB RDS yang dikelola sendiri.
Arsitektur Penyimpanan Data: Analisis arsitektur penyimpanan data kluster lama untuk memberikan dasar bagi desain jalur migrasi data selanjutnya. Arsitektur penyimpanan data bisa berupa Hadoop Distributed File System (HDFS) lokal, Object Storage Service (OSS), atau JindoFS dalam mode blok.
Arsitektur Otentikasi Pengguna: Periksa apakah menggunakan layanan seperti OpenLDAP, Ranger, dan Kerberos yang diterapkan di kluster lama. Ini membantu memastikan bahwa arsitektur baru dapat mewarisi mekanisme keamanan yang ada setelah migrasi.
Sistem Penjadwalan: Konfirmasikan sistem pengembangan dan penjadwalan yang digunakan untuk mempertahankan konsistensi penjadwalan dan migrasi tugas yang lancar.
Jika Anda ingin meng-upgrade beberapa kluster lama, kami sarankan untuk memigrasikan data kluster lama satu per satu untuk memastikan kontinuitas dan stabilitas bisnis. Kemudian, tentukan urutan migrasi dan buat rencana migrasi yang layak berdasarkan kebutuhan dan prioritas bisnis aktual untuk memastikan migrasi data yang lancar dari setiap kluster lama ke kluster baru.
Urutkan informasi rinci tentang kluster lama
Lihat konfigurasi instance
Saat membuat kluster di konsol EMR baru, informasi dasar tentang instance kluster lama dapat diterapkan ke kluster baru. Untuk informasi lebih lanjut, lihat Buat Kluster di Konsol EMR Baru. Anda perlu melihat dan mengurutkan konfigurasi perangkat lunak dan keras kluster lama. Konfigurasi lainnya dapat langsung diterapkan ke kluster baru.
Lihat konfigurasi kluster dan grup node pada tab Basic Information dan Nodes kluster lama Anda di halaman EMR on ECS dan catat informasi yang dijelaskan dalam tabel berikut.
Tipe konfigurasi
Item konfigurasi
Isi untuk diurutkan
Konfigurasi perangkat lunak
Versi kluster
Versi layanan
Komponen yang sebenarnya digunakan
Jenis penyimpanan metadata Hive
Layanan yang digunakan di kluster lama dan versinya.
Konfigurasi perangkat keras
Zona tempat kluster berada
Spesifikasi dan metode penagihan setiap grup node
Zona tempat kluster lama berada dan konfigurasi perangkat keras setiap grup node di kluster lama, seperti vCPU, memori, disk sistem, dan disk data.
(Opsional) Ekspor konfigurasi layanan
Dalam operasi & pemeliharaan harian kluster, pengguna sering menyesuaikan konfigurasi default layanan atau menambahkan konfigurasi kustom tambahan berdasarkan kebutuhan bisnis mereka. Untuk memigrasikan informasi konfigurasi secara efisien antara kluster yang berbeda, Anda dapat memanfaatkan sepenuhnya fitur ekspor konfigurasi EMR untuk mengekspor semua konfigurasi kluster lama sekaligus, dan kemudian mengimpor konfigurasi sekaligus selama inisialisasi kluster baru. Ini memungkinkan Anda memigrasikan konfigurasi layanan dengan cepat dan mudah. Sebagai alternatif, Anda dapat secara manual memodifikasi dan menyesuaikan konfigurasi layanan satu per satu di halaman manajemen layanan setelah kluster baru dimulai.
Ekspor konfigurasi layanan.
Referensi Ekspor dan Impor Konfigurasi Layanan untuk mengekspor file konfigurasi layanan dengan beberapa klik.
CatatanSelect Configuration Files: Disarankan untuk memilih hanya file konfigurasi yang telah diedit. Anda dapat memilih beberapa file konfigurasi sekaligus.
Export Mode: Parameter ini tidak dapat diatur ke Export Only Custom or Modified Configurations untuk kluster Hadoop.
Export Format: Pilih JSON. Dengan cara ini, konfigurasi layanan dapat diimpor ke kluster baru dengan mudah.
Tabel berikut menjelaskan parameter dalam file konfigurasi yang diekspor.
Parameter
Deskripsi
NamaAplikasi
Nama layanan.
NamaFileKonfigurasi
Nama file konfigurasi.
ConfigItemKey
Nama item konfigurasi.
ConfigItemValue
Nilai item konfigurasi.
Modifikasi file konfigurasi.
Periksa dengan cermat informasi konfigurasi yang diekspor dari kluster lama, filter dan simpan item konfigurasi yang diperlukan untuk lingkungan baru, dan kemudian hapus konfigurasi yang tidak diperlukan.
Saat menyesuaikan pengaturan parameter untuk sumber daya terkait YARN, Anda harus mempertimbangkan spesifikasi sumber daya perangkat keras aktual kluster baru untuk memastikan bahwa pengaturan item konfigurasi yang ingin Anda impor ke kluster baru masuk akal.
Jika Anda telah mengonfigurasi pengaturan terkait JindoFS, seperti penyedia kredensial, kami sarankan Anda menyesuaikan pengaturan berdasarkan konfigurasi OSS- atau OSS-HDFS-terkait. Untuk informasi lebih lanjut, lihat Konfigurasikan Penyedia Kredensial untuk OSS atau OSS-HDFS.
Gunakan konfigurasi layanan dalam file konfigurasi sebagai konfigurasi preset untuk kluster baru. Untuk informasi lebih lanjut, lihat "(Opsional) Konfigurasi Perangkat Lunak Kustom" dalam topik ini.
(Opsional) Urutkan tindakan bootstrap
Anda dapat memeriksa apakah skrip tindakan bootstrap dikonfigurasikan untuk kluster lama dalam fase melihat konfigurasi instance. Jika skrip tindakan bootstrap dikonfigurasikan, Anda harus mengevaluasi fungsionalitas setiap skrip tindakan bootstrap untuk menentukan apakah akan menggunakannya di kluster baru.
Untuk skrip tindakan bootstrap yang ingin Anda gunakan di kluster baru, lakukan operasi berikut untuk menyesuaikan skrip agar memastikan bahwa skrip dapat berjalan dengan benar di kluster baru.
Ubah informasi yang relevan dengan versi komponen open source dalam skrip tindakan bootstrap. Informasi tersebut mencakup nama paket JAR dan jalurnya. Untuk informasi tentang jalur file di konsol EMR lama dan baru, lihat Jalur File yang Sering Digunakan.
Jika objek perlu diunduh dari Object Storage Service (OSS) selama eksekusi skrip, Anda mungkin perlu memodifikasi perintah OSS yang sesuai. Untuk informasi lebih lanjut, lihat Gunakan Tindakan Bootstrap untuk Menjalankan Skrip.
Setelah skrip dimodifikasi, unggah skrip ke OSS. Saat membuat kluster baru, masukkan jalur OSS yang dimodifikasi dari skrip tindakan bootstrap.
PentingSebelum menerapkan skrip tindakan bootstrap ke kluster produksi, pastikan bahwa skrip telah lulus verifikasi di lingkungan pengujian.
(Opsional) Urutkan aturan penskalaan otomatis
Jika aturan penskalaan otomatis dikonfigurasikan untuk kluster lama, lihat aturan penskalaan otomatis yang dikonfigurasikan dan fokus pada informasi seperti jumlah maksimum instance, jumlah minimum instance, shutdown lembut, mode pemicu, dan aturan pemicu. Setelah membuat kluster baru, konfigurasikan ulang aturan penskalaan otomatis. Untuk informasi lebih lanjut, lihat Konfigurasikan Aturan Penskalaan Otomatis Kustom. Untuk melihat aturan penskalaan otomatis yang dikonfigurasikan untuk kluster lama, lakukan langkah-langkah berikut:
Pergi ke tab Penskalaan Otomatis.
Masuk ke Konsol EMR. Di panel navigasi kiri, klik EMR on ECS.
Temukan kluster yang diinginkan dan klik nama kluster di kolom ID/Nama Kluster.
Di halaman yang muncul, klik tab Auto Scaling.
Lihat aturan penskalaan otomatis.
Di tab Auto Scaling, temukan grup penskalaan otomatis yang diinginkan dan klik Configure Rule di kolom Tindakan. Fokus pada parameter berikut dalam panel Konfigurasikan Penskalaan Otomatis:
Jumlah Maksimum Instance
Jumlah Minimum Instance
Shutdown Lembut
Mode Pemicu
Aturan Pemicu (Perluasan dan Penyusutan)
CatatanAnda dapat mengonfigurasi parameter, seperti Mode Pemilihan Tipe Instance, Metode Penagihan, Tipe Instance, dan Shutdown Lembut, di panel Konfigurasikan Penskalaan Otomatis untuk kluster baru. Untuk informasi lebih lanjut, lihat Kelola Grup Node.
(Opsional) Lihat beban kluster
Anda dapat melihat beban kluster untuk mengamati penggunaan sumber daya harian kluster lama. Ini membantu Anda mengevaluasi konfigurasi perangkat keras yang diperlukan untuk kluster baru. Sebagai alternatif, Anda dapat memigrasikan konfigurasi kluster dengan lancar untuk memastikan bahwa kluster lama dan baru menggunakan konfigurasi perangkat keras yang sama. Kemudian, Anda dapat memodifikasi konfigurasi perangkat keras kluster baru berdasarkan pemanfaatan sumber daya selama kluster berjalan.
Metode 1: Lihat Metrik
Lihat metrik beban kluster dan fokus pada penggunaan sumber daya layanan YARN dan HDFS. Untuk informasi lebih lanjut, lihat Lihat Metrik Layanan.
Metode 2: Lihat Laporan Kluster Harian di EMR Doctor
EMR Doctor menyediakan laporan kluster harian yang berisi hasil analisis global sumber daya komputasi, sumber daya penjadwalan YARN, dan sumber daya penyimpanan HDFS di kluster. Anda dapat melihat jumlah total data yang ada di kluster, distribusi data panas dan dingin, serta distribusi tugas komputasi di kluster. Untuk informasi lebih lanjut, lihat Lihat Laporan Kluster Harian dan Hasil Analisis dalam Laporan.
CatatanAnda harus mengaktifkan EMR Doctor jika ingin menggunakan EMR Doctor di konsol EMR lama. Untuk informasi lebih lanjut tentang cara mengaktifkan EMR Doctor, lihat Aktifkan EMR Doctor (Kluster Hadoop).
Formulasikan rencana migrasi dan tentukan waktu migrasi
Tentukan objek migrasi akhir berdasarkan situasi bisnis big data Anda dan konfigurasi aktual kluster lama, klarifikasi informasi kunci berikut, dan kemudian referensi operasi migrasi selanjutnya untuk perencanaan yang masuk akal dari sumber daya manusia dan siklus migrasi.
Versi produk dan layanan kluster baru. Untuk informasi tentang kompatibilitas layanan dan komponen, lihat Versi Produk dan Layanan Opsional (Pilih Setidaknya Satu) dalam topik ini.
Metode penyimpanan dan manajemen metadata kluster baru. Pilih Metadata Terpadu DLF atau RDS Mandiri.
Solusi penyimpanan kluster baru. Pilih OSS-HDFS atau OSS.
Langkah 1: Buat kluster di konsol EMR baru
Buat kluster baru
Untuk informasi tentang cara membuat kluster baru, lihat Buat Kluster. Anda dapat mengonfigurasi parameter berdasarkan pengaturan yang Anda urutkan dalam fase melihat konfigurasi instance. Catat konfigurasi berikut:
Versi Produk dan Layanan Opsional (Pilih Setidaknya Satu)
Anda dapat memilih layanan versi tertentu yang ingin Anda deploy di kluster baru berdasarkan kompatibilitas layanan dan daftar layanan yang diurutkan dalam fase melihat konfigurasi instance.
Kompatibilitas Layanan
Dengan pembaruan versi layanan di komunitas open source, versi layanan tertentu di kluster DataLake lebih baru daripada yang di kluster Hadoop. Tabel berikut menjelaskan kompatibilitas mundur versi layanan yang lebih baru. Anda dapat menentukan versi layanan di kluster baru berdasarkan informasi versi perangkat lunak kluster lama dan informasi yang dijelaskan dalam tabel berikut.
Layanan kluster di konsol EMR 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
Semua versi kompatibel
-
-
-
Delta Lake
0.6.X
0.8.0 hingga 1.1.0
-
-
Iceberg
0.12.X
0.13.X
-
-
Hudi
0.6.X
0.8.X
0.9.X
0.10.X
Sqoop
Semua versi kompatibel
-
-
-
Ranger
1.X
2.X
-
-
OpenLDAP
Semua versi kompatibel
-
-
-
CatatanDalam rentang kompatibilitas mundur, versi layanan yang lebih baru dapat kompatibel dengan versi layanan yang lebih lama.
Informasi kompatibilitas layanan di atas hanya untuk referensi. Untuk informasi lebih lanjut, lihat deskripsi resmi setiap layanan di komunitas open source.
Karena perubahan popularitas layanan di komunitas open source dan pembaruan serta iterasi teknologi baru yang terus berlanjut, beberapa layanan open source tidak lagi didukung di konsol EMR baru.
Sebagai contoh, Hue, Zeppelin, dan Oozie tidak didukung di konsol EMR baru. Kami sarankan Anda memigrasikan konfigurasi layanan ini ke EMR Notebook atau EMR Workflow, atau membangun mesin yang sesuai di kluster baru.
Versi Produk
PentingJika versi perangkat lunak memenuhi persyaratan, disarankan untuk memilih versi EMR terbaru guna memanfaatkan lebih banyak fitur.
Dalam skenario data lake, Alibaba Cloud EMR menyediakan seri versi produk berikut: EMR V3.X dan EMR V5.X. Setiap seri mencakup beberapa versi produk dengan layanan dan versi layanan yang bervariasi tergantung pada versi produk. Saat membuat kluster baru, pilih versi produk yang sesuai berdasarkan skenario data lake dan persyaratan kompatibilitas layanan. Tabel berikut menjelaskan pemetaan versi produk antara kluster lama dan baru.
Versi produk kluster lama
Versi produk kluster baru
EMR V3.35.0: YARN 2.8.5, HDFS 2.8.5, Hive 2.3.7, dan Spark 2.4.7
Seri EMR V3.X
EMR V5.6.0: YARN 3.2.1, HDFS 3.2.1, Hive 3.1.2, dan Spark 3.2.1
Seri EMR V5.X
Pilihan HDFS dan OSS-HDFS
Di EMR V5.12.1, EMR V3.46.1, atau versi minor yang lebih baru dari EMR V5.12.1 atau EMR V3.46.1, Anda dapat memilih HDFS atau OSS-HDFS dari layanan opsional sebagai penyimpanan dasar.

Saat membuat kluster baru, pilih layanan opsional berdasarkan solusi penyimpanan kluster di Formulasikan Rencana Migrasi dan Tentukan Waktu Migrasi dalam topik ini.
Penyimpanan di konsol EMR baru
Layanan untuk dipilih
OSS
OSS-HDFS
OSS-HDFS
OSS-HDFS
CatatanJika Anda memilih OSS-HDFS dari layanan opsional, Anda juga harus mengonfigurasi parameter Root Storage Directory of Cluster untuk menentukan bucket tempat OSS-HDFS diaktifkan sebagai jalur penyimpanan root kluster baru.
Metadata
Jenis penyimpanan metadata berikut didukung di konsol EMR baru. Pilih jenis berdasarkan solusi penyimpanan metadata yang ditentukan di Formulasikan Rencana Migrasi dan Tentukan Waktu Migrasi dalam topik ini. Jika migrasi metadata diperlukan, referensi Migrasi Metadata dalam topik ini untuk memigrasikan metadata setelah kluster baru dibuat.
Tipe penyimpanan metadata
Deskripsi
DLF Unified Metadata (direkomendasikan)
Metadata disimpan di DLF. Jika DLF sudah digunakan di konsol EMR lama, Anda dapat mengatur parameter DLF Catalog ke nilai yang ditentukan di konsol EMR lama. Setelah kluster baru dibuat, metadata yang sama akan disinkronkan secara otomatis, dan Anda tidak perlu memigrasikan metadata.
Self-managed RDS
Metadata disimpan di database ApsaraDB RDS mandiri milik Alibaba Cloud. Jika Anda memilih Self-managed RDS, Anda harus mengonfigurasi parameter database ApsaraDB RDS yang ada. Untuk informasi lebih lanjut, lihat Konfigurasikan database ApsaraDB RDS for MySQL mandiri.
Built-in MySQL
Metadata disimpan di database MySQL lokal kluster Anda.
PentingJenis ini hanya digunakan di lingkungan pengujian.
(Opsional) Konfigurasi Perangkat Lunak Kustom
Jika Anda telah mengekspor konfigurasi layanan kluster lama atau berencana menggunakan konfigurasi layanan sebagai konfigurasi preset untuk kluster baru, Anda dapat mengaktifkan Konfigurasi Perangkat Lunak Kustom saat membuat kluster baru dan menyalin konfigurasi layanan ke bidang yang muncul setelah Anda mengaktifkan Konfigurasi Perangkat Lunak Kustom. Untuk informasi lebih lanjut, lihat Kustomisasi Konfigurasi Perangkat Lunak.
Konfigurasi perangkat keras
Dalam fase melihat konfigurasi instance, Anda dapat memiliki pemahaman menyeluruh tentang konfigurasi perangkat keras setiap node di kluster lama. Anda harus memilih konfigurasi sumber daya perangkat keras yang tepat untuk tipe node yang berbeda berdasarkan kebutuhan bisnis Anda. Tipe node termasuk master, core, dan task.
Kami sarankan Anda memilih keluarga instance Elastic Compute Service (ECS) terbaru dan jenis disk cloud saat membuat kluster baru untuk menggunakan fitur perangkat keras yang diperbarui.
Anda dapat membuat grup node yang ditugaskan peran yang sama setelah membuat kluster baru.
Tetapkan IP Jaringan Publik: Anda dapat menentukan apakah akan mengaktifkan akses Internet untuk grup node. Setelah Anda menghidupkan sakelar, semua node dalam grup node terhubung ke Internet.
Jika Anda ingin masuk ke node master kluster Anda melalui Internet, atau Anda ingin menggunakan fitur mengakses UI web komponen open source, Anda harus menghidupkan sakelar untuk grup node master.
(Opsional) Buat gateway di konsol EMR baru
Gateway digunakan untuk mengirimkan pekerjaan ke kluster EMR dan mengisolasi kluster dengan cara yang aman. Jika Anda sudah menggunakan kluster gateway di konsol EMR lama, Anda dapat membuat gateway di konsol EMR baru.
EMR menyediakan rencana penyebaran gateway yang lebih fleksibel di konsol EMR baru, yang memungkinkan Anda untuk menerapkan gateway pada instance ECS yang ada dan menerapkan sinkronisasi otomatis konfigurasi kluster Anda. Untuk menyederhanakan penyebaran gateway, EMR menyediakan alat EMR-CLI yang dapat Anda gunakan untuk menerapkan gateway pada instance ECS Alibaba Cloud dengan mudah. Untuk informasi lebih lanjut, lihat Gunakan EMR-CLI untuk Menerapkan Gateway.
Langkah 2: Migrasikan dan verifikasi data
Setelah Anda membangun lingkungan kluster baru, Anda harus memigrasikan metadata, data, dan pekerjaan dari kluster lama ke kluster baru.
Migrasikan metadata
Konsol EMR lama dan baru mendukung mode manajemen metadata berikut: DLF Unified Metadata, Self-managed RDS, dan Built-in MySQL. Kami sangat menyarankan Anda memilih DLF Unified Metadata saat membuat kluster baru. Tabel berikut menjelaskan rencana migrasi metadata untuk mode manajemen metadata yang berbeda di konsol EMR lama dan baru.
Mode manajemen metadata di konsol EMR lama | Mode manajemen metadata di konsol EMR baru | Metode migrasi |
DLF | DLF | Anda tidak perlu memigrasikan metadata. Anda hanya perlu memastikan bahwa katalog DLF yang ditentukan untuk kluster baru sama dengan yang untuk kluster lama. |
Unified metabase | DLF | Untuk informasi lebih lanjut, lihat Migrasi metadata EMR. |
Local MySQL | DLF | Untuk informasi lebih lanjut, lihat Migrasi metadata. |
Self-managed ApsaraDB RDS | DLF | Untuk informasi lebih lanjut, lihat Migrasi metadata. |
Migrasikan data
Tabel berikut menjelaskan metode migrasi data untuk mode penyimpanan yang berbeda di konsol EMR lama dan baru. Anda dapat memilih metode berdasarkan kebutuhan bisnis Anda untuk memastikan bahwa data dari kluster lama dapat dimigrasikan dengan lancar dan akurat ke kluster baru.
Mode penyimpanan di konsol EMR lama | Mode penyimpanan di konsol EMR baru | Metode migrasi |
OSS | OSS | Anda tidak perlu memigrasikan data. |
OSS | OSS-HDFS | Gunakan Jindo DistCp untuk memigrasikan data. |
JindoFS dalam mode blok | OSS-HDFS | |
HDFS | OSS-HDFS |
Verifikasi data
Jika Anda tidak perlu memigrasikan data ke kluster baru, Anda dapat melewati langkah ini.
Setelah data dimigrasikan ke kluster baru, Anda harus memverifikasi kebenaran data seperti data HDFS dan data dalam database dan tabel Hive. Jika ketidaksesuaian data ditemukan, Anda harus segera menyelesaikan masalah tersebut. Sebagai contoh, Anda dapat menjalankan ulang tugas yang terpengaruh atau melengkapi data yang hilang.
Anda dapat memilih metode berdasarkan kebutuhan verifikasi data Anda.
Permintaan | Metode verifikasi |
Verifikasi file | Hitung nilai checkSum file dan bandingkan hasil perhitungan untuk memastikan tidak ada perubahan yang dilakukan pada file atau file tidak rusak selama proses migrasi. |
Verifikasi data kasar | Periksa statistik pada tingkat tabel untuk mengevaluasi konsistensi data keseluruhan dengan cepat. Statistik tersebut mencakup jumlah total baris dalam tabel, jumlah dan rata-rata nilai dalam kolom numerik, serta nilai minimum dan maksimum dalam kolom numerik. |
Verifikasi data detail | Periksa setiap baris data secara detail untuk memastikan semua item data tetap tidak berubah setelah migrasi. Metode verifikasi ini membantu Anda memeriksa integritas dan akurasi data secara mendalam. |
Migrasikan pekerjaan
Untuk memastikan bahwa pekerjaan kluster lama dapat dijadwalkan dan dieksekusi sesuai harapan di kluster baru, kebijakan migrasi berikut disediakan dalam sistem penjadwalan dan lingkungan yang berbeda:
Jika Anda menggunakan fitur pengembangan data di Data Platform di konsol EMR lama, Anda harus memigrasikan pekerjaan dari EMR Data Platform di konsol EMR lama ke EMR Workflow. Untuk informasi lebih lanjut, lihat Pengumuman tentang Migrasi Data dari EMR Data Platform di Konsol EMR Lama.
Jika Anda menggunakan lingkungan pengembangan lainnya, seperti Alibaba Cloud DataWorks atau platform pengembangan mandiri, ikuti instruksi yang dijelaskan dalam rencana migrasi yang disediakan oleh lingkungan pengembangan terkait.
Referensi dokumentasi migrasi spesifik dari platform yang sesuai dan sesuaikan konfigurasi terkait berdasarkan situasi penyebaran aktual dan kebutuhan bisnis Anda. Sebagai contoh, Anda dapat mengubah pengaturan utama seperti informasi kluster komputasi untuk memastikan bahwa pekerjaan dapat dijadwalkan sesuai harapan di kluster baru.
Langkah 3: Lakukan verifikasi double-run pada kluster lama dan baru
Saat memigrasikan data antar kluster, verifikasi double-run diperlukan untuk meminimalkan dampak potensial pada bisnis online. Replikasi lalu lintas online ke kluster baru dan eksekusi pekerjaan di kluster baru terlibat dalam proses ini. Ini membantu memastikan konsistensi data dan akurasi bisnis.
Metode spesifik verifikasi double-run bervariasi berdasarkan lingkungan pengembangan aktual Anda, karakteristik bisnis, dan persyaratan pemrosesan data. Oleh karena itu, kami sangat menyarankan Anda merumuskan rencana verifikasi double-run yang sesuai berdasarkan skenario dan kebutuhan bisnis Anda.
Langkah 4: Lepaskan kluster lama
Setelah verifikasi bisnis data selesai, Anda dapat mengirimkan data. Anda dapat secara bertahap memigrasikan pekerjaan dari kluster lama ke kluster baru dan secara bertahap meningkatkan volume pemrosesan pekerjaan di kluster baru untuk memastikan bahwa semua pekerjaan dapat berjalan stabil di kluster baru.
Setelah data bisnis kluster lama sepenuhnya dimigrasikan ke kluster baru, dan tidak ada data bisnis yang dijalankan di kluster lama, Anda dapat mengikuti instruksi yang dijelaskan di Lepaskan Kluster untuk melepaskan kluster lama dengan cara yang aman dan teratur.