Bagikan melalui

Mengembangkan model semantik Direct Lake

  • Artikel

Artikel ini menjelaskan topik desain yang relevan dengan pengembangan model semantik Direct Lake.

Buatlah model

Anda menggunakan portal Fabric untuk membuat model semantik Direct Lake di ruang kerja. Ini adalah proses sederhana yang melibatkan pemilihan tabel mana dari satu lakehouse atau gudang untuk ditambahkan ke model semantik.

Anda kemudian dapat menggunakan pengalaman pemodelan web untuk mengembangkan model semantik lebih lanjut. Pengalaman ini memungkinkan Anda membuat hubungan antar tabel, membuat ukuran dan grup perhitungan, menandai tabel tanggal, dan mengatur properti untuk model dan objeknya (seperti format kolom). Anda juga dapat menyiapkan model keamanan tingkat baris (RLS) dengan menentukan peran dan aturan, dan dengan menambahkan anggota (akun pengguna Microsoft Entra atau grup keamanan) ke peran tersebut.

Atau, Anda dapat melanjutkan pengembangan model Anda dengan menggunakan alat yang mematuhi XMLA, seperti SQL Server Management Studio (SSMS) (versi 19.1 atau yang lebih baru) atau alat komunitas sumber terbuka. Untuk informasi selengkapnya, lihat dukungan penulisan Model dengan titik akhir XMLA di bagian selanjutnya dari artikel ini.

Tip

Anda dapat mempelajari cara membuat lakehouse, tabel Delta, dan model semantik Direct Lake dasar dengan menyelesaikan tutorial ini.

Tabel model

Tabel model didasarkan pada tabel atau tampilan titik akhir analitik SQL. Namun, hindari menggunakan tampilan jika memungkinkan. Itu karena kueri ke tabel model berdasarkan pandangan akan selalu beralih kembali ke mode DirectQuery, yang dapat menyebabkan performa kueri melambat.

Tabel harus menyertakan kolom untuk pemfilteran, pengelompokan, pengurutan, dan ringkasan, selain kolom yang mendukung hubungan model. Meskipun kolom yang tidak perlu tidak memengaruhi performa kueri model semantik (karena tidak akan dimuat ke dalam memori), kolom tersebut menghasilkan ukuran penyimpanan yang lebih besar di OneLake dan memerlukan lebih banyak sumber daya komputasi untuk dimuat dan dikelola.

Peringatan

Menggunakan kolom yang menerapkan masking data dinamis (DDM) dalam model semantik Direct Lake tidak didukung.

Untuk mempelajari cara memilih tabel mana yang akan disertakan dalam model semantik Direct Lake Anda, lihat Edit tabel untuk model semantik Direct Lake.

Untuk informasi selengkapnya tentang kolom yang akan disertakan dalam tabel model semantik Anda, lihat Memahami penyimpanan untuk model semantik Direct Lake.

Menerapkan aturan akses data

Saat Anda memiliki persyaratan untuk mengirimkan subset data model ke pengguna yang berbeda, Anda dapat menerapkan aturan akses data. Anda menerapkan aturan dengan menyiapkan keamanan tingkat objek (OLS) dan/atau keamanan tingkat baris (RLS) di titik akhir analitik SQL atau dalam model semantik.

Nota

Topik memberlakukan aturan akses data berbeda, namun terkait, dengan mengatur izin untuk konsumen konten, pembuat, dan pengguna yang akan mengelola model semantik (dan item Fabric terkait). Untuk informasi selengkapnya tentang mengatur izin, lihat Mengelola model semantik Direct Lake.

Keamanan tingkat objek (OLS)

OLS melibatkan pembatasan akses untuk menemukan dan mengkueri objek atau kolom. Misalnya, Anda dapat menggunakan OLS untuk membatasi pengguna yang dapat mengakses kolom Salary dari tabel Employee.

Untuk titik akhir analitik SQL, Anda dapat menyiapkan OLS untuk mengontrol akses ke objek titik akhir, seperti tabel atau tampilan, dan keamanan tingkat kolom (CLS) untuk mengontrol akses ke kolom tabel titik akhir.

Untuk model semantik, Anda dapat mengatur OLS untuk mengontrol akses ke tabel model atau kolom. Anda perlu menggunakan alat komunitas sumber terbuka seperti Editor Tabular untuk menyiapkan OLS.

Keamanan tingkat baris (RLS)

