Power BI’da model kurarken yıllarca aynı ikilemi yaşadık: Import hızlıdır ama her yenilemede tüm veriyi kopyalar; DirectQuery veriyi kopyalamaz ama her tıklamada kaynağa sorgu gönderir ve yavaşlar. Microsoft Fabric ile gelen Direct Lake bu ikisinin arasında üçüncü bir yol açıyor: veri OneLake’teki Delta tablolarında kalıyor, ama sorgular Import ile aynı motor (VertiPaq) tarafından bellekten cevaplanıyor. Bu yazıda Direct Lake’in nasıl çalıştığını, iki türü arasındaki farkı ve en sık karşılaşılan performans tuzaklarını anlatıyorum.
Direct Lake aslında ne yapıyor?
Import modunda yenileme, kaynaktaki veriyi baştan sona okuyup modelin içine sıkıştırarak yazar. Direct Lake’te ise yenileme sadece meta veriyi günceller. Microsoft bu işleme framing diyor: model, Delta tablosunun en son sürümüne bakar ve hangi Parquet dosyalarını kullanacağını kaydeder. Bu yüzden yenileme genellikle birkaç saniye sürer.
Veri belleğe ise ihtiyaç anında yüklenir. Bir sorgu bir sütuna ilk kez ihtiyaç duyduğunda o sütun OneLake’ten okunup belleğe alınır (transcoding); sonraki sorgular aynı sütunu doğrudan bellekten kullanır. Uzun süre kullanılmayan sütunlar bellekten düşürülür. Yani raporda hiç kullanılmayan bir açıklama sütunu bellekte yer kaplamaz.
Bunun pratik bir sonucu var: bir raporun ilk açılışı (“soğuk” durum) sonraki açılışlardan biraz daha yavaş olabilir. Performans test ederken ilk sorguyu ve sonrakileri ayrı değerlendirmek gerekiyor.
İki tür Direct Lake var
Bugün Direct Lake’in iki çeşidi bulunuyor ve aralarındaki fark sanıldığından büyük:
| Direct Lake on OneLake | Direct Lake on SQL | |
|---|---|---|
| Veri kaynağı | Birden fazla Fabric öğesi (lakehouse, warehouse, shortcut’lar) | Tek bir SQL analytics endpoint |
| DirectQuery’ye düşme (fallback) | Yok | Var, koşullar sağlanmazsa otomatik |
| SQL view’lar | Desteklenmiyor | Destekleniyor ama DirectQuery’ye düşer |
| Import tablolarla aynı modelde | Evet | Hayır |
| SQL tarafındaki RLS/OLS | Uygulanmaz, güvenlik modelde tanımlanmalı | Uygulanır ama sorgular DirectQuery’ye düşer |
Microsoft yeni modeller için Direct Lake on OneLake‘i öneriyor. En önemli farkı, birden fazla kaynağı tek modelde birleştirebilmesi ve gerektiğinde Import tablolarla karışık (composite) model kurulabilmesi. SQL tarafında view’lara ya da SQL güvenliğine bağımlıysanız Direct Lake on SQL hâlâ seçenek, ama o durumda performansın bir kısmını DirectQuery’ye kaptırmayı göze almanız gerekiyor.
Power BI Desktop’ta model oluşturmak
Direct Lake on OneLake modelini doğrudan Power BI Desktop’tan kurabilirsiniz:
- Şeritten OneLake catalog‘u açın.
- Bir lakehouse ya da warehouse seçip Connect‘e basın.
- Modele bir ad verin, Fabric çalışma alanını seçin, kullanacağınız tabloları işaretleyip OK deyin.
Model, çalışma alanında oluşturulur ve siz onu live edit modunda düzenlersiniz. Burada alışkanlıklarımızı değiştiren birkaç nokta var: yayımlama adımı yok, değişiklikler otomatik kaydedilir ve geri alma (undo) bulunmuyor. Bunun yerine her düzenleme oturumunun başında bir sürüm (version history) oluşturuluyor. İlişkileri ya da ölçüleri büyük ölçüde değiştirecekseniz bunu bilerek başlamak iyi olur. Bu modu kullanmak için kiracıda XMLA uç noktasının açık, kapasitede de Read Write olarak ayarlanmış olması gerekiyor.
Sessiz yavaşlama: DirectQuery’ye düşme
Direct Lake on SQL kullanıyorsanız dikkat etmeniz gereken en önemli konu fallback. Model bir tabloyu Direct Lake ile okuyamadığında (tablo bir SQL view’a dayanıyorsa, SQL tarafında RLS varsa ya da tablo kapasite sınırlarını aşıyorsa) o tablo için sorgular sessizce DirectQuery’ye döner. Rapor çalışmaya devam eder, sadece yavaşlar; bu yüzden fark etmek zor olabilir.
Hangi tablonun neden düştüğünü görmek için DAX sorgu görünümünde şu sorguyu çalıştırın:
EVALUATE TABLETRAITS()Sonuçtaki [DirectLakeFallbackInfo] sütununda None görüyorsanız tablo Direct Lake modunda çalışıyor demektir. Başka bir değer, düşmenin nedenini gösterir.
Geliştirme sırasında bu davranışı kapatmak da mümkün. Model görünümünde semantik modelin Properties panelindeki Direct Lake behavior ayarı üç değer alıyor:
- Automatic (varsayılan): koşullar sağlanmazsa sessizce DirectQuery’ye düşer.
- Direct Lake Only: düşmek yerine hata verir. Geliştirme ortamında sorunları erken görmek için ideal.
- DirectQuery Only: her zaman DirectQuery kullanır. Düşme durumunda performansın ne olacağını ölçmek için işe yarar.
Direct Lake on OneLake’te bu ayar yok: model her zaman Direct Lake Only gibi davranır. Sınırlar aşılırsa model sorgulanamaz ve önce Delta tablolarının düzeltilmesi gerekir.
Performansın asıl belirleyicisi: Delta tabloları
Import modunda verinin nasıl sıkıştırılacağına Power BI karar veriyordu. Direct Lake’te bu iş Delta tablolarını yazan tarafa, yani veri mühendisliğine geçiyor. Raporun hızı büyük ölçüde tabloların nasıl yazıldığına bağlı. Dört konuya dikkat etmek yeterli:
1. V-Order. V-Order, Parquet dosyalarını VertiPaq’in kolay okuyacağı şekilde sıralayıp sıkıştıran bir yazma optimizasyonu. Warehouse’ta varsayılan olarak açık, ancak yeni çalışma alanlarında Spark ile yazılan tablolarda kapalı geliyor. Tablonuzu ağırlıklı olarak Power BI okuyacaksa tablo düzeyinde açın:
%%sql
ALTER TABLE dbo.fact_satis
SET TBLPROPERTIES ("delta.parquet.vorder.enabled" = "true");Bu ayar sadece bundan sonraki yazmaları etkiler. Mevcut dosyalar için bir sonraki maddedeki OPTIMIZE komutunu kullanabilirsiniz.
2. Küçük dosyaları birleştirin. Sık yapılan küçük eklemeler yüzlerce küçük Parquet dosyası ve satır grubu üretir. Hem sorgular yavaşlar hem de kapasite sınırlarına yaklaşırsınız. OPTIMIZE bu dosyaları birleştirir; VORDER ile birlikte kullanıldığında V-Order’ı da uygular:
%%sql
OPTIMIZE dbo.fact_satis VORDER;Bir uyarı: OPTIMIZE dosyaları değiştirdiği için bellekteki ilgili sütunlar geçersiz olur ve sonraki ilk sorgu veriyi yeniden yükler. Bu yüzden her yüklemeden sonra değil, hafta sonu ya da gece gibi sakin zamanlarda çalıştırmak daha mantıklı.
3. Satır grubu boyutu. Microsoft, satır grubu başına 1 ile 16 milyon satır arasını öneriyor. Çok sayıda küçük satır grubu, Direct Lake’in birleştirmesi gereken parça sayısını artırır. Mevcut durumu semantic-link-labs kütüphanesiyle bir notebook’tan kontrol edebilirsiniz:
%pip install semantic-link-labs
import sempy_labs as labs
sonuc = labs.delta_analyzer("fact_satis")
display(sonuc["Summary"])4. Tabloyu her seferinde baştan yazmayın. Tüm tabloyu silip yeniden yazan (overwrite) yükleme kalıpları, framing’in sadece değişen kısmı güncellemesini engeller ve her yenilemede tüm sütunların yeniden yüklenmesine yol açar. Mümkünse sadece yeni satırları ekleyin (append) ya da düşük kardinaliteli bir sütuna (örneğin ay) göre bölümlenmiş tabloda sadece ilgili bölümü güncelleyin.
Kapasite sınırlarını bilin
Direct Lake, Fabric kapasitesi (F SKU) gerektiriyor ve her SKU için tablo başına sınırlar var. Küçük kapasitelerde (F2–F32) tablo başına 1.000 Parquet dosyası, 1.000 satır grubu ve 300 milyon satır sınırı bulunuyor. F64’te bu değerler 5.000 dosya ve 1,5 milyar satıra çıkıyor. Ayrıca belleğe alınabilecek veri miktarı da SKU’ya bağlı: F2–F8 için 3 GB, F64 için 25 GB. Büyük bir olgu tablonuz varsa kapasite seçmeden önce bu tabloya mutlaka bakın.
Hangi modu ne zaman seçmeli?
- Direct Lake: Veri zaten Fabric’te, lakehouse ya da warehouse’ta duruyorsa; hacim büyük ya da hızla büyüyorsa; verinin gün içinde birkaç kez güncellenmesi gerekiyorsa.
- Import: Veri hazırlığını Power Query içinde yapmanız gerekiyorsa, kaynağı değiştirme imkânınız yoksa, Fabric kapasiteniz yoksa ya da hibrit tablolar ve model içi bölümleme gibi Import’a özgü özelliklere ihtiyaç duyuyorsanız.
- DirectQuery: Sorguların gerçekten kaynak veritabanında çalışması gerekiyorsa ve kaynak bu yükü kaldırabiliyorsa.
Bu seçenekler birbirini dışlamıyor. Direct Lake on OneLake modelinde büyük olgu tablolarını Direct Lake ile, küçük ve Power Query’de hazırlanan bir boyut tablosunu Import ile aynı modelde tutabilirsiniz.
Son bir ipucu
Semantik model ayarlarındaki Keep your Direct Lake data up to date seçeneği varsayılan olarak açık gelir ve Delta tablolarında değişiklik algılandığı anda modeli günceller. Gün içinde sık güncellenen küçük modeller için bu harika. Ancak ETL süreciniz birden fazla tabloyu sırayla yüklüyorsa, kullanıcılar yükleme yarıdayken olgu tablosunun yenisini, boyut tablosunun eskisini görebilir. Böyle durumlarda bu seçeneği kapatıp yükleme bittiğinde modeli pipeline’ın son adımı olarak yenilemek daha güvenli.
HABERDAR OL
Yeni rehberler, kategorilere ayrılmış tek bir e-postada.
Her pazartesi, o hafta yayımlanan yazılar konu başlıklarına göre derlenmiş olarak gelen kutunda. Yeni yazı yoksa e-posta da yok.
1 yorum