Fase 1: Strategi dan perencanaan migrasi

Artikel ini adalah bagian 1 dari 4 dalam seri praktik terbaik migrasi dari Azure Synapse Spark ke Microsoft Fabric.

Mulai di sini sebelum Anda memindahkan notebook, definisi tugas Spark, kumpulan, atau metadata danau. Artikel ini membantu Anda menilai cakupan properti Synapse Spark Anda, memilih pendekatan migrasi yang cocok dengan toleransi risiko dan garis waktu pengiriman Anda, dan memahami perbedaan Fabric yang memengaruhi perencanaan.

Pada akhir langkah ini, Anda harus tahu apa yang perlu dipindahkan, pola migrasi mana yang akan digunakan, di mana risiko kompatibilitas utama berada, dan batasan pemutaran kembali atau eksekusi paralel apa yang perlu Anda perhitungkan.

Dalam artikel ini, Anda akan mempelajari cara:

Menilai jejak Synapse Spark Anda.
Pilih antara lift-and-shift, modernisasi bertahap, dan operasi paralel.
Mempertimbangkan batasan pengembalian dan sinkronisasi.
Tinjau fitur utama dan perbedaan arsitektur antara Synapse Spark dan Fabric Spark.

Menilai jejak Synapse Spark Anda

Azure Synapse Analytics mencakup beberapa jenis beban kerja. Panduan ini berfokus pada migrasi pool Spark, notebook, definisi job Spark, database danau, dan metadata Hive Metastore ke Fabric. Untuk panduan migrasi kumpulan SQL khusus, pipa data, Data Explorer, dan keamanan, lihat panduan tambahan.

Beban Kerja Synapse	Tujuan Fabric	Alat dan Jalur Migrasi
Pool Spark	Fabric Spark (Lakehouse)	Asisten Migrasi Spark (pratinjau); migrasi manual kumpulan/lingkungan
Notebooks	Buku Catatan Kain	Spark Migration Assistant; pemfaktoran ulang kode untuk API khusus Synapse
Definisi pekerjaan Spark	Definisi Pekerjaan Spark di Fabric	Spark Migration Assistant (disarankan); pembuatan ulang manual jika diperlukan
Database Lake	katalog Fabric Lakehouse	Spark Migration Assistant (tabel Delta dengan fitur pintasan); Ekspor/impor HMS untuk non-Delta
Hive Metastore	katalog Fabric Lakehouse	Notebook ekspor/impor HMS; Pintasan OneLake untuk data
Layanan Tertaut	Fabric Connections / Key Vault	Membuat Koneksi Fabric; memigrasikan rahasia ke Key Vault; merefaktor kode notebook

Jalankan Alat Penilaian Fabric

Sebelum merencanakan migrasi Anda, jalankan Alat Penilaian Fabric untuk menghasilkan laporan komprehensif ruang kerja sumber Synapse Anda. Alat ini memindai ruang kerja Anda dan menggabungkan ringkasan semua objek — Kumpulan Spark, notebook, definisi pekerjaan Spark, database lake, layanan tertaut, dan konfigurasinya — memberi Anda gambaran yang jelas tentang cakupan migrasi.

Unduh alat. Alat Penilaian Fabric tersedia di repositori GitHub microsoft/fabric-toolbox pada microsoft/fabric-toolbox.
Jalankan penilaian. Arahkan alat ke ruang kerja Azure Synapse Anda. Ini memindai semua item terkait Spark dan menghasilkan laporan dengan jumlah objek, konfigurasi, dependensi, dan potensi masalah kompatibilitas.
Tinjau laporan. Gunakan output penilaian untuk memahami cakupan migrasi Anda: berapa banyak notebook, kumpulan, SJD, dan database yang perlu dimigrasikan, layanan tertaut mana yang digunakan, dan apa potensi pemblokir yang ada (kumpulan GPU, fitur yang tidak didukung, dan lainnya).

Tip

Jalankan alat penilaian di awal proses perencanaan Anda. Laporan ini membantu Anda memperkirakan upaya, mengidentifikasi pemblokir, dan memprioritaskan beban kerja mana yang akan dimigrasikan terlebih dahulu. Ini juga berfungsi sebagai inventarisasi dasar untuk Fase 1 daftar periksa migrasi.

