Aracılığıyla paylaş

Direct Lake semantik modelleri geliştirme

  • Makale

Bu makalede Direct Lake semantik modelleri geliştirmeyle ilgili tasarım konuları açıklanmaktadır.

Modeli oluşturma

Çalışma alanında Direct Lake anlam modeli oluşturmak için Fabric portalını kullanırsınız. Tek bir göl evinden veya ambardan semantik modele eklenecek tabloları seçmeyi içeren basit bir işlemdir.

Ardından anlam modelini daha da geliştirmek için web modelleme deneyimi kullanabilirsiniz. Bu deneyim tablolar arasında ilişkiler oluşturmanıza, ölçüler ve hesaplama grupları oluşturmanıza, tarih tablolarını işaretlemenize ve model ile nesneleri (sütun biçimleri gibi) için özellikler ayarlamanıza olanak tanır. Ayrıca rolleri ve kuralları tanımlayarak ve bu rollere üye ekleyerek (Microsoft Entra kullanıcı hesapları veya güvenlik grupları) satır düzeyi güvenlik (RLS) model ayarlayabilirsiniz.

Alternatif olarak, SQL Server Management Studio (SSMS) (sürüm 19.1 veya üzeri) veya açık kaynak, topluluk araçları gibi XMLA uyumlu bir araç kullanarak modelinizin geliştirmeye devam edebilirsiniz. Daha fazla bilgi için bu makalenin devamında XMLA uç noktası ile model yazma desteği konusuna bakın.

Bahşiş

Bu kılavuzu tamamlayarak bir lakehouse, bir Delta tablosu ve temel bir Direct Lake semantik modeli oluşturmayıöğrenebilirsiniz.

Model tabloları

Model tabloları bir tabloyu veya SQL analiz uç noktasının görünümünü temel alır. Ancak, mümkün olduğunca görünümleri kullanmaktan kaçının. Bunun nedeni, bir görünüme dayalı model tablosuna yapılan sorguların her zamanDirectQuery moduna geri dönmesidir ve bu da sorgu performansının düşmesine neden olabilir.

Tablolar, model ilişkilerini destekleyen sütunlara ek olarak filtreleme, gruplandırma, sıralama ve özetleme için sütunlar içermelidir. Gereksiz sütunlar semantik model sorgu performansını etkilemez (belleğe yüklenmedikleri için), OneLake'te daha büyük bir depolama boyutuna neden olur ve yüklenip bakımını yapmak için daha fazla işlem kaynağı gerektirir.

Uyarı

Direct Lake anlam modellerinde dinamik veri maskeleme (DDM) uygulayan sütunların kullanılması desteklenmez.

Direct Lake semantik modelinize eklenecek tabloları seçmeyi öğrenmek için bkz. Direct Lake anlam modelleri için tabloları düzenleme.

Anlam modeli tablolarınıza eklenecek sütunlar hakkında daha fazla bilgi için bkz. Direct Lake anlam modelleri için depolamayı anlama.

Veri erişim kurallarını zorunlu kılma

Farklı kullanıcılara model verilerinin alt kümelerini teslim etme gereksinimleriniz olduğunda, veri erişim kurallarını zorunlu kılabilirsiniz. SQL analiz uç noktası veya anlamsal modelde nesne düzeyi güvenlik (OLS) ve/veya satır düzeyi güvenlik (RLS) ayarlayarak kuralları zorunlu kılarsınız.

Not

veri erişim kurallarını zorlama konusu, içerik tüketicileri, oluşturucular ve anlam modelini (ve ilgili Doku öğelerini) yönetecek kullanıcılar için izinleri ayarlamayla ilgilidir. İzinleri ayarlama hakkında daha fazla bilgi için bkz. Direct Lake anlam modellerini yönetme.

Nesne düzeyinde güvenlik (OLS)

OLS, nesneleri veya sütunları bulma ve sorgulama erişimini kısıtlamayı içerir. Örneğin, Employee tablosundan Salary sütununa erişebilecek kullanıcıları sınırlamak için OLS kullanabilirsiniz.

SQL analiz uç noktası için, uç nokta nesnelerine erişimi denetlemekiçin OLS'yi ayarlayabilirsiniz; örneğin tablolar veya görünümler ve sütun düzeyinde güvenlik (CLS) uç nokta tablosu sütunlarına erişimi denetlemek.

Anlamsal model için, model tablolarına veya sütunlarına erişimi denetlemekiçin OLS'yi ayarlayabilirsiniz. OLS'yi ayarlamak için Tablosal Düzenleyici gibi açık kaynak topluluk araçlarını kullanmanız gerekir.

Satır düzeyi güvenlik (RLS)

