"Import mı DirectQuery mi?" — Power BI'ın Ebedi Sorusu

Power BI'da veri bağlantısı seçimi raporların hızını, güncelliğini ve ölçeklenebilirliğini doğrudan etkiler. Forumlarda her gün sorulan bu sorunun artık 4 cevabı var — çünkü Fabric ile DirectLake ve klasik Composite Model seçenekleri de devreye girdi.

4 Bağlantı Modu

Import Mode

TEXT
Çalışma mantığı:
Kaynak DB → [Kopyala] → Power BI Bellek (VertiPaq) → Rapor

Artılar:
+ En hızlı sorgu performansı
+ Tüm DAX fonksiyonları desteklenir
+ Offline çalışabilir

Eksiler:
- Veri eski kalır (zamanlı yenileme)
- Pro: ~1 GB, Premium: ~10 GB boyut limiti
- Yenileme süresi uzun olabilir

DirectQuery

TEXT
Çalışma mantığı:
Rapor sorgusu → [Gerçek zamanlı] → Kaynak DB → Sonuç

Artılar:
+ Her zaman güncel veri
+ Boyut limiti yok
+ Kaynak DB'deki güvenlik kuralları geçerli

Eksiler:
- Yavaş (her sorgu kaynağa gider)
- Bazı DAX fonksiyonları desteklenmez
- Kaynak DB yükü artar
- Ağ gecikmesine duyarlı

Composite Model

Composite Model, aynı raporda bazı tabloları Import, bazılarını DirectQuery olarak kullanmanızı sağlar.

Strateji: Dimension tabloları Import (küçük, nadiren değişir), Fact tablosu DirectQuery (büyük, sürekli güncellenir).

DAX
// Composite Model'de Dual mode
// Dimension tablosunu hem Import hem DQ olarak ayarlayabilirsiniz
// Tablo > Properties > Storage Mode = Dual

// Dual mode: 
// - Import tablosuyla JOIN → Import hızında
// - DQ tablosuyla JOIN → DQ modunda

DirectLake (Fabric)

TEXT
Çalışma mantığı:
OneLake Delta Parquet → [Doğrudan oku] → VertiPaq Engine → Rapor

Artılar:
+ Import hızında performans
+ Her zaman güncel (refresh gerekmez)
+ Veri kopyalanmaz

Eksiler:
- Sadece Fabric kapasitesinde çalışır
- Guardrail sınırları (fallback riski)
- Verinin Delta formatında olması gerekir

Karar Matrisi

| Senaryo | Önerilen Mod | Neden |

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

| Küçük veri (< 500 MB) | Import | En hızlı, en kolay |

| Büyük veri (> 10 GB) | DirectQuery veya DirectLake | Boyut limiti |

| Gerçek zamanlı gerekli | DirectQuery veya DirectLake | Güncellik |

| SAP HANA kaynağı | DirectQuery | HANA kendi optimize eder |

| SQL Server + büyük fact | Composite Model | Dimension: Import, Fact: DQ |

| Fabric Lakehouse | DirectLake | En iyi performans/güncellik dengesi |

| Azure SQL + RLS | DirectQuery | Kaynak DB güvenliği kullanılır |

Composite Model Best Practices

1. Aggregation Tabloları

Composite Model'de Aggregation tabloları ekleyerek DirectQuery sorgularını dramatik şekilde hızlandırabilirsiniz.

DAX
// Aggregation tablosu örneği
// Aylık satış özeti — Import modda
// Detay tablosu — DirectQuery modda

// Power BI otomatik olarak:
// - Ay bazlı sorgu → Aggregation (hızlı)
// - Günlük detay sorgusu → DirectQuery (yavaş ama detaylı)

2. User-Defined Aggregation Kuralları

Model görünümünde:

  • Aggregation tablosuna sağ tıklayın
  • "Manage aggregations" seçin
  • Her kolon için summarization (Sum, GroupBy) ve detay tablo eşlemesini yapın

3. Performans İzleme

TEXT
Performance Analyzer'da kontrol edin:
- "DirectQuery" süresi → Kaynak DB'ye giden sorgular
- "DAX Query" süresi → VertiPaq'ta çözülen sorgular

Hedef: Mümkün olduğunca çok sorgunun Import/Aggregation'dan
çözülmesi, DQ sorgularının minimumda kalması.

Migration Path: Import → Composite → DirectLake

💡Fabric'e henüz geçmediyseniz, büyük fact tabloları için Composite Model kullanmaya başlayın. Fabric'e geçtiğinizde DirectLake'e geçiş çok kolay olacak.

Sonuç

Power BI bağlantı modu seçimi "one-size-fits-all" değildir. Küçük veri setlerinde Import'la başlayın, büyüdükçe Composite Model'e geçin, Fabric kullanıyorsanız DirectLake'i değerlendirin. Önemli olan her tablonun ihtiyacına uygun modu seçmek — Star Schema'daki Dimension tabloları Import, büyük Fact tabloları DirectQuery veya DirectLake.