POWER BI PERFORMANS OPTİMİZASYONU: MODEL BOYUTU VE GÖRSEL STRATEJİSİ

Power BI raporları ilk başta “hızlı” hissettirir; veri büyüdükçe ve görseller çoğaldıkça aynı rapor bir anda ağırlaşabilir. Kullanıcı tarafında bu durum “filtreye basıyorum, bekliyorum” olarak görünür; arka planda ise model boyutu, ilişkiler, DAX hesaplama maliyeti ve görsel sorgu sayısı birleşerek gecikme yaratır.

Bu yazıda performansı iki ana eksende ele alacağız: model boyutu (data model + sıkıştırma + ilişkiler) ve görsel stratejisi (sayfa tasarımı + etkileşimler + sorgu sayısı). Hedef, raporun hem hızlı açılması hem de slicer/filtre etkileşimlerinde “akıcı” kalması.

Yaklaşımımız pratik: önce ölç, sonra sadeleştir, sonra katmanlı optimizasyon uygula. Bu sayede “her şeyi DAX ile çözmek” ya da “her şeyi DirectQuery yapmak” gibi uçlara savrulmadan, doğru noktaya yatırım yaparsınız. Daha kapsamlı bir yol haritası için Power BI Eğitimi içeriğine de göz atabilirsiniz.

Primary keyword: Power BI performans optimizasyonu için doğru teşhis

Performans iyileştirme çoğu zaman “hızlandırma”dan önce neyin yavaşlattığını bulma işidir. Power BI Desktop’ta model ve rapor tarafını ayrı ayrı düşünmek gerekir: veri modeli iyi olsa bile görsel kurgusu kötü ise sayfa açılışı ağır olur; görseller iyi olsa bile model şişkin ise bellek ve CPU tüketimi artar.

İlk adım olarak üç noktayı kontrol edin: (1) model boyutu ve kolon sayısı, (2) ilişkiler ve kardinalite, (3) sayfa başına görsel sayısı ve etkileşimler. Bu çerçeve, hızlı “kök neden” bulmanıza yardım eder.

Ölçmeden optimize etmeyin: Performance Analyzer ve DAX Studio

Rapor sayfasını açtığınızda hangi görselin ne kadar süre tuttuğunu görmek için Performance Analyzer kullanın. DAX hesaplamalarında ise sorgu planı ve depolama motoru/hesaplama motoru ayrımını incelemek için DAX Studio değerlidir. Buradaki amaç “en pahalı 3 noktayı” bulup önce onları düzeltmektir.

// Basit bir ölçüm kontrol listesi (yorum satırı olarak)
// 1) Performance Analyzer: Visual display time + DAX query time
// 2) Model: tablo/kolon sayısı, yüksek kardinalite sütunlar
// 3) İlişkiler: bi-directional, many-to-many, belirsiz filtre akışı

Hız algısı: sayfa açılışı ile etkileşim gecikmesini ayırın

Kullanıcıların şikâyeti bazen “sayfa geçişleri yavaş”, bazen “slicer değişince gecikiyor” şeklindedir. Sayfa açılışı genellikle görsel sayısı ve görsel başına sorgu maliyetiyle ilişkilidir; etkileşim gecikmesi ise model tasarımı ve DAX karmaşıklığıyla daha doğrudan bağlantılıdır.

Model boyutunu küçültme: sıkıştırma, kolon seçimi ve veri tipleri

Power BI’ın VertiPaq motoru kolon bazlı sıkıştırmada çok güçlüdür; ancak gereksiz kolonlar, yüksek kardinalite ve yanlış veri tipleri sıkıştırma verimini düşürür. Model boyutu büyüdükçe bellek baskısı artar, yenilemeler uzar ve sorgu yanıtı yavaşlayabilir.

Gereksiz kolonları kaldırın: “şimdi lazım değil” bile pahalıdır

Özellikle kaynak sistemlerden “her ihtimale karşı” alınan kolonlar modelin şişmesine yol açar. Metin alanları, GUID’ler, serbest açıklamalar gibi kolonlar çoğu raporda görselleştirilmez ama sıkıştırmayı kötüleştirir. İyi pratik: rapor gereksinimlerinde kullanılmayan kolonları Power Query’de kaldırıp modele hiç sokmamak.

Yüksek kardinaliteyi yönetin: metin yerine surrogate key ve özetleme

Ürün kodu, müşteri e-posta adresi, işlem numarası gibi alanlar yüksek kardinalite üretir. Bu alanların doğrudan görsel ekseni veya slicer olması pahalıdır. Çözüm olarak: ilişki tarafında numeric surrogate key kullanın, metin alanlarını boyut tablosunda tutun; görselleştirmede ise mümkün olduğunda gruplama/özetleme kullanın.

Doğru veri tipi ve format: tarih/saat ve decimal tuzakları

Tarih-saat kolonlarını gerçekten saat düzeyi gerekmiyorsa yalnızca tarih olarak saklamak, ondalıklı sayıları gereksiz yüksek hassasiyette tutmamak model boyutunu düşürür. Ayrıca “metin gibi duran sayılar” hem sıkıştırmayı hem de DAX dönüşümlerini pahalılaştırır. Power Query’de tipi en başta doğruya çekmek iyi bir alışkanlıktır.

Veri modeli tasarımı: star schema, ilişki yönü ve kardinalite

Power BI performansında en çok kazandıran hamlelerden biri düzgün bir star schema kurmaktır. Boyut tabloları filtreler, fakt tablo ölçümlenir; karmaşık ilişki ağları yerine sade ve tahmin edilebilir bir filtre akışı oluşur. Bu, hem DAX yazımını basitleştirir hem de sorgu planlarını daha verimli hale getirir.

Tek yönlü ilişkiler ve net filtre akışı

Bi-directional ilişkiler bazı senaryolarda pratik görünse de filtre yayılımını artırarak sorgu maliyetini yükseltebilir. Mümkün olduğunda tek yönlü ilişkileri tercih edin ve ölçüleri CALCULATE ile kontrollü şekilde yönetin. “Her yerden her yere filtre” yerine “ihtiyaç anında hesaplama” yaklaşımı daha ölçeklenebilirdir.

Many-to-many ilişkilerde köprü tablo stratejisi

Many-to-many ilişkiler performans açısından risklidir. Eğer kaçınılmazsa, köprü (bridge) tablo ile modeli stabilize edin ve görsel düzeyinde kullanılacak alanları dikkatle seçin. Ayrıca kimlik (key) alanlarının tiplerini uyumlu tutmak ve boş değerleri yönetmek gereksiz taramaları azaltır.

Ölçü tablosu ve adlandırma: bakım maliyeti performansı da etkiler

Model büyüdükçe ölçülerin dağınık olması hem geliştirmeyi yavaşlatır hem de yanlış hesapların tekrar tekrar hesaplanmasına neden olur. Ölçüleri merkezi bir tabloda toplamak, açıklama eklemek ve tutarlı adlandırma yapmak; ekiplerin “aynı işi iki kez yazma” riskini düşürür.

Power Query performansı: query folding, adım sayısı ve veri yenileme

Rapor performansı sadece görsel yanıtı değildir; yenileme süresi de operasyonel maliyettir. Power Query tarafında hedef, mümkün olduğunca kaynağa “katlanabilen” (query folding) dönüşümlerle çalışmak ve veri çekimini minimuma indirmektir.

Query folding’i koruyun: filtreyi en başa alın

Filtreleme ve kolon seçimini erken yapmak, kaynağın işi yapmasını sağlar. Özellikle SQL tabanlı kaynaklarda folding kaybolursa Power BI tarafında gereksiz veri çekimi olur. Dönüşümleri adım adım gözden geçirip folding’i bozan işlemleri tespit edin.

Incremental refresh ve partition mantığı

Büyük fakt tablolarında her seferinde tüm geçmişi yenilemek yerine incremental refresh ile sadece yeni/son dönemi güncellemek ciddi kazanım sağlar. Bu sayede yenileme pencereleri kısalır ve kaynak sistem yükü azalır. Doğru tarih alanı seçimi ve aralıkların iş ihtiyacına göre ayarlanması kritiktir.

Aggregation tables: detay yerine özet üzerinden hız

Özellikle yüksek hacimli transaction verilerinde, kullanıcıların çoğu zaman ay/hafta/ürün grubu gibi özet seviyede analiz yaptığını görürsünüz. Aggregation table yaklaşımı, detay veriyi gerektiğinde tutarken sık kullanılan özet sorguları hızlandırır.

// Aggregation örneği (DAX ile özet tablo üretimi - konsept amaçlı)
Agg_Sales_ByMonth =
SUMMARIZECOLUMNS(
  'Date'[Year],
  'Date'[Month],
  'Product'[Category],
  "SalesAmount", SUM('Sales'[SalesAmount]),
  "OrderCount", DISTINCTCOUNT('Sales'[OrderId])
)

Görsel stratejisi: sayfa başına sorgu sayısını azaltma

Rapor sayfalarında performansın düşmesinin en yaygın nedeni, aynı anda çok fazla görselin çalışması ve her birinin ayrı sorgu üretmesidir. Özellikle karmaşık ölçülerle beslenen çok sayıda kart, matris ve özel görsel sayfa açılışını ağırlaştırır. Buradaki hedef, “görsel sayısını azaltmak”tan çok “görsel başına maliyeti ve eşzamanlı sorgu sayısını” düşürmektir.

Gereksiz etkileşimleri kapatın ve filtre akışını sadeleştirin

Her slicer’ın her görseli etkilemesi şart değildir. Edit interactions ile yalnızca ihtiyaç duyulan etkileşimleri açık bırakın. Bu, hem sorgu sayısını hem de görsellerin tekrar render edilmesini azaltır. Ayrıca aynı işi yapan birden fazla slicer yerine hiyerarşik slicer veya senkronize slicer kullanmak daha kontrollüdür.

Görsel türü seçimi: matris ve custom visual maliyeti

Matris görselleri yüksek satır/sütun kombinasyonlarında pahalıdır. Custom visual’lar ise render maliyeti ve ek hesaplama gerektirebilir. Kullanım amacına göre daha hafif alternatifler (ör. bar chart + drillthrough) düşünün. Kurumsal kullanımda “ilk ekranda özet, detayda ayrı sayfa” yaklaşımı genellikle daha hızlıdır.

Alan sayısını sınırlayın: özellikle tooltips ve detay kolonları

Bir görselin tooltips alanına eklediğiniz her ölçü, sorgu maliyetini artırabilir. Detay kolonlarını “detay sayfasına” taşıyın; ana sayfada yalnızca karar vermeyi sağlayan metrikleri bırakın. Bu, kullanıcı deneyimini de iyileştirir çünkü dikkat dağıtan kalabalık azalır.

DAX performansı: ölçü tasarımı, filtre bağlamı ve hesaplama maliyeti

DAX performansında kritik nokta, ölçünün hem hesaplama motorunu hem de depolama motorunu nasıl kullandığıdır. Daha az satır taramak, daha az karmaşık filtre bağlamı oluşturmak ve tekrar eden hesapları azaltmak temel hedeflerdir.

Iterator yerine toplulaştırma: SUMX her zaman kötü değil, ama pahalı olabilir

SUMX, AVERAGEX gibi iterator’lar satır satır hesaplama yaptığı için büyük tablolarda maliyeti yükseltebilir. Mümkünse depolama motoruna yakın toplulaştırmalar (SUM, COUNT, DISTINCTCOUNT) ile başlayın. İhtiyaç varsa iterator kullanın ama tabloyu filtreleyip küçülttükten sonra çalıştırın.

SELECTEDVALUE ve CALCULATE: bağlamı kontrol ederek hız kazanın