RLS, tablolardaki veri alt kümelerine erişimi kısıtlamayı içerir. Örneğin, satış temsilcilerinin yalnızca kendi satış bölgesindeki müşterilerin satış verilerine erişebildiğinden emin olmak için RLS kullanabilirsiniz.

SQL analiz uç noktası için RLS'yi uç nokta tablosundaki satırlara erişimi denetlemek için ayarlayabilirsiniz.

Önemli

Sorgu, SQL analiz uç noktasında RLS içeren herhangi bir tabloyu kullandığında DirectQuery moduna geri döner. Sorgu performansı daha yavaş olabilir.

Anlamsal model için, RLS'yi model tablolarındaki satırlara erişimi denetlemekiçin ayarlayabilirsiniz. RLS, web modelleme deneyiminde veya üçüncü taraf bir araç kullanılarak ayarlanabilir.

Sorgular nasıl değerlendirilir?

Direct Lake anlam modelleri geliştirmenin nedeni, OneLake'te büyük hacimli veriler üzerinde yüksek performanslı sorgular elde etmektir. Bu nedenle, bellek içi sorgulama olasılığını en üst düzeye çıkaran bir çözüm tasarlamaya çalışmanız gerekir.

Aşağıdaki adımlar sorguların nasıl değerlendirildiğini (ve başarısız olup olmadıklarını) yaklaşık olarak açıklar. Direct Lake depolama modunun avantajları yalnızca beşinci adım elde edildiğinde mümkündür.

  1. Sorgu semantik model OLS ile kısıtlanmış bir tablo veya sütun içeriyorsa, bir hata sonucu döndürülür (rapor görseli işlenemez).
  2. Sorgu, SQL analytics uç noktası CLS ile kısıtlanmış bir sütun içeriyorsa (veya tablo reddedildiyse), bir hata sonucu döndürülür (rapor görseli işlenemez).
    1. Bulut bağlantısı SSO (varsayılan) kullanıyorsa CLS, rapor tüketicisinin erişim düzeyine göre belirlenir.
    2. Bulut bağlantısı sabit bir kimlik kullanıyorsa CLS, sabit kimliğin erişim düzeyine göre belirlenir.
  3. Sorgu, SQL analiz uç noktasında RLS'yi zorlayan bir tablo içeriyorsa veya bir görünüm kullanılıyorsa, sorgu DirectQuery moduna geri döner.
    1. Bulut bağlantısı SSO (varsayılan) kullanıyorsa, RLS rapor tüketicisinin erişim düzeyine göre belirlenir.
    2. Bulut bağlantısı sabit bir kimlik kullanıyorsa RLS, sabit kimliğin erişim düzeyine göre belirlenir.
  4. Sorgu kapasite sınırlarını aşarsa DirectQuery moduna geçer.
  5. Aksi takdirde, sorgu bellek içi önbellekten karşılanır. Sütun verileri gerektiğinde bellek yüklenir.

Kaynak öğe izinleri

Verilere erişmek için kullanılan hesap aşağıdakilerden biridir.

  • Bulut bağlantısı SSO kullanıyorsa (varsayılan), rapor tüketicisi olur.
  • Bulut bağlantısı sabit bir kimlik kullanıyorsa, bu sabit kimliktir.

Hesabın kaynak öğede (lakehouse veya ambar) Okuma ve ReadData izinlerine sahip olması gerekir. Öğe izinleri çalışma alanı rollerinden devralınabilir veya bu makale açıklandığı gibi öğe için açıkça atanabilir.

Bu gereksinimin karşılandığı varsayıldığında, Fabric gerekli erişimi sağlayarak semantik modelin Delta tablolarını ve ilişkili Parquet dosyalarını okumasına izin verir. Bu, sütun verilerini belleğe yüklemek ve veri erişim kurallarının uygulanması için gereklidir.

Veri erişimi kuralı seçenekleri

Veri erişim kurallarını şu şekilde ayarlayabilirsiniz:

  • Yalnızca anlamsal model.
  • Yalnızca SQL analiz uç noktası.
  • Hem anlamsal modelde hem de SQL analiz uç noktasında.

Anlamsal modeldeki kurallar

Veri erişim kurallarını zorunlu kılmanız gerekiyorsa, uygun olduğunda bunu anlamsal modelde yapmanız gerekir. Bunun nedeni, semantik model tarafından zorlanan RLS'nin yüksek performanslı sorgular elde etmek için verilerin bellek içi önbelleğini filtreleyerek gerçekleştirilmiş olmasıdır.

Ayrıca, rapor tüketicilerine göl evi veya ambarı sorgulama izni verilmediğinde de uygun bir yaklaşımdır.

Her iki durumda da bulut bağlantısının SSO yerine sabit bir kimlik kullanması kesinlikle önerilir. SSO, son kullanıcıların SQL analiz uç noktasına doğrudan erişebildiğini ve bu nedenle anlam modelindeki güvenlik kurallarını atlayabileceğini gösterir.