Pola migrasi

Pilih pola migrasi Anda berdasarkan batasan organisasi, toleransi risiko, dan garis waktu Anda.

Pola angkat dan geser

Migrasikan semua beban kerja Spark sekaligus menggunakan Migration Assistant dengan perubahan minimal. Fokus pada menjalankan notebook dan pekerjaan di Fabric secepat mungkin - refaktor hanya bagian yang menyebabkan kerusakan (layanan tertaut, jalur file, API yang tidak didukung). Terima arsitektur saat ini as-is.

Gunakan lift-and-shift saat:

Ruang kerja Synapse Anda sedang dinonaktifkan pada tenggat waktu tetap dan Anda perlu bergerak cepat.
Beban kerja Spark Anda sudah dirancang dengan baik (Delta-first, kode bersih, beberapa dependensi layanan tertaut).
Ruang kerja Anda cukup untuk migrasi sekali jalan dan tim Anda dapat menangani proses refaktorisasi dalam satu sprint.
Konsumen hilir (Power BI, API) dapat mentolerir jendela pengalihan singkat.

Modernisasi bertahis

Migrasikan beban kerja secara bertahap berdasarkan prioritas, sambil merancang ulang sepanjang proses. Mulailah dengan beban kerja bernilai tertinggi atau berisiko terendah terlebih dahulu. Saat Anda memigrasi setiap batch, konsolidasikan pool Spark ke dalam lebih sedikit Environment, adopsi praktik terbaik lakehouse (Delta-first, V-order untuk konsumen BI), aktifkan NEE, dan desain ulang untuk Direct Lake.

Gunakan modernisasi bertahis saat:

Anda memiliki lingkungan Synapse yang besar atau kompleks dengan beberapa tim dan beragam beban kerja yang tidak dapat dimigrasikan dalam satu tahap.
Arsitektur Anda saat ini memiliki utang teknis yang ingin Anda atasi (format non-Delta, dependensi titik pemasangan, kumpulan Spark yang luas).
Anda memiliki fleksibilitas pada garis waktu dan ingin meningkatkan performa dan efisiensi biaya selama migrasi.
Beban kerja yang berbeda memiliki pemilik yang berbeda dan membutuhkan jadwal migrasi independen.

Pola pelaksanaan paralel

Jalankan kedua lingkungan secara bersamaan selama transisi. Arahkan beban kerja Spark baru ke Fabric sementara beban kerja lama berlanjut di Synapse. Validasi beban kerja yang dimigrasikan dengan membandingkan hasil secara bersamaan sebelum beralih. Menonaktifkan Synapse secara bertahap seiring dengan meningkatnya kepercayaan.

Gunakan eksekusi paralel saat:

Beban kerja Anda memiliki SLA yang ketat atau dokumen peraturan yang menuntut validasi yang diperpanjang sebelum alih fungsi.
Anda perlu membuktikan performa Fabric memenuhi atau melebihi Synapse sebelum pemangku kepentingan menyetujui penonaktifan.
Konsumen hilir Anda (dasbor, API, model ML) tidak dapat mentolerir perbedaan apa pun selama transisi.
Anda memigrasikan alur produksi di mana hasil yang salah memiliki efek bisnis yang tinggi (pelaporan keuangan, kepatuhan).

Eksekusi paralel memperkenalkan masalah sinkronisasi data yang harus Anda desain untuk di muka. Pilih salah satu pola ini:

Shared storage layer: Biarkan Synapse dan Fabric membaca dan menulis ke penyimpanan ADLS Gen2 yang sama melalui pintasan OneLake. Ini menyimpan kedua platform pada file Delta yang sama, tetapi Anda harus mencegah konflik tulis dengan memastikan hanya satu platform menulis ke tabel tertentu pada satu waktu.
Write-once, read-both: Pertahankan Synapse sebagai penulis utama selama transisi dan izinkan Fabric membaca data yang sama melalui pintasan. Setelah Anda memvalidasi notebook yang dimigrasikan di Fabric, alihkan jalur tulis ke Fabric dan jadikan Synapse sebagai pengguna hanya-baca hingga pensiun. Ini adalah opsi paling aman untuk sebagian besar migrasi.
Dual-write: Hindari menjalankan ETL yang sama di kedua lingkungan secara bersamaan kecuali Anda sudah memiliki perbandingan otomatis dan alat rekonsiliasi. Dual-write cenderung menciptakan divergensi, duplikasi, dan kesibukan administratif.

