E-MapReduce：Solusi migrasi data E-MapReduce

Interkoneksi jaringan antara kluster baru dan lama

• Kluster Hadoop yang dibangun sendiri pada IDC offline

  Kluster Hadoop yang dibangun sendiri dapat dimigrasikan ke E-MapReduce melalui OSS, atau dengan menggunakan Alibaba Cloud Express Connect untuk membangun koneksi antara IDC offline Anda dan VPC tempat kluster E-MapReduce berada.

• Kluster Hadoop yang dibangun sendiri pada instance ECS

  Karena jaringan VPC terisolasi secara logis, kami menyarankan Anda menggunakan layanan E-MapReduce yang terhubung dengan VPC untuk membangun interkoneksi. Tergantung pada jenis jaringan spesifik yang terlibat dalam interkoneksi, Anda perlu melakukan tindakan berikut:

  • Interkoneksi antara jaringan klasik dan jaringan VPC

    Untuk kluster Hadoop yang dibangun pada instance ECS, Anda perlu menghubungkan jaringan klasik dan jaringan VPC menggunakan metode ClassicLink. Untuk informasi lebih lanjut, lihat Membangun Koneksi ClassicLink.

  • Interkoneksi antara jaringan VPC

    Untuk memastikan konektivitas optimal antara jaringan VPC, kami sarankan Anda membuat kluster baru di wilayah dan zona yang sama dengan kluster lama.

Migrasi data HDFS

• Sinkronisasi Data dengan DistCp

  Untuk informasi lebih lanjut, lihat Hadoop DistCp.

  Anda dapat memigrasikan data HDFS penuh dan inkremental menggunakan alat DistCp. Untuk mengurangi tekanan pada sumber daya kluster saat ini, kami sarankan Anda menjalankan perintah distcp setelah jaringan kluster baru dan lama terhubung.

  • Sinkronisasi Data Penuh

    hadoop distcp -pbugpcax -m 1000 -bandwidth 30 hdfs://oldclusterip:8020/user/hive/warehouse /user/hive/warehouse

  • Sinkronisasi Data Inkremental

    hadoop distcp -pbugpcax -m 1000 -bandwidth 30  -update -delete hdfs://oldclusterip:8020/user/hive/warehouse /user/hive/warehouse

  Deskripsi Parameter:

  • hdfs://oldclusterip:8020 menunjukkan IP namenode dari kluster lama. Jika ada beberapa namenode, masukkan namenode yang berstatus aktif.

  • Secara default, jumlah replika adalah 3. Jika Anda ingin mempertahankan jumlah replika asli, tambahkan r setelah -p, seperti -prbugpcax. Jika izin dan ACL tidak perlu disinkronkan, hapus p dan a setelah -p.

  • -m menunjukkan jumlah maps dan ukuran kluster, yang sesuai dengan volume data. Misalnya, jika sebuah kluster memiliki cpu 2000-core, Anda dapat menentukan 2000 maps.

  • -bandwidth menunjukkan nilai perkiraan kecepatan sinkronisasi dari satu map, yang diimplementasikan dengan mengontrol kecepatan salinan replika.

  • -update, memverifikasi checksum dan ukuran file dari file sumber dan target. Jika ukuran file yang dibandingkan berbeda, file sumber akan memperbarui data kluster target. Jika ada penulisan data selama sinkronisasi kluster lama dan baru, -update dapat digunakan untuk sinkronisasi data inkremental.

  • -delete, jika data di kluster lama tidak ada lagi, data di kluster baru akan dihapus.

  Catatan

  • Kecepatan keseluruhan migrasi dipengaruhi oleh bandwidth dan ukuran kluster. Semakin banyak jumlah file, semakin lama waktu yang diperlukan untuk memproses checksum. Jika Anda memiliki sejumlah besar data untuk dimigrasikan, cobalah menyinkronkan beberapa direktori untuk mengevaluasi waktu keseluruhan. Jika sinkronisasi dilakukan dalam periode waktu tertentu, Anda dapat membagi direktori menjadi beberapa direktori kecil dan menyinkronkannya satu per satu.

  • Pemberhentian layanan singkat diperlukan untuk sinkronisasi data penuh untuk mengaktifkan penulisan ganda dan penghitungan ganda, serta langsung beralih layanan ke kluster baru.