Önemli

Anlamsal model öğesi izinleri, Power BI uygulamalarıaracılığıyla açıkça veya çalışma alanı rolleri aracılığıyla örtük olarak ayarlanabilir.

Özellikle, semantik model üzerinde yazma iznine sahip kullanıcılar için veri erişim kuralları uygulanmaz. Buna karşılık, veri erişim kuralları Görüntüleyicisi çalışma alanı rolüne atanan kullanıcılar için geçerlidir. Ancak, Yöneticisi, Üyeveya Katkıda Bulunan çalışma alanı rolüne atanan kullanıcılar, anlam modeli üzerinde örtük olarak Yazma iznine sahiptir ve bu nedenle veri erişimi kuralları uygulanmaz. Daha fazla bilgi için bkz. çalışma alanlarındaki roller.

SQL analiz uç noktasındaki kurallar

Anlam modeli bulut bağlantısıçoklu oturum açma (SSO) kullandığında SQL analiz uç noktasında veri erişim kurallarını zorunlu kılmak uygundur. Bunun nedeni, kullanıcının kimliğinin SQL analytics uç noktasını sorgulamak üzere temsilci olarak atanarak sorguların yalnızca kullanıcının erişmesine izin verilen verileri döndürmesini sağlamasıdır. Kullanıcılar sql analizi uç noktasını doğrudan diğer iş yükleri için sorguladığında (örneğin, Power BI sayfalandırılmış raporu oluşturmak veya verileri dışarı aktarmak için) bu düzeyde veri erişim kurallarını zorunlu kılmak da uygundur.

Özellikle de, semantik model sorgusu, SQL analiz uç noktasında RLS'yi zorlayan herhangi bir tablo içerdiğinde DirectQuery moduna geri döner. Sonuç olarak, semantik model yüksek performanslı sorgular elde etmek için verileri hiçbir zaman belleğe önbelleğe almayabilir.

Her iki katmandaki kurallar

Veri erişim kuralları her iki katmanda da zorunlu kılınabilir. Ancak bu yaklaşım, ek karmaşıklık ve yönetim yükü içerir. Bu durumda bulut bağlantısının SSO yerine sabit bir kimlik kullanması kesinlikle önerilir.

Veri erişim kuralı seçeneklerinin karşılaştırması

Aşağıdaki tabloda veri veri erişimi kurulum seçenekleri karşılaştırlenmiştir.

Veri erişim kurallarını uygulama Yorum
Yalnızca anlamsal model Kullanıcılara göl evi veya ambarı sorgulamak için öğe izinleri verilmediğinde bu seçeneği kullanın. Bulut bağlantısını sabit bir kimlik kullanacak şekilde ayarlayın. Bellek içi önbellekten yüksek sorgu performansı elde edilebilir.
Yalnızca SQL analitik uç noktası Kullanıcıların ambardan veya anlamsal modelden ve tutarlı veri erişim kurallarıyla verilere erişmesi gerektiğinde bu seçeneği kullanın. Bulut bağlantısı için SSO'nun etkinleştirildiğinden emin olun. Sorgu performansı yavaş olabilir.
Lakehouse veya depo ve anlamsal modeli Bu seçenek ek yönetim yükü içerir. Bulut bağlantısını sabit bir kimlik kullanacak şekilde ayarlayın.

Veri erişim kurallarını zorunlu tutmayla ilgili önerilen uygulamalar şunlardır:

  • Farklı kullanıcıların veri alt kümeleriyle sınırlandırılması gerekiyorsa, uygun olduğunda RLS'yi yalnızca anlamsal model katmanında zorunlu kılın. Bu şekilde kullanıcılar yüksek performanslı bellek içi sorgulardan yararlanacaktır. Bu durumda bulut bağlantısının SSO yerine sabit bir kimlik kullanması kesinlikle önerilir.
  • Mümkünse, rapor görsellerinde hatalara neden olduğundan OLS ve CLS'yi her iki katmanda da zorlamaktan kaçının. Hatalar, kullanıcılar için karışıklığa veya endişeye yol açabilir. Özetlenebilir sütunlar için CLS (mümkünse) yerine belirli koşullarda BLANK döndüren ölçüler oluşturmayı göz önünde bulundurun.

XMLA uç noktası ile model yazma desteği

Direct Lake anlam modelleri, SSMS (19.1 veya üzeri) ve açık kaynak topluluk araçları gibi araçları kullanarak XMLA uç noktasıyla yazma işlemlerini destekler.

Bahşiş

Anlamsal modelleri geliştirmek, yönetmek veya iyileştirmek için üçüncü taraf araçları kullanma hakkında daha fazla bilgi için bkz. gelişmiş veri modeli yönetimi kullanım senaryosu.

