Aracılığıyla paylaş


Direct Lake

Direct Lake modu, Power BI'da çok büyük veri hacimlerini analiz etmek için kullanılan anlamsal bir model özelliğidir. Direct Lake, bir göl evi veya ambar uç noktasını sorgulamak zorunda kalmadan ve verileri Power BI modeline içeri aktarmak veya çoğaltmak zorunda kalmadan parquet biçimli dosyaları doğrudan bir veri gölünden yüklemeyi temel alır. Direct Lake, göldeki verileri doğrudan Power BI altyapısına yüklemek için analize hazır hızlı bir yoldur. Aşağıdaki diyagramda klasik içeri aktarma ve DirectQuery modlarının Direct Lake moduyla karşılaştırması gösterilmektedir.

Direct Lake özelliklerinin diyagramı.

DirectQuery modunda, Power BI altyapısı verileri kaynaktaki sorgular; bu da yavaş olabilir ancak içeri aktarma modu gibi verileri kopyalamak zorunda kalmamasını sağlar. Veri kaynağındaki tüm değişiklikler sorgu sonuçlarına hemen yansıtılır.

Öte yandan içeri aktarma modunda veriler, SQL veya diğer sorgu türlerini veri kaynağına çevirip geçirmek zorunda kalmadan DAX ve MDX rapor sorguları için önbelleğe alınıp iyileştirildiğinden performans daha iyi olabilir. Ancak Power BI altyapısının yenileme sırasında yeni verileri modele kopyalaması gerekir. Kaynakta yapılan tüm değişiklikler yalnızca sonraki model yenilemesiyle alınır.

Direct Lake modu, verileri doğrudan OneLake'ten yükleyerek içeri aktarma gereksinimini ortadan kaldırır. DirectQuery'den farklı olarak, DAX veya MDX'ten diğer sorgu dillerine veya diğer veritabanı sistemlerinde sorgu yürütmeye yönelik çeviri yoktur ve içeri aktarma moduna benzer bir performans elde edilir. Açık içeri aktarma işlemi olmadığından, veri kaynağında gerçekleşen değişiklikleri almak mümkündür ve dezavantajlarını önlerken hem DirectQuery hem de içeri aktarma modlarının avantajlarını birleştirir. Direct Lake modu, veri kaynağında sık sık güncelleştirmeler yapılan çok büyük modelleri ve modelleri analiz etmek için ideal bir seçim olabilir.

Direct Lake ayrıca satır düzeyi güvenliği ve nesne düzeyinde güvenliği de destekler, bu nedenle kullanıcılar yalnızca görme iznine sahip oldukları verileri görür.

Önkoşullar

Direct Lake yalnızca Microsoft Premium (P) SKU'larında ve Microsoft Fabric (F) SKU'larında desteklenir.

Önemli

Yeni müşteriler için Direct Lake yalnızca Microsoft Fabric (F) SKU'larında desteklenir. Mevcut müşteriler Direct Lake'i Premium (P) SKU'larla kullanmaya devam edebilir, ancak Doku kapasitesi SKU'su'na geçiş önerilir. Power BI Premium lisanslama hakkında daha fazla bilgi için bkz. lisanslama duyurusu.

Göl evi

Direct Lake'i kullanmadan önce, desteklenen bir Microsoft Fabric kapasitesinde barındırılan bir çalışma alanında bir veya daha fazla Delta tablosu içeren bir lakehouse (veya ambar) sağlamanız gerekir. Lakehouse gereklidir çünkü OneLake'te parke biçimli dosyalarınız için depolama konumu sağlar. Lakehouse ayrıca Bir Direct Lake modeli oluşturmak için Web modelleme özelliğini başlatmak için bir erişim noktası sağlar.

Bir göl evi sağlamayı, göl evinde delta tablosu oluşturmayı ve göl evi için temel bir model oluşturmayı öğrenmek için bkz . Direct Lake için göl evi oluşturma.

SQL uç noktası

Göl evi sağlamanın bir parçası olarak, SQL sorgulaması için bir SQL uç noktası ve raporlama için varsayılan bir model oluşturulur ve lakehouse'a eklenen tablolarla güncelleştirilir. Direct Lake modu, verileri doğrudan OneLake'ten yüklerken SQL uç noktasını sorgulamasa da, direct Lake modelinin DirectQuery moduna sorunsuz bir şekilde geri dönmesi gerektiğinde (örneğin, veri kaynağı gelişmiş güvenlik veya Direct Lake üzerinden okunmayan görünümler gibi belirli özellikleri kullandığında) gereklidir. Direct Lake modu ayrıca şema ve güvenlikle ilgili bilgiler için SQL uç noktasını sorgular.