• Konfigurasi Izin HDFS

  HDFS menyediakan pengaturan izin. Sebelum memigrasikan data HDFS, Anda perlu memastikan apakah kluster lama memiliki aturan ACL dan apakah aturan tersebut akan disinkronkan, serta memeriksa apakah dfs.permissions.enabled dan dfs.namenode.acls.enabled dikonfigurasikan sama di kluster lama dan baru. Konfigurasi ini akan berlaku segera.

  Jika ada aturan ACL yang harus disinkronkan, parameter distcp harus ditambahkan ke -p untuk menyinkronkan parameter izin. Jika operasi distcp menampilkan bahwa kluster tidak mendukung ACL, ini berarti Anda belum menyetel aturan ACL untuk kluster yang sesuai. Jika kluster baru belum dikonfigurasi dengan aturan ACL, Anda dapat menambahkannya dan memulai ulang NM. Jika kluster lama tidak mendukung aturan ACL, Anda tidak perlu menyetel atau menyinkronkan aturan ACL.

Sinkronisasi metadata Hive

• Ikhtisar

  Metadata Hive umumnya disimpan di MySQL. Saat membandingkan dengan sinkronisasi data MySQL, perhatikan bahwa:

  • Lokasi harus diubah

  • Penyesuaian versi Hive diperlukan

  E-MapReduce mendukung metabase Hive, termasuk:

  • Metabase terpadu, di mana EMR mengelola RDS dan setiap pengguna memiliki skema

  • RDS yang dibangun sendiri

  • MySQL yang dibangun sendiri pada instance ECS

  Untuk memastikan data konsisten setelah migrasi antara kluster lama dan baru, kami sarankan Anda menghentikan layanan metastore selama migrasi, membuka layanan metastore di kluster lama setelah migrasi, dan kemudian mengirimkan pekerjaan di kluster baru.

• Prosedur:

  1. Hapus metabase kluster baru dan masukkan drop database xxx.

  2. Jalankan perintah mysqldump untuk mengekspor struktur tabel dan data metabase kluster lama.

  3. Ganti lokasi. Tabel dan partisi dalam metadata Hive semuanya memiliki informasi lokasi dalam prefix nameservices dfs, seperti hdfs://mycluster:8020/. Namun, prefix nameservices kluster E-MapReduce adalah emr-cluster, yang berarti Anda perlu mengganti informasi lokasi.

     Untuk mengganti informasi lokasi, ekspor data sebagai berikut.

     mysqldump --databases hivemeta --single-transaction -u root –p > hive_databases.sql

     Gunakan sed untuk mengganti hdfs://oldcluster:8020/ dengan hdfs://emr-cluster/ dan kemudian impor data ke database baru.

     mysql hivemeta -p < hive_databases.sql

  4. Di antarmuka kluster baru, hentikan layanan hivemetastore.

  5. Masuk ke metabase baru dan buat database.

  6. Di metabase baru, impor semua data yang diekspor dari metabase lama setelah bidang lokasi diganti.

  7. Saat ini, versi Hive E-MapReduce adalah versi stabil terbaru. Namun, jika versi Hive kluster yang dibangun sendiri lebih lama, data yang diimpor mungkin tidak dapat digunakan secara langsung. Untuk menyelesaikan masalah ini, Anda perlu menjalankan skrip Hive yang ditingkatkan (abaikan masalah tabel dan bidang). Untuk informasi lebih lanjut, lihat Skrip Peningkatan Hive. Sebagai contoh, untuk meningkatkan Hive 1.2 ke 2.3.0, jalankan upgrade-1.2.0-to-2.0.0.mysql.sql, upgrade-2.0.0-to-2.1.0.mysql.sql, upgrade-2.1.0-to-2.2.0.mysql.sql, dan upgrade-2.2.0-to-2.3.0.mysql.sql secara berurutan. Skrip ini terutama digunakan untuk membangun tabel, menambahkan bidang, dan mengubah konten.

  8. Pengecualian bahwa tabel dan bidang sudah ada dapat diabaikan. Setelah semua metadata direvisi, mulai ulang MetaServer, masukkan perintah hive di baris perintah, kueri database dan tabel, dan verifikasi informasi tersebut benar.