RLS melibatkan pembatasan akses ke subset data dalam tabel. Misalnya, Anda dapat menggunakan RLS untuk memastikan bahwa tenaga penjualan hanya dapat mengakses data penjualan untuk pelanggan di wilayah penjualan mereka.

Untuk titik akhir analitik SQL, Anda dapat mengatur RLS untuk mengontrol akses ke baris dalam tabel pada titik akhir.

Penting

Saat kueri menggunakan tabel apa pun yang memiliki RLS di titik akhir analitik SQL, kueri akan kembali ke mode DirectQuery. Kinerja kueri mungkin lebih lambat.

Untuk model semantik, Anda dapat menyiapkan RLS untuk mengontrol akses ke baris dalam tabel model. RLS dapat disiapkan dalam pengalaman pemodelan web atau dengan menggunakan alat pihak ketiga.

Bagaimana kueri dievaluasi

Alasan untuk mengembangkan model semantik Direct Lake adalah untuk mencapai kueri performa tinggi atas data dalam volume besar di OneLake. Oleh karena itu, Anda harus berusaha untuk merancang solusi yang memaksimalkan kemungkinan kueri yang dilakukan dalam memori.

Langkah-langkah berikut mendekati bagaimana kueri dievaluasi (dan apakah gagal). Manfaat mode penyimpanan Direct Lake hanya dimungkinkan ketika langkah kelima tercapai.

  1. Jika kueri berisi tabel atau kolom apa pun yang dibatasi oleh OLS model semantik, akan mengembalikan pesan kesalahan (tampilan laporan tidak dapat ditampilkan).
  2. Jika kueri berisi kolom apa pun yang dibatasi oleh titik akhir analitik SQL (CLS) (atau jika tabel ditolak), akan mengembalikan hasil galat (visual laporan akan gagal dirender).
    1. Jika koneksi cloud menggunakan SSO (default), CLS ditentukan oleh tingkat akses konsumen laporan.
    2. Jika koneksi cloud menggunakan identitas tetap, CLS ditentukan oleh tingkat akses identitas tetap.
  3. Jika kueri berisi tabel apa pun di titik akhir analitik SQL yang memberlakukan RLS atau tampilan digunakan, kueri akan kembali ke mode DirectQuery.
    1. Jika koneksi cloud menggunakan SSO (default), RLS ditentukan oleh tingkat akses konsumen laporan.
    2. Jika koneksi cloud menggunakan identitas tetap, RLS ditentukan oleh tingkat akses identitas tetap.
  4. Jika kueri melebihi kapasitas pagar pembatas, maka akan beralih kembali ke mode DirectQuery.
  5. Jika tidak, kueri terpenuhi dari cache dalam memori. Data kolom dimuat ke dalam memori saat dan ketika diperlukan.

Izin item sumber

Akun yang digunakan untuk mengakses data adalah salah satu hal berikut.

  • Jika koneksi cloud menggunakan SSO (default), maka dialah yang menjadi konsumen laporan.
  • Jika koneksi cloud menggunakan identitas tetap, itu adalah identitas tetap.

Akun setidaknya harus memiliki izin Read dan ReadData pada item sumber (lakehouse atau gudang). Izin item dapat diwariskan dari peran ruang kerja atau ditetapkan secara eksplisit untuk item seperti yang dijelaskan dalam artikel ini.

Dengan asumsi persyaratan ini terpenuhi, Fabric memberikan akses yang diperlukan ke model semantik untuk membaca tabel Delta dan file Parquet terkait (untuk memuat data kolom ke dalam memori) dan aturan akses data dapat diterapkan.

Opsi aturan akses data

Anda dapat menyiapkan aturan akses data di:

  • Model semantik saja.
  • Titik akhir untuk analitik SQL saja.
  • Pada model semantik dan pada titik akhir analitik SQL.

Aturan dalam model semantik

Jika Anda harus menerapkan aturan akses data, Anda harus melakukannya dalam model semantik kapan pun layak. Itu karena RLS yang diberlakukan oleh model semantik dicapai dengan memfilter cache data dalam memori untuk mencapai kueri performa tinggi.

Ini juga merupakan pendekatan yang cocok ketika para konsumen laporan tidak diberi izin untuk melakukan kueri pada lakehouse atau gudang data.

Dalam kedua kasus, sangat disarankan agar koneksi cloud menggunakan identitas tetap alih-alih SSO. SSO akan menyiratkan bahwa pengguna akhir dapat mengakses titik akhir analitik SQL secara langsung dan karenanya dapat melewati aturan keamanan dalam model semantik.

