Panduan keputusan Microsoft Fabric: pilih penyimpanan data

Gunakan panduan referensi ini dan contoh skenario untuk membantu Anda memilih penyimpanan data untuk beban kerja Microsoft Fabric Anda.

Properti penyimpanan data

Gudang data Lakehouse Power BI Datamart KQL Database (Eventhouse)
Volume data Tidak Terbatas Tidak Terbatas Hingga 100 GB Tidak Terbatas
Jenis data Terstruktur Tidak terstruktur, semi terstruktur, terstruktur Terstruktur Tidak terstruktur, semi terstruktur, terstruktur
Persona pengembang utama Pengembang gudang data, insinyur SQL Insinyur data, ilmuwan data Pengembang warga Ilmuwan Data Warga Negara, Insinyur data, Ilmuwan data, insinyur SQL
Set keterampilan pengembang utama SQL Spark(Scala, PySpark, Spark SQL, R) Tidak ada kode, SQL Tidak ada kode, KQL, SQL
Data yang diatur oleh Database, skema, dan tabel Folder dan file, database, dan tabel Database, tabel, kueri Database, skema, dan tabel
Membacakan operasi T-SQL, Spark (mendukung pembacaan dari tabel menggunakan pintasan, belum mendukung akses tampilan, prosedur tersimpan, fuksi, dll.) Spark,T-SQL Spark,T-SQL,Power BI KQL, T-SQL, Spark, Power BI
Operasi tulis T-SQL Spark(Scala, PySpark, Spark SQL, R) Aliran Data, T-SQL KQL, Spark, ekosistem konektor
Transaksi multi-tabel Ya No Tidak Ya, untuk penyerapan multi-tabel. Lihat kebijakan pembaruan.
Antarmuka pengembangan utama Skrip SQL Buku catatan Spark, definisi kerja Spark Power BI KQL Queryset, KQL Database
Keamanan Tingkat objek (tabel, tampilan, fungsi, prosedur tersimpan, dll.), tingkat kolom, tingkat baris, DDL/DML, masking data dinamis Tingkat baris, tingkat tabel (saat menggunakan T-SQL), tidak ada untuk Spark Editor RLS bawaan Keamanan tingkat baris
Mengakses data melalui pintasan Ya (secara tidak langsung melalui lakehouse) Ya No Ya
Dapat menjadi sumber untuk pintasan Ya (tabel) Ya (file dan tabel) Tidak Ya
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) No Ya, kueri di seluruh KQL Database, lakehouse, dan gudang dengan pintasan
Analitik tingkat lanjut Elemen asli Time Series, Penyimpanan geospasial penuh, dan kemampuan kueri
Dukungan pemformatan tingkat lanjut Pengindeksan penuh untuk teks gratis dan data semi-terstruktur seperti JSON
Latensi penyerapan Penyerapan antrean, Penyerapan streaming memiliki latensi beberapa detik

Catatan

Eventhouse adalah ruang kerja untuk beberapa database KQL. KQL Database umumnya tersedia, sedangkan Eventhouse dalam pratinjau. Untuk informasi selengkapnya, lihat Gambaran umum Eventhouse (pratinjau).

Skenario

Tinjau skenario ini untuk bantuan dalam memilih penyimpanan 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 akan 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 untuk berinteraksi terutama dengan T-SQL, sekaligus memungkinkan setiap pengguna Spark di organisasi mengakses data.

Skenario 2

Rob, seorang teknisi data, perlu menyimpan dan memodelkan beberapa terabyte data di 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 berbagai keterampilan mereka 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 bahwa 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, tidak ada kemampuan kode, dan volume data di bawah 100 GB.

Ash bekerja dengan analis bisnis yang akrab 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.

Skenario 4

Daisy adalah analis bisnis yang berpengalaman menggunakan Power BI untuk menganalisis hambatan rantai pasokan untuk rantai ritel global yang besar. Mereka perlu membangun solusi data yang dapat diskalakan yang dapat menangani miliaran baris data dan dapat digunakan untuk membangun dasbor dan laporan yang dapat digunakan untuk membuat keputusan bisnis. Data berasal dari tanaman, pemasok, pengirit, dan sumber lainnya dalam berbagai format terstruktur, semi terstruktur, dan tidak terstruktur.

Daisy memutuskan untuk menggunakan KQL Database karena skalabilitasnya, waktu respons cepat, kemampuan analitik tingkat lanjut termasuk analisis rangkaian waktu, fungsi geospasial, dan mode kueri langsung cepat di Power BI. Kueri dapat dijalankan menggunakan Power BI dan KQL untuk membandingkan antara periode saat ini dan sebelumnya, dengan cepat mengidentifikasi masalah yang muncul, atau menyediakan analitik geo-spasial rute darat dan maritim.