Perencanaan migrasi: Teradata ke Fabric Data Warehouse

Diterapkan pada:✅ Gudang di Microsoft Fabric

Memindahkan estate Teradata perusahaan ke Fabric Data Warehouse melibatkan lebih dari sekadar skema dan transfer data. Rencanakan kode SQL dan BTEQ, proses pemuatan, keamanan, pelaporan, operasi, dan kinerja.

Artikel ini mengatur pekerjaan ke dalam lima tahap. Gunakan tahap-tahapan tersebut sebagai runbook yang dapat diulang untuk setiap gelombang migrasi. Untuk implementasi yang direkomendasikan, lihat Metode Migrasi untuk Teradata. Untuk remediasi kode, lihat Terjemahkan SQL Teradata untuk Fabric Data Warehouse.

Important

Konfirmasi keterbatasan Fabric Data Warehouse saat ini dan luas permukaan T-SQL sebelum setiap gelombang migrasi. Tetapkan penanggung jawab dan rencana perbaikan untuk setiap perbedaan yang menghambat.

Gunakan modernisasi selektif untuk sebagian besar beban kerja:

  • Menjaga model bisnis dan logika yang telah tervalidasi.
  • Gunakan Migration Assistant untuk menerjemahkan dan mendistribusikan metadata yang didukung.
  • Ganti SQL, utilitas, dan operasi khusus Teradata dengan pola native Fabric.
  • Desain ulang hanya beban kerja yang terblokir oleh ketergantungan yang tidak didukung atau masalah arsitektur yang sudah ada.

Migrasi secara bergelombang berdasarkan domain bisnis, data mart, atau klaster beban kerja. Hindari migrasi besar yang dilakukan sekaligus.

Menilai dan mengevaluasi

Nilai alur kerja ini bersama-sama agar Anda tidak melewatkan ketergantungan apa pun:

Alur Kerja Assess
Desain dan performa model data, volume, pertumbuhan, kemencengan, lebar tabel, konkurensi, waktu proses, dan tujuan layanan
ETL dan pemuatan FastLoad, MultiLoad, Teradata Parallel Transporter, BTEQ impor/ekspor, jadwal, perilaku restart, dan beban bertahap
Keamanan dan operasi Pengguna, peran, izin, akun layanan, audit, pemulihan, pemantauan, dan kepemilikan dukungan
Visualisasi dan pelaporan Laporan, model semantik, aplikasi, ekspor, jadwal penyegaran, dan ketergantungan koneksi
Kompatibilitas SQL Tabel, tampilan, makro, prosedur, fungsi, tipe data, QUALIFY, tabel volatile, PERIOD, dan alur kontrol BTEQ
Alat migrasi Ekstraksi metadata, kesiapan Migration Assistant, pemindahan data, kontrol sumber, dan otomatisasi penyebaran
Melampaui migrasi Praktik cutover, rollback, optimasi, pelatihan, dekomisioning, dan penggunaan ulang untuk gelombang berikutnya

Tentukan hasil bisnis, cakupan, penanggung jawab, metrik keberhasilan, dan ekspektasi terkait rollback. Buat inventaris objek, peta ketergantungan, baseline beban kerja, register kompatibilitas, dan rencana gelombang.

Merencanakan dan mendesain

Ubah penilaian menjadi desain yang dapat dieksekusi:

  1. Konfirmasikan Warehouse sebagai target untuk analitik relasional yang berpusat pada SQL.
  2. Definisikan ruang kerja pengembangan, pengujian, dan produksi, kapasitas, penamaan, dan kepemilikan.
  3. Petakan objek dan tipe data Teradata ke target Fabric. Catat item yang tidak didukung dan alternatif yang disetujui. Gunakan Migration Assistant untuk terjemahan metadata.
  4. Rancang pergerakan data historis dan inkremental secara terpisah.
  5. Rancang ulang akses berdasarkan Microsoft Entra ID, peran workspace, izin item, dan izin SQL Warehouse.
  6. Tentukan kriteria penerapan, validasi, peralihan, dan pemulihan.

Utamakan model dimensional, pemuatan berorientasi batch, ELT modular, dan penggunaan ulang yang tertata kelola melalui OneLake dalam desain target.

Migrate