Penting

Izin item model semantik dapat diatur secara eksplisit melalui aplikasi Power BI , atau diperoleh secara implisit melalui peran ruang kerja.

Perlu dicatat bahwa aturan akses data model semantik tidak diberlakukan untuk pengguna yang memiliki izin Tulis pada model semantik. Sebaliknya, aturan akses data berlaku untuk pengguna yang ditetapkan ke peran ruang kerja Penampil. Namun, pengguna yang ditetapkan ke peran ruang kerja Admin, Anggota, atau Kontributor secara implisit memiliki izin Tulis pada model semantik sehingga aturan akses data tidak diberlakukan. Untuk informasi selengkapnya, lihat Peran di ruang kerja.

Aturan di titik akhir analitik SQL

Sebaiknya terapkan aturan akses data di titik akhir analitik SQL saat model semantik koneksi cloud menggunakan akses menyeluruh (SSO). Itu karena identitas pengguna didelegasikan untuk mengkueri titik akhir analitik SQL, memastikan bahwa kueri hanya mengembalikan data yang diizinkan untuk diakses pengguna. Ini juga sesuai untuk menerapkan aturan akses data pada tingkat ini ketika pengguna akan meminta titik akhir analitik SQL secara langsung untuk beban kerja lain (misalnya, untuk membuat laporan paginasi Power BI, atau mengekspor data).

Namun, terutama, kueri model semantik akan kembali ke mode DirectQuery ketika menyertakan tabel apa pun yang memberlakukan RLS di titik akhir analitik SQL. Akibatnya, model semantik mungkin tidak pernah menyimpan data ke dalam memori untuk mencapai kueri performa tinggi.

Aturan di kedua lapisan

Aturan akses data dapat diberlakukan di kedua lapisan. Namun, pendekatan ini melibatkan kompleksitas ekstra dan overhead manajemen. Dalam hal ini, sangat disarankan agar koneksi cloud menggunakan identitas tetap alih-alih SSO.

Perbandingan opsi aturan akses data

Tabel berikut membandingkan opsi penyiapan akses data.

Menerapkan aturan akses data Komentar
Hanya model semantik Gunakan opsi ini ketika pengguna tidak diberikan izin akses untuk meminta data dari lakehouse atau gudang. Siapkan koneksi cloud untuk menggunakan identitas tetap. Performa kueri tinggi dapat dicapai dari cache dalam memori.
Titik akhir analitik SQL saja Gunakan opsi ini saat pengguna perlu mengakses data dari gudang atau model semantik, dan dengan aturan akses data yang konsisten. Pastikan SSO diaktifkan untuk koneksi cloud. Kinerja kueri mungkin lambat.
Lakehouse atau gudang dan model semantik Opsi ini melibatkan overhead manajemen ekstra. Siapkan koneksi cloud untuk menggunakan identitas tetap.

Berikut adalah praktik yang direkomendasikan terkait penerapan aturan akses data:

  • Jika pengguna yang berbeda harus dibatasi untuk subset data, kapan pun layak, terapkan RLS hanya pada lapisan model semantik. Dengan begitu, pengguna akan mendapat manfaat dari kueri memori berkinerja tinggi. Dalam hal ini, sangat disarankan agar koneksi cloud menggunakan identitas tetap alih-alih SSO.
  • Jika memungkinkan, hindari memberlakukan OLS dan CLS di salah satu lapisan karena menghasilkan kesalahan dalam visual laporan. Kesalahan dapat menyebabkan kebingungan atau kekhawatiran bagi pengguna. Untuk kolom yang dapat dirangkum, pertimbangkan untuk membuat langkah-langkah yang mengembalikan BLANK dalam kondisi tertentu alih-alih CLS (jika memungkinkan).

Dukungan penulisan model dengan titik akhir XMLA

Model semantik Direct Lake mendukung operasi tulis dengan titik akhir XMLA dengan menggunakan alat seperti SQL Server Management Studio (19.1 atau yang lebih baru), dan alat komunitas sumber terbuka.

Tips

Untuk informasi selengkapnya tentang menggunakan alat pihak ketiga untuk mengembangkan, mengelola, atau mengoptimalkan model semantik, lihat skenario penggunaan manajemen model data tingkat lanjut.