Migrasi data Flume

• Konfigurasi Penulisan Simultan Flume di Dua Kluster

  Aktifkan layanan Flume di kluster baru dan tulis data ke kluster baru sesuai dengan aturan yang identik dengan kluster lama.

• Tulis Tabel Partisi Flume

  Saat menjalankan penulisan ganda data Flume, Anda harus mengontrol waktu mulai untuk memastikan bahwa kluster baru disinkronkan ketika Flume memulai partisi waktu baru. Jika Flume menyinkronkan semua tabel setiap jam, Anda perlu mengaktifkan layanan sinkronisasi Flume sebelum sinkronisasi berikutnya. Ini memastikan bahwa data yang ditulis oleh Flume dalam jam baru diduplikasi dengan benar. Data lama yang tidak lengkap kemudian disinkronkan saat sinkronisasi data penuh dengan DistCp dilakukan. Data baru yang dihasilkan setelah waktu penulisan simultan diaktifkan tidak disinkronkan.

  Catatan

  Saat mempartisi data, JANGAN masukkan data yang baru ditulis ke direktori sinkronisasi data.

Sinkronisasi pekerjaan

Jika peningkatan versi Hadoop, Hive, Spark, dan MapReduce besar, Anda mungkin perlu membangun ulang pekerjaan Anda sesuai kebutuhan.

Verifikasi data

Data diverifikasi melalui laporan yang dihasilkan sendiri oleh pelanggan.

Migrasi kluster Presto

Jika kluster Presto digunakan untuk kueri data, file konfigurasi Hive perlu dimodifikasi. Untuk informasi lebih lanjut, lihat Dokumentasi Presto.

Lampiran