Pelaksanaan paralel juga memengaruhi manajemen perubahan. Meskipun Synapse tetap menjadi lingkungan pengembangan aktif, notebook apa pun, definisi kerja Spark, konfigurasi kumpulan Spark, atau perubahan skema database lake yang dibuat di Synapse tidak tercermin secara otomatis dalam Fabric. Anda harus memigrasikan kembali aset yang terpengaruh agar kedua lingkungan tetap selaras.

Kode notebook perubahan: Jalankan kembali Spark Migration Assistant atau ekspor ulang dan impor ulang secara manual buku catatan yang diperbarui. Terapkan kembali pemfaktoran ulang kode khusus Fabric, termasuk notebookutils, pembaruan jalur file, dan rahasia Key Vault.
Perubahan definisi pekerjaan Spark: Migrasi ulang melalui Migration Assistant atau buat ulang definisi pekerjaan Spark yang diperbarui secara manual di Fabric.
Perubahan konfigurasi kumpulan Spark: Perbarui Lingkungan Fabric yang sesuai agar menjadi sesuai dengan ukuran simpul yang direvisi, pengaturan skala otomatis, dan pustaka.
Perubahan skema database lake: Jalankan kembali notebook ekspor/impor HMS, atau buat atau ubah tabel yang terpengaruh secara manual di Lakehouse Fabric.

Untuk mengurangi overhead migrasi ulang, buat pembekuan perubahan di sisi Synapse setelah migrasi dimulai. Jika perubahan tidak dapat dihentikan, simpan log perubahan sehingga Anda dapat memutarnya kembali di Fabric sebelum cutover.

Pertimbangan pembatalan

Migrasi dari Synapse ke Fabric adalah operasi salin — tidak akan mengubah ataupun menghapus ruang kerja Synapse sumber Anda. Kumpulan, notebook, dan data Spark asli Anda tetap utuh sepanjang proses. Ini membuat pengembalian menjadi sederhana:

Jika hasil migrasi tidak memuaskan, lanjutkan menggunakan ruang kerja Synapse yang ada. Tidak ada perubahan yang perlu dikembalikan.
Hapus item Fabric yang dimigrasikan (notebook, lingkungan, definisi job Spark) dan coba ulang setelah mengatasi masalah.
Pintasan OneLake menunjuk ke penyimpanan ADLS Gen2 yang ada — menghapus pintasan tidak memengaruhi data sumber.
Jangan nonaktifkan ruang kerja Synapse Anda hingga semua beban kerja yang dimigrasikan divalidasi di Fabric dan konsumen hilir dialihkan.

Tip

Mulai dari yang kecil dan buktikan kelangsungan hidup dengan cepat. Pilih beban kerja Spark yang representatif dan lakukan migrasi menyeluruh dari awal hingga akhir — mulai dari pengaturan pool, refactoring notebook, hingga validasi. Pilih sesuatu yang melatih pola Anda yang paling umum (akses data, layanan tertaut, operasi katalog) tetapi rendah risikonya untuk iterasi. Dokumentasikan langkah-langkah, masalah yang dihadapi, dan resolusi untuk membangun proses yang dapat diulang untuk migrasi berikutnya.

Paritas fitur dan perbedaan utama

Memahami perbedaan arsitektur antara Synapse dan Fabric sangat penting untuk perencanaan. Tabel berikut menyoroti perbedaan utama dalam arsitektur komputasi dan kemampuan Spark.

Untuk perbandingan lengkapnya, lihat Compare Fabric dan Azure Synapse Spark: Perbedaan Utama.

Komputasi dan arsitektur

