Arsitektur medali gudang data modern di Microsoft Fabric

Microsoft Fabric

Power BI

Contoh penerapan ini menggambarkan arsitektur medallion gudang data modern (MDW) yang mengutamakan SQL. Gudang data modern menggunakan penyimpanan data berbasis SQL untuk mengatur data terstruktur untuk analitik dan pelaporan. Arsitektur ini mengimplementasikan lapisan perunggu, perak, dan emas dalam Fabric Data Warehouse dan menggunakan Fabric Data Factory untuk mengatur penyerapan dan transformasi data.

Fabric Data Warehouse menyimpan data relasional dalam format Delta di OneLake dan mendukung pengembangan T-SQL melalui tabel, tampilan, transaksi, dan prosedur tersimpan. Power BI, klien SQL, dan aplikasi lainnya mengonsumsi data yang dikumpulkan dari lapisan emas.

Important

Pola medali Fabric yang direkomendasikan menggunakan lakehouse untuk setiap lapisan atau menggunakan lakehouse untuk lapisan perunggu dan perak dan gudang untuk lapisan emas. Arsitektur ini menggunakan gudang untuk ketiga lapisan karena data tetap terstruktur dan diubah dengan menggunakan SQL sepanjang proses. Lakehouse lebih cocok untuk pemrosesan berbasis Spark, beban kerja ilmu data, dan volume besar data yang tidak terstruktur atau semistruktur. Untuk implementasi lakehouse-first yang mendukung Spark dan data yang tidak terstruktur, lihat Greenfield lakehouse di Microsoft Fabric.

Architecture

Unduh file arsitektur ini dalam format PowerPoint.

Dalam diagram, Mirroring menangani replikasi database operasional, dan pipeline Fabric Data Factory memasukkan sumber data yang tidak dicerminkan ke jalur bronze.

Aliran Data

Aliran data berikut sesuai dengan diagram sebelumnya:

Database operasional, aplikasi SaaS, file, dan sistem sumber lainnya menghasilkan data.
Penyerapan membawa data sumber ke dalam Fabric melalui dua jalur. Untuk database operasional yang didukung, Mirroring in Fabric terus mereplikasi data ke dalam item database cermin di OneLake. Langkah warehouse CTAS atau INSERT ... SELECT kemudian menyimpan data tersebut secara persisten di warehouse bronze. Untuk file, aplikasi SaaS, dan sumber lain yang tidak dicerminkan, gunakan alur Fabric Data Factory atau gudang T-SQL, seperti COPY INTO, untuk memuat tabel perunggu.
Lapisan perunggu menyimpan data mentah dan diproses minimal dalam tabel gudang. Metadata penyerapan, seperti tanda waktu muat dan pengidentifikasi sumber, mendukung audit dan pemrosesan ulang.
Tahap transformasi pertama (Bronze to silver) memvalidasi dan mengubah data perunggu menjadi lapisan perak.
Lapisan perak berisi data yang telah dibersihkan, dideduplikasi, dan distandardisasi. Jika analisis historis diperlukan, tabel silver menyimpan perubahan pada sumber data beserta tanggal efektif dan indikator baris terkini.
Prosedur tersimpan atau job dbt biasanya menerapkan tahap Bronze to silver menggunakan pola SQL seperti CREATE TABLE AS SELECT (CTAS), INSERT ... SELECT, dan MERGE.
Lapisan gold menyediakan skema bintang, data mart, dan tabel yang telah diagregasi sebelumnya serta siap digunakan.
Tahap transformasi kedua (Silver to gold) mengubah data perak menjadi entitas bisnis, dimensi, fakta, dan agregat di lapisan emas.
Power BI mengonsumsi data emas melalui model semantik. Pengguna lain, seperti klien SQL, notebook, dan aplikasi, dapat menjalankan kueri pada endpoint SQL gudang data.

Components

Fabric Data Warehouse menyediakan tabel komputasi dan relasional T-SQL untuk lapisan perunggu, perak, dan emas.
OneLake menyimpan data warehouse dalam format Delta dan menyimpan data yang direplikasi melalui pencerminan Fabric.
Pencerminan di Fabric secara terus-menerus mereplikasi database operasional yang didukung ke OneLake.
Fabric Data Factory menyerap data dan mengatur prosedur tersimpan, alur, dan aktivitas transformasi lainnya.
Power BI menyediakan model semantik, laporan, dan dasbor berdasarkan data gold yang telah dikurasi.

