Direct Lake, Microsoft Fabric’te Power BI semantik modellerinin veriyi OneLake’teki Delta tablolarından doğrudan okumasını sağlayan depolama modudur. Import modundaki gibi veriyi modele kopyalamaya gerek kalmaz, DirectQuery’deki gibi her sorguda kaynak sisteme gidilmez. Bu yazıda, mevcut Power BI Import modellerini Direct Lake’e taşıyan ekiplerin en sık karşılaştığı 7 sorunu ve her birinin çözümünü anlatıyoruz. Yazı Power BI geliştiricileri, veri mühendisleri ve BI ekip liderleri için hazırlandı.
Direct Lake neden cazip görünüyor?
Import modunda büyük modellerin yenilenmesi saatler sürebilir ve her yenileme kapasite tüketir. Direct Lake’te ise ETL süreci Delta tablolarını güncellediğinde model yeni veriyi neredeyse anında görür. Bu, özellikle gün içinde birden fazla güncelleme gereken finans ve operasyon raporları için ciddi bir avantajdır.
Ancak geçiş, depolama modunu değiştirip kaydetmekten ibaret değildir. Import dünyasında alışılmış bazı yöntemler Direct Lake’te çalışmaz ya da performansı beklenmedik biçimde düşürür. Ekibinizin hangi seviyede Power BI bilgisine sahip olduğunu değerlendirmek için Power BI temel mi ileri seviye mi yazımız faydalı bir başlangıç noktası olabilir.
Sorun 1: Power Query dönüşümleri modelde kalamıyor
Import modellerinde veri temizleme, birleştirme ve sütun türetme işlerinin önemli bir kısmı Power Query’de yapılır. Direct Lake modellerinde ise Power Query katmanı yoktur. Model, Delta tablosunda ne varsa onu okur.
Çözüm: Dönüşüm mantığını modelden önceki katmana, yani Lakehouse veya Warehouse’a taşıyın. Bu iş Dataflow Gen2, Spark notebook veya SQL ile yapılabilir. Geçiş öncesinde her modeldeki Power Query adımlarının bir envanterini çıkarmak, sürpriz yaşamamanın en güvenli yoludur.
Sorun 2: Hesaplanmış sütunlar ve tablolar sorun çıkarıyor
Import modellerinde DAX ile oluşturulan hesaplanmış sütunlar yaygındır. Direct Lake tablolarında bu destek sınırlıdır ve bazı senaryolarda hiç çalışmaz.
Çözüm: Satır bazında hesaplanan her değeri Delta tablosuna fiziksel bir sütun olarak ekleyin. Ölçüler (measure) ise DAX’ta kalmaya devam eder. Bu ayrım aslında iyi bir mimari pratiktir: satır bazlı iş kuralları veri katmanında, toplama mantığı semantik modelde yaşar.
Sorun 3: Sorgular sessizce DirectQuery’ye düşüyor
Direct Lake’in SQL analitik uç noktası üzerinden çalışan türünde (Direct Lake on SQL), belirli durumlarda sorgular DirectQuery moduna düşer. Bu durum fallback olarak adlandırılır ve rapor hâlâ çalıştığı için çoğu zaman fark edilmez. Kullanıcılar sadece raporun yavaşladığını hisseder.
Microsoft’un dokümantasyonuna göre fallback üç ana nedenle tetiklenir: modelde SQL view kullanılması, SQL uç noktasında ayrıntılı erişim güvenliği tanımlanmış olması ve kapasite limitlerinin (guardrail) aşılması.
Çözüm: Geliştirme aşamasında fallback’i kapatın. Böylece desteklenmeyen bir durum olduğunda sorgu hata verir ve sorunu hemen görürsünüz. OneLake üzerinden çalışan yeni tür (Direct Lake on OneLake) ise SQL uç noktasına bağlı olmadığı için DirectQuery fallback desteklemez. Hangi türü seçeceğinize geçişin başında karar verin.
Sorun 4: Guardrail limitleri küçük dosyalarla aşılıyor
Her Fabric kapasite boyutunun (SKU) Direct Lake için belirlediği limitler vardır: tablo başına Parquet dosyası sayısı, row group sayısı, satır sayısı ve model boyutu. Örneğin F2’den F8’e kadar olan kapasitelerde tablo başına dosya sınırı 1.000, satır sınırı 300 milyondur.
Satır limiti genellikle öngörülebilir. Asıl sorun dosya sayısıdır. Her 15 dakikada bir küçük artımlar yazan bir ETL süreci, birkaç hafta içinde bir tabloda binlerce küçük Parquet dosyası oluşturabilir. Limit aşıldığında Direct Lake on SQL modellerinde sorgular DirectQuery’ye düşer.
Çözüm: Delta tablolarında düzenli bakım yapın. OPTIMIZE komutu küçük dosyaları birleştirir, V-Order ise okuma performansını artırır. Bakım işini ETL hattının sonuna zamanlanmış bir adım olarak ekleyin.
Sorun 5: Satır düzeyi güvenlik yanlış katmanda tanımlanıyor
Import modellerinde satır düzeyi güvenlik (RLS) semantik modelde tanımlanır. Fabric’e geçen bazı ekipler, güvenliği “kaynağa yakın olsun” düşüncesiyle SQL uç noktasında tanımlıyor. Direct Lake on SQL modellerinde bu, tüm sorguların DirectQuery’ye düşmesine yol açar ve performansı ciddi biçimde düşürür.
Çözüm: Direct Lake on SQL kullanıyorsanız RLS’yi semantik modelde tanımlamaya devam edin. Direct Lake on OneLake kullanıyorsanız OneLake güvenlik özelliklerini değerlendirin. Güvenlik tasarımını geçişin ilk haftasında netleştirin, sonradan değiştirmek maliyetlidir.
Sorun 6: Yenileme mantığı ETL ile senkron değil
Direct Lake’te “yenileme” veriyi kopyalamaz. Model, Delta tablolarının hangi versiyonunu okuyacağını belirleyen meta veriyi günceller. Bu işleme framing denir. Varsayılan olarak model, Delta tablolarındaki değişiklikleri otomatik olarak algılar.
Sorun şurada başlar: ETL süreci beş tabloyu sırayla güncelliyorsa ve model ilk tablo güncellendiği anda yeni veriyi görürse, kullanıcı bir süre birbiriyle tutarsız veriler görebilir. Satış tablosu bugünün verisini gösterirken müşteri tablosu hâlâ dünkü halinde kalabilir.
Çözüm: Otomatik güncellemeyi kapatın ve ETL hattının son adımı olarak modeli yenileyen bir tetikleyici ekleyin. Böylece kullanıcılar her zaman tutarlı bir veri kümesi görür.
Sorun 7: Kapasite yanlış boyutlandırılıyor
Fabric, Power BI Premium kapasitelerinin yerini alan F SKU’larla çalışır. Kapasite seçerken sadece veri hacmine değil, eş zamanlı kullanıcı sayısına ve lisans modeline de bakmak gerekir. F64 ve üzeri kapasitelerde içerik görüntüleyen kullanıcıların ayrıca Power BI Pro lisansına ihtiyacı yoktur. Daha küçük kapasitelerde ise her görüntüleyicinin lisansı olmalıdır.
Performans açısından dikkat edilmesi gereken bir nokta daha var: Direct Lake, sütunları ilk sorguda belleğe yükler. Sabah ilk açılan raporlar bu yüzden yavaş gelebilir. Kritik raporlar için mesai öncesinde ısınma sorguları çalıştırmak bu sorunu azaltır.
Çözüm: Pilot bir iş alanıyla başlayın, Fabric Capacity Metrics uygulamasıyla gerçek tüketimi iki ile dört hafta izleyin, ardından kapasite kararını verin. Bulut maliyetini finansal açıdan değerlendirmek isteyen yöneticiler için CAPEX ve OPEX farkları yazımız bu kararın çerçevesini çizer.
Geçiş öncesi kontrol listesi
Bir modeli Direct Lake’e taşımadan önce şu soruları cevaplayın:
- Modeldeki tüm Power Query adımları veri katmanına taşındı mı?
- Hesaplanmış sütunlar Delta tablolarına fiziksel sütun olarak eklendi mi?
- Direct Lake on SQL mi, Direct Lake on OneLake mi kullanılacak?
- Tabloların dosya sayısı ve satır sayısı, seçilen SKU’nun limitlerinin altında mı?
- RLS hangi katmanda tanımlanacak?
- Model yenilemesi ETL hattının sonuna bağlandı mı?
- Pilot dönemde kapasite tüketimi izlendi mi?
Sonuç
Direct Lake, doğru kurgulandığında Power BI raporlarını hem daha güncel hem de daha verimli hale getirir. Ancak Import modellerinde alışılmış yöntemlerin bir kısmı burada işe yaramaz. Başarılı geçişin sırrı, iş mantığını semantik modelden veri katmanına taşımak ve fallback, guardrail ile framing kavramlarını baştan anlamaktır.
Bu geçişi yönetecek ekiplerin DAX, veri modelleme ve performans optimizasyonunda güçlü olması gerekir. Power BI Advanced eğitimi tam olarak bu konuları ileri seviyede işler. Ekipte Power BI’a yeni başlayanlar varsa Power BI Fundamentals eğitimi ile ortak bir temel oluşturmak faydalı olur. Fabric’in üzerinde çalıştığı Azure altyapısını tanımak isteyenler için Microsoft Azure Fundamentals eğitimi iyi bir başlangıçtır. Fabric’teki yapay zeka özelliklerini merak edenler ise Power BI Copilot ile doğal dil analizi yazımıza göz atabilir.
Sıkça sorulan sorular
Direct Lake nedir?
Direct Lake, Power BI semantik modellerinin veriyi OneLake’teki Delta tablolarından doğrudan okuduğu depolama modudur. Veriyi modele kopyalamadan Import moduna yakın sorgu performansı sunmayı hedefler ve yalnızca Microsoft Fabric kapasitelerinde kullanılabilir.
Direct Lake ile Import modu arasındaki fark nedir?
Import modunda veri, her yenilemede semantik modele kopyalanır. Direct Lake’te ise veri OneLake’te kalır ve model yalnızca sorgunun ihtiyaç duyduğu sütunları belleğe yükler. Bu sayede yenileme süreleri kısalır ve veri daha güncel olur.
DirectQuery fallback nedir ve nasıl önlenir?
Direct Lake on SQL modellerinde, SQL view kullanımı, SQL uç noktasında tanımlı güvenlik veya kapasite limitlerinin aşılması durumunda sorguların DirectQuery moduna geçmesidir. Geliştirme aşamasında fallback’i kapatmak ve Delta tablolarında düzenli bakım yapmak bu sorunu önler.
Direct Lake için hangi Fabric kapasitesi gerekir?
Direct Lake tüm F SKU’larda kullanılabilir, ancak her SKU’nun tablo başına dosya, satır ve model boyutu limitleri farklıdır. F64 ve üzeri kapasitelerde görüntüleyicilerin ayrıca Pro lisansına ihtiyacı olmaz. Doğru kapasite, pilot dönemdeki gerçek tüketim izlenerek belirlenmelidir.