Depolama modu kararları
| Durum | Öneri |
|---|---|
| Veri 1 GB'ın altında, günlük yenileme yeterli | Import |
| Fabric lakehouse/warehouse'ta Delta tablolar, büyük hacim | Direct Lake |
| Kaynakta sürekli değişen veri, saniyeler önemli | DirectQuery (ya da gerçek zamanlı zekâ) |
| Özet hızlı olsun, ayrıntı canlı kalsın | Bileşik model: toplama tablosu Import, ayrıntı DirectQuery |
| Birden çok yayımlanmış modeli birleştirmek | Bileşik model: canlı bağlantı + yerel tablolar (DirectQuery for Power BI datasets/AS) |
Bileşik modeller ve Dual
Bir tabloyu Dual yapmak, onu hem Import hem DirectQuery gibi davranabilir kılar: Import tabloyla birlikte sorgulanınca bellekten, DirectQuery tabloyla birlikte sorgulanınca kaynaktan okunur. Boyut tabloları genellikle Dual olur; böylece “zayıf ilişki” (limited relationship) oluşmaz.
Kullanıcı tanımlı toplamalar
Milyar satırlık bir DirectQuery olgu tablosunun yanında ay × ürün düzeyinde bir Import özet tablo oluşturulur ve Toplamaları yönet ile eşlenir (Satış Toplamı → Satislar[Tutar] Toplam). Sorgu özet düzeyindeyse motor özet tabloyu kullanır, ayrıntıya inilince DirectQuery'ye düşer. Kullanıcı yalnızca ayrıntı tablosunu görür.
Büyük model biçimi
Premium/Fabric kapasitesinde anlam modeli ayarı: model 10 GB sınırını aşabilir, XMLA yazma işlemleri ve artımlı yenileme bölümleri daha verimli olur. Büyük modellerde açılması önerilir.
Direct Lake
- Direct Lake on OneLake: Model doğrudan OneLake'teki Delta dosyalarını okur; birden çok lakehouse/warehouse'tan tablo alabilir; SQL uç noktasına bağımlı değildir.
- Direct Lake on SQL analytics endpoint: Lakehouse/warehouse'un SQL uç noktası üzerinden; görünümler (view) ya da satır düzeyi güvenlik gibi durumlarda sorgu DirectQuery'ye geri döner (fallback).
- Geri dönüş davranışı (DirectLakeBehavior): Otomatik, Yalnızca Direct Lake (geri dönüş yerine hata), Yalnızca DirectQuery. Performansı öngörülebilir tutmak için geri dönüşleri izle.
- Çerçeveleme (framing): Direct Lake'te “yenileme”, modelin Delta tablolarının hangi sürümüne bakacağını güncellemektir; veri kopyalanmaz, saniyeler sürer.
Artımlı yenileme
- Power Query'de
RangeStartveRangeEnd(Tarih/Saat) parametrelerini oluştur. - Olgu tablosunu
[Tarih] >= RangeStart and [Tarih] < RangeEndile filtrele (sorgu katlanmalı). - Tabloya sağ tık → Artımlı yenileme: “Son 5 yılı arşivle, son 10 günü yenile”, isteğe bağlı “yalnızca tam günler”, “veri değişikliklerini algıla”, ve DirectQuery ile gerçek zamanlı son bölüm (hibrit tablo).
- Yayımla; ilk yenileme bölümleri oluşturur, sonrakiler yalnızca son bölümleri yeniler.
XMLA uç noktası
Premium/Fabric çalışma alanları Analysis Services protokolüyle erişilebilir. Tabular Editor, SQL Server Management Studio, DAX Studio ve ALM Toolkit bu uç noktayla modele bağlanır: tek tablo ya da bölüm yenileme, hesaplama grubu ve nesne düzeyi güvenlik (OLS) tanımlama, modeli komut dosyasıyla dağıtma. “Okuma-yazma” kapasite ayarından açılır.
Bileşik model: tablo tablo karar vermek
Senaryo: Anadolu Market'in satış satırları şirket içindeki bir SQL veritabanında yüz milyonlarca satıra ulaştı. Yönetim aylık kategori özetine bakıyor; mağaza müdürleri ise gün içi satışları görmek istiyor. Tek bir depolama modu herkese uymaz; bileşik model (composite model) her tabloya ayrı mod vermeyi sağlar:
| Tablo | Mod | Gerekçe |
|---|---|---|
Satislar (ayrıntı) | DirectQuery | Belleğe sığmıyor, gün içi güncellik gerekli |
Tarih, Urunler, Kategoriler, Musteriler | Dual | Dilimleyiciler bellekten açılır; DirectQuery olguyla birleşince sorguya kaynakta katılır |
Hedefler | Import | Excel'den gelir, ayda bir değişir |
| Aylık özet tablo | Import (gizli) | Yönetim sorgularını bellekten karşılar |
Boyutlar Import olsaydı, DirectQuery olgu ile aralarındaki ilişki sınırlı ilişki (limited relationship) olurdu: farklı kaynak grupları arasında motor ilişkiyi tam bir birleşim gibi kuramaz. Sonuçları: RELATED çalışmaz, eşleşmeyen satırlar için boş satır (blank row) oluşmaz, her sorgu iki dünya arasında veri taşır. Dual bu yüzden boyutların varsayılanıdır.
Yayımlanmış modele bağlanıp genişletmek
Finans ekibi onaylı satış modelini kullanmak, ama kendi gider bütçesi tablosunu eklemek istiyor. Canlı bağlantıyı “yerel model”e çevirmek (Power BI anlam modellerine DirectQuery) bunu sağlar. Dikkat: kullanıcının kaynak modelde Derleme (Build) izni olmalı, kaynak modeldeki RLS geçerliliğini korur ve kiracıda “Power BI anlam modellerine DirectQuery bağlantılarına izin ver” ayarı açık olmalı. Zincir uzadıkça (model üstüne model üstüne model) sorgular yavaşlar ve hata ayıklamak zorlaşır; iki halkadan uzun zincirden kaçın.
DirectQuery'e geri dönüş ve Direct Lake davranışı
Direct Lake'in iki biçimi farklı davranır; karar verirken bu farkı bilmek gerekir:
| Direct Lake on OneLake | Direct Lake on SQL (SQL analiz uç noktası) | |
|---|---|---|
| Kaynak | Bir ya da birden çok Fabric öğesinin Delta tabloları | Tek bir lakehouse/warehouse'un SQL uç noktası |
| DirectQuery'e geri dönüş | Yok | Var: SQL görünümü (view), SQL tarafı ayrıntılı erişim denetimi ya da RLS, işlenmemiş tablo, sınır aşımı |
| Sınır (guardrail) aşılırsa | Yenileme başarısız olur; Delta tabloları iyileştirilene kadar model sorgulanamaz | Geri dönüş açıksa sorgu DirectQuery ile çalışır, yenileme uyarıyla tamamlanır |
| Import tablolarla bileşik | Desteklenir | Aynı modelde karıştırılamaz; Desktop'ta üstüne bileşik model kurulabilir |
Kapasiteye göre sınırlardan örnekler: F2–F8'de tablo başına 1.000 Parquet dosyası/satır grubu, 300 milyon satır ve diskte 10 GB model; F64'te tablo başına 5.000 dosya/satır grubu ve 1,5 milyar satır, belleğe alınabilecek veri için 25 GB üst sınır. Sınırın altında kalmanın yolu çoğu zaman SKU büyütmek değil, Delta tablolarını bakımlı tutmaktır: küçük dosyaları birleştirmek (compaction), V-Order ile yazmak.
- İlk sorgu yavaşsa: Direct Lake sütunları ihtiyaç oldukça belleğe alır (transcoding). Sabah ilk açılış soğuktur; çerçeveleme (framing) sonrası bir ısınma sorgusu planlamak yaygın bir çözümdür.
- Bellek dolarsa: sütunlar bellekten atılıp yeniden yüklenir (paging); her şey çalışır ama yavaşlar.
- Geri dönüşü izle: “Direct Lake davranışı” (Direct Lake behavior) özelliğiyle geri dönüşü kapatırsan sorun sessiz yavaşlık yerine açık hata olarak görünür; Fabric kapasite ölçümleri uygulamasında geri dönüşleri takip et.
- SQL görünümü yerine: lakehouse'ta somutlaştırılmış görünüm (materialized view) ya da dönüşümü yapılmış bir Delta tablosu kullan.
Toplama tabloları ve artımlı yenileme: kısa hatırlatma
Bu iki konunun ayrıntısını ayrı bir ders işliyor; burada yalnızca karar ölçütü. Toplama tablosunun değeri, tanesine (grain) bağlıdır. Bu modelde Satislar 1.620 satırdır; ay × kategori düzeyinde özet 199 satıra iner. Ürün düzeyinde bir soru gelirse bu özet cevap veremez ve sorgu ayrıntıya düşer. Özet tabloyu, panoların gerçekten sorduğu soruların tanesinde kur; Performans Analizi ile “özet kullanıldı mı?” diye doğrula. Artımlı yenileme ise yenileme süresinin sınırlarını (paylaşılan kapasitede 2 saat, Premium/Fabric'te 5 saat) aşan tablolar için ilk adaydır.
Modeli kullanıcıya anlatmak: klasörler, açıklamalar, çeviriler
119 ölçülük bir model, alan listesinde düz bir liste olarak kullanılamaz. Kurumsal bir modelde şu üç meta veri en az ölçü kadar önemlidir:
- Görüntüleme klasörü (Display folder):
Satış\Temel,Satış\Zaman Zekâsı,Müşteri\RFM. Ters eğik çizgi alt klasör, noktalı virgül aynı ölçüyü iki klasörde gösterir. Klasör adları da çevrilebilir. - Açıklama (Description): alan listesinde araç ipucu olarak çıkar. “İptal hariç, iade dahil net satış; Tarih tablosuyla aktif ilişki” gibi tanımlar yazılmalı. Copilot ve “Yapay zekâ için verileri hazırla” (Prep data for AI) ayarları da bu açıklamalardan yararlanır.
- Gizleme ve özetleme: anahtar sütunlar (
UrunNo,MusteriNo) olgu tablosunda gizli olmalı; sayısal kimlikler “Özetleme: Hiçbiri” olmalı ki kimse SatirNo toplamı almasın.
Meta veri çevirileri (translations)
Almanya'daki ortak şirket aynı modeli kullanacak. Üç ayrı çeviri türü vardır ve zorlukları farklıdır:
| Tür | Neyi çevirir? | Nasıl? |
|---|---|---|
| Meta veri çevirisi | Tablo, sütun, ölçü, hiyerarşi adları; açıklamalar; görüntüleme klasörleri | Modelin içinde, dil (culture) başına; Translations Builder gibi araçlarla |
| Rapor etiketi çevirisi | Başlıklar, düğme metinleri | Yerleşik özellik yok; etiketleri ölçü olarak tutan gizli bir tablo kalıbı |
| Veri çevirisi | “Elektronik” → “Elektronik”, “Ev & Yaşam” → “Haus & Wohnen” | Kaynakta çevrilmiş sütunlar + seçim mekanizması |
Sayfa sekmesi adları ve metin kutularındaki sabit yazılar çevrilemez; çok dilli raporlar Web'de yayımla ile desteklenmez. Ölçü adlarını çevirmek DAX'ı bozmaz: formüller nesneye başvurur, görünen ada değil.
Nesne düzeyinde güvenlik (OLS) de kurumsal modelin parçasıdır; ayrıntısı Satır ve nesne düzeyinde güvenlik dersindedir.
Ölçek kararları
| Belirti | Önce dene | Sonra |
|---|---|---|
| Pro'da model boyutu 1 GB sınırına yaklaştı | Gereksiz sütun, kardinalite, otomatik tarih/saat | PPU ya da Fabric kapasitesi; büyük model biçimi |
| Yenileme 2 saati aşıyor | Sorgu katlama, artımlı yenileme | Kapasite (5 saat), XMLA ile bölüm bölüm yenileme |
| Günde 8'den fazla yenileme gerekiyor | Gerçekten gerekli mi? Hangi tablo? | Kapasitede 48'e kadar zamanlanmış; Direct Lake ya da DirectQuery |
| Birden çok ekip aynı tanımları yeniden yazıyor | Tek onaylı model + Derleme izni | Bileşik modelle ekip tablolarını ekleme |