Panduan desain

Panduan berikut menjelaskan cara mengimplementasikan lapisan perunggu, perak, dan emas dan mengatur ruang kerja pendukung. Sesuaikan rekomendasi ini dengan sumber data dan persyaratan tata kelola beban kerja Anda dan keterampilan tim Anda.

Lapisan perunggu: Penyerapan data mentah

Lapisan perunggu menyerap data mentah dan menangkap semua data sumber dalam bentuk aslinya tanpa menerapkan logika bisnis apa pun. Ini berfungsi sebagai sistem catatan, memungkinkan keterlacakan penuh dan pemrosesan ulang. Tabel dalam lapisan ini mencerminkan skema sumber dengan cermat dan sengaja menghindari pemfilteran, deduplikasi, atau pengayaan. Kolom metadata opsional, seperti tanda waktu penyerapan atau nama file sumber, sering mendukung audit.

Untuk database operasional yang didukung, gunakan Mirroring di Fabric untuk terus mereplikasi tabel sumber ke OneLake. Untuk sumber file, SaaS, atau tidak didukung, gunakan alur Fabric Data Factory, COPY INTO untuk penyerapan massal, atau OPENROWSET dengan CTAS atau INSERT ... SELECT untuk mempertahankan data file eksternal di gudang perunggu.

Pada tahap ini, penyerapan terus membentuk ulang minimal sehingga lapisan perunggu tetap menjadi sistem rekaman yang dapat diputar ulang. Jika diperlukan untuk sumber yang tidak dicerminkan, prosedur tersimpan beban perunggu (atau model dbt yang setara) dapat menstandarkan rekaman masuk dan menambahkan metadata beban.

Praktik terbaik untuk lapisan perunggu menekankan untuk mempertahankan semua data mentah, termasuk rekaman yang tidak valid, menggunakan penyerapan batch untuk menghindari masalah file kecil, menyelaraskan skema dengan erat dengan sistem sumber, dan mengotomatiskan alur kerja penyerapan dengan menggunakan alur Fabric untuk memastikan konsistensi dan keandalan dalam skala besar.

Lapisan perak: Pembersihan dan kesuaian data

Lapisan perak berfokus pada pembersihan dan kesesuaian data dengan menyempurnakan data perunggu melalui penerapan aturan kualitas data, standardisasi, deduplikasi, dan integrasi di beberapa sumber. Ini pada akhirnya menghasilkan satu sumber kebenaran untuk data yang dibersihkan dan dapat diandalkan.

Anda biasanya menerapkan transformasi pada tahap ini dengan menggunakan T-SQL, menggunakan pola seperti CREATE TABLE AS SELECT (CTAS), INSERT … SELECT, dan MERGE pernyataan untuk mendukung pemrosesan batch dan bertambah bertahap. Meskipun Fabric Data Warehouse tidak mendukung tampilan materialisasi, Anda dapat menggunakan tampilan danau materialisasi, yang diimplementasikan dengan menggunakan Spark, untuk menghasilkan tabel Delta. Titik akhir analitik SQL mengekspos tabel Delta ini sebagai tabel yang dapat dibaca gudang.

Praktik terbaik untuk lapisan perak mencakup merancang transformasi agar bersifat idempoten, menerapkan aturan kualitas data secara konsisten, dan menggunakan MERGE untuk pembaruan inkremental. Ketika beban kerja memerlukan penyimpanan riwayat, simpan versi tiap baris beserta tanggal mulai dan tanggal berakhir berlaku serta indikator baris aktif. Dimensi emas dapat menggunakan riwayat ini untuk mengimplementasikan perilaku dimensi (SCD) tipe 1 atau tipe 2 yang berubah secara perlahan.

Lapisan emas: Data yang dikumpulkan untuk analitik

Lapisan emas menyediakan data siap digunakan untuk bisnis yang telah dikurasi dan dioptimalkan untuk analitik, pelaporan, dan digunakan oleh alat BI seperti Power BI. Lapisan ini dirancang berdasarkan pola pemodelan analitik, umumnya menggunakan skema bintang dengan tabel fakta dan tabel dimensi, data mart khusus domain, serta tabel ringkasan praagregasi untuk mendukung kueri yang cepat dan analisis yang intuitif.

Anda biasanya menurunkan tabel emas hanya dari data perak dan menyediakannya kepada pengguna akhir serta alat bantu pelaporan.

