Panduan keputusan Microsoft Fabric: aktivitas salin, aliran data, atau Spark

  • Artikel

Gunakan panduan referensi ini dan contoh skenario untuk membantu Anda dalam memutuskan apakah Anda memerlukan aktivitas salin, aliran data, atau Spark untuk beban kerja Microsoft Fabric Anda.

Menyalin properti aktivitas, aliran data, dan Spark

Aktivitas penyalinan alur Aliran Data Gen 2 Spark
Gunakan huruf besar Migrasi data lake dan gudang data,
penyerapan data,
transformasi ringan		 Penyerapan data,
transformasi data,
manipulasi data,
pembuatan profil data		 Penyerapan data,
transformasi data,
pemrosesan data,
pembuatan profil data
Persona pengembang utama Insinyur data,
integrator data		 Insinyur data,
integrator data,
analis bisnis		 Insinyur data,
ilmuwan data,
pengembang data
Set keterampilan pengembang utama ETL
SQL
JSON		 ETL
M
SQL		 Spark (Scala, Python, Spark SQL, R)
Kode ditulis Tidak ada kode,
kode rendah		 Tidak ada kode,
kode rendah		 Kode
Volume data Rendah ke tinggi Rendah ke tinggi Rendah ke tinggi
Antarmuka pengembangan Wizard
kanvas		 Power query Notebook
Definisi kerja Spark
Sumber 30+ konektor 150+ konektor Ratusan pustaka Spark
Tujuan 18+ konektor Lakehouse
Database Azure SQL,
Penjelajah Data Azure,
Analitik Azure Synapse		 Ratusan pustaka Spark
Kompleksitas transformasi Rendah:
ringan - konversi jenis, pemetaan kolom, gabungkan/pisahkan file, ratakan hierarki		 Rendah ke tinggi:
300+ fungsi transformasi		 Rendah ke tinggi:
dukungan untuk pustaka Spark dan sumber terbuka asli

Tinjau tiga skenario berikut untuk bantuan dalam memilih cara bekerja dengan data Anda di Fabric.

Scenario1

Leo, seorang teknisi data, perlu menyerap data dalam jumlah besar dari sistem eksternal, baik lokal maupun cloud. Sistem eksternal ini mencakup database, sistem file, dan API. Leo tidak ingin menulis dan memelihara kode untuk setiap konektor atau operasi pergerakan data. Dia ingin mengikuti praktik terbaik lapisan medali, dengan perunggu, perak, dan emas. Leo tidak memiliki pengalaman dengan Spark, jadi dia lebih suka antarmuka pengguna seret dan letakkan sebanyak mungkin, dengan pengkodian minimal. Dan dia juga ingin memproses data sesuai jadwal.

Langkah pertama adalah memasukkan data mentah ke lakehouse lapisan perunggu dari sumber daya data Azure dan berbagai sumber pihak ketiga (seperti Snowflake Web, REST, AWS S3, GCS, dll.). Dia menginginkan lakehouse terkonsolidasi, sehingga semua data dari berbagai sumber LOB, lokal, dan cloud berada di satu tempat. Leo meninjau opsi dan memilih aktivitas penyalinan alur sebagai pilihan yang sesuai untuk salinan biner mentahnya. Pola ini berlaku untuk refresh data historis dan bertambah bertahap. Dengan aktivitas salin, Leo dapat memuat data Gold ke gudang data tanpa kode jika kebutuhan muncul dan alur menyediakan penyerapan data skala tinggi yang dapat memindahkan data skala petabyte. Aktivitas salin adalah pilihan kode rendah dan tanpa kode terbaik untuk memindahkan petabyte data ke lakehouse dan gudang dari berbagai sumber, baik ad-hoc atau melalui jadwal.

Scenario2

Mary adalah insinyur data dengan pengetahuan mendalam tentang beberapa persyaratan pelaporan analitik LOB. Tim hulu telah berhasil menerapkan solusi untuk memigrasikan beberapa data historis dan inkremental LOB ke dalam lakehouse umum. Mary telah ditugaskan untuk membersihkan data, menerapkan logika bisnis, dan memuatnya ke beberapa tujuan (seperti Azure SQL DB, ADX, dan lakehouse) sebagai persiapan untuk tim pelaporan masing-masing.

Mary adalah pengguna Power Query berpengalaman, dan volume data berada dalam rentang rendah hingga menengah untuk mencapai performa yang diinginkan. Aliran data menyediakan antarmuka tanpa kode atau kode rendah untuk menyerap data dari ratusan sumber data. Dengan aliran data, Anda dapat mengubah data menggunakan opsi transformasi data 300+, dan menulis hasilnya ke beberapa tujuan dengan antarmuka pengguna yang mudah digunakan dan sangat visual. Mary meninjau opsi dan memutuskan bahwa masuk akal untuk menggunakan Dataflow Gen 2 sebagai opsi transformasi pilihannya.

Scenario3

Adam adalah insinyur data yang bekerja untuk perusahaan ritel besar yang menggunakan lakehouse untuk menyimpan dan menganalisis data pelanggannya. Sebagai bagian dari pekerjaannya, Adam bertanggung jawab untuk membangun dan memelihara alur data yang mengekstrak, mengubah, dan memuat data ke lakehouse. Salah satu persyaratan bisnis perusahaan adalah melakukan analitik ulasan pelanggan untuk mendapatkan wawasan tentang pengalaman pelanggan mereka dan meningkatkan layanan mereka.

Adam memutuskan opsi terbaik adalah menggunakan Spark untuk membangun logika ekstrak dan transformasi. Spark menyediakan platform komputasi terdistribusi yang dapat memproses data dalam jumlah besar secara paralel. Dia menulis aplikasi Spark menggunakan Python atau Scala, yang membaca data terstruktur, semi terstruktur, dan tidak terstruktur dari OneLake untuk ulasan dan umpan balik pelanggan. Aplikasi membersihkan, mengubah, dan menulis data ke tabel Delta di lakehouse. Data kemudian siap digunakan untuk analitik hilir.

Konten terkait