Kemampuan	Azure Synapse	Fabric
Model penyebaran	PaaS (mengonfigurasi dan mengelola sumber daya)	SaaS (berbasis kapasitas, tidak ada manajemen infrastruktur)
Model komputasi	Kumpulan Spark (yang berbasis simpul-simpul); membutuhkan minimal 3 simpul	Unit Kapasitas (CU) didistribusikan untuk semua beban kerja; Pool Spark digunakan sebagai template konfigurasi; Dukung eksekusi pada satu node; Penagihan Otomatis untuk Spark (dibayar sesuai penggunaan, serupa dengan model Synapse)
Mesin Spark	Kumpulan Synapse Spark (Spark 3.4, 3.5); Kumpulan GPU didukung	Fabric Spark (Runtime 1.2/1.3/2.0: Spark 3.4–4.0); tidak ada dukungan GPU; berjalan pada perangkat keras generasi terbaru untuk meningkatkan performa
Skalabilitas	Skala otomatis simpul untuk Spark (min 3 node)	Autoskalasi node untuk Spark (minimum satu node); skala berbasis kapasitas
Pengaktifan sesi	Pendekatan berbasis kumpulan; cold start untuk kluster baru	Kumpulan Pemula (startup tingkat detik); Kumpulan Langsung Kustom; Mode Konkurensi Tinggi
Model biaya	Per jam node (Spark); jeda/lanjutkan	Dua opsi: (1) Fabric Spark menggunakan model konsumsi bersama berbasis Unit Kapasitas (CU), atau (2) Penagihan Skala Otomatis untuk Spark – bayar sesuai pemakaian mode Spark

Spark: Synapse Spark vs. Fabric Spark

Kemampuan	Sinapse Spark	Fabric Spark
Versi Spark	Spark 3.4 (EOL), 3.5 (Pratinjau).	Spark 3.4 (RT 1.2 EOL), 3.5 (RT 1.3 GA), 4.0 (Pratinjau RT 2.0)
Akselerasi kueri	Tidak ada mesin akselerasi asli	Mesin Eksekusi Native (Velox/Gluten, hingga 4x pada TPC-DS)
Model kumpulan	Kumpulan tetap dengan jumlah maksimum simpul per kumpulan; minimum 3 simpul	Kumpulan Pemula (startup tingkat detik, tidak diperlukan konfigurasi); Kumpulan Kustom untuk ukuran simpul dan pustaka kustom tertentu; Eksekusi node tunggal didukung
Keamanan (jaringan)	Jaringan virtual terkelola; Titik Akhir Privat	Titik Akhir Privat Terkelola (MPE); Kebijakan Akses Keluar (OAP); Kunci Dikelola Pelanggan (CMK)
Dukungan GPU	Kumpulan sumber daya yang dipercepat oleh GPU tersedia	Tidak didukung
Konkurensi tinggi	Tidak didukung	Didukung: beberapa buku catatan berbagi satu sesi Spark
Manajemen pustaka	Pustaka tingkat kumpulan dan tingkat ruang kerja; unggahan manual roda, JAR, tar.gz	Manajemen pustaka berbasis lingkungan: umpan publik (PyPI/Conda) + unggahan kustom (roda, JAR). Untuk mereplikasi pustaka tingkat ruang kerja Synapse, buat Lingkungan dengan pustaka yang diperlukan dan atur sebagai default ruang kerja. Semua notebook dan SJD di ruang kerja mewarisinya secara otomatis.
Orde V	Tidak tersedia	Pengoptimalan Parquet waktu penulisan; peningkatan 40–60% untuk Power BI Direct Lake dan ~10% untuk endpoint analitik SQL; tidak ada manfaat baca Spark; 15–33% overhead penulisan
Optimalkan Penulisan	Dinonaktifkan secara default	Diaktifkan secara default
Format tabel default	Parquet (Opsional Delta)	Delta Lake (default dan diperlukan untuk tabel Lakehouse)
Hive Metastore	HMS bawaan; HMS eksternal melalui Azure SQL DB atau MySQL (tidak digunakan lagi setelah Spark 3.4)	katalog Fabric Lakehouse; Migrasi HMS melalui skrip ekspor/impor
DMTS di buku catatan	Dukungan	Didukung dalam buku catatan; belum didukung dalam definisi pekerjaan Spark
Identitas terkelola untuk KV	Dukungan	Didukung dalam notebook dan definisi kerja Spark
mssparkutils	Perpustakaan lengkap (fs, kredensial, buku catatan, env, lakehouse)	notebookutils (API serupa; beberapa perbedaan dalam nama metode)

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-04-28