Gunakan kunci pengganti yang stabil untuk dimensi sehingga fakta tidak bergantung pada kunci sistem sumber yang dapat diubah. Fabric Data Warehouse mendukung BIGINT IDENTITY kolom untuk pembuatan kunci pengganti. Nilai identitas unik tetapi tidak dijamin berurutan atau diurutkan, dan kesenjangan dapat terjadi. Jika batasan tersebut tidak sesuai untuk beban kerja, buat dan pertahankan kunci pengganti dalam logika transformasi dan pertahankan pemetaan yang tahan lama ke setiap kunci alami. Jangan meregenerasi kunci pengganti selama refresh penuh.

Praktik terbaik untuk lapisan emas mencakup pemodelan data agar selaras dengan kasus penggunaan analitik dan bisnis, melakukan praagregasi data jika memungkinkan untuk meningkatkan performa, menerapkan kontrol keamanan seperti keamanan tingkat baris (RLS), keamanan tingkat kolom (CLS), dan penyamaran data, serta mendokumentasikan asal usul data dan transformasi secara menyeluruh.

Strategi ruang kerja

Strategi ruang kerja menentukan bagaimana lapisan perunggu, perak, dan emas dipisahkan secara logis dan fisik untuk menyeimbangkan tata kelola, keamanan, dan kesederhanaan operasional. Anda dapat menerapkan lapisan dengan menggunakan ruang kerja terpisah per lapisan, yang kami sarankan ketika batas keamanan yang kuat, kepemilikan yang jelas, atau pemisahan tanggung jawab yang ketat diperlukan. Misalnya, Anda harus mengisolasi penyerapan data mentah dari data bisnis yang dikumpulkan.

Atau, Anda dapat menerapkan lapisan dalam satu ruang kerja dengan menggunakan gudang terpisah untuk data perunggu, perak, dan emas. Pendekatan ini dapat mengurangi beban pengelolaan dan menyederhanakan pengembangan serta pengujian antarlapisan, sambil mempertahankan separasi pada tingkat warehouse antara lapisan medallion.

Pilihan antara pendekatan ini biasanya tergantung pada faktor-faktor seperti skala organisasi, persyaratan keamanan, struktur tim, dan kematangan tata kelola. Banyak perusahaan mengadopsi model hibrid seiring berkembangnya implementasi Fabric mereka. Sebaiknya gunakan ruang kerja terpisah saat diperlukan isolasi, tata kelola, dan batas kepemilikan.

Panduan implementasi

Fabric Data Warehouse memberikan konsistensi transaksi dan pemrosesan data yang andal di seluruh lapisan perunggu, perak, dan emas. Gunakan penulisan berorientasi batch untuk meminimalkan masalah file kecil dan meningkatkan penyimpanan dan efisiensi kueri. Gunakan MERGE pernyataan untuk menangani data yang terlambat tiba atau diubah dalam skenario pemrosesan bertahap.

Jaga agar transaksi berlangsung singkat untuk mengurangi perebutan sumber daya dan mengoptimalkan konkurensi, terutama di lingkungan dengan tingkat pemasukan data yang tinggi. Pantau performa dan kesehatan operasional secara aktif dengan menggunakan wawasan kueri Fabric dan tampilan manajemen dinamis (DMV). Pemisahan arsitektur beban kerja baca dan tulis di Fabric lebih lanjut memungkinkan pekerjaan penyerapan dan transformasi berjalan bersamaan tanpa memblokir kueri analitik, memastikan performa yang dapat diprediksi untuk analitik hilir dan pelaporan.

Gunakan prosedur tersimpan T-SQL dan Fabric alur Data Factory untuk transformasi dan orkestrasi SQL asli. Tim yang lebih menyukai model dan pengujian SQL modular dapat menggunakan adaptor dbt yang dikelola Microsoft untuk Fabric Data Warehouse. Jalankan pengujian keunikan, integritas referensial, dan nilai yang diterima sebagai penyebaran atau gerbang alur sebelum menerbitkan data ke lapisan hilir.

Alternatives

Arsitektur ini mencakup beberapa komponen yang dapat Anda ganti dengan layanan atau pendekatan Azure lainnya, tergantung pada persyaratan fungsional dan nonfungsi beban kerja Anda. Pertimbangkan alternatif berikut dan kompromi masing-masing.