Yazma işlemlerini gerçekleştirebilmeniz için kapasite için XMLA okuma-yazma seçeneğinin etkinleştirilmesi gerekir. Daha fazla bilgi için bkz. XMLA okuma-yazma erişimini etkinleştirme.

XMLA uç noktası desteğiyle model yazma işlemleri:

  • Direct Lake modeli meta verilerini özelleştirme, birleştirme, betik oluşturma, hata ayıklama ve test etme.
  • Azure DevOps ve GitHub ile kaynak ve sürüm denetimi, sürekli tümleştirme ve sürekli dağıtım (CI/CD). Daha fazla bilgi için bkz. İçerik yaşam döngüsü yönetimi .
  • Anlamsal model yenileme ve PowerShell ve REST API'lerini kullanarak Direct Lake anlam modellerine değişiklik uygulama gibi otomasyon görevleri.

XMLA kullanarak bir anlam modelini değiştirirken, değiştirilen nesnenin değiştirilmiş veya kaldırılmış özellikleri içerecek şekilde ChangedProperties ve PBI_RemovedChildren koleksiyonunu güncelleştirmeniz gerekir. Bu güncelleştirmeyi gerçekleştirmezseniz, şema Lakehouse ile bir sonraki eşitlendiğinde Power BI modelleme araçları yaptığınız değişikliklerin üzerine yazabilir.

Power BI anlam modelleri için köken etiketleri makalesinde anlam modeli nesne kökeni etiketleri hakkında daha fazla bilgi edinin.

Önemli

XMLA uygulamaları kullanılarak oluşturulan Direct Lake tabloları, uygulama bir yenileme komutu gönderene kadar başlangıçta işlenmemiş durumda olur. İşlenmemiş tablolar içeren sorgular her zaman DirectQuery moduna geri döner. Bu nedenle, yeni bir anlam modeli oluşturduğunuzda, tabloyu işlemek için modeli yenilediğinizden emin olun.

Daha fazla bilgi için bkz. XMLA uç noktasıyla anlam modeli bağlantısı.

Direct Lake model meta verileri

XMLA uç noktasıyla bir Direct Lake anlam modeline bağlandığınızda, meta veriler diğer tüm modellerde olduğu gibi görünür. Ancak, Direct Lake modelleri aşağıdaki farklılıkları gösterir:

  • Veritabanı nesnesinin compatibilityLevel özelliği 1604 (veya üzeridir).
  • Direct Lake bölümlerinin mode özelliği directLakeolarak ayarlanır.
  • Direct Lake bölümleri, veri kaynaklarını tanımlamak için paylaşılan ifadeler kullanır. İfade, göl evi veya ambarın SQL analiz uç noktasını gösterir. Direct Lake şema ve güvenlik bilgilerini bulmak için SQL analiz uç noktasını kullanır, ancak verileri doğrudan OneLake'ten yükler (herhangi bir nedenle DirectQuery moduna geri dönmediği sürece)

Yayın sonrası görevler

Direct Lake anlam modelini yayımladıktan sonra bazı kurulum görevlerini tamamlamanız gerekir. Daha fazla bilgi için bkz. Direct Lake anlam modellerini yönetme.

Desteklenmeyen özellikler

Aşağıdaki model özellikleri Direct Lake anlam modelleri tarafından desteklenmez:

  • Direct Lake depolama modunda tablolara veya sütunlara başvuran hesaplanan tablolar
  • Direct Lake depolama modunda tablolara veya sütunlara başvuran hesaplanmış sütunlar
  • Hibrit tablolar
  • Kullanıcı tanımlı toplamalar
  • Bileşik modeller, direct Lake depolama modu tablolarını aynı modeldeDirectQuery veya İkili depolama modu tablolarıyla birleştiremezsiniz. Ancak, Power BI Desktop'ı kullanarak Direct Lake anlam modeline canlı bağlantı oluşturabilir ve ardından bunu yeni ölçülerle genişletebilir ve buradan bu modelde değişiklik yeni tablolar ekleme seçeneğine tıklayabilirsiniz (İçeri Aktarma, DirectQuery veya İkili depolama modunu kullanarak). Bu eylem, Direct Lake modunda anlam modeline bir DirectQuery bağlantısı oluşturur, bu nedenle tablolar DirectQuery depolama modu olarak gösterilir, ancak bu depolama modu DirectQuery'ye geri dönüşü göstermez. Yalnızca bu yeni model ile Direct Lake modeli arasındaki bağlantı DirectQuery'dir ve sorgular Yine de OneLake'ten veri almak için Direct Lake'i kullanır. Daha fazla bilgi için bkz. Anlamsal model üzerinde bileşik model oluşturma.
  • Dinamik veri maskeleme uygulayan SQL analiz uç noktası sütunlarını temel alan sütunlar.

İlgili içerik