Data Warehouse

SQL uç noktası olan bir lakehouse'a alternatif olarak, SQL deyimlerini veya veri işlem hatlarını kullanarak bir ambar sağlayabilir ve tablolar ekleyebilirsiniz. Tek başına veri ambarı sağlama yordamı, göl evi yordamıyla neredeyse aynıdır.

XMLA uç noktası ile model yazma desteği

Direct Lake modelleri, SQL Server Management Studio (19.1 ve üzeri) gibi araçları ve Tablosal Düzenleyici ve DAX studio gibi dış BI araçlarının en son sürümlerini kullanarak XMLA uç noktası üzerinden yazma işlemlerini destekler. XMLA uç noktası desteği aracılığıyla 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).

  • PowerShell ve REST API'lerini kullanarak Direct Lake modellerinde yenileme ve değişiklik uygulama gibi otomasyon görevleri.

XMLA uygulamaları kullanılarak oluşturulan Direct Lake tabloları, uygulama bir yenileme komutu oluşturana kadar başlangıçta işlenmemiş durumda olur. İşlenmemiş tablolar DirectQuery moduna geri döner. Yeni bir anlam modeli oluştururken, tablolarınızı işlemek için anlam modelinizi yenilediğinizden emin olun.

XMLA okuma-yazmayı etkinleştirme

XMLA uç noktası aracılığıyla Direct Lake modellerinde yazma işlemleri gerçekleştirmeden önce kapasite için XMLA okuma-yazma etkinleştirilmelidir.

Doku deneme kapasiteleri için, deneme kullanıcısı XMLA okuma-yazmayı etkinleştirmek için gereken yönetici ayrıcalıklarına sahiptir.

  1. Yönetici portalında Kapasite ayarları'nı seçin.

  2. Deneme sekmesini seçin.

  3. Deneme sürümünü içeren kapasiteyi ve kapasite adında kullanıcı adınızı seçin.

  4. Power BI iş yüklerini genişletin ve XMLA Uç Noktası ayarında Okuma Yazma'yı seçin.

    Doku deneme kapasitesi için XMLA Uç Noktası okuma-yazma ayarının ekran görüntüsü.

XMLA Uç Noktası ayarının kapasiteye atanan tüm çalışma alanları ve modeller için geçerli olduğunu unutmayın.

Direct Lake model meta verileri