Untuk skenario yang menekankan rekayasa data skala besar, analitik tingkat lanjut, pembelajaran mesin, atau data yang tidak terstruktur, arsitektur lakehouse-first pada Microsoft Fabric bisa lebih cocok. Dalam pendekatan ini, Fabric lakehouse berfungsi sebagai penyimpanan data utama di OneLake, dan transformasi terutama diimplementasikan dengan menggunakan alat berbasis Spark seperti notebook atau Dataflow Gen2. Pola ini menyediakan komputasi terdistribusi, notebook, dan alat pembelajaran mesin yang bukan fokus arsitektur gudang SQL-first ini.

Untuk organisasi dengan fokus yang kuat pada ilmu data, AI, atau pemrosesan terdistribusi yang kompleks, Azure Databricks adalah alternatif lain. Azure Databricks biasanya dipilih ketika beban kerja memerlukan integrasi mendalam dengan kerangka kerja pembelajaran mesin sumber terbuka, kontrol terperinci atas eksekusi Spark, atau portabilitas multicloud.

Untuk analitik yang hampir real time atau berbasis peristiwa, Fabric Real-Time Intelligence, Azure Event Hubs, atau Azure Stream Analytics mungkin lebih cocok daripada desain medali berorientasi batch yang berpusat pada Fabric Data Warehouse.

Detail skenario

Fabric Data Warehouse sangat cocok untuk arsitektur medali ini ketika tujuan utamanya adalah untuk memberikan data yang diatur dan siap analitik dalam skala besar dengan menggunakan pola SQL yang sudah dikenal.

Skenario 1: Semantik relasional dan performa SQL untuk himpunan data yang dikumpulkan dan siap analitik

Fabric Data Warehouse sangat cocok karena menyediakan tabel dan tampilan relasional, transaksi ACID, dan operasi T-SQL di atas data Delta. Rangkaian fitur ini mendukung beban kerja ketika data sudah dibersihkan dan distandardisasi serta harus dikueri secara konsisten melalui SQL.

Contoh: Maskapai membangun himpunan data emas yang dikumpulkan untuk operasi penerbangan dan analitik pendapatan. Analis mengandalkan performa kueri SQL yang stabil untuk mengevaluasi tren performa tepat waktu, profitabilitas rute, dan pemanfaatan kru. Menggunakan tabel dan tampilan gudang memastikan konsistensi transaksi dan perilaku kueri yang andal, yang lebih sulit dijamin dengan akses berbasis file ad hoc.

Skenario 2: Tata kelola terpusat dengan pengalaman berfokus pada SQL

Fabric Data Warehouse memungkinkan tata kelola terpusat melalui izin ruang kerja, keamanan tingkat objek, dan silsilah data bawaan, sambil mengekspos data melalui antarmuka SQL yang akrab bagi tim teknik analitik. Pendekatan ini mengurangi gesekan operasional, menyederhanakan kontrol akses, dan mempercepat adopsi di seluruh tim tanpa memperkenalkan paradigma akses baru.

Contoh: Perusahaan global memberlakukan pemisahan tugas yang ketat: tim platform mengelola penyerapan dan transformasi, dan tim analitik hanya menggunakan data yang dikumpulkan. Dengan hanya mengekspos tabel lapisan emas melalui gudang dan mengatur akses secara terpusat, organisasi menghindari akses yang tidak terkendali ke data mentah atau menengah sambil mempertahankan alur kerja berbasis SQL yang akrab.

Skenario 3: Konsumsi data yang dioptimalkan untuk BI untuk pelaporan dan dasbor

Gudang data ini dioptimalkan untuk tingkat konkurensi tinggi dan beban kerja yang didominasi operasi baca, sehingga menjadi pilihan yang tepat ketika banyak pengguna bisnis mengakses dasbor dan laporan yang dibangun di atas model semantik yang konsisten. Pengoptimalan ini sangat penting di mana performa, stabilitas, dan perilaku kueri yang dapat diprediksi diperlukan selama penggunaan puncak.

Contoh: Tim keuangan dan operasi mengakses dasbor Power BI selama jam kerja untuk memantau KPI seperti pendapatan, efisiensi operasional, dan kepatuhan SLA. Fabric Data Warehouse mengisolasi SELECT dan beban kerja non-SELECT ke dalam kumpulan komputasi yang terpisah, sehingga mengurangi perebutan sumber daya secara langsung antara kueri dasbor dan ingesti data warehouse.

