POWER BI PERFORMANS MODELLEME
Pazartesi sabahı satış toplantısı başlıyor; rapor açılması 90 saniye sürüyor, ilk filtre tıklamasında ekran donuyor, ikinci dilimleyicide CPU fan sesi duyuluyor. Sorun veri miktarı değil — modelin şekli. Tek bir dev tabloya 14 ilişki bağlanmış, kardinalitesi yüksek metinler ölçü olarak çekiliyor, VertiPaq motoru her tıklamada yeniden taranıyor. Star schema disiplinine geçmek ve sık sorulan kırılımlar için aggregate tablo kurmak, aynı veri hacmiyle saniyeler içinde cevap veren bir model çıkartır.
1. Yavaşlığın Gerçek Kaynağı: Modelin Şekli
Çoğu yavaş raporun arkasında donanım değil, snowflake veya flat-table karmaşası yatar. Power BI'ın VertiPaq motoru, yıldız şemasıyla en verimli sıkıştırmayı yapar; merkezdeki fact tablosu sayısal ölçümleri tutar, etrafındaki dimension tabloları metin niteliklerini barındırır. Bu ayrım kaybolduğunda — örneğin müşteri adı fact içinde tekrar ettiğinde — sözlük şişer, sıkıştırma oranı düşer, sorgu süresi tırmanır.
İlk teşhis için DAX Studio'da VertiPaq Analyzer raporu çekin: hangi sütun ne kadar RAM tutuyor, kardinalite kaç? GUID veya serbest metin alanları genelde ilk şüphelidir.
2. Star Schema Disiplinine Geçiş
Star schema, sadece güzel bir diyagram değil; sorgu motorunun beklediği yapıdır. Geçişte üç temel kural:
- Fact tablosu yalnızca sayısal ölçüler ve dimension'a referans veren anahtarlar barındırır.
- Dimension tabloları tek yönde fact'e bağlanır; bi-directional ilişkiden mümkün olduğunca kaçınılır.
- Tarih boyutu manuel kurulur ve hem fact'e hem de varsa hedef/bütçe tablosuna ayrı ilişkilerle bağlanır.
Snowflake'ten star'a indirgeme genelde Power Query tarafında yapılır — alt dimensiyonlar üst dimension'a merge edilerek tek tabloya düşürülür. Sonuç: daha az JOIN, daha hızlı filter propagation.
3. Aggregate Tablolar: Detayı Saklı, Hızı Görünür
100 milyon satırlık fact üzerinde bölge bazında aylık ciro sorulduğunda, motor her seferinde tüm satırları taramak zorunda kalır. Aggregate tablo, sık sorulan kırılımları önceden hesaplanmış halde tutar — örneğin bölge × ay × kategori granülünde 80 bin satıra düşmüş bir özet. Power BI motoru sorguyu otomatik olarak agg tabloya yönlendirir; istenen kırılım agg'da yoksa detail fact'e geri düşer.
Aggregate tasarımında dikkat edilecekler:
- Hangi ölçüler ve hangi granülde toplanacak — kullanım istatistiklerine bakarak karar verin.
- Agg tablonun dimension'ları detail fact ile aynı dimension'lara bağlanmalı (manage aggregations ekranında eşlenir).
- SUM, COUNT, MIN, MAX agg'a yansır; DISTINCTCOUNT yansımaz — bu ölçüler için ayrı strateji gerekir.
- Import mode agg + DirectQuery detail kombinasyonu, büyük modellerde en yaygın hibrit desendir.
4. Storage Mode ve Composite Modeller
Tablonun storage mode'u performansın yarısıdır. Import en hızlısıdır ama veri boyutu sınırlıdır. DirectQuery anlık veri sunar ama her tıklama kaynak veritabanına gider. Dual mode, dimension tablolarında en mantıklı tercihtir: motor hangisinin gerektiğine sorgu bazında karar verir.
Composite model kurarken dimension'ları Dual, fact detail'i DirectQuery, agg fact'i Import yapmak — büyük veri ile interaktif deneyimi birleştiren klasik bir desendir. Storage mode seçimleri, modelleme desenleri ve dataset tasarımı için resmi rehber sayfalarına başvurmak, kenar senaryolarda doğru kararı vermeyi kolaylaştırır.
5. DAX Tarafında Sık Yapılan Hatalar
Model doğru kurulsa bile DAX yanlış yazılırsa filtre context her ölçüde yeniden hesaplanır. Sık karşılaşılan tuzaklar:
- FILTER içinde tablo yerine sütun referansı yetiyorsa onu kullanın — tablo iterasyonu pahalıdır.
- CALCULATE içinde gereksiz ALL kullanımı bütün filtreyi siler; KEEPFILTERS daha hedeflidir.
- Iterator fonksiyonlar (SUMX, AVERAGEX) küçük tablolar üzerinde çalıştırılmalı — büyük fact'te ölçü düzeyinde değil, view düzeyinde toplanmalı.
- Calculated column yerine measure tercih edin; column model boyutunu büyütür, measure sadece sorgu anında çalışır.
Performance Analyzer ile her görselin DAX süresini ve render süresini ayrı ayrı görebilir, darboğazı net şekilde tespit edebilirsiniz.
6. Ölçüm ve İyileştirme Döngüsü
Performansı tek seferlik bir proje değil, sürekli ölçüm-iyileştirme döngüsü olarak ele almak gerekir. VertiPaq Analyzer'dan model boyutunu, DAX Studio'dan sorgu sürelerini, Performance Analyzer'dan görsel sürelerini düzenli takip edin. Yeni bir tablo eklendiğinde kardinalite kontrolü, yeni bir ölçü eklendiğinde DAX trace alışkanlığı zamanla raporların yavaşlamasını engeller.
Konunun pratik tarafına derinlemesine girmek ve gerçek veri seti üzerinde uygulama yapmak için Power BI eğitimi içeriklerinden yararlanabilirsiniz; model tasarımı, DAX optimizasyonu ve aggregate kurulumu adım adım işlenmektedir.
7. Hangi Sırayla Müdahale Etmeli?
Yavaş bir rapora ilk dokunuş genelde DAX'ı kurcalamak olur ama yanlış sıra budur. Önce modelin şeklini düzeltin: snowflake'i star'a indirgeyin, gereksiz sütunları atın, kardinalitesi yüksek metinleri ayıklayın. Sonra storage mode'a karar verin. Ardından aggregate tablo kurun. En son DAX optimizasyonuna inin. Bu sıra ters çevrildiğinde, iyi yazılmış DAX bile kötü modelin ağırlığını taşıyamaz.
90 saniyede açılan rapor, doğru kurulmuş bir star schema, yerinde bir aggregate ve disiplinli DAX ile 3-5 saniyeye kadar inebilir — donanımı değiştirmeden, veri kaynağını değiştirmeden. Anahtar, motora beklediği şekli vermektir.
Sıkça Sorulan Sorular
Power BI raporum neden açılırken 90 saniye sürüyor?
Genelde sebep veri hacmi değil, modelin şeklidir. Tek dev tabloya bağlı çoklu ilişkiler, snowflake yapı, kardinalitesi yüksek metin sütunları ve fact içinde gereksiz dimension nitelikleri VertiPaq sıkıştırmasını bozar. İlk adım DAX Studio'da VertiPaq Analyzer ile sütun bazında RAM ve kardinalite raporu almak, ardından modeli star schema'ya indirgemektir.
Star schema her senaryoda en doğru tercih midir?
Power BI'ın VertiPaq motoru star schema için optimize edilmiştir, bu yüzden raporlama modellerinde varsayılan tercih olmalıdır. Operasyonel kayıt veya makine öğrenmesi gibi farklı amaçlarda farklı yapılar tercih edilebilir; ancak analitik raporlama söz konusu olduğunda star schema disiplini sorgu hızı ve sıkıştırma açısından net biçimde önde gelir.
Aggregate tablo kurmak DirectQuery zorunluluğu doğurur mu?
Hayır. Aggregate tablolar tamamen Import modunda da kullanılabilir; sadece kullanıcının sık sorduğu kırılımları önceden hesaplanmış olarak tutar. Ancak en yaygın senaryo, agg tablonun Import, detail fact'in DirectQuery olduğu composite modeldir — bu kombinasyon büyük veri ile interaktif deneyimi aynı anda mümkün kılar.
Calculated column ile measure arasında performans farkı var mıdır?
Evet, ciddi fark vardır. Calculated column model yüklenirken hesaplanır ve sonuçları diskte tutulur, bu da dosya boyutunu ve RAM kullanımını artırır. Measure ise sadece sorgu anında çalışır, depolama maliyeti yoktur. Mümkün olan her durumda measure tercih edilmeli; column ancak filter veya relationship için gerçekten gerekiyorsa kullanılmalıdır.
Bi-directional ilişkiden neden kaçınmak gerekiyor?
Bi-directional ilişki, filtre yayılımını her iki yöne açtığı için sorgu planını karmaşıklaştırır ve beklenmeyen sonuçlara yol açabilir. Performans tarafında da çift yönlü filter propagation maliyetlidir. Many-to-many gerçekten kaçınılmazsa kullanılmalı, aksi durumda tek yönlü ilişki ve gerektiğinde CROSSFILTER fonksiyonu daha kontrollü bir alternatiftir.
DISTINCTCOUNT ölçüsünü aggregate ile hızlandırabilir miyim?
Doğrudan hayır; DISTINCTCOUNT toplanabilir bir fonksiyon olmadığı için klasik aggregate'a yansımaz. Pratik çözüm, sık kullanılan distinct count kırılımları için ayrı bir önceden hesaplanmış tablo tutmak veya HyperLogLog tabanlı yaklaşık sayım yaklaşımları kullanmaktır. Tasarım aşamasında bu ölçülerin maliyetini baştan planlamak gerekir.
Performance Analyzer'da yüksek DAX süresi gördüğümde nereden başlamalıyım?
Önce Copy Query ile sorguyu DAX Studio'ya alın, Server Timings açıkken çalıştırın. Storage Engine süresi yüksekse model tarafında — büyük tablo taraması veya kötü sıkıştırma — sorun var demektir. Formula Engine süresi yüksekse DAX ifadesi karmaşıktır; iterator kullanımı, gereksiz CALCULATE veya context transition gibi noktalar gözden geçirilmelidir.
Dual storage mode tam olarak ne işe yarar?
Dual mode, bir tablonun aynı anda hem Import gibi hem DirectQuery gibi davranabilmesini sağlar. Sorgu motoru, ilgili sorgunun ihtiyacına göre hangi modu kullanacağına karar verir. Bu özellikle dimension tabloları için idealdir: küçük ve sık kullanıldıkları için Import hızı verir, ama DirectQuery fact ile ilişki kurulduğunda kaynağa inmeden de cevap verebilir.
