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.
Konten terkait
Saran dan Komentar
https://aka.ms/ContentUserFeedback.
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat:Kirim dan lihat umpan balik untuk