Skenario 4: Dukungan pemodelan dimensi untuk lapisan emas yang dapat digunakan kembali

Fabric Data Warehouse selaras secara alami dengan pola pemodelan dimensi, termasuk tabel fakta dan dimensi, yang biasanya Anda gunakan dalam lapisan emas untuk mengekspos himpunan data yang ramah bisnis dan dapat digunakan kembali. Model ini menyederhanakan analitik, mengurangi duplikasi logika, dan mempromosikan definisi metrik yang konsisten di seluruh tim.

Contoh: Organisasi ritel membuat tabel dimensi bersama untuk pelanggan, produk, dan toko, bersama dengan tabel fakta untuk penjualan dan inventarisasi. Himpunan data emas ini digunakan kembali di beberapa laporan Power BI dan unit bisnis, memastikan bahwa KPI seperti penjualan bersih atau pergantian inventarisasi ditentukan sekali dan diterapkan secara konsisten.

Considerations

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat Anda gunakan untuk meningkatkan kualitas beban kerja.

Keandalan

Keandalan membantu memastikan bahwa aplikasi Anda dapat memenuhi komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat daftar periksa tinjauan desain untuk Keandalan.

Tinjau Keandalan di Microsoft Fabric untuk model ketahanan yang didokumentasikan, termasuk perilaku saat suatu zona tidak tersedia dan pertimbangan regional. Validasi ekspektasi pemulihan terhadap panduan ini untuk wilayah dan persyaratan beban kerja Anda.

Untuk skenario pemulihan bencana lintas wilayah, rancang dan dokumentasikan strategi pemulihan yang selaras dengan persyaratan organisasi dan model tanggung jawab bersama.

Fabric Data Warehouse hanya mendukung PRIMARY KEY, , dan FOREIGN KEYUNIQUE hanya sebagai NOT ENFORCED. Gudang data tidak memvalidasi keunikan atau integritas referensial. Logika penyerapan dan transformasi harus mendeteksi rekaman duplikat atau tanpa induk dan mencegahnya mencapai lapisan hilir.

Keamanan

Keamanan menjamin perlindungan terhadap serangan yang disengaja dan penyalahgunaan data serta sistem berharga Anda. Untuk informasi selengkapnya, lihat daftar periksa tinjauan desain untuk Keamanan.

Microsoft Fabric menyediakan kemampuan untuk mengelola, mengontrol, dan mengaudit pengaturan keamanan berdasarkan persyaratan organisasi. Pertimbangkan praktik keamanan berikut:

Gunakan akses menyeluruh (SSO) Microsoft Entra ID untuk mengautentikasi pengguna dan menyediakan manajemen identitas yang konsisten di seluruh perangkat dan lokasi.
Terapkan izin berbasis ruang kerja untuk mengontrol siapa yang dapat membuat, memodifikasi, atau menggunakan artefak Fabric.
Gunakan kontrol keamanan jaringan masuk dan keluar Fabric saat mengakses data atau layanan di dalam atau di luar jaringan Anda. Kontrol ini mencakup Akses Bersyarat, tautan privat, akses ruang kerja tepercaya, dan titik akhir privat terkelola.
Gunakan log audit Fabric untuk melacak aktivitas pengguna, perubahan konfigurasi, dan akses data di seluruh platform.

Untuk informasi selengkapnya, lihat Keamanan di Fabric.

Pengoptimalan Biaya

Pengoptimalan Biaya berfokus pada cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat daftar periksa tinjauan desain untuk Pengoptimalan Biaya.

Microsoft Fabric menyediakan reservasi kapasitas untuk sejumlah unit kapasitas (CUs) yang ditentukan. Reservasi satu tahun dapat membantu mengurangi biaya untuk beban kerja dengan status stabil yang dapat diprediksi.

Untuk memaksimalkan pemanfaatan kapasitas Fabric, pertimbangkan praktik berikut:

