Mengelola model semantik Direct Lake
Artikel ini menjelaskan topik desain yang relevan dengan mengelola model semantik Direct Lake.
Tugas pasca-publikasi
Setelah pertama kali menerbitkan model semantik Direct Lake yang siap dilaporkan, Anda harus segera menyelesaikan beberapa tugas pascapublikasi. Tugas-tugas ini juga dapat disesuaikan kapan saja selama siklus hidup model semantik.
- Menyiapkan koneksi cloud
- Mengelola keanggotaan peran dalam keamanan
- Mengatur hak akses item Fabric
- Menyiapkan refresh terjadwal
Secara opsional, Anda juga dapat menyiapkan penemuan data agar pembuat laporan dapat membaca metadata, membantu mereka memahami data di hub data OneLake dan meminta akses ke data tersebut. Anda juga dapat mendukung (bersertifikat atau dipromosikan) model semantik untuk menyampaikan bahwa model tersebut menggambarkan data berkualitas yang cocok untuk digunakan.
Menyiapkan koneksi cloud
Model semantik Direct Lake menggunakan koneksi cloud untuk menyambungkan ke titik akhir analitik SQL. Ini memungkinkan akses ke data sumber, yang merupakan file Parquet di OneLake (mode penyimpanan Direct Lake, yang melibatkan pemuatan data kolom ke dalam memori) atau titik akhir analitik SQL (ketika kueri beralih kembali ke mode DirectQuery).
Koneksi cloud default
Saat Anda membuat model semantik Direct Lake, koneksi cloud default digunakan. Ini memanfaatkan single sign-on (SSO), yang berarti bahwa identitas yang meminta model semantik (seringkali pengguna laporan) digunakan untuk melakukan kueri data endpoint analitik SQL.
Koneksi cloud yang dapat dibagikan
Secara opsional, Anda dapat membuat koneksi cloud yang dapat dibagikan (SCC) sehingga koneksi ke sumber data dapat dibuat dengan identitas tetap. Ini dapat membantu pelanggan perusahaan melindungi penyimpanan data organisasi mereka. Departemen TI dapat mengelola kredensial, membuat SCC, dan membagikannya kepada pembuat yang dituju untuk pengelolaan akses terpusat.
Untuk menyiapkan identitas tetap, lihat Menentukan identitas tetap untuk model semantik Direct Lake.
Otentikasi
Identitas tetap dapat mengautentikasi baik dengan menggunakan OAuth 2.0 atau Perwakilan layanan.
Nota
Hanya autentikasi Microsoft Entra yang didukung. Oleh karena itu, autentikasi Dasar tidak didukung untuk model semantik Direct Lake.
OAuth 2.0
Saat menggunakan OAuth 2.0, Anda dapat mengautentikasi dengan akun pengguna Microsoft Entra. Akun pengguna harus memiliki izin untuk mengkueri tabel dan tampilan titik akhir analitik SQL, dan metadata skema.
Menggunakan akun pengguna tertentu bukanlah praktik yang disarankan. Itu karena kueri model semantik akan gagal jika kata sandi berubah atau akun pengguna dihapus (seperti ketika karyawan meninggalkan organisasi).
Prinsipal layanan
Mengautentikasi dengan perwakilan layanan adalah praktik yang direkomendasikan karena tidak bergantung pada akun pengguna tertentu. Prinsip keamanan harus memiliki izin untuk mengkueri tabel dan tampilan titik akhir analitik SQL, dan metadata skema.
Agar berkelanjutan, kredensial dari perwakilan layanan dapat dikelola melalui rotasi rahasia atau sertifikat.
Nota
Pengaturan tenant Fabric harus mengizinkan prinsipal layanan, dan prinsipal layanan harus termasuk dalam grup keamanan yang telah ditentukan.
Masuk sekali
Saat Anda membuat koneksi cloud yang dapat dibagikan, kotak centang Login Tunggal tidak dicentang secara otomatis. Itu adalah penyiapan yang benar saat menggunakan identitas tetap.
Anda dapat mengaktifkan SSO saat Anda ingin identitas yang meminta model semantik juga mengkueri titik akhir analitik SQL. Dalam konfigurasi ini, model semantik Direct Lake akan menggunakan identitas tetap untuk me-refresh model dan identitas pengguna untuk mengkueri data.
Saat menggunakan identitas tetap, adalah praktik umum untuk menonaktifkan SSO sehingga identitas tetap digunakan untuk refresh dan kueri, tetapi tidak ada persyaratan teknis untuk melakukannya.
Praktik yang direkomendasikan untuk koneksi cloud
Berikut adalah praktik yang direkomendasikan yang terkait dengan koneksi cloud:
- Ketika semua pengguna dapat mengakses data (dan memiliki izin untuk melakukannya), tidak perlu membuat koneksi cloud bersama. Sebagai gantinya, pengaturan koneksi cloud default dapat digunakan. Dalam hal ini, identitas pengguna yang mengkueri model akan digunakan jika kueri kembali ke mode DirectQuery.
- Buat koneksi cloud bersama saat Anda ingin menggunakan identitas tetap untuk mengkueri data sumber. Itu bisa karena pengguna yang mengkueri model semantik tidak diberikan izin untuk membaca lakehouse atau gudang. Pendekatan ini sangat relevan ketika model semantik memberlakukan RLS.
- Jika Anda menggunakan identitas tetap, gunakan opsi perwakilan Layanan karena lebih aman dan andal. Itu karena tidak mengandalkan satu akun pengguna atau izin mereka, dan tidak akan memerlukan pemeliharaan (dan gangguan) jika mereka mengubah kata sandi mereka atau meninggalkan organisasi.
- Jika pengguna yang berbeda harus dibatasi untuk mengakses hanya subset data, jika layak, terapkan RLS hanya pada lapisan model semantik. Dengan begitu, pengguna akan mendapat manfaat dari kueri dalam memori performa tinggi.
- Jika memungkinkan, hindari OLS dan CLS karena menghasilkan kesalahan dalam visual laporan. Kesalahan dapat membuat kebingungan atau kekhawatiran bagi pengguna. Untuk kolom yang dapat dirangkum, pertimbangkan untuk membuat ukuran yang mengembalikan nilai kosong dalam kondisi tertentu alih-alih CLS (jika memungkinkan).
Mengelola keanggotaan peran keamanan
Jika model semantik Direct Lake Anda memberlakukan keamanan tingkat baris (RLS) , Anda mungkin perlu mengelola anggota yang ditugaskan ke peran keamanan. Untuk informasi selengkapnya, lihat Mengelola keamanan pada model Anda.
Mengatur izin Fabric item
Model semantik Direct Lake mematuhi model keamanan berlapis. Mereka melakukan pemeriksaan izin melalui titik akhir analitik SQL untuk menentukan apakah identitas yang mencoba mengakses data memiliki izin akses data yang diperlukan.
Anda harus memberikan izin kepada pengguna sehingga mereka dapat menggunakan atau mengelola model semantik Direct Lake. Singkatnya, konsumen laporan memerlukan izin Baca, dan pembuat laporan memerlukan izin Bangun. Izin model semantik dapat ditetapkan secara langsung atau diperoleh secara implisit melalui peran ruang kerja. Untuk mengelola pengaturan model semantik (untuk refresh dan konfigurasi lainnya), Anda harus menjadi pemilik model semantik .
Bergantung pada penyiapan koneksi cloud, dan apakah pengguna perlu melakukan kueri pada lakehouse atau endpoint analitik SQL pada gudang data, Anda mungkin perlu memberikan izin lain, sebagaimana dijelaskan dalam tabel pada bagian ini.
Nota
Terutama, pengguna tidak pernah memerlukan izin untuk membaca data di OneLake. Itu karena Fabric memberikan izin yang diperlukan ke model semantik untuk membaca tabel Delta dan file Parquet terkait (untuk memuat data kolom ke dalam memori). Model semantik juga memiliki izin yang diperlukan untuk membaca titik akhir analitik SQL secara berkala untuk melakukan pemeriksaan izin untuk menentukan data apa yang dapat diakses pengguna kueri (atau identitas tetap).
Pertimbangkan skenario dan persyaratan izin berikut.
| Skenario | Izin yang diperlukan | Komentar |
|---|---|---|
| Pengguna dapat melihat laporan | • Berikan izin Baca untuk laporan dan izin Baca untuk model semantik. • Jika koneksi cloud menggunakan SSO, berikan setidaknya izin Baca untuk gudang atau lakehouse. |
Laporan tidak perlu berada di ruang kerja yang sama dengan model semantik. Untuk informasi lebih lanjut, lihat Strategi untuk konsumen baca-saja. |
| Pengguna dapat membuat laporan | • Berikan izin Build untuk model semantik. • Jika koneksi cloud menggunakan SSO, berikan setidaknya izin Membaca untuk lakehouse atau data warehouse. |
Untuk informasi selengkapnya, lihat Strategi untuk pembuat konten. |
| Pengguna dapat mengkueri model semantik tetapi ditolak mengkueri titik akhir analitik lakehouse atau SQL | • Jangan memberikan izin apa pun untuk rumah danau atau gudang. | Hanya cocok saat koneksi cloud menggunakan identitas tetap. |
| Pengguna dapat mengkueri model semantik dan titik akhir analitik SQL tetapi tidak diizinkan untuk mengkueri lakehouse. | • Berikan izin Baca dan ReadData untuk lakehouse atau gudang. | Penting : Kueri yang dikirim ke titik akhir analitik SQL akan melewati izin akses data yang diberlakukan oleh model semantik. |
| Mengelola model semantik, termasuk pengaturan refresh | • Membutuhkan kepemilikan model semantik. | Untuk informasi selengkapnya, lihat kepemilikan model semantik. |
Penting
Anda harus selalu menguji izin secara menyeluruh sebelum merilis model semantik dan laporan Anda ke lingkungan produksi.
Untuk informasi selengkapnya, lihat izin model Semantik .
Menyegarkan model semantik Direct Lake
Penyegaran model Direct Lake yang bersifat semantik menghasilkan operasi pembingkaian . Operasi refresh dapat dipicu:
- Secara manual, dengan melakukan refresh sesuai permintaan di portal Fabric, atau dengan menjalankan perintah Tabular Model Scripting Language (TMSL) Refresh dari skrip di SQL Server Management Studio (SSMS), atau dengan menggunakan alat pihak ketiga yang terhubung melalui titik akhir XMLA.
- Secara otomatis, dengan menyiapkan jadwal refresh di portal Fabric.
- Secara otomatis, saat perubahan terdeteksi dalam tabel Delta yang mendasar—untuk informasi selengkapnya, lihat Pembaruan otomatis (dijelaskan berikutnya).
- Secara terprogram, dengan memicu refresh dengan menggunakan Power BI REST API atau TOM. Anda dapat memicu refresh terprogram sebagai langkah terakhir dari proses ekstrak, transformasi, dan pemuatan (ETL).
Pembaruan otomatis
Ada pengaturan tingkat model semantik bernama Selalu perbarui data Direct Lake Anda yang melakukan pembaruan otomatis tabel Direct Lake. Ini diaktifkan secara default. Ini memastikan bahwa perubahan data di OneLake secara otomatis tercermin dalam model semantik Direct Lake. Pengaturan tersedia di portal Fabric, di pengaturan model semantik bagian Refresh.
Saat pengaturan diaktifkan, model semantik melakukan operasi pembingkaian setiap kali modifikasi data dalam tabel Delta yang mendasar terdeteksi. Operasi pembingkaian selalu khusus hanya untuk tabel-tabel di mana modifikasi data terdeteksi.
Kami menyarankan agar Anda membiarkan pengaturan aktif, terutama ketika Anda memiliki model semantik kecil atau menengah. Ini sangat berguna ketika Anda memiliki persyaratan pelaporan latensi rendah dan tabel Delta dimodifikasi secara teratur.
Dalam beberapa situasi, Anda mungkin ingin menonaktifkan pembaruan otomatis. Misalnya, Anda mungkin perlu mengizinkan penyelesaian pekerjaan persiapan data atau proses ETL sebelum mengekspos data baru kepada konsumen model semantik. Saat dinonaktifkan, Anda dapat memicu refresh dengan menggunakan metode terprogram (dijelaskan sebelumnya).
Nota
Power BI menangguhkan pembaruan otomatis saat kesalahan tidak dapat dipulihkan ditemui selama refresh. Kesalahan yang tidak dapat dipulihkan dapat terjadi, misalnya, ketika refresh gagal setelah beberapa upaya. Jadi, pastikan model semantik Anda dapat berhasil di-refresh. Power BI secara otomatis melanjutkan pembaruan otomatis saat refresh sesuai permintaan berikutnya selesai tanpa kesalahan.
Menghangatkan cache
Operasi penyegaran model semantik Direct Lake mungkin akan mengeluarkan semua kolom yang berada di memori komputer. Itu berarti kueri pertama setelah refresh model semantik Direct Lake dapat mengalami beberapa penundaan karena kolom dimuat ke dalam memori. Penundaan mungkin hanya terlihat ketika Anda memiliki data dalam volume yang sangat besar.
Untuk menghindari penundaan tersebut, pertimbangkan untuk menghangatkan cache dengan secara terprogram mengirim kueri ke model semantik. Cara mudah untuk mengirim kueri adalah dengan menggunakan tautan semantik . Operasi ini harus dilakukan segera setelah operasi refresh selesai.
Penting
Menghangatkan cache mungkin hanya masuk akal ketika penundaan tidak dapat diterima. Berhati-hatilah untuk tidak memuat data secara tidak perlu ke dalam memori yang dapat menempatkan tekanan pada kapasitas beban kerja lain, menyebabkannya dikurangi atau tidak diprioritaskan.
Mengatur properti perilaku Direct Lake
Anda dapat mengontrol fallback model semantik Direct Lake Anda dengan mengatur properti DirectLakeBehavior. Ini dapat diatur ke:
- Otomatis: (Default) Kueri-kueri beralih ke mode DirectQuery jika data yang diperlukan tidak dapat dimuat secara efisien ke dalam memori.
- DirectLakeOnly: Semua kueri hanya menggunakan mode penyimpanan Direct Lake. Pengembalian ke mode DirectQuery dinonaktifkan. Jika data tidak dapat dimuat ke dalam memori, kesalahan akan dikembalikan.
- DirectQueryOnly: Semua kueri hanya menggunakan mode DirectQuery. Gunakan pengaturan ini untuk menguji performa fallback, di mana, misalnya, Anda dapat mengamati performa kueri dalam laporan yang tersambung.
Anda dapat mengatur properti dalam pengalaman pemodelan web , atau dengan menggunakan Tabular Object Model (TOM) atau Tabular Model Scripting Language (TMSL).
Saran
Pertimbangkan untuk menonaktifkan fallback DirectQuery saat Anda ingin memproses kueri dalam mode penyimpanan Direct Lake saja. Sebaiknya nonaktifkan fallback saat Anda tidak ingin kembali ke DirectQuery. Ini juga dapat membantu ketika Anda ingin menganalisis pemrosesan kueri untuk model semantik Direct Lake untuk mengidentifikasi apakah dan seberapa sering fallback terjadi.
Memantau model semantik dari Direct Lake
Anda dapat memantau model semantik Direct Lake untuk menentukan performa kueri DAX pada visual laporan, atau untuk mengetahui kapan sistem kembali ke mode DirectQuery.
Anda dapat menggunakan Performance Analyzer, SQL Server Profiler, Azure Log Analytics, atau alat komunitas sumber terbuka, seperti DAX Studio.
Penganalisis Performa
Anda dapat menggunakan Performance Analyzer di Power BI Desktop untuk merekam waktu pemrosesan yang diperlukan untuk memperbarui elemen laporan yang dimulai sebagai akibat dari interaksi pengguna apa pun yang mengakibatkan eksekusi kueri. Jika hasil pemantauan menunjukkan metrik kueri Direct , itu berarti kueri DAX diproses dalam mode DirectQuery. Dengan tidak adanya metrik tersebut, kueri DAX diproses dalam mode Direct Lake.
Untuk informasi selengkapnya, lihat Menganalisis denganPerformance Analyzer.
SQL Server Profiler
Anda dapat menggunakan SQL Server Profiler untuk mengambil detail tentang performa kueri dengan melacak peristiwa kueri. Ini diinstal dengan SQL Server Management Studio (SSMS). Sebelum memulai, pastikan Anda telah menginstal versi terbaru SSMS.
Untuk informasi selengkapnya, lihat Analisis dengan menggunakan SQL Server Profiler.
Penting
Secara umum, mode penyimpanan Direct Lake memberikan performa kueri yang cepat kecuali jika diperlukan fallback ke mode DirectQuery. Karena fallback ke mode DirectQuery dapat memengaruhi performa kueri, penting untuk menganalisis pemrosesan kueri untuk model semantik Direct Lake untuk mengidentifikasi apakah, seberapa sering, dan mengapa fallback terjadi.
Azure Log Analytics
Anda dapat menggunakan Azure Log Analytics untuk mengumpulkan, menganalisis, dan bertindak berdasarkan data telemetri yang terkait dengan model semantik Direct Lake. Ini adalah layanan dalam Azure Monitor, yang digunakan Power BI untuk menyimpan log aktivitas.
Untuk informasi selengkapnya, lihat Menggunakan Azure Log Analytics di Power BI.