Sebelum Anda dapat melakukan operasi tulis, opsi baca-tulis XMLA harus diaktifkan untuk kapabilitas. Untuk informasi selengkapnya, lihat Aktifkan XMLA read-write.

Operasi penulisan model dengan dukungan titik akhir XMLA:

  • Menyesuaikan, menggabungkan, membuat skrip, men-debug, dan menguji metadata model Direct Lake.
  • Kontrol sumber dan versi, integrasi berkelanjutan dan penyebaran berkelanjutan (CI/CD) dengan Azure DevOps dan GitHub. Untuk informasi selengkapnya, lihat Manajemen siklus hidup konten.
  • Tugas otomatisasi seperti refresh model semantik, dan menerapkan perubahan pada model semantik Direct Lake dengan menggunakan PowerShell dan REST API.

Saat mengubah model semantik menggunakan XMLA, Anda harus memperbarui koleksi ChangedProperties dan PBI_RemovedChildren untuk objek yang diubah agar menyertakan properti yang dimodifikasi atau dihapus. Jika Anda tidak melakukan pembaruan tersebut, alat pemodelan Power BI mungkin menimpa perubahan apa pun saat berikutnya skema disinkronkan dengan Lakehouse.

Pelajari lebih lanjut tentang tag silsilah objek model semantik dalam artikel "tag silsilah untuk model semantik Power BI" .

Penting

Tabel Direct Lake yang dibuat dengan menggunakan aplikasi XMLA pada awalnya akan berada dalam status tidak diolah hingga aplikasi mengirim perintah refresh. Kueri yang melibatkan tabel yang tidak diolah akan selalu kembali ke mode DirectQuery. Jadi, saat Anda membuat model semantik baru, pastikan untuk merefresh model untuk memproses tabelnya.

Untuk informasi selengkapnya, lihat Konektivitas model Semantik dengan titik akhir XMLA.

Metadata model Danau Langsung

Saat Anda terhubung ke model semantik Direct Lake dengan titik akhir XMLA, metadata terlihat seperti model lain. Namun, model Direct Lake menunjukkan perbedaan berikut:

  • Properti compatibilityLevel objek database adalah 1604 (atau lebih tinggi).
  • Properti mode partisi Direct Lake diatur ke directLake.
  • Partisi Direct Lake menggunakan ekspresi yang dibagikan untuk menentukan sumber data. Ekspresi menunjuk ke titik akhir analitik SQL dari lakehouse atau gudang data. Direct Lake menggunakan titik akhir analitik SQL untuk menemukan skema dan informasi keamanan, tetapi memuat data langsung dari OneLake (kecuali kembali ke mode DirectQuery karena alasan apa pun).

Tugas pasca-publikasi

Setelah menerbitkan model semantik Direct Lake, Anda harus menyelesaikan beberapa tugas penyiapan. Untuk informasi selengkapnya, lihat Mengelola model semantik Direct Lake.

Fitur yang tidak didukung

Fitur model berikut tidak didukung oleh model semantik Direct Lake:

  • Tabel yang dihitung mengacu pada tabel atau kolom dalam mode penyimpanan Direct Lake
  • Kolom yang dihitung mereferensikan tabel atau kolom dalam mode penyimpanan Direct Lake
  • Tabel hibrid
  • Agregasi yang ditentukan pengguna
  • Model komposit, di mana Anda tidak dapat menggabungkan tabel mode penyimpanan Direct Lake dengan tabel mode penyimpanan DirectQuery atau Dual dalam model yang sama. Namun, Anda dapat menggunakan Power BI Desktop untuk membuat koneksi langsung ke model semantik Direct Lake lalu memperluasnya dengan langkah-langkah baru, dan dari sana Anda dapat mengklik opsi untuk membuat perubahan pada model ini menambahkan tabel baru (menggunakan mode Impor, DirectQuery, atau Penyimpanan ganda). Tindakan ini membuat koneksi DirectQuery ke model semantik dalam mode Direct Lake, sehingga tabel ditampilkan sebagai mode penyimpanan DirectQuery, tetapi mode penyimpanan ini tidak menunjukkan fallback ke DirectQuery. Hanya koneksi antara model baru ini dan model Direct Lake yang menggunakan DirectQuery, sementara kueri tetap menggunakan Direct Lake untuk mendapatkan data dari OneLake. Untuk informasi selengkapnya, lihat Membangun model komposit pada model semantik.
  • Kolom berdasarkan kolom titik akhir analitik SQL yang menerapkan masking data dinamis.

Konten terkait