DirectLake: Herkesin Konuştuğu, Kimsenin Tam Anlamadığı Özellik

Microsoft Fabric'in en çok tartışılan özelliği DirectLake. Reddit, Microsoft Tech Community ve Twitter'da her gün düzinelerce soru soruluyor: _"DirectLake gerçekten Import kadar hızlı mı?"_, _"Neden fallback yapıyor?"_, _"RLS ile çalışır mı?"_

Bu rehberde DirectLake'i derinlemesine açıklıyor, gerçek dünya senaryolarında ne zaman işe yaradığını ve ne zaman tuzağa düşürebileceğini anlatıyoruz.

DirectLake Nasıl Çalışır?

Geleneksel Power BI'da iki bağlantı modu vardır:

  • Import: Veri bellekte saklanır → hızlı ama eski
  • DirectQuery: Her sorguda kaynağa gider → güncel ama yavaş

DirectLake, üçüncü bir yol sunar: Delta/Parquet dosyalarını doğrudan OneLake'den okur, vertiPaq motoruna yükler ama veri kopyalamaz. Sonuç: Import hızında sorgular, DirectQuery güncelliğinde veriler.

Teknik Detay

DirectLake, Delta dosyalarının Parquet column chunks'larını doğrudan belleğe yükler. Bu sayede:

  • Veri kopyalama (Import refresh) gerekmez
  • Her sorgu en güncel Delta dosyalarını okur
  • VertiPaq sıkıştırma ve indexleme otomatik uygulanır
  • Sonuç: Import'a yakın performans

DirectLake Guardrails (Sınırlar)

İşte forumlarda en çok kafa karışıklığı yaratan konu: DirectLake'in sınırları ve fallback davranışı.

| Guardrail | F2 | F4 | F8 | F16 | F64 |

|---|---|---|---|---|---|

| Max satır sayısı | 300M | 300M | 1.5B | 3B | 12B |

| Max tablo sayısı | Sınırsız | Sınırsız | Sınırsız | Sınırsız | Sınırsız |

| Max tablo başına sütun | Sınırsız | Sınırsız | Sınırsız | Sınırsız | Sınırsız |

| Max Parquet dosya boyutu | 300M row group | 300M | 300M | 300M | 300M |

⚠️Bu sınırları aşarsanız DirectLake sessizce DirectQuery'ye fallback yapar. Raporlarınız çalışmaya devam eder ama performans dramatik şekilde düşer — ve bunu fark etmeyebilirsiniz.

Fallback: En Büyük Tuzak

Fallback Tetikleyen Durumlar

  • Satır sayısı guardrail'i aşıldığında
  • Desteklenmeyen DAX fonksiyonları kullanıldığında
  • RLS (Row Level Security) bazı senaryolarda
  • Calculated columns bazı karmaşık senaryolarda
  • Karmaşık CALCULATE filtreleri

Fallback'i Nasıl Tespit Edersiniz?

SQL
-- DAX Studio veya Semantic Model üzerinden
-- VertiPaq Analyzer ile DirectLake durumunu kontrol edin

-- Fabric'te: Semantic Model > Settings > DirectLake behavior
-- Seçenekler:
-- 1. Automatic (varsayılan): Sessizce DQ'ya düşer
-- 2. DirectLake Only: Fallback olmaz, hata verir
-- 3. DirectQuery Only: DirectLake kullanmaz
💡Forum Tavsiyesi: Test ortamında "DirectLake Only" ayarını açın. Hangi sorguların fallback yaptığını anında görürsünüz. Prodüksiyonda "Automatic" bırakın.

DirectLake Optimizasyonu

DirectLake'den maksimum performans almak için:

1. V-Order Sıkıştırma

Fabric'te Delta tablolarına V-Order sıkıştırma uygulamak, DirectLake okuma performansını %50'ye kadar artırabilir.

Python
class="code-comment"># Fabric Notebook - V-Order ile yazma
df.write.format(class="code-string">"delta") \
    .option(class="code-string">"vorder", class="code-string">"true") \
    .mode(class="code-string">"overwrite") \
    .save(class="code-string">"Tables/optimized_sales")

2. Parquet Dosya Boyutu

Çok küçük dosyalar (< 8MB) DirectLake performansını düşürür. OPTIMIZE komutuyla birleştirin:

SQL
-- Delta tablosunu optimize et (Fabric Notebook SQL)
OPTIMIZE lakehouse.Tables.sales;

-- Ayrıca VACUUM ile eski dosyaları temizleyin
VACUUM lakehouse.Tables.sales RETAIN 168 HOURS;

3. Partition Stratejisi

Çok fazla partition DirectLake'i yavaşlatır. Yılık veya aylık partition yeterli.

Python
class="code-comment"># İyi: Yıl bazlı partition
df.write.format(class="code-string">"delta") \
    .partitionBy(class="code-string">"Yil") \
    .mode(class="code-string">"overwrite") \
    .save(class="code-string">"Tables/partitioned_sales")

class="code-comment"># Kötü: Günlük partition (çok fazla küçük dosya)
class="code-comment"># df.write.partitionBy(class="code-string">"Tarih")  # YAPMAYIN!

DirectLake vs Import vs DirectQuery

| Kriter | Import | DirectQuery | DirectLake |

|---|---|---|---|

| Performans | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ |

| Güncellik | Zamanlanmış | Gerçek zamanlı | Gerçek zamanlı |

| Refresh gerekli mi? | Evet | Hayır | Hayır |

| Veri kopyalama | Evet | Hayır | Hayır |

| Fabric gerekli mi? | Hayır | Hayır | Evet |

| Guardrail riski | Yok | Yok | Var (fallback) |

Gerçek Dünya Senaryosu

Bir perakende firması için DirectLake projesi:

  • Veri: 50M satırlık satış fact tablosu, 5 dimension
  • Kapasite: F4
  • Guardrail: 300M satır → sorun yok
  • V-Order: Uygulandı → %40 daha hızlı okuma
  • Sonuç: Eski Import model 15 dakikada refresh oluyordu. DirectLake ile refresh süresi sıfır, sorgu performansı aynı

Sonuç

DirectLake, Fabric'in en güçlü özelliğidir — doğru kullanıldığında. Import hızında, DirectQuery güncelliğinde raporlar sunar. Ancak guardrail'leri bilmek, fallback davranışını izlemek ve V-Order optimizasyonu uygulamak kritiktir. Test ortamında "DirectLake Only" ile sorunları erken tespit edin, prodüksiyonda "Automatic" ile güvenli çalışın.

💡DirectLake mimarinizi birlikte kuralım. Mevcut Power BI raporlarınızı Fabric DirectLake'e taşıma sürecinde size rehberlik ediyoruz.