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.

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.

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.

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:

1. Hangi ölçüler ve hangi granülde toplanacak — kullanım istatistiklerine bakarak karar verin.
2. Agg tablonun dimension'ları detail fact ile aynı dimension'lara bağlanmalı (manage aggregations ekranında eşlenir).
3. SUM, COUNT, MIN, MAX agg'a yansır; DISTINCTCOUNT yansımaz — bu ölçüler için ayrı strateji gerekir.
4. Import mode agg + DirectQuery detail kombinasyonu, büyük modellerde en yaygın hibrit desendir.

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.

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.

Ö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.

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.