Panduan keputusan Microsoft Fabric: gudang data atau lakehouse
Gunakan panduan referensi ini dan contoh skenario untuk membantu Anda memilih antara gudang data atau lakehouse untuk beban kerja Anda menggunakan Microsoft Fabric.
Penting
Microsoft Fabric sedang dalam pratinjau.
Properti gudang data dan lakehouse
Gudang data | Lakehouse | Power BI Datamart | |
---|---|---|---|
Volume data | Tak Terbatas | Tidak Terbatas | Hingga 100 GB |
Tipe data | Terstruktur | Terstruktur semi terstruktur, terstruktur |
Terstruktur |
Persona pengembang utama | Pengembang gudang data, Teknisi SQL |
Insinyur data, ilmuwan data |
Pengembang warga |
Set keterampilan pengembang utama | SQL | Spark (Scala, PySpark, Spark SQL, R) |
Tanpa kode, SQL |
Data yang diatur oleh | Database, skema, dan tabel | Folder dan file, database dan tabel |
Database, tabel, kueri |
Membacakan operasi | Spark T-SQL |
Spark T-SQL |
Spark T-SQL, Power BI |
Operasi tulis | T-SQL | Spark (Scala, PySpark, Spark SQL, R) |
Aliran data, T-SQL |
Transaksi multi-tabel | Ya | Tidak | Tidak |
Antarmuka pengembangan utama | Skrip SQL | Buku catatan Spark, Definisi kerja Spark |
Power BI |
Keamanan | Tingkat objek (tabel, tampilan, fungsi, prosedur tersimpan, dll.), tingkat kolom, tingkat baris, DDL/DML |
Tingkat baris, tingkat tabel (saat menggunakan T-SQL), tidak ada untuk Spark |
Editor RLS bawaan |
Mengakses data melalui pintasan | Ya (secara tidak langsung melalui lakehouse) | Ya | Tidak |
Bisa menjadi sumber untuk pintasan | Ya (tabel) | Ya (file dan tabel) | Tidak |
Kueri di seluruh item | Ya, kueri di seluruh tabel lakehouse dan gudang | Ya, kueri di seluruh tabel lakehouse dan gudang; kueri di seluruh lakehouse (termasuk pintasan menggunakan Spark) |
Tidak |
Skenario
Tinjau skenario ini untuk bantuan dalam memilih antara menggunakan lakehouse atau gudang data di Fabric.
Skenario 1
Susan, pengembang profesional, baru menggunakan Microsoft Fabric. Mereka siap untuk mulai membersihkan, memodelkan, dan menganalisis data tetapi perlu memutuskan untuk membangun gudang data atau lakehouse. Setelah meninjau detail dalam tabel sebelumnya, poin keputusan utama adalah set keterampilan yang tersedia dan kebutuhan untuk transaksi multi-tabel.
Susan telah menghabiskan bertahun-tahun membangun gudang data pada mesin database relasional, dan terbiasa dengan sintaks dan fungsionalitas SQL. Memikirkan tim yang lebih besar, konsumen utama data ini juga terampil dengan alat analitik SQL dan SQL. Susan memutuskan untuk menggunakan gudang data, yang memungkinkan tim berinteraksi terutama dengan T-SQL, sekaligus memungkinkan setiap pengguna Spark di organisasi untuk mengakses data.
Skenario 2
Rob, seorang teknisi data, perlu menyimpan dan memodelkan beberapa terabyte data dalam Fabric. Tim ini memiliki campuran keterampilan PySpark dan T-SQL. Sebagian besar tim yang menjalankan kueri T-SQL adalah konsumen, dan oleh karena itu tidak perlu menulis pernyataan INSERT, UPDATE, atau DELETE. Pengembang yang tersisa nyaman bekerja di notebook, dan karena data disimpan di Delta, mereka dapat berinteraksi dengan sintaks SQL serupa.
Rob memutuskan untuk menggunakan lakehouse, yang memungkinkan tim teknik data untuk menggunakan keterampilan mereka yang beragam terhadap data, sambil memungkinkan anggota tim yang sangat terampil dalam T-SQL untuk mengonsumsi data.
Skenario 3
Ash, pengembang warga, adalah pengembang Power BI. Mereka terbiasa dengan Excel, Power BI, dan Office. Mereka perlu membangun produk data untuk unit bisnis. Mereka tahu mereka tidak memiliki keterampilan untuk membangun gudang data atau lakehouse, dan mereka tampak terlalu banyak untuk kebutuhan dan volume data mereka. Mereka meninjau detail dalam tabel sebelumnya dan melihat bahwa poin keputusan utama adalah keterampilan mereka sendiri dan kebutuhan mereka akan layanan mandiri, tanpa kemampuan kode, dan volume data di bawah 100 GB.
Ash bekerja dengan analis bisnis yang terbiasa dengan Power BI dan Microsoft Office, dan tahu bahwa mereka sudah memiliki langganan kapasitas Premium. Saat mereka memikirkan tim mereka yang lebih besar, mereka menyadari konsumen utama data ini mungkin analis, terbiasa dengan alat analitik tanpa kode dan SQL. Ash memutuskan untuk menggunakan datamart Power BI, yang memungkinkan tim berinteraksi membangun kemampuan dengan cepat, menggunakan pengalaman tanpa kode. Kueri dapat dijalankan melalui Power BI dan T-SQL, sekaligus memungkinkan setiap pengguna Spark di organisasi untuk mengakses data juga.