Mulailah dengan kapasitas uji coba atau SKU F prabayar untuk memahami perilaku beban kerja. Jalankan bukti konsep dengan cakupan terbatas dengan beban kerja penyerapan data, transformasi, dan pelaporan yang representatif. Pantau konsumsi CU dan ekstrapolasi hasil untuk memperkirakan kebutuhan produksi. Anda dapat menskalakan kapasitas Fabric saat permintaan meningkat.
Analisis penggunaan historis untuk mengidentifikasi periode puncak dan di luar puncak. Jadwalkan beban kerja nonkritis atau yang berjalan di latar belakang pada periode permintaan yang lebih rendah untuk mengurangi tekanan CU yang berkelanjutan.
Kurangi konsumsi komputasi yang tidak perlu dengan mengoptimalkan kueri SQL, Ekspresi Analisis Data (DAX), dan pekerjaan latar belakang.
Fabric mendukung bursting dan smoothing untuk menyerap lonjakan jangka pendek dalam permintaan komputasi dan menyebarkan konsumsi beban kerja latar belakang dari waktu ke waktu. Fitur-fitur ini membantu menentukan kapasitas berdasarkan penggunaan rata-rata, bukan permintaan puncak. Untuk informasi selengkapnya, lihat Mengevaluasi dan mengoptimalkan kapasitas Fabric Anda.
Koordinasikan transformasi jangka panjang dan operasi refresh untuk menghindari tumpang tindih beban kerja komputasi tinggi pada kapasitas yang sama. Untuk informasi selengkapnya, lihat Manajemen beban kerja di Fabric Data Warehouse.

Ingatlah pertimbangan harga berikut:

Volume penyimpanan OneLake, periode retensi, dan pola akses data secara langsung memengaruhi total biaya. Perkirakan pertumbuhan data yang diharapkan per lapisan medali dan selaraskan retensi dengan persyaratan bisnis dan kepatuhan.
Harga Microsoft Fabric didasarkan pada kapasitas F yang ditetapkan, yang diukur dalam CUs. Power BI lisensi per pengguna terpisah dan tidak menyediakan kapasitas Fabric.

Gunakan perkiraan preconfigured dalam kalkulator harga Azure untuk mendapatkan biaya awal untuk arsitektur ini. Sesuaikan nilai agar sesuai dengan beban kerja yang diharapkan.

Keunggulan Operasi

Keunggulan Operasional mencakup proses operasional yang menyebarkan, memantau, dan memelihara beban kerja dalam produksi. Untuk informasi selengkapnya, lihat daftar periksa tinjauan desain untuk Keunggulan Operasional.

Microsoft Fabric menyediakan visibilitas operasional bawaan di seluruh beban kerja rekayasa data, pergudangan, dan analitik. Gunakan aplikasi Metrik Kapasitas Fabric untuk memantau konsumsi kapasitas, mengidentifikasi artefak yang banyak menggunakan sumber daya, dan memahami bagaimana beban kerja interaktif dan latar belakang berkontribusi terhadap penggunaan kapasitas secara keseluruhan. Wawasan ini membantu tim membuat keputusan operasional berdasarkan informasi tentang penskalaan, penjadwalan, dan pengoptimalan.

Siapkan pemberitahuan proaktif sehingga administrator kapasitas dapat mengidentifikasi kondisi pemanfaatan atau pembatasan yang tinggi lebih awal dan merespons sebelum dampak pengguna terjadi.

Efisiensi Performa

Efisiensi Performa mengacu pada kemampuan beban kerja untuk menskalakan dan memenuhi permintaan pengguna secara efisien. Untuk informasi selengkapnya, lihat daftar periksa ulasan desain untuk Efisiensi Performa.

Microsoft Fabric mencakup beberapa mekanisme untuk membantu mengelola performa dan pemanfaatan kapasitas:

Peningkatan kapasitas sesaat dan perataan beban memungkinkan lonjakan singkat pada kebutuhan komputasi diselesaikan lebih cepat sambil meratakan penggunaan seiring waktu. Operasi interaktif biasanya lancar selama beberapa menit, dan operasi latar belakang lancar di jendela yang lebih panjang.
Pembatasan diterapkan ketika suatu kapasitas mengalami penggunaan komputasi terus-menerus yang melebihi batas SKU yang ditetapkan untuknya. Throttling menunda atau menolak operasi baru untuk melindungi stabilitas platform.
Aplikasi Metrik Kapasitas Fabric memberikan visibilitas terperinci ke dalam konsumsi kapasitas dan membedakan antara operasi interaktif (seperti kueri laporan) dan operasi latar belakang (seperti penyerapan atau refresh model). Perbedaan ini memungkinkan pengoptimalan performa yang ditargetkan untuk berbagai jenis beban kerja.

Kontributor

Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.

Prabhjot Kaur | Arsitek Solusi Cloud Senior

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Langkah selanjutnya

Saran dan Komentar

Apakah halaman ini membantu?