XMLA uç noktası aracılığıyla tek başına bir Direct Lake modeline bağlanırken meta veriler diğer modellere benzer. Ancak, Direct Lake modelleri aşağıdaki farklılıkları gösterir:

  • compatibilityLevel Veritabanı nesnesinin özelliği 1604 veya üzeridir.

  • Mode Direct Lake bölümlerinin özelliği olarak directLakeayarlanır.

  • Direct Lake bölümleri, veri kaynaklarını tanımlamak için paylaşılan ifadeler kullanır. İfade, bir göl evi veya ambarın SQL uç noktasını gösterir. Direct Lake, şema ve güvenlik bilgilerini bulmak için SQL uç noktasını kullanır ancak verileri doğrudan Delta tablolarından yükler (Direct Lake'in herhangi bir nedenle DirectQuery moduna geri dönmesi gerekmediği sürece).

SSMS'de örnek bir XMLA sorgusu aşağıda verilmiştir:

SSMS'de XMLA sorgusu ekran görüntüsü.

XMLA uç noktası aracılığıyla araç desteği hakkında daha fazla bilgi edinmek için bkz . XMLA uç noktasıyla anlam modeli bağlantısı.

Geri dönüş

Direct Lake modundaki Power BI anlam modelleri, Delta tablolarını doğrudan OneLake'ten okur. Ancak Direct Lake modelindeki bir DAX sorgusu SKU sınırlarını aşarsa veya bir ambardaki SQL görünümleri gibi Direct Lake modunu desteklemeyen özellikler kullanırsa sorgu DirectQuery moduna geri dönebilir. DirectQuery modunda sorgular, lakehouse veya ambarın SQL uç noktasından sonuçları almak için SQL kullanır ve bu da sorgu performansını etkileyebilir. DAX sorgularını yalnızca saf Direct Lake modunda işlemek istiyorsanız DirectQuery moduna geri dönüşü devre dışı bırakabilirsiniz. DirectQuery'ye geri dönmenize gerek yoksa geri dönüşü devre dışı bırakmanız önerilir. Direct Lake modeli için sorgu işlemeyi analiz ederek geri dönüşlerin olup olmadığını ve ne sıklıkta gerçekleştiğini belirlemek de yararlı olabilir. DirectQuery modu hakkında daha fazla bilgi edinmek için bkz . Power BI'da anlam modeli modları.

Korumalar, DaX sorgularını işlemek için DirectQuery moduna geri dönmenin gerekli olduğu Direct Lake modu için kaynak sınırlarını tanımlar. Delta tablosu için parquet dosyalarının ve satır gruplarının sayısını belirleme hakkında ayrıntılı bilgi için Delta tablosu özellikleri başvurusuna bakın.

Direct Lake semantik modellerinde Maksimum Bellek, ne kadar verinin disk belleğine alınabileceğine ilişkin üst bellek kaynak sınırını temsil eder. Aslında, bu bir koruma alanı değildir çünkü aşılması DirectQuery'ye geri dönüşe neden olmaz; ancak, veri miktarı OneLake verilerinden model verilerinin sayfalama ve dışarısına neden olacak kadar büyükse performansı etkileyebilir.

Aşağıdaki tabloda hem kaynak korumaları hem de En Fazla Bellek listelenir:

Doku SKU'ları Tablo başına parquet dosyaları Tablo başına satır grupları Tablo başına satır sayısı (milyon) Diskte maksimum model boyutu/OneLake1 (GB) Maksimum bellek (GB)
F2 1,000 1,000 300 10 3
F4 1,000 1,000 300 10 3
F8 1,000 1,000 300 10 3
F16 1,000 1,000 300 20 5
F32 1,000 1,000 300 40 10
F64/FT1/P1 5.000 5.000 1.500 Sınırsız 25
F128/P2 5.000 5.000 3.000 Sınırsız 50
F256/P3 5.000 5.000 6.000 Sınırsız 100
F512/P4 Kategori 10,000 10,000 12,000 Sınırsız 200
F1024/P5 Kategori 10,000 Kategori 10,000 24,000 Sınırsız 400
F2048 Kategori 10,000 Kategori 10,000 24,000 Sınırsız 400

1 - Aşılırsa, disk/Onelake üzerindeki maksimum model boyutu, sorgu başına değerlendirilen diğer korumalardan farklı olarak modeldeki tüm sorguların DirectQuery'ye geri dönmesine neden olur.

Doku SKU'nuza bağlı olarak, Direct Lake modelleri için ek Kapasite birimi ve Sorgu başına maksimum bellek sınırları da geçerlidir. Daha fazla bilgi edinmek için bkz . Kapasiteler ve SKU'lar.

Geri dönüş davranışı

Direct Lake modelleri, üç seçeneği olan DirectLakeBehavior özelliğini içerir:

Otomatik - (Varsayılan) Veriler belleğe verimli bir şekilde yüklenmiyorsa sorguların DirectQuery moduna geri döneceğini belirtir.

DirectLakeOnly - Yalnızca Direct Lake modunu kullanan tüm sorguları belirtir. DirectQuery moduna geri dönüş devre dışı bırakıldı. Veriler belleğe yüklenemiyorsa bir hata döndürülür. DAX sorgularının belleğe veri yükleyemediğini ve hata döndürülmeye zorladığını belirlemek için bu ayarı kullanın.

DirectQueryOnly - Yalnızca DirectQuery modunu kullanan tüm sorguları belirtir. Geri dönüş performansını test etmek için bu ayarı kullanın.

DirectLakeBehavior özelliği, Tablosal Nesne Modeli (TOM) veya Tablosal Model Betik Dili (TMSL) kullanılarak yapılandırılabilir.

Aşağıdaki örnek, tüm sorguların yalnızca Direct Lake modunu kullandığını belirtir:

// Disable fallback to DirectQuery mode.
//
database.Model.DirectLakeBehavior = DirectLakeBehavior.DirectLakeOnly = 1;
database.Model.SaveChanges();

Sorgu işlemeyi analiz etme

Bir rapor görselinin veri kaynağına yönelik DAX sorgularının Direct Lake modunu kullanarak veya DirectQuery moduna geri dönerek en iyi performansı sağladığını belirlemek için, sorguları analiz etmek için Power BI Desktop'ta, SQL Server Profiler'da veya diğer üçüncü taraf araçlarda Performans çözümleyicisini kullanabilirsiniz. Daha fazla bilgi edinmek için bkz . Direct Lake modelleri için sorgu işlemeyi analiz etme.

Yenile

Varsayılan olarak, OneLake'teki veri değişiklikleri otomatik olarak bir Direct Lake modeline yansıtılır. Modelin ayarlarında Direct Lake verilerinizi güncel tutun seçeneğini devre dışı bırakarak bu davranışı değiştirebilirsiniz.

Model ayarlarında Direct Lake yenileme seçeneğinin ekran görüntüsü.

Örneğin, yeni verileri modelin tüketicilerine ifşa etmeden önce veri hazırlama işlerinin tamamlanmasına izin vermeniz gerekiyorsa devre dışı bırakmak isteyebilirsiniz. Devre dışı bırakıldığında yenilemeyi el ile veya yenileme API'lerini kullanarak çağırabilirsiniz. Direct Lake modeli için yenileme çağırma, modelin Delta Lake tablosunun en son sürümünün meta verilerini analiz ettiği ve OneLake'deki en son dosyalara başvuracak şekilde güncelleştirildiği düşük maliyetli bir işlemdir.

Yenileme sırasında kurtarılamaz bir hatayla karşılaşılırsa Power BI'ın Direct Lake tablolarının otomatik güncelleştirmelerini duraklatabileceğini unutmayın, bu nedenle anlamsal modelinizin başarıyla yenilenebileceğinden emin olun. Kullanıcı tarafından çağrılan sonraki yenileme hatasız tamamlandığında Power BI otomatik güncelleştirmeleri otomatik olarak sürdürür.

Çoklu oturum açma (SSO) varsayılan olarak etkinleştirildi

Varsayılan olarak Direct Lake modelleri , Fabric Lakehouse ve Warehouse veri kaynaklarına erişmek ve modelle şu anda etkileşimde olan kullanıcının kimliğini kullanmak için Microsoft Entra Çoklu Oturum Açma'yı (SSO) kullanır. Aşağıdaki ekran görüntüsünde gösterilen Ağ Geçidi ve bulut bağlantıları bölümünü genişleterek Direct Lake model ayarlarında yapılandırmayı de kontrol edebilirsiniz. Direct Lake modeli, Lakehouse veya Warehouse'a doğrudan erişilebildiği için açık bir veri bağlantısı gerektirmez ve SSO, depolanan bağlantı kimlik bilgileri gereksinimini ortadan kaldırır.

Ağ geçidi ve bulut bağlantıları yapılandırma ayarlarının ekran görüntüsü.

Ayrıca, depolanan kimlik bilgilerini kullanmak istediğiniz durumlarda Lakehouse veya Warehouse veri kaynağını paylaşılabilir bir bulut bağlantısına (SCC) açıkça bağlayabilir ve böylece söz konusu veri kaynağı bağlantısı için SSO'nun devre dışı bırakılmasını sağlayabilirsiniz. Veri kaynağını açıkça bağlamak için Ağ geçidi ve bulut bağlantıları bölümündeki Haritalar için: liste kutusundaN SCC'yi seçin. Ayrıca, Bağlantı oluştur'u seçip bağlantı adı sağlama adımlarını izleyerek de yeni bir bağlantı oluşturabilirsiniz. Ardından, yeni bağlantının kimlik doğrulama yöntemi olarak OAuth 2.0'ı seçin, istenen kimlik bilgilerini girin ve Çoklu oturum açma onay kutusunu temizleyin, ardından Lakehouse veya Warehouse veri kaynağını yeni oluşturduğunuz yeni SCC bağlantısına bağlayın.

Varsayılan: Çoklu Oturum Açma (Entra Id) bağlantı yapılandırması Direct Lake modeli yapılandırmasını basitleştirir, ancak Lakehouse veya Warehouse veri kaynağına kişisel bir bulut bağlantınız (PCC) varsa, Direct Lake modeli eşleşen PCC'ye otomatik olarak bağlanır ve böylece veri kaynağı için önceden tanımladığınız bağlantı ayarları hemen uygulanır. Modellerin Doku veri kaynaklarına doğru ayarlarla erişmesini sağlamak için Direct Lake modellerinizin bağlantı yapılandırmasını onaylamanız gerekir.

Anlamsal modeller Direct Lake, Import ve DirectQuery modundaki Fabric Lakehouses ve Warehouse'lar için Varsayılan: Çoklu Oturum Açma (Entra Id) bağlantı yapılandırmasını kullanabilir. Diğer tüm veri kaynakları açıkça tanımlanmış veri bağlantıları gerektirir.

Katmanlı veri erişim güvenliği

Göl evleri ve ambarlar üzerinde oluşturulan Direct Lake modelleri, verilere erişmeye çalışan kimliğin gerekli veri erişim izinlerine sahip olup olmadığını belirlemek için T-SQL Uç Noktası üzerinden izin denetimleri gerçekleştirerek lakehouse'ların ve ambarların desteklediği katmanlı güvenlik modeline bağlıdır. Varsayılan olarak, Direct Lake modelleri çoklu oturum açma (SSO) kullanır, bu nedenle etkileşimli kullanıcının etkin izinleri kullanıcının verilere erişimine izin verilip verilmediğini belirler. Direct Lake modeli sabit bir kimlik kullanacak şekilde yapılandırılmışsa, sabit kimliğin etkin izni, anlam modeliyle etkileşim kuran kullanıcıların verilere erişip erişemediğini belirler. T-SQL Uç Noktası, OneLake güvenlik ve SQL izinlerinin birleşimine göre Direct Lake modeline İzin Verildi veya Reddedildi değerini döndürür.

Örneğin, bir ambar yöneticisi, kullanıcının OneLake güvenlik izinleri olmasa bile bu tablodan okuyabilmesi için bir kullanıcıya tablo üzerinde SELECT izinleri verebilir. Kullanıcı göl evi/depo düzeyinde yetkilendirilmişti. Buna karşılık, bir ambar yöneticisi de kullanıcının tabloya okuma erişimini reddedebilir. Daha sonra kullanıcı OneLake güvenlik Okuma izinlerine sahip olsa bile bu tablodan okuyamaz. DENY deyimi, verilen OneLake güvenlik veya SQL izinlerini geçersiz kılarak. Bir kullanıcının OneLake güvenlik ve SQL izinlerinin herhangi bir bileşimini vermiş olabileceği etkili izinler için aşağıdaki tabloya bakın.

OneLake güvenlik izinleri SQL izinleri Etkili izinler
İzin Ver Hiçbiri İzin Ver
Hiçbiri İzin ver İzin ver
İzin ver Reddet Reddet
Hiçbiri Reddet Reddet

Bilinen sorunlar ve sınırlamalar

  • Tasarım gereği, yalnızca Lakehouse veya Warehouse'daki tablolardan türetilen anlamsal modeldeki tablolar Direct Lake modunu destekler. Modeldeki tablolar Lakehouse veya Warehouse'daki SQL görünümlerinden türetilebilir ancak bu tabloları kullanan sorgular DirectQuery moduna geri döner.

  • Direct Lake semantik model tabloları yalnızca tek bir Lakehouse veya Warehouse'dan tablolardan ve görünümlerden türetilebilir.

  • Direct Lake tabloları şu anda aynı modelde İçeri Aktarma, DirectQuery veya İkili gibi diğer tablo türleriyle karıştırılamaz. Bileşik modeller şu anda desteklenmiyor.

  • DateTime ilişkileri Direct Lake modellerinde desteklenmez.

  • Hesaplanmış sütunlar ve hesaplanan tablolar desteklenmez.

  • Yüksek duyarlıklı ondalık değerler ve para türleri gibi bazı veri türleri desteklenmeyebilir.

  • Direct Lake tabloları karmaşık Delta tablo sütun türlerini desteklemez. İkili ve Guid semantik türleri de desteklenmez. Bu veri türlerini dizelere veya desteklenen diğer veri türlerine dönüştürmeniz gerekir.

  • Tablo ilişkileri, anahtar sütunlarının veri türlerinin çakışmasını gerektirir. Birincil anahtar sütunları benzersiz değerler içermelidir. Yinelenen birincil anahtar değerleri algılanırsa DAX sorguları başarısız olur.

  • Dize sütun değerlerinin uzunluğu 32.764 Unicode karakterle sınırlıdır.

  • 'NaN' (Sayı Değil) kayan nokta değeri Direct Lake modellerinde desteklenmez.

  • Katıştırılmış varlıkları kullanan katıştırılmış senaryolar henüz desteklenmemektedir.

  • Direct Lake modelleri için doğrulama sınırlıdır. Kullanıcı seçimleri doğru kabul edilir ve hiçbir sorgu ilişkiler veya tarih tablosundaki seçili tarih sütunu için kardinaliteyi ve çapraz filtre seçimlerini doğrulamaz.

  • Yenileme geçmişindeki Direct Lake sekmesinde yalnızca Direct Lake ile ilgili yenileme hataları listelenir. Başarılı yenilemeler şu anda atlanıyor.

Kullanmaya başlayın

Kuruluşunuzda Direct Lake çözümünü kullanmaya başlamanın en iyi yolu bir Lakehouse oluşturmak, içinde bir Delta tablosu oluşturmak ve ardından Microsoft Fabric çalışma alanınızda göl evi için temel bir anlam modeli oluşturmaktır. Daha fazla bilgi edinmek için bkz . Direct Lake için göl evi oluşturma.