source /usr/lib/hive-current/scripts/metastore/upgrade/mysql/upgrade-1.2.0-to-2.0.0.mysql.sql
CREATE TABLE COMPACTION_QUEUE (
  CQ_ID bigint PRIMARY KEY,
  CQ_DATABASE varchar(128) NOT NULL,
  CQ_TABLE varchar(128) NOT NULL,
  CQ_PARTITION varchar(767),
  CQ_STATE char(1) NOT NULL,
  CQ_TYPE char(1) NOT NULL,
  CQ_WORKER_ID varchar(128),
  Cq_start bigint,
  CQ_RUN_AS varchar(128),
  CQ_HIGHEST_TXN_ID bigint,
  CQ_META_INFO varbinary(2048),
  CQ_HADOOP_JOB_ID varchar(32)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE TXNS (
  TXN_ID bigint PRIMARY KEY,
  TXN_STATE char(1) NOT NULL,
  TXN_STARTED bigint NOT NULL,
  TXN_LAST_HEARTBEAT bigint NOT NULL,
  TXN_USER varchar(128) NOT NULL,
  TXN_HOST varchar(128) NOT NULL,
  TXN_AGENT_INFO varchar(128),
  TXN_META_INFO varchar(128),
  TXN_HEARTBEAT_COUNT int
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE HIVE_LOCKS (
  HL_LOCK_EXT_ID bigint NOT NULL,
  HL_LOCK_INT_ID bigint NOT NULL,
  HL_TXNID bigint,
  HL_DB varchar(128) NOT NULL,
  HL_TABLE varchar(128),
  HL_PARTITION varchar(767),
  HL_LOCK_STATE char(1) not null,
  HL_LOCK_TYPE char(1) not null,
  HL_LAST_HEARTBEAT bigint NOT NULL,
  HL_ACQUIRED_AT bigint,
  HL_USER varchar(128) NOT NULL,
  HL_HOST varchar(128) NOT NULL,
  HL_HEARTBEAT_COUNT int,
  HL_AGENT_INFO varchar(128),
  HL_BLOCKEDBY_EXT_ID bigint,
  HL_BLOCKEDBY_INT_ID bigint,
  PRIMARY KEY(HL_LOCK_EXT_ID, HL_LOCK_INT_ID),
  KEY HIVE_LOCK_TXNID_INDEX (HL_TXNID)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE INDEX HL_TXNID_IDX ON HIVE_LOCKS (HL_TXNID);
source /usr/lib/hive-current/scripts/metastore/upgrade/mysql/upgrade-1.2.0-to-2.0.0.mysql.sql
source /usr/lib/hive-current/scripts/metastore/upgrade/mysql/upgrade-2.0.0-to-2.1.0.mysql.sql

CREATE TABLE TXN_COMPONENTS (
  TC_TXNID bigint,
  TC_DATABASE varchar(128) NOT NULL,
  TC_TABLE varchar(128),
  TC_PARTITION varchar(767),
  FOREIGN KEY (TC_TXNID) REFERENCES TXNS (TXN_ID)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
source /usr/lib/hive-current/scripts/metastore/upgrade/mysql/upgrade-2.0.0-to-2.1.0.mysql.sql
source /usr/lib/hive-current/scripts/metastore/upgrade/mysql/upgrade-2.1.0-to-2.2.0.mysql.sql
CREATE TABLE IF NOT EXISTS `NOTIFICATION_LOG`
(
    `NL_ID` BIGINT(20) NOT NULL,
    `EVENT_ID` BIGINT(20) NOT NULL,
    `EVENT_TIME` INT(11) NOT NULL,
    `EVENT_TYPE` varchar(32) NOT NULL,
    `DB_NAME` varchar(128),
    `TBL_NAME` varchar(128),
    `MESSAGE` mediumtext,
    PRIMARY KEY (`NL_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE IF NOT EXISTS `PARTITION_EVENTS` (
  `PART_NAME_ID` bigint(20) NOT NULL,
  `DB_NAME` varchar(128) CHARACTER SET latin1 COLLATE latin1_bin DEFAULT NULL,
  `EVENT_TIME` bigint(20) NOT NULL,
  `EVENT_TYPE` int(11) NOT NULL,
  `PARTITION_NAME` varchar(767) CHARACTER SET latin1 COLLATE latin1_bin DEFAULT NULL,
  `TBL_NAME` varchar(128) CHARACTER SET latin1 COLLATE latin1_bin DEFAULT NULL,
  PRIMARY KEY (`PART_NAME_ID`),
  KEY `PARTITIONEVENTINDEX` (`PARTITION_NAME`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE COMPLETED_TXN_COMPONENTS (
  CTC_TXNID bigint NOT NULL,
  CTC_DATABASE varchar(128) NOT NULL,
  CTC_TABLE varchar(128),
  CTC_PARTITION varchar(767)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
 source /usr/lib/hive-current/scripts/metastore/upgrade/mysql/upgrade-2.1.0-to-2.2.0.mysql.sql
 source /usr/lib/hive-current/scripts/metastore/upgrade/mysql/upgrade-2.2.0-to-2.3.0.mysql.sql
  CREATE TABLE NEXT_TXN_ID (
  NTXN_NEXT bigint NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
INSERT INTO NEXT_TXN_ID VALUES(1);
CREATE TABLE NEXT_LOCK_ID (
  NL_NEXT bigint NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
INSERT INTO NEXT_LOCK_ID VALUES(1);