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
Gunakan informasi ini untuk membandingkan penyimpanan data Fabric seperti gudang, lakehouse, Eventhouse, database SQL, dan datamart Power BI, berdasarkan volume data, jenis, persona pengembang, set keterampilan, operasi, dan kemampuan lainnya. Perbandingan ini diatur ke dalam dua tabel berikut:
| Tabel 1 dari 2 | rumah danau | Gudang | Eventhouse |
|---|---|---|---|
| volume data | Tanpa Batas | Tak Terbatas | Tak Terbatas |
| Jenis data | Tidak Terstruktur setengah terstruktur Terstruktur |
Terstruktur semi terstruktur (JSON) |
Tidak Terstruktur semi terstruktur, Terstruktur |
| Persona pengembang utama | Insinyur data, ilmuwan data | Pengembang gudang data, arsitek data, insinyur data, pengembang database | Pengembang aplikasi, ilmuwan data, insinyur data |
| keterampilan pengembangan primer | Spark (Scala, PySpark, Spark SQL, R) | SQL | Tidak ada kode, KQL, SQL |
| Data diatur menurut | Folder dan file, basis data, dan tabel | Database, skema, dan tabel | Database, skema, dan tabel |
| operasi baca | Spark, T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
| Operasi tulis | Spark (Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Spark, ekosistem konektor |
| Transaksi multi-tabel | Tidak | Ya | Ya, untuk penyerapan multi-tabel |
| antarmuka pengembangan utama | Notebook Spark, definisi tugas Spark | Skrip SQL | Kumpulan Kuery KQL, Basis Data KQL |
| Keamanan | RLS, CLS**, tingkat tabel (T-SQL), tidak tersedia untuk Spark | Object level, RLS, CLS, DDL/DML, pemadaman data dinamis | RLS |
| Mengakses data melalui pintasan | Ya | Ya, melalui titik akhir analitik SQL | Ya |
| Dapat menjadi sumber untuk pintasan | Ya (file dan tabel) | Ya (tabel-tabel) | Ya |
| kueri di seluruh item | Ya | Ya | Ya |
| Analitik tingkat lanjut | Antarmuka untuk pemrosesan data skala besar, paralelisme data bawaan, dan toleransi kesalahan | Antarmuka untuk pemrosesan data skala besar, paralelisme data bawaan, dan toleransi kesalahan | Elemen asli Time Series, kemampuan geo-spasial dan kueri penuh |
| Dukungan pemformatan tingkat lanjut | Tabel yang ditentukan menggunakan format file yang kompatibel dengan PARQUET, CSV, AVRO, JSON, dan Apache Hive | Tabel yang ditentukan menggunakan format file yang kompatibel dengan PARQUET, CSV, AVRO, JSON, dan Apache Hive | Pengindeksan penuh untuk teks gratis dan data semi-terstruktur seperti JSON |
| latensi penyerapan | Tersedia secara instan untuk pencarian. | Tersedia secara instan untuk pencarian | Pengambilan data antrean, pengambilan data streaming memiliki latensi beberapa detik. |
* Spark mendukung pembacaan dari tabel menggunakan pintasan, belum mendukung akses tampilan, prosedur tersimpan, fungsi, dll.
| Tabel 2 dari 2 | Fabric SQL database | Power BI Datamart |
|---|---|---|
| volume data | 4 TB | Hingga 100 GB |
| Jenis data | Terstruktur setengah terstruktur Tidak terstruktur |
Terstruktur |
| Persona pengembang utama | Pengembang AI, Pengembang aplikasi, pengembang database, admin DB | Ilmuwan data, analis data |
| keterampilan utama pengembang | SQL | Tidak ada kode, SQL |
| Data disusun berdasarkan | Database, skema, tabel | Basis data, tabel, kueri |
| operasi baca | T-SQL | Spark, T-SQL |
| operasi tulis | T-SQL | Aliran Data, T-SQL |
| Transaksi Multi-tabel | Ya, kepatuhan ACID penuh | Tidak |
| antarmuka pengembangan utama | Skrip SQL | Power BI |
| Keamanan | Level objek, RLS, CLS, DDL/DML, penyamaran data dinamis | Editor RLS bawaan |
| Mengakses data melalui pintasan | Ya | Tidak |
| Dapat menjadi sumber untuk pintasan | Ya (tabel-tabel) | Tidak |
| pencarian di seluruh item | Ya | Tidak |
| Analitik tingkat lanjut | Kemampuan analitik T-SQL, data direplikasi ke format delta parquet di OneLake untuk analisis data. | Antarmuka untuk pemrosesan data dengan penyetelan performa otomatis |
| Dukungan pemformatan tingkat lanjut | Dukungan tabel untuk OLTP, JSON, vektor, graf, XML, spasial, nilai kunci | Tabel yang ditentukan menggunakan format file yang kompatibel dengan PARQUET, CSV, AVRO, JSON, dan Apache Hive |
| latensi penyerapan | Tersedia langsung untuk pencarian | Tersedia secara instan untuk mengajukan pertanyaan |
** Keamanan tingkat kolom tersedia di Lakehouse melalui titik akhir analitik SQL, menggunakan T-SQL.
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 keterampilan yang dimiliki 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 SQL dan alat analitik SQL. Susan memutuskan untuk menggunakan gudang Fabric, yang memungkinkan tim untuk berinteraksi terutama dengan T-SQL, sambil juga memungkinkan setiap pengguna Spark di organisasi untuk mengakses data.
Susan membuat gudang data baru dan berinteraksi dengannya menggunakan T-SQL sama seperti database server SQL lainnya. Sebagian besar kode T-SQL yang ada yang telah ditulisnya untuk membangun gudangnya di SQL Server akan bekerja pada gudang data Fabric membuat transisi menjadi mudah. Jika dia memilih, dia bahkan dapat menggunakan alat yang sama yang berfungsi dengan databasenya yang lain, seperti SQL Server Management Studio. Menggunakan editor SQL di portal Fabric, Susan dan anggota tim lainnya menulis kueri analitik yang mereferensikan gudang data lain dan tabel Delta di lakehouse hanya dengan menggunakan nama tiga bagian untuk melakukan kueri lintas database.
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 beragam keterampilan mereka dalam pengelolaan data, sambil memungkinkan anggota tim yang sangat terampil dalam T-SQL untuk memanfaatkan 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 sepenuhnya memiliki keterampilan untuk membangun gudang data atau lakehouse, dan hal-hal tersebut tampak terlalu berlebihan 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 adalah analis, terbiasa dengan alat analitik tanpa kode dan SQL. Ash memutuskan untuk menggunakandatamart 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 pabrik, pemasok, pengirim, dan sumber lainnya dalam berbagai format terstruktur, semi-terstruktur, dan tidak terstruktur.
Daisy memutuskan untuk menggunakanEventhousekarena skalabilitasnya, waktu respons cepat, kemampuan analitik tingkat lanjut termasuk analisis rangkaian waktu, fungsi geospasial, dan mode kueri langsung yang 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.
Skenario 5
Kirby adalah arsitek aplikasi yang berpengalaman dalam mengembangkan aplikasi .NET untuk data operasional. Mereka membutuhkan database dengan konkurensi tinggi, kepatuhan transaksi ACID penuh, dan penerapan kunci asing yang ketat untuk integritas relasional. Kirby menginginkan manfaat penyetelan performa otomatis untuk menyederhanakan manajemen database sehari-hari.
Kirby memutuskan untuk menggunakan database SQL di Fabric, dengan Mesin Basis Data SQL yang sama seperti Azure SQL Database. Database SQL di Fabric secara otomatis diskalakan untuk memenuhi permintaan sepanjang hari kerja. Mereka memiliki kemampuan penuh dari tabel transaksi dan fleksibilitas tingkat isolasi transaksi mulai dari serializable hingga snapshot telah dikomit. Basis data SQL pada Fabric secara otomatis membuat dan menghapus indeks nonclustered berdasarkan sinyal kuat dari rencana eksekusi yang diamati dari waktu ke waktu.
Dalam skenario Kirby, data dari aplikasi operasional harus digabungkan dengan data lain di Fabric: di Spark, di dalam gudang data, dan dari peristiwa real-time di Eventhouse. Setiap database Fabric menyertakan titik akhir analitik SQL, sehingga memungkinkan akses data secara real-time dari Spark atau dengan kueri Power BI menggunakan mode DirectLake. Solusi pelaporan ini membebaskan database operasional utama dari beban overhead kerja analitik, dan mengeliminasi risiko denormalisasi. Kirby juga memiliki data operasional yang ada di database SQL lainnya, dan perlu mengimpor data tersebut tanpa transformasi. Untuk mengimpor data operasional yang ada tanpa konversi jenis data apa pun, Kirby merancang alur data dengan Fabric Data Factory untuk mengimpor data ke dalam database Fabric SQL.