POWER BI PERFORMANS OPTİMİZASYONU

Power BI sarı logosu yanında hız göstergesi iğnesi yeşil bölgede, rapor performansı simgeleniyor

İlk haftalarında akıcı çalışan bir Power BI raporu altı ay sonra açılışı yirmi saniye süren, görsellerin yüklenmesi dakikalar alan bir yapıya dönüşebilir. Sorun veri büyümesi değildir genelde; tasarımın yanlış kararlarıdır. Performans optimizasyonu rapora son anda eklenen bir cila değildir; baştan doğru tasarımdan gelen kalıcı bir özelliktir. Bu yazı performansı belirleyen kararların nereden geldiğini ve nasıl düzeltileceğini ele alıyor.

Yıldız Şeması Disiplini

Power BI performansının en büyük belirleyicisi veri modelinin yapısıdır. Yıldız şeması (star schema) yaklaşımıyla kurulmuş modeller; merkezde fact tabloları, çevresinde dimension tabloları; en hızlı çalışan modellerdir. Düz tabloda (flat table) tutulan veri görünüşten dolayı pratik gibi durur ama performans olarak çok zayıftır. Snowflake (dimension'lar arasında alt ilişkilerle) modelleri ise yıldıza göre daha yavaştır.

Var olan modeli yıldız şemasına çevirmek başlangıçta zahmetli olabilir ama uzun vadede performans kazanımı çoğu zaman birkaç katı olur. Power Query bu dönüşümü yapmak için doğru yerdir; flat tablo dimension ve fact'lere bölünür.

Sütun Tipi ve Boyutu

Bir sütunun veri tipi performansı doğrudan etkiler. Tamsayı (integer) sütunlar metin (text) sütunlardan çok daha hızlıdır. Tarih sütunları tarih olarak (date) saklanmalı, metin olarak değil. Decimal sayılar fixed decimal type olarak işaretlendiğinde daha hızlı işlenir.

Yüksek kardinaliteli (çok sayıda farklı değer içeren) sütunlar bellek tüketir ve performansı düşürür. Müşteri ID'si gibi yüksek kardinaliteli sütun zorunluysa olduğu gibi kalır ama "Yorum" tipi açık metin sütunları görsel olarak gerekmediği sürece modele alınmaz. Power Query'de gereksiz sütunlar baştan filtrelenir; "olur belki gerekir" düşüncesiyle modeli şişirmek performansı düşürür.

Merkezde fact tablo küpü ve çevresinde dört boyut küpü ile sade yıldız şema modeli

DAX Ölçü Yazımı

DAX ölçülerinin verimliliği performansı belirgin biçimde etkiler. SUMX gibi iteratif fonksiyonlar tek bir SUM'dan daha yavaştır; gerek olmadıkça SUMX kullanılmaz. CALCULATE içine yazılan filtre ifadeleri performansı doğrudan etkiler; basit filtreler (Tarih[Yıl] = 2026 gibi) karmaşık filtre ifadelerinden çok daha hızlıdır.

FILTER fonksiyonu kuvvetli ama pahalıdır. Aynı sonucu üreten iki yazımın performans farkı tipik olarak şu biçimde olur:

// Yavaş — FILTER tüm Tarih tablosunu satır satır gezer
2026 Satış =
CALCULATE(
 SUM(Satis[Tutar]),
 FILTER(Tarih, Tarih[Yıl] = 2026)
)

// Hızlı — basit filtre VertiPaq motorunda doğrudan uygulanır
2026 Satış =
CALCULATE(
 SUM(Satis[Tutar]),
 Tarih[Yıl] = 2026
)

FILTER sadece gerçekten karmaşık koşullar için (örneğin başka bir ölçünün sonucuyla karşılaştırma) kullanılır.

Görsel Strateji

Bir sayfada çok fazla görsel olması performansı düşürür. Her görsel kendi DAX sorgusunu çalıştırır; on beş görsel olan sayfa açılırken on beş sorgu paralel çalışır. Beş on görsel çoğu zaman yeterlidir; daha fazla ihtiyaç varsa sayfaları ayırmak daha doğru bir tercihtir.

Tablo veya matrix görselleri çok satır gösteriyorsa pahalıdır. On bin satırlık bir tablo görseli açılırken performans cezası alır. Bu tip görseller için "Top N" filtresiyle gösterim sınırlandırılır veya pivot benzeri özet yapısıyla satır sayısı azaltılır.

Tooltip ve Drill-Through

Görsellerde tooltip ve drill-through (detaylara inme) özellikleri kullanıcı deneyimi için değerli ama performans yükü getirir. Güncel özellikler ve seçenekler Power BI resmi belgelerinde listelenir. Her hover'da tooltip için yeni sorgu çalışır. Kompleks tooltip raporu yerine basit tooltip ile yetinmek hızı korur.

Drill-through sayfaları üzerinde RLS ve filtre etkileşimleri detaylı hesaplama yapar. Bu yüzden drill-through sayfaları sade tutulur; ana sayfanın tüm görselleri tekrar gösterilmez.

Aggregation Tabloları

Büyük veri setleri için aggregation tabloları performans için kritiktir. Detay tablo binlerce milyon satır içerse de ay bazında özet tablo binlerce satır olur. Power BI'a hangi sorgu için hangi tabloyu kullanacağı öğretilir; ay bazında istenen sorgu özet tabloya, gün bazında istenen sorgu detay tabloya gider. Bu yapı çoğu rapor sorgusunu hızlı tablodan çalıştırır.

Aggregation Premium kapasite veya Premium Per User lisansı gerektirir. Bu özelliği kullanmak için lisans bütçesi planlanır; ölçek büyüdüğünde yatırım kendini kısa sürede çıkarır.

Yenileme Stratejisi

Veri yenileme stratejisi de performansa etki eder. Üç ana seçenek vardır ve seçim performansın temelini belirler:

  • Import mode: Veri Power BI tarafına alınır; sorgular bellekte çalışır, çok hızlıdır. Çoğu raporlama senaryosunda tercih edilir.
  • DirectQuery: Her sorgu kaynağa gider; performans kaynağa bağımlıdır. Sadece çok büyük veri setlerinde veya canlı veri zorunluluğunda kullanılır.
  • Composite (hibrit): Bazı tablolar Import, bazıları DirectQuery olarak işaretlenir. Dimension tabloları Import, devasa fact tabloları DirectQuery olarak tutulur.

Incremental refresh büyük tablolar için yenileme süresini büyük ölçüde azaltır. Her gün tüm tabloyu yenilemek yerine son haftayı yenilemek hız kazandırır. Bu özellik Premium lisansta veya Pro'da 1 GB altındaki veri setlerinde çalışır.

Aylık takvim üzerinde tarihi geçmiş günler gri ve son yedi gün sarı vurgulu artımlı yenileme akışı

Performance Analyzer

Power BI Desktop'ta yerleşik Performance Analyzer aracı hangi görselin ne kadar sürdüğünü ölçer. View menüsünde Performance Analyzer açılır, kaydetme başlatılır, sayfa yenilenir, ölçümler listelenir. Bu detaylar hangi görsellerin yavaş olduğunu, ne kadar süre DAX'ta ne kadar süre render'da harcandığını gösterir.

Bu analiz sürekli yapılmaz ama yeni rapor yapılırken ve sorun çıktığında değerli bir araçtır. Performance Analyzer çıktısı yöneticilere "şu görsel beş saniye sürüyor" deyip somut bir iyileştirme planı önermenizi sağlar.

VertiPaq Analyzer

Veri modelinin bellek kullanımını analiz etmek için VertiPaq Analyzer (DAX Studio veya Tabular Editor ile) kullanılır. Hangi tablonun ne kadar bellek tükettiğini, hangi sütunun en büyük olduğunu gösterir. Bu analizden çıkan sonuçlar modelin nereden küçültüleceğini gösterir; yüksek bellek tüketen sütunlar gözden geçirilir ve gereksiz olanlar atılır.

Performans optimizasyonu disiplin gerektiren bir konudur ama doğru yapıldığında raporlama deneyimini kökten dönüştürür. Power BI eğitimi bu disiplini gerçek model örnekleri üzerinden uygulamalı olarak öğretir.

Sıkça Sorulan Sorular

Yıldız şeması her zaman daha mı hızlı?

Power BI'ın VertiPaq motoru yıldız şeması için optimize edilmiştir; çoğunlukla yıldız hem hızlı hem bakımı kolaydır. Çok özel durumlar dışında yıldız tercih edilir.

Çok büyük tabloda Direct Query mı Import mu?

Hızlı tepki istiyorsanız ve veri tek seferde çekilebiliyorsa Import. Veri tek seferde çekilemez veya canlı olması zorunluysa Direct Query. Hibrit yaklaşım (composite model) de bir seçenektir.

DAX optimizasyonu için ne öğrenmek lazım?

Filter context ve row context kavramları temeldir. Bunlar üzerine CALCULATE, FILTER, ALL, KEEPFILTERS, REMOVEFILTERS fonksiyonlarının nasıl çalıştığını bilmek gerekir. DAX Studio araçla pratik gelir.

Görsel sayısı kaç olabilir?

Sayfa başı altı sekiz görsel pratik bir hedeftir. On beş üzeri görsel hem performansı düşürür hem kullanıcı dikkatini dağıtır. Çok bilgi için sayfa bölmek tercih edilir.

Power Query ile DAX arasında performans nasıl?

Hesaplamalar mümkün olduğu kadar Power Query'de yapılır; modele temiz veri girer. DAX runtime'da hesaplama yapar, bu yüzden DAX'a kalan iş azaltıldıkça performans iyileşir.

Premium kapasite şart mı?

Standart raporlama için değil. Aggregation, incremental refresh ve büyük veri için Premium gerekli olabilir. Karar veri büyüklüğü ve kullanıcı sayısına göre verilir.