Jalankan setiap gelombang dengan urutan berikut:

  1. Sediakan ruang kerja target, identitas, koneksi, dan jalur deployment.
  2. Unggah file SQL Teradata yang telah diekstrak ke Migration Assistant, terjemahkan metadata, dan perbaiki objek yang memerlukan perhatian.
  3. Salin himpunan data representatif dan validasi throughput, pemetaan, kesalahan, serta perilaku restart.
  4. Selesaikan beban historis dan tetapkan sinkronisasi bertahap saat diperlukan.
  5. Ciptakan ulang proses keamanan dan operasional.
  6. Validasi data, perilaku SQL, laporan, aplikasi, dan kinerja representatif.
  7. Lakukan pengalihan koneksi dan beralih setelah kriteria penerimaan terpenuhi.

Jangan gunakan keberhasilan pembuatan objek sebagai satu-satunya sinyal penyelesaian. Gelombang hanya selesai ketika data, perilaku, keamanan, operasi, dan konsumsi hilir memenuhi kriteria penerimaan mereka.

Pantau dan kelola

Mengoperasikan sumber dan target secara paralel selama periode yang dibutuhkan oleh profil risiko beban kerja.

  • Bandingkan kesegaran data, jumlah baris, agregat bisnis, dan laporkan hasil antar lingkungan.
  • Pantau durasi beban, durasi kueri, kegagalan, pengulangan, konsumsi kapasitas, sesi aktif, dan masalah yang dilaporkan pengguna.
  • Tinjau penugasan akses, identitas istimewa, izin Warehouse, dan hasil tes keamanan.
  • Simpan kode terjemahan, aset penerapan, keputusan pemetaan, bukti pengujian, dan pengecualian dalam kontrol sumber.
  • Lacak kesiapan migrasi berdasarkan beban kerja dan gerbang penerimaan, tidak hanya berdasarkan jumlah objek yang dimigrasikan.
  • Catat masalah terjemahan dan pemuatan berulang sebagai panduan yang dapat digunakan ulang untuk gelombang berikutnya.
  • Tetapkan prosedur eskalasi, pemulihan, rollback, dan hypercare sebelum pemangkasan produksi.

Tata kelola mencakup garis keturunan, kepemilikan, klasifikasi, retensi, audit, dan akuntabilitas operasional. Terapkan langkah pengendalian ini selama migrasi, bukan setelah peralihan akhir.

Optimasi dan modernisasi

Setelah Anda menetapkan kebenaran dan stabilitas, hapus pola kompatibilitas sementara dan gunakan kemampuan Fabric-native.

  • Memfaktorkan ulang terjemahan SQL literal menjadi T-SQL modular.
  • Menyederhanakan pandangan yang sangat terstruktur dan pekerjaan prosedural monolitik.
  • Standarkan ingesti throughput tinggi pada pola berbasis file yang efisien dan dapat dimulai kembali.
  • Lakukan penyetelan menggunakan pedoman kinerja Fabric Data Warehouse dan pengujian konkurensi yang representatif.
  • Kurangi salinan data yang tidak perlu dengan menggunakan akses OneLake yang diatur sesuai dengan arsitektur.
  • Integrasikan Data Factory, Power BI, notebook, dan beban kerja Fabric lainnya di mana mereka mengurangi duplikasi atau kompleksitas operasional.
  • Tinjau kapasitas, keamanan, keandalan, dan biaya setelah perilaku beban kerja stabil.
  • Ubah gelombang yang sudah selesai menjadi template yang dapat digunakan ulang untuk domain berikutnya.

Daftar periksa penerimaan gelombang migrasi

Sebelum proses cutover, pastikan bahwa:

  • Inventaris objek dan peta ketergantungan sudah lengkap untuk gelombang tersebut.
  • Pemblokiran keterbatasan T-SQL telah disetujui sebagai remediasi.
  • Skema dan kode dapat diterapkan secara berulang di setiap lingkungan target.
  • Jalur data historis dan inkremental lolos uji skala dan pemulihan.
  • Rekonsiliasi data dan validasi bisnis memenuhi ambang batas yang telah disepakati.
  • Keamanan dibuat ulang dan divalidasi dengan identitas representatif.
  • Laporan, model semantik, aplikasi, dan pekerjaan operasional lolos pengujian.
  • Kinerja dan konkurensi memenuhi tujuan beban kerja.
  • Rencana pemantauan, dukungan kepemilikan, rollback, dan hypercare aktif.
  • Pemilik bisnis dan teknis menyetujui peralihan.

Konten terkait

  • Terakhir diperbarui pada