Ölçülerde gereksiz IF dallanmaları, karmaşık FILTER ifadeleri ve geniş kapsamlı ALL kullanımı performansı düşürebilir. Filtre bağlamını netleştirmek için SELECTEDVALUE ile kullanıcı seçimlerini güvenli okumak, CALCULATE ile değişiklikleri hedefli yapmak daha verimli olur.

// Daha kontrollü bir ölçü örneği: hedefli bağlam yönetimi
Total Sales :=
SUM ( 'Sales'[SalesAmount] )

Sales (Selected Year) :=
VAR y = SELECTEDVALUE ( 'Date'[Year] )
RETURN
IF (
  NOT ISBLANK ( y ),
  CALCULATE ( [Total Sales], 'Date'[Year] = y ),
  [Total Sales]
)

Önbellek ve tekrar kullanım: ölçüleri bölüp yeniden kullanın

Bir ölçü içinde aynı hesaplama parçalarını tekrar tekrar yazmak hem bakımı zorlaştırır hem de bazı senaryolarda gereksiz maliyet yaratır. Ortak parçaları ayrı ölçülere bölmek, rapor genelinde tutarlılığı artırır. Ayrıca görsellerde hesaplanan değerleri “aynı” ölçüden çağırmak, farklı varyantların çoğalmasını engeller.

DirectQuery, Composite Model ve kapasite yönetimi

DirectQuery “gerçek zamanlı” ihtiyacını karşılayabilir; ancak her etkileşimde kaynağa giden sorgular gecikme üretir. Composite model ile boyutları içeri alıp faktı DirectQuery’de bırakmak, bazı senaryolarda iyi denge sağlar. Burada kritik olan, veri kaynağı performansı ve ağ gecikmesinin rapor deneyimini doğrudan etkilediğidir.

Ne zaman Import, ne zaman DirectQuery?

Yüksek etkileşimli dashboard’lar ve sık kullanılan metrikler için Import genellikle daha hızlıdır. Gerçek zamanlı stok/operasyon gibi senaryolarda DirectQuery mantıklıdır ama görsel sayısını ve karmaşıklığı azaltmak gerekir. Ayrıca indeksleme, özet görünümler ve parametrik filtreler kaynağa binen yükü azaltır.

Kapasite ve eşzamanlılık: kullanıcı sayısı artınca ortaya çıkan sorunlar

Tek bir geliştirici makinesinde “hızlı” görünen rapor, çok kullanıcıyla paylaşıldığında yavaşlayabilir. Eşzamanlı sorgular, kapasite CPU/bellek ve veri yenileme çakışmaları performansı etkiler. Yayın sonrası izleme, kapasite metrikleri ve kullanım analizleriyle darboğazları görünür kılmak önemlidir.

Uygulanabilir bir kontrol listesi: 30 dakikada hızlı kazanımlar

Aşağıdaki adımlar, çoğu kurumsal raporda kısa sürede ölçülebilir iyileştirme sağlar. Önce en pahalı noktaları bulun, sonra sırayla ilerleyin; her adım sonrası tekrar ölçüm yapın.

1. Modelden kullanılmayan kolonları kaldırın, veri tiplerini düzeltin.
2. İlişkileri star schema’ya yaklaştırın, bi-directional kullanımını azaltın.
3. Performance Analyzer ile en pahalı 3 görseli belirleyin ve sadeleştirin.
4. Tooltips ve detay alanlarını azaltın, etkileşimleri gereksizse kapatın.
5. DAX ölçülerinde iterator/FILTER yoğun noktaları hedefli optimize edin.
6. Büyük tablolar için incremental refresh ve gerekiyorsa aggregation düşünün.

Bu düzen, raporu sadece hızlandırmaz; aynı zamanda bakım maliyetini düşürür ve ekip içinde daha öngörülebilir bir geliştirme standardı oluşturur. Özellikle büyüyen veri hacminde, model boyutu ve görsel stratejisi birlikte yönetildiğinde kalıcı performans elde edilir.