Power BI Performans Optimizasyonu: Modelleme, Star Schema, Aggregation ve Hızlandırma Teknikleri
Power BI raporları ilk günlerde “uçuyor” gibi hissedilir. Veri azdır, sayfa sayısı azdır, ölçüler basittir. Zamanla veri büyür, kullanıcı sayısı artar, raporlar çoğalır ve bir noktada kaçınılmaz şikâyet gelir: “Filtre değişince rapor bekletiyor.”
Buradaki kritik gerçek şu: Power BI performansı tek bir ayarla düzelmez. Performans; modelleme, ilişkiler, veri hazırlama (Power Query), DAX, yenileme (refresh) ve rapor tasarımı gibi katmanların toplamıdır. Bu yazıda, özellikle kurumsal projelerde en çok fark yaratan dört başlığa odaklanacağız:
- Modelleme yaklaşımı
- Star Schema (yıldız şema)
- Aggregation (özet tablolar)
- Hızlandırma teknikleri (DAX, tasarım, refresh, mod seçimi)
Hedefimiz net: daha hızlı açılan sayfalar, daha seri filtre tepkileri, büyüdükçe bozulmayan bir mimari.
Power BI Neden Yavaşlar? (Kök Nedenleri Doğru Teşhis Edin)
Power BI’daki yavaşlığın tipik kaynakları genelde şuralardan çıkar:
1) Veri hazırlama (Power Query) ve kaynak sorguları
- Gereksiz kolonlar çekilir, model şişer
- Ağır dönüşümler Power BI tarafında yapılır (kaynak yerine)
- Query Folding bozulur, veri çekme süresi uzar
2) Model katmanı (VertiPaq + ilişkiler)
- Star schema yerine “karma model” kurulur
- Çok sayıda tablo, belirsiz join yolları
- Çift yönlü ilişkiler (Both) kontrolsüz kullanılır
- Yüksek kardinalite (çok benzersiz değer) kolonlar modeli ağırlaştırır
3) DAX (measure) katmanı
- Gereksiz iterasyon (SUMX, FILTER)
- Aynı hesaplar tekrar tekrar yaptırılır
- Filtre bağlamı gereksiz büyür
4) Rapor tasarımı
- Bir sayfada aşırı görsel (15–25+), hepsi etkileşimli
- Çok fazla slicer, cross-highlighting
- Detay tablolar tek sayfada “her şey” olarak sunulur
Bu yüzden performans optimizasyonu, “önce ölç – sonra düzelt” disiplinidir.
Önce Ölçün: Performans Sorunu Nerede?
Optimizasyona başlamadan önce “sorun nerede”yi bulun. Pratik yaklaşım:
- Sayfa mı yavaş? (ilk açılış)
- Filtre mi yavaş? (slicer değişince)
- Görsel mi yavaş? (özellikle matrix/tablo)
- Refresh mi yavaş? (yayınlama sonrası yenileme)
Power BI Desktop’ta en basit ve etkili başlangıç:
- Performance Analyzer ile hangi görselin ne kadar süre aldığını görün.
- Eğer DAX şüphesi varsa, ölçüleri sadeleştirmek için “ölçü bazlı” ilerleyin.
- Eğer model şüphesi varsa, tablo/kolon/ilişki tasarımına dönün.
Performansın Temeli: Doğru Modelleme Mantığı
Power BI’ın Import modunda performans motoru VertiPaq’tır (kolon bazlı sıkıştırma). VertiPaq en iyi performansı şu koşullarda verir:
- Fakt tablolar (transaction/hareket) net ve sade
- Boyut tablolar (dimension) tekrar kullanılabilir
- İlişkiler tek yönlü, anlaşılır
- Model “okunaklı” ve tahmin edilebilir
Bu noktada Star Schema devreye girer.
Star Schema Nedir ve Neden Power BI’ı Hızlandırır?
Star Schema (yıldız şema), BI dünyasında performans ve sürdürülebilirlik için en sık kullanılan modelleme yaklaşımıdır.
Star Schema yapısı
- Ortada Fact: satış satırları, fatura satırları, stok hareketleri, log kayıtları gibi “olay” tablosu
- Etrafında Dimension: Tarih, ürün, müşteri, depo, bölge, personel gibi “tanım” tabloları
Altın kural: Filtreler Dimension’dan Fact’e akar.
Power BI’da star schema performansı neden iyidir?
- Join yolları netleşir, belirsizlik azalır
- Filtre bağlamı daha küçük ve daha hızlı çalışır
- DAX ölçüleri daha az “çapraz tablo” işi yapar
- Model büyüdükçe yönetim kolaylaşır
Sık yapılan hata: “Her tabloyu bağlayalım”
Özellikle operasyonel sistemden gelen tabloları doğrudan rapora atıp “hepsi birbirine bağlı” model kurmak, kısa vadede hızlı başlar ama uzun vadede:
- performansı düşürür,
- doğru sonuç üretmeyi zorlaştırır,
- bakım maliyetini artırır.
İlişki Ayarları: Tek Yön, Doğru Kardinalite, Temiz Anahtar
Modeliniz star schema olsa bile ilişkiler yanlışsa performans yine düşer.
1) Kardinalite (1:* ilişkisi standard)
- Dimension tablosunda anahtar kolon benzersiz olmalı (ProductId gibi)
- Fact tablosunda aynı anahtar çok satırda geçer
Uyarı: Dimension anahtarınız benzersiz değilse many-to-many başlar ve performans/Doğruluk riski artar.
2) Cross filter direction: Varsayılan “Single”
Çift yön (Both) ilişki bazen işleri kolaylaştırır gibi görünür; fakat çoğu kurumsal raporda:
- filtre bağlamını büyütür,
- beklenmedik sonuçlar çıkarabilir,
- performansı düşürür.
Pratik kural:
- %80 senaryoda: Single
- Zorunluysa: kontrollü “Both” ya da DAX ile bilinçli yönlendirme
3) Tarih tablosu (Date dimension) şart
Kurumsal raporlarda tek bir Date tablosu kullanmak hem performansı hem yönetimi kolaylaştırır:
- aynı tarihle ilgili tüm hesaplar tek yerde,
- Year/Quarter/Month/Week gibi kolonlar hazır,
- time intelligence daha stabil.
Modeli Hafifletin: En Hızlı Kazanım Buradan Gelir
Power BI performansında “en hızlı ve net” fark yaratan işlerden biri: modeli zayıflatmak (gereksizi atmak).
Kolonları budayın (Column diet)
- Raporlarda kullanılmayan kolonları modele almayın
- Özellikle fact tablolarda “açıklama/metin” kolonları şişirir
- “Belki lazım olur” kolonları RAM ve hız maliyetidir
Veri tiplerini düzeltin
- Sayısal değer string olmasın
- Tarihler Date/DateTime olarak doğru dursun
- ID kolonları mümkünse integer key ile daha iyi sıkışır
Yüksek kardinaliteyi yönetin
GUID, TransactionId, uzun metin alanları gibi çok benzersiz kolonlar sıkıştırmayı bozar. Çözümler:
- Gereksiz unique kolonları kaldırın
- Metinleri dimension’a taşıyın veya raporda kullanmayın
- “İş için şart değilse” fact’te tutmayın
Power Query (ETL) Performansı: Query Folding’i Korumak
Power Query güçlüdür ama yanlış kullanılırsa performansı öldürür.
Query Folding neden önemli?
Folding varsa Power BI dönüşümleri kaynağa “ittirir” (SQL Server’da çalışır). Folding yoksa Power BI her şeyi kendi üstünde işler: daha yavaş, daha maliyetli.
Folding’i bozan tipik durumlar:
- ağır custom dönüşümler,
- bazı join/dönüşüm kombinasyonları,
- gereksiz satır satır işlemler.
İyi pratik:
- ağır dönüşümleri mümkünse kaynakta çözün (view / DWH katmanı)
- Power Query’yi “hafif temizlik ve şekillendirme” için kullanın
DAX Hızlandırma: Ölçüler Neden Yavaşlar ve Nasıl İyileştirilir?
DAX performansı çoğunlukla iki şeyle ilgilidir:
- Ne kadar satır dolaşıyorsunuz? (iterasyon)
- Filtre bağlamı ne kadar karmaşık?
1) Gereksiz iterasyondan kaçının
SUMX/FILTER gibi fonksiyonlar bazı senaryolarda şarttır ama “refleks” gibi kullanılırsa pahalıdır.
Kendinize sorun:
Bu hesap gerçekten satır satır mı yapılmalı, yoksa agregasyonla çözülebilir mi?
2) VAR kullanın: aynı işi tekrar yaptırmayın
Aynı ara sonucu 2–3 kez hesaplatmak yerine bir kez hesaplatıp tekrar kullanmak çoğu raporda hissedilir fark yaratır.
3) Filtreyi modele taşıyın
Her ölçünün içinde aynı filtre kalıbı dönüyorsa, bu genelde modelleme ile daha sade hale getirilebilir:
- flag kolonlar,
- doğru dimension ilişkileri,
- daha doğru granülerlik.
Aggregation: Büyük Veride “Turbo” Etkisi
Power BI’da milyonlarca satırlık fact tabloyla çalışırken asıl mesele şudur:
Kullanıcıların çoğu zaman detay değil özet görmesi gerekir.
Aggregation (özet tablolar) burada devreye girer.
Aggregation ne sağlar?
- Kullanıcı aylık trend bakarken 50 milyon satırı taramak zorunda kalmaz
- Özet tablo üzerinden “hızlı cevap” alınır
- Detay gerekiyorsa drill-down/drill-through ile detay fact’e gidilir
Ne zaman aggregation şart olur?
- Fact tablo çok büyükse (milyonlar+)
- Raporlar ağırlıkla “gün/ay/ürün kategori/bölge” düzeyinde çalışıyorsa
- Kullanıcı sayısı fazlaysa ve kapasite yönetimi önemliyse
Basit aggregation tasarım reçetesi
- Kullanıcıların en çok baktığı seviyeleri çıkarın: Ay, Bölge, Kategori
- Bu seviyede özet tablo üretin (örn. AylıkSatışÖzet)
- Modelde hem özet hem detay fact’i tutun
- Özet sayfaları özet tablodan, detay sayfaları büyük fact’ten besleyin
Bu yaklaşım, “sadece hız” değil aynı zamanda ölçeklenebilirlik kazandırır.
Incremental Refresh: Yenilemeyi Hızlandırın, Kaynağı Yormayın
Performans sadece rapor açılışı değildir. Refresh süresi uzadıkça:
- kapasite meşgul olur,
- kaynak sistem (SQL/ERP) zorlanır,
- rapor güncelliği riske girer.
Incremental Refresh ile:
- Son X gün/ay sık yenilenir
- Geçmiş veri “dokunulmadan” saklanır
- Yenileme süreleri dramatik şekilde düşer
Özellikle log/transaction verisi büyüyorsa incremental refresh çoğu zaman “olmazsa olmazdır”.
Import vs DirectQuery vs Composite: Doğru Modu Seçin
Yanlış mod seçimi, en iyi modellemeyi bile boşa çıkarabilir.
Import
- En hızlı kullanıcı deneyimi
- RAM kullanır
- Çoğu dashboard senaryosu için ideal
DirectQuery
- Kaynağa anlık gider
- Kaynak iyi tasarlanmadıysa (indeks, view, sorgu) yavaşlar
- “Her görsel = yeni sorgu” maliyetini düşünmek gerekir
Composite (Import + DirectQuery)
- Bazı tablolar import ile hızlı
- Bazıları direct ile güncel
- Kurumsal yapılarda sık kullanılan dengeli yaklaşım
Pratik kural:
“Hız ve kullanıcı deneyimi” öncelikse → Import + iyi modelleme + aggregation
“Anlık veri” kritikse → Composite / kontrollü DirectQuery
Rapor Tasarımıyla Hızlandırma: Görsel Sayısını ve Etkileşimi Yönetin
Modeliniz mükemmel olsa bile, rapor sayfası “aşırı yük” taşıyorsa yavaşlar.
Tasarım için performans kuralları
- Bir sayfada görsel sayısını makul tutun (genelde 8–12 bandı iyidir)
- Çok sayıda slicer yerine “filtre paneli” yaklaşımı düşünün
- Cross-highlighting/cross-filtering etkileşimlerini gerektiği kadar açık bırakın
- Büyük detay tablolarını ayrı sayfaya taşıyın (drill-through)
Özet + Detay mimarisi
- Özet sayfalar: hızlı, KPI odaklı
- Detay sayfalar: filtrelenmiş, amaçlı analiz
Bu yaklaşım hem performansı hem kullanıcı memnuniyetini artırır.
10 Dakikada Hız Kazandıran Kontrol Listesi (Quick Wins)
Hızlı bir iyileştirme turu yapmak isterseniz:
- Kullanılmayan kolonları modelden kaldırdım
- Metin/GUID ağırlıklı kolonları fact’ten temizledim
- İlişkileri çoğunlukla Single yaptım
- Many-to-many ilişkileri azalttım / kontrol altına aldım
- Date dimension kullandım
- Slicer sayısını azalttım, sayfayı sadeleştirdim
- En yavaş görseli Performance Analyzer ile tespit ettim
- En pahalı DAX ölçülerini VAR ile sadeleştirdim
Bu checklist bile çoğu projede “ilk etap”ta hissedilir fark yaratır.
Sonuç: Power BI Performansı “Şans” Değil, Mimari İşidir
Power BI performans optimizasyonu; rastgele ayarlarla değil, doğru modelleme ve doğru strateji ile çözülür. Star schema ile sadeleşen model, kontrollü ilişkiler, temiz veri hazırlama, iyi DAX pratikleri ve gerektiğinde aggregation/incremental refresh gibi teknikler birleştiğinde:
- Raporlar hızlı açılır
- Filtreler seri tepki verir
- Veri büyüdükçe sistem bozulmaz
- Kullanıcı sayısı artsa bile yönetilebilir kalır
Sıradaki Okumalar (İç Link Önerileri)
Web sitende aynı formatta şu içeriklerle birbirine linkleyebilirsin:
- DAX Rehberi: En Sık Kullanılan Measure Desenleri
- SSRS vs Power BI: Hangi Senaryoda Hangisi?
- SSIS ile ETL Performans Optimizasyonu: Incremental Load ve Hata Yönetimi
CTA (İletişim / Hizmet Metni)
Power BI raporlarınız yavaşsa, çoğu zaman sorun tek yerde değildir: model + DAX + veri + tasarım birlikte ele alınmalıdır. İstersen mevcut raporlarınız için performans analizi çıkarıp, star schema dönüşümü, aggregation planı ve incremental refresh stratejisiyle net bir iyileştirme yol haritası hazırlayabiliriz.
