Bagikan melalui

Mengevaluasi dan mengoptimalkan kapasitas Microsoft Fabric Anda

Artikel ini menjelaskan cara mengevaluasi dan mengoptimalkan beban pada kapasitas Microsoft Fabric Anda. Ini juga menjelaskan strategi untuk mengatasi situasi kelebihan beban, dan memberi Anda panduan untuk membantu mengoptimalkan komputasi untuk setiap pengalaman Fabric.

Meskipun model kapasitas Fabric menyederhanakan penyiapan dan memungkinkan kolaborasi, ada kemungkinan besar untuk menghabiskan sumber daya komputasi bersama dari kapasitas. Mungkin juga terjadi bahwa Anda membayar lebih banyak sumber daya daripada yang diperlukan. Situasi ini dapat muncul ketika desain beberapa pengalaman Fabric tidak mengikuti praktik terbaik.

Penting untuk mengurangi risiko pembuangan sumber daya bersama, Fabric—sebagai layanan terkelola—secara otomatis mengatasi situasi tersebut dengan dua cara.

  • Bursting dan smoothing memastikan bahwa aktivitas intensif CPU diselesaikan dengan cepat tanpa memerlukan SKU yang lebih tinggi (dan dapat dijalankan kapan saja sepanjang hari).
  • Throttling menunda atau menolak operasi ketika kapasitas mengalami permintaan CPU yang terus menerus dan tinggi (di atas batas SKU).

Smoothing mengurangi kemungkinan terjadinya pembatasan (meskipun throttling masih dapat terjadi). Smoothing adalah cara penggunaan didistribusikan berdasarkan batas, namun tidak bergantung pada pelaksanaan tugas. Smoothing tidak mengubah kinerja, ini hanya mendistribusikan pencatatan penggunaan komputasi selama periode waktu yang lebih lama, sehingga SKU yang lebih besar tidak diperlukan untuk menangani puncak beban komputasi.

Untuk mempelajari selengkapnya tentang kapasitas Fabric, lihat konsep dan lisensi Microsoft Fabric dan Fabric Capacities – Semua yang perlu Anda ketahui tentang apa yang baru dan apa yang akan terjadi.

Alat perencanaan dan anggaran

Merencanakan ukuran kapasitas bisa menjadi tantangan. Itu karena komputasi yang diperlukan dapat sangat bervariasi karena operasi yang dilakukan, seberapa baik mereka dijalankan (misalnya, efisiensi kueri DAX atau kode Python dalam buku catatan), atau tingkat konkurensi.

Untuk membantu Anda menentukan ukuran kapasitas yang tepat, Anda dapat menyediakan kapasitas uji coba atau SKU F prabayar untuk mengukur ukuran kapasitas aktual yang diperlukan sebelum membeli instans cadangan F SKU.

Petunjuk / Saran

Ini selalu merupakan strategi yang baik untuk memulai dari yang kecil dan kemudian secara bertahap meningkatkan ukuran kapasitas Anda seperlunya.

Memantau kapasitas

Anda harus memantau pemanfaatan untuk memaksimalkan kapasitas Anda. Yang terpenting, penting untuk dipahami bahwa operasi Fabric bersifat interaktif atau latar belakang. Misalnya, kueri DAX dari laporan Power BI adalah permintaan sesuai permintaan yang merupakan operasi interaktif, sementara refresh model semantik adalah operasi latar belakang. Untuk informasi selengkapnya tentang operasi dan bagaimana mereka menggunakan sumber daya dalam Fabric, lihat Operasi Fabric.

Pemantauan dapat menginformasikan Anda bahwa pembatasan sedang berlangsung. Pembatasan dapat terjadi ketika ada banyak atau operasi interaktif yang berjalan lama. Biasanya, operasi latar belakang yang terkait dengan pengalaman SQL dan Spark diperhalus, yang berarti mereka disebarkan selama periode 24 jam.

Aplikasi Fabric Capacity Metrics adalah cara terbaik untuk memvisualisasikan dan memantau penggunaan terkini. Aplikasi ini diuraikan ke jenis item (model semantik, notebook, alur, dan lainnya), dan membantu Anda mengidentifikasi item atau operasi yang menggunakan tingkat komputasi tinggi (sehingga dapat dioptimalkan).

Administrator dapat menggunakan Ruang Kerja Pemantauan Admin untuk mempelajari tentang item yang sering dipakai (serta adopsi secara keseluruhan). Mereka juga dapat menggunakan Monitoring hub untuk melihat aktivitas saat ini dan terbaru di tenant. Informasi selengkapnya tentang beberapa operasi mungkin juga tersedia dari Log Analytics atau log gateway data lokal.

Mengelola penggunaan komputasi tinggi

Ketika kapasitas sangat terpakai dan mulai menunjukkan penyempitan atau penolakan, ada tiga strategi untuk mengatasinya: mengoptimalkan, menambah kapasitas, dan peningkatan skala.

Ini adalah praktik yang baik untuk menyiapkan pemberitahuan untuk mengetahui ketika pemanfaatan kapasitas melebihi ambang batas yang ditetapkan. Selain itu, pertimbangkan untuk menggunakan pengaturan khusus beban kerja untuk membatasi ukuran operasi (misalnya, batas waktu kueri Power BI atau batas baris, atau pengaturan ruang kerja Spark).

Optimalkan

Pembuat konten harus selalu mengoptimalkan desain item Fabric mereka untuk memastikan bahwa efisien dan menggunakan sumber daya komputasi sesedikit mungkin. Panduan khusus untuk setiap pengalaman Fabric disediakan nanti dalam artikel ini.

Meningkatkan skala

Anda meningkatkan kapasitas untuk meningkatkan ukuran SKU untuk sementara atau permanen (dengan kapasitas komputasi yang lebih besar). Peningkatan skala memastikan bahwa ada sumber daya komputasi yang memadai yang tersedia untuk semua item pada kapasitas dan untuk menghindari pembatasan.

Anda juga dapat mengubah ukuran, menjeda, dan melanjutkan SKU Fabric F untuk menyelaraskan dengan pola konsumsi.

Perluasan distribusi

Anda meluaskan skala dengan memindahkan beberapa ruang kerja atau item Anda ke kapasitas Fabric yang berbeda untuk menyebarkan beban kerja. Ini bisa menjadi pilihan yang baik ketika strategi kapasitas, pengaturan, atau administrator yang berbeda diperlukan. Penyediaan beberapa kapasitas juga merupakan strategi yang baik untuk membantu mengisolasi komputasi untuk item berprioritas tinggi, dan juga untuk konten layanan mandiri atau pengembangan. Misalnya, eksekutif di organisasi Anda mengharapkan laporan dan dasbor yang sangat responsif. Laporan dan dasbor ini dapat berada dalam kapasitas terpisah yang didedikasikan untuk pelaporan eksekutif.

Anda juga dapat mempertimbangkan untuk memindahkan ruang kerja Power BI ke kapasitas bersama, asalkan konsumen memiliki lisensi Power BI Pro yang memungkinkan mereka terus mengakses konten.

Mengonfigurasi perlindungan lonjakan

Perlindungan Lonjakan membantu membatasi penggunaan kapasitas Anda secara berlebihan dengan membatasi jumlah total pekerjaan latar belakang komputasi yang digunakan. Ini mengurangi total komputasi sehingga penundaan atau penolakan interaktif lebih kecil kemungkinannya. Hal ini juga membantu kapasitas pulih lebih cepat ketika terjadi periode pembatasan atau penolakan. Anda mengonfigurasi perlindungan lonjakan untuk setiap kapasitas. Perlindungan lonjakan membantu mencegah pembatasan dan penolakan tetapi bukan pengganti pengoptimalan kapasitas, peningkatan skala, dan penskalaan.

Ketika perlindungan lonjakan arus aktif, pekerjaan latar belakang ditangguhkan. Ini berarti ada dampak di seluruh kapasitas Anda bahkan ketika perlindungan lonjakan diaktifkan. Dengan menggunakan perlindungan arus listrik, Anda menyetel kapasitas Anda untuk tetap berada dalam kisaran penggunaan yang paling menyeimbangkan kebutuhan komputasi dalam kapasitas. Untuk melindungi solusi penting sepenuhnya, disarankan untuk mengisolasinya dalam kapasitas yang sesuai.

Pengoptimalan komputasi berdasarkan pengalaman Fabric

Pengalaman dan item dalam Fabric bekerja secara berbeda, sehingga Anda tidak selalu mengoptimalkannya dengan cara yang sama. Bagian ini mencantumkan item Fabric sesuai dengan pengalaman, dan tindakan yang dapat Anda ambil untuk mengoptimalkannya.

Fabric Data Warehouse

Gudang data menggunakan arsitektur tanpa server dan simpulnya dikelola secara otomatis oleh layanan. Penggunaan kapasitas dihitung berdasarkan unit kapasitas detik per kueri yang aktif daripada jumlah waktu simpul frontend dan backend disediakan.

Semua operasi gudang data adalah operasi latar belakang, dan dikelola dengan mulus selama periode 24 jam.

Titik akhir analitik SQL bertujuan untuk memberikan performa secara default. Untuk akhir ini, ada lebih sedikit opsi penyetelan kueri yang tersedia dibandingkan dengan kumpulan SQL khusus SQL Server atau Azure Synapse Analytics.

Berikut adalah beberapa poin yang perlu dipertimbangkan untuk membantu meminimalkan komputasi.

  • Tulis kueri dengan menggunakan T-SQL yang paling optimal. Jika memungkinkan, batasi jumlah kolom, perhitungan, agregasi, dan operasi lain yang tidak perlu meningkatkan penggunaan sumber daya kueri.
  • Desain tabel untuk menggunakan jenis data sekecil mungkin. Pilihan jenis data Anda dapat sangat memengaruhi rencana kueri yang dihasilkan oleh mesin SQL. Misalnya, mengurangi VARCHAR bidang dari panjang 500 hingga 25 atau berubah DECIMAL(32, 8) menjadi DECIMAL(10, 2) dapat mengakibatkan penurunan sumber daya yang signifikan yang dialokasikan untuk kueri.
  • Gunakan desain skema bintang untuk mengurangi jumlah baris yang dibaca dan untuk meminimalkan gabungan kueri.
  • Pastikan statistik ada dan statistik tersebut sudah diperbarui. Statistik memainkan peran penting dalam menghasilkan rencana eksekusi yang paling optimal. Mereka dibuat secara otomatis saat runtime tetapi Anda mungkin perlu memperbaruinya secara manual, terutama setelah data dimuat atau diperbarui. Pertimbangkan untuk membuat statistik dengan menggunakan FULLSCAN opsi daripada mengandalkan statistik yang dihasilkan secara otomatis yang menggunakan pengambilan sampel.
  • Gunakan tampilan bawaan untuk memantau kueri dan penggunaan, terutama saat memecahkan masalah.

Fabric Rekayasa Data dan Fabric Ilmu Data

Pengalaman Rekayasa Data dan Ilmu Data menggunakan komputasi Spark untuk memproses, menganalisis, dan menyimpan data di Fabric lakehouse. Pengaturan dan pengukuran komputasi Spark dilakukan dalam bentuk vCores. Namun, Fabric menggunakan CUs sebagai ukuran komputasi yang dikonsumsi oleh berbagai item, termasuk notebook Spark, definisi tugas Spark, dan pekerjaan lakehouse.

Di Spark, satu CU berarti dua vCore Spark untuk komputasi. Misalnya, ketika pelanggan membeli SKU F64, 128 spark v-core tersedia untuk pengalaman Spark.

Semua operasi Spark adalah operasi latar belakang, dan dihaluskan selama periode 24 jam.

Untuk informasi selengkapnya, lihat Pelaporan penagihan dan pemanfaatan di Fabric Spark.

Berikut adalah beberapa poin yang perlu dipertimbangkan untuk membantu meminimalkan komputasi.

  • Selalu berusaha untuk menulis kode Spark yang efisien. Untuk informasi selengkapnya, lihat Optimisasi pekerjaan Apache Spark di Azure Synapse Analytics dan Perluan untuk mengoptimalkan penulisan di Apache Spark.
  • Pesan eksekutor yang diperlukan untuk pekerjaan Spark Anda agar membebaskan sumber daya untuk pekerjaan atau beban kerja Spark lainnya. Jika tidak, Anda meningkatkan kemungkinan pekerjaan Spark gagal dengan status HTTP 430, yang berarti terlalu banyak permintaan untuk kapasitas. Anda dapat melihat jumlah pelaksana yang dialokasikan ke notebook di hub pemantauan Fabric, di mana Anda juga dapat menentukan jumlah eksekutor aktual yang digunakan oleh notebook. Pekerjaan Spark hanya mencadangkan node yang diperlukan dan memungkinkan submit paralel dalam batas SKU.
  • Kumpulan Spark hanya dapat dikonfigurasi untuk menggunakan jumlah maksimum vCore yang didukung oleh SKU. Namun, Anda dapat menskalakan beban kerja rekayasa data dengan menerima pekerjaan Spark paralel dalam batas SKU. Pendekatan ini umumnya dikenal sebagai faktor burst, dan diaktifkan secara default untuk beban kerja Spark pada tingkat kapasitas. Untuk informasi selengkapnya, lihat Pembatasan konkurensi dan pemrosesan antre.
  • Sesi Spark yang aktif dapat menambah pemanfaatan CU pada kapasitas. Untuk alasan ini, penting untuk menghentikan sesi Spark aktif saat tidak digunakan. Perhatikan bahwa waktu kedaluwarsa sesi Spark default diatur ke 20 menit. Pengguna dapat mengubah batas waktu sesi di notebook atau definisi kerja Spark.

Kecerdasan Waktu Nyata

Konsumsi CU database KQL dihitung berdasarkan jumlah detik database aktif dan jumlah vCore yang digunakan. Misalnya, saat database Anda menggunakan empat vCore dan aktif selama 10 menit, Anda akan menggunakan CU 2.400 (4 x 10 x 60) detik.

Semua operasi database KQL adalah operasi interaktif.

Mekanisme skala otomatis digunakan untuk menentukan ukuran database KQL Anda. Ini memastikan bahwa pengoptimalan biaya dan performa terbaik dicapai berdasarkan pola penggunaan.

Untuk memungkinkan data tersedia untuk mesin Fabric lainnya, database KQL disinkronkan dengan OneLake. Berdasarkan jumlah transaksi baca dan transaksi tulis yang dilakukan oleh database KQL Anda, CUs akan dimanfaatkan dari kapasitas Anda. Ini menggunakan meter OneLake Read and Write, yang setara dengan operasi baca dan tulis pada akun Azure Data Lake Storage (ADLS) Gen2.

Data Factory

Bagian ini berkaitan dengan pengoptimalan untuk aliran data dan alur di Data Factory.

Semua operasi adalah operasi latar belakang, dan dilancarkan selama periode 24 jam.

Berikut adalah beberapa poin yang perlu dipertimbangkan untuk membantu meminimalkan komputasi.

  • Hindari logika Power Query yang tidak efisien untuk meminimalkan dan mengoptimalkan transformasi data yang mahal, seperti penggabungan dan pengurutan.
  • Berusaha untuk mencapai penggabungan kueri jika memungkinkan. Ini dapat meningkatkan performa aliran data Anda dengan mengurangi jumlah data yang perlu ditransfer antara sumber data dan tujuan. Saat pemisahan kueri tidak berlangsung, Power Query mengambil semua data dari sumber data dan melakukan transformasi secara lokal, yang mungkin tidak efisien dan lambat.
  • Nonaktifkan penahapan saat bekerja dengan volume data kecil dan/atau melakukan transformasi sederhana. Penahapan mungkin diperlukan dalam beberapa kasus, misalnya ketika melakukan pemuatan gudang data.
  • Hindari merefresh data lebih sering daripada yang diperlukan sumber data. Misalnya, jika sumber data hanya diperbarui setiap 24 jam sekali, refresh data per jam tidak akan memberikan nilai lagi. Sebagai gantinya, pertimbangkan untuk menyegarkan data pada frekuensi yang sesuai untuk memastikan bahwa data tersebut sudah diperbarui dan akurat.

Power BI

Operasi Power BI bersifat interaktif atau latar belakang.

Operasi interaktif berikut biasanya menghasilkan penggunaan komputasi yang tinggi.

  • Model semantik yang tidak mengikuti praktik terbaik. Misalnya, mereka mungkin tidak mengadopsi desain skema bintang dengan hubungan satu ke banyak. Atau, mereka mungkin menyertakan filter keamanan tingkat baris (RLS) yang kompleks dan mahal. Pertimbangkan untuk menggunakan Tabular Editor dan Best Practice Analyzer untuk menentukan apakah pendekatan terbaik telah diikuti.
  • Langkah-langkah DAX tidak efisien.
  • Halaman laporan berisi terlalu banyak visual, yang dapat mengakibatkan refresh visual lambat.
  • Visual laporan menampilkan hasil kardinalitas tinggi (terlalu banyak baris atau kolom), atau berisi terlalu banyak ukuran.
  • Kapasitas mengalami konkurensi tinggi karena ada terlalu banyak pengguna untuk ukuran kapasitas. Pertimbangkan untuk mengaktifkan scale-out kueri untuk meningkatkan pengalaman pengguna pada model semantik dengan konkurensi tinggi (tetapi tidak menghasilkan lebih banyak komputasi total).

Operasi latar belakang berikut biasanya menghasilkan penggunaan komputasi yang tinggi.

  • Transformasi data yang tidak efisien atau terlalu kompleks dalam logika Power Query.
  • Tidak adanya penggabungan kueri atau penyegaran bertahap untuk tabel fakta besar.
  • Report bursting, yaitu ketika sejumlah besar laporan Power BI atau laporan terpaginasikan dihasilkan pada saat yang sama.

Konten terkait

Ada pertanyaan lagi? Coba tanyakan kepada Komunitas Fabric.

  • Last updated on