POWER BI PERFORMANS: VERİ MODELLEME, CARDİNALİTY VE OPTİMİZASYON

Power BI’de yavaşlayan raporların çoğu “daha güçlü bilgisayar” ihtiyacından değil, modelin yanlış büyümesinden kaynaklanır. Veri modeli, DAX ve sorgu katmanı birbiriyle uyumlu tasarlandığında; aynı veriyle daha hızlı yenileme, daha akıcı filtreleme ve daha düşük bellek tüketimi elde edersiniz.

Performans optimizasyonu bir “son dakika cilası” değil, baştan uca tasarım yaklaşımıdır: doğru şema, düşük cardinality, amaçlı sütunlar, ölçeklenebilir ölçüler ve kaynakta katlanabilen (folding) sorgular. Bu yazıda, Power BI performansını sistematik biçimde iyileştirmek için veri modelleme, cardinality ve optimizasyon pratiklerini bir araya getiriyoruz.

Hedefimiz şu: rapor deneyimini hızlandırırken modelin okunabilirliğini ve bakım kolaylığını da artırmak. Çünkü hızlı ama karmaşık bir model, kısa vadede iyi görünse de uzun vadede rapor sahipliği maliyetini yükseltir.

Power BI performansını belirleyen temel: veri modelleme zihniyeti

Power BI’da performansın kalbi, içe aktarılan verinin VertiPaq motoru tarafından nasıl saklandığı ve ilişkiler üzerinden nasıl filtrelendiğidir. Bu yüzden optimizasyonu yalnızca DAX’a indirgemek yanıltıcı olur. Model tasarımı doğruysa, ölçüler daha az hesap yapar; görseller daha az satır tarar ve dilimleyiciler daha az bellek taşır.

İlk karar genellikle bağlantı modudur. Import, VertiPaq sıkıştırması sayesinde hızlı sorgu verir; DirectQuery ise kaynağa bağımlıdır ve her görselde arka uç sorgusu üretebilir. Composite modeller hibrit esneklik sağlar ama ilişkiler ve yönler artınca karmaşıklık büyür. Buradaki amaç, “her şeyi DirectQuery yapayım” değil, iş ihtiyacına göre en az maliyetli yolu seçmektir.

Import, DirectQuery ve karma modellerde doğru beklenti

Import modunda rapor performansı büyük ölçüde modelin boyutu ve ilişkilerin tasarımına bağlıdır. DirectQuery’de ise veri kaynağının indeksleri, sorgu planı ve ağ gecikmesi belirleyici olur. Karma modelde, görselin kullandığı tabloların moduna göre farklı motorlar devreye girer; bu nedenle veri akışını ve filtre yayılımını daha dikkatli kurgulamak gerekir.

VertiPaq sıkıştırma mantığını anlamak: neden bazı modeller şişer?

VertiPaq kolon bazlı saklama kullanır. Tekrarlayan değerler sözlük (dictionary) ile tutulur ve veriler sıkıştırılır. Bu yüzden düşük cardinality, genellikle daha iyi sıkıştırma demektir. Bir sütun milyonlarca benzersiz değer içeriyorsa (örneğin tam zaman damgası veya GUID), sözlük büyür ve bellek tüketimi artar. Performans iyileştirmesi çoğu zaman “sütun azaltma” ve “cardinality düşürme” ile başlar.

• Gereksiz sütunları yüklemeyin; raporda kullanılmayan her sütun, model boyutunu artırabilir.
• Metin yerine uygun veri türlerini kullanın (tamsayı, tarih, sabit kodlar).
• Boyut tablolarını küçük ve tanımlayıcı tutun; ölçü hesaplamalarını fact üzerinden yönetin.
• İlişki sayısını artırmak yerine, yıldız şemaya yaklaşın ve yolları sadeleştirin.

Cardinality nedir ve neden Power BI performansında kritik rol oynar?

Cardinality, bir sütundaki benzersiz değer sayısıdır. Yüksek cardinality genellikle büyük sözlük, daha fazla bellek, daha düşük sıkıştırma oranı ve daha ağır tarama anlamına gelir. Ayrıca ilişkilerde cardinality, join davranışını ve filtre yayılım maliyetini dolaylı etkiler.

En sık yapılan hata, kaynak sistemdeki “teknik anahtarları” modelde aynen tutmaktır. Örneğin TransactionId, SessionId, GUID, Email gibi alanlar çoğu zaman rapor analizinde gerekmez. Gerekli olduğunda bile, her görselin bu alanı taşıması gerekmeyebilir; bu nedenle rapor seviyesinde kullanım senaryolarını netleştirmek önemlidir.

Yüksek cardinality örnekleri ve tipik etkileri

Şunlar genellikle yüksek cardinality üretir: tam zaman damgası (DateTime), serbest metin açıklamalar, GUID anahtarları, ürün seri numaraları, IP adresleri. Bu alanları doğrudan boyutlarda tutmak, dilimleyicilerin ağırlaşmasına ve modelin şişmesine yol açabilir. Eğer analiz ihtiyacı yalnızca “gün” veya “saat” seviyesindeyse, ham alanı tutmak yerine türetilmiş alanlar kullanmak daha sağlıklıdır.

Tarih ve saat alanlarını yönetmek: detay seviyesini bilinçli düşürme

Birçok rapor günlük veya aylık analiz yapar. Buna rağmen fact tablosunda saniye hassasiyetinde zaman damgası tutulur ve görseller bu alan üzerinden filtrelenir. Alternatif yaklaşım: ham alanı modelden çıkarıp ETL’de veya Power Query’de tarih ve saat dilimi gibi alanlar üretmek. Böylece sözlük büyümesi azalır ve ilişkiler daha stabil hale gelir.

İlişkiler, filtre akışı ve yıldız şema: karmaşıklığı azalt, hızı artır

Power BI modelinde ilişkiler sadece “tablolar bağlandı” anlamına gelmez; filtre yönü, kardinalite tipi ve ilişki yolu, sorgu anında motorun nasıl çalışacağını belirler. Çok sayıda tabloyu birbirine “her yöne filtre” ile bağlamak kısa vadede kolay gibi görünür ama uzun vadede yavaşlama ve belirsiz sonuçlar üretir.

Tek yön mü, çift yön mü? Filtre yönünü stratejik seçin

Genel kural: boyuttan fact’e tek yön filtre, en öngörülebilir ve performanslı yaklaşımdır. Çift yön filtre, özellikle çoktan çoğa (many-to-many) senaryolarda veya “bridge” tablolarında gerekebilir; ancak her çift yön ilişki, filtre yayılımını artırarak görsel hesap maliyetini yükseltebilir. Bir ihtiyacınız yoksa çift yönü varsayılan yapmayın.

Yıldız şema (star schema) ile ölçülerin işini kolaylaştırma

Yıldız şemada fact tablo olayları taşır; boyut tabloları ise tanımlayıcı nitelikleri barındırır. Bu yapı DAX için idealdir: filtreler boyutlardan gelir, hesaplar fact üzerinde yapılır. Ayrıca kullanıcı deneyimi daha nettir; rapor alanları dağınık olmaz. Snowflake (kar tanesi) şeması, gereksiz join yolu oluşturduğunda performansı olumsuz etkileyebilir; mümkün olduğunda boyutları düzleştirmek (denormalize) daha iyi sonuç verir.

1. Fact tablolarını “olay” seviyesinde netleştirin (satış satırı mı, fatura mı?).
2. Boyutları (Tarih, Ürün, Müşteri, Bölge) ayrı tutun ve gereksiz kolonları ayıklayın.
3. Boyut → Fact ilişkilerini tek yön kurun; istisnaları belgeleyin.
4. Birden fazla ilişki yolu oluşuyorsa, aktif/pasif ilişkileri bilinçli yönetin.

Sütun tasarımı ve veri türleri: model boyutunu küçültmenin en hızlı yolu

Performans için en etkili müdahalelerden biri, sütunların gerçekten gerekli olup olmadığını ve doğru veri türünde olup olmadığını kontrol etmektir. Metin kolonları çoğu zaman pahalıdır; aynı bilgiyi bir kod alanıyla temsil etmek veya boyut tablosuna taşımak bellek kazanımı sağlar.

Veri türü seçimi: metin yerine sayısal kodlar, tarih yerine tarih

Örneğin “Durum” alanı 5–10 değer alıyorsa metin olarak kalabilir; ancak “ÜrünKodu” gibi binlerce değer taşıyan alan için kaynakta sayısal bir surrogate key varsa onu tercih etmek sıkıştırmayı iyileştirir. Tarih alanlarının “Date” olarak tutulması, gereksiz zaman hassasiyetini ortadan kaldırır.

Hesaplanan sütun mu, ölçü mü? Hesabı doğru yere koyun

Hesaplanan sütunlar model yenileme sırasında hesaplanır ve depolanır; ölçüler ise sorgu anında çalışır. Bu nedenle “her görselde tekrar hesaplanan” bir iş mantığı varsa ve sonuç satır bazında değişmiyorsa, hesaplanan sütun mantıklı olabilir. Ancak çoğu toplama, oran ve filtre duyarlı hesap için ölçü daha uygundur. Burada kritik olan, gereksiz hesaplanan sütun üretmemek ve ölçüleri de aşırı karmaşık hale getirmemektir.

// Örnek: Boyuta taşınabilecek bir alanı fact'te tutmak yerine sadeleştirme
// FactSales[OrderDateTime] (yüksek cardinality) yerine:
FactSales[OrderDate] = DATEVALUE ( FactSales[OrderDateTime] )

// Boyut tablosunda tarih hiyerarşisini yönetmek:
DimDate[YearMonth] = FORMAT ( DimDate[Date], "YYYY-MM" )

DAX performansı: ölçüleri daha az iş yapacak şekilde tasarlayın

DAX performansında en büyük maliyetler, büyük tablolar üzerinde iterator fonksiyonları (SUMX, FILTER, ADDCOLUMNS) ile gereksiz satır dolaşımı ve karmaşık filtre bağlamı dönüşümleridir. Ölçülerin hedefi, motorun mümkün olduğunca depolama motoru (storage engine) tarafında hızlı taramalar yapabilmesini sağlamaktır. İyi tasarlanmış bir ölçü, gereksiz ara tablolar üretmez ve filtreleri kontrollü uygular.

Iterator kullanımı: gerçekten gerekiyor mu?

SUMX gibi iterator’lar güçlüdür ama büyük fact tabloda her satırda hesap yaparsa pahalılaşır. Mümkünse basit toplama için SUM tercih edin; hesap satır bazında şartlıysa, önceden sınıflandırılmış bir kolon veya daha düşük satır sayılı bir ara tablo kullanmayı düşünün.

VAR, ölçü katmanlama ve filtre kontrolü

VAR kullanımı, aynı ifadeyi tekrar tekrar hesaplamayı engeller ve okunabilirliği artırır. Ayrıca filtreleri erken aşamada daraltmak ve ölçüleri katmanlayarak tekrar kullanım sağlamak, hem bakım hem performans açısından faydalıdır. Filtreyi nerede uyguladığınız (CALCULATE içinde mi, görsel filtrelerinde mi) çoğu zaman sonucu ve hızı değiştirir.

// Örnek: Performans odaklı bir satış ölçüsü (VAR + kontrollü filtre)
[Net Satış] =
VAR iade =
    CALCULATE (
        SUM ( FactSales[Amount] ),
        FactSales[IsReturn] = TRUE()
    )
VAR brut =
    SUM ( FactSales[Amount] )
RETURN
    brut - iade

// Örnek: Kategori bazında pay hesaplama (bağlamı doğru yönetme)
[Kategori Payı] =
VAR katNet = [Net Satış]
VAR toplam =
    CALCULATE ( [Net Satış], ALL ( DimProduct[Category] ) )
RETURN
    DIVIDE ( katNet, toplam )

Ölçülerde “her şeyi tek ölçüde yapmak” yerine, temel ölçüler (Net Satış, Adet, Marj) ve bunların üzerine kurulan türev ölçüler (Pay, YoY, YTD) yaklaşımı hem performansı hem de model yönetişimini iyileştirir. Böylece bir optimizasyon yaptığınızda tüm raporlar tutarlı biçimde etkilenir.

Power Query optimizasyonu: veri hazırlığını hızlandırmak ve folding’i korumak

Yenileme süresi uzadığında ilk bakılması gereken yer, Power Query adımlarının veri kaynağına katlanıp katlanmadığıdır. Folding, dönüşümlerin kaynağa push edilmesi demektir; katlanma bozulduğunda Power BI, büyük veriyi istemci tarafında işleyebilir ve bu da yenilemeyi dramatik şekilde yavaşlatır.

Query folding’i koruyan adımlar ve sık yapılan hatalar

Tür dönüşümleri, filtreler, seçili kolonlar gibi adımlar çoğu kaynaktan katlanabilir. Buna karşılık, satır bazlı özel fonksiyonlar, bazı birleştirmeler veya erken aşamada yapılan “Add Index Column” gibi işlemler folding’i kırabilir. Doğru yaklaşım, katlanabilir adımları mümkün olduğunca erken yapmak ve katlanmayı bozabilecek adımları en sona bırakmaktır.

Incremental refresh ve yükleme stratejisi

Büyük fact tablolarında incremental refresh, yenileme maliyetini düşürür. Özellikle tarih bazlı partition mantığıyla yalnızca yeni dönemlerin güncellenmesi, hem veri kaynağını hem de Power BI kapasitesini rahatlatır. Ancak bunun çalışması için tarih kolonunun tutarlı olması ve aralık filtrelerinin kaynağa doğru iletilmesi gerekir.

// Örnek Power Query (M): kolon azaltma + filtreyi erken uygulama (folding dostu)
let
    Source = Sql.Database("SERVERNAME", "DWH"),
    Sales = Source{[Schema="dbo",Item="FactSales"]}[Data],
    KeepCols = Table.SelectColumns(Sales, {"OrderDate", "ProductKey", "CustomerKey", "Amount", "IsReturn"}),
    Filtered = Table.SelectRows(KeepCols, each [OrderDate] >= #date(2024, 1, 1)),
    Types = Table.TransformColumnTypes(Filtered, {{"OrderDate", type date}, {"Amount", type number}, {"IsReturn", type logical}})
in
    Types

Modeli ölçmeden optimize etmeyin: doğru araçlarla darboğazı bulun

Optimizasyonun en büyük tuzağı, “hissettiğim yere göre” müdahale etmektir. Bunun yerine ölçüm yapın: hangi görsel yavaş, hangi ölçü pahalı, hangi etkileşimde süre sıçrıyor? Power BI Desktop’ta Performance Analyzer, görsel bazında süreleri izlemenizi sağlar. DAX Studio ile sorgu planını ve depolama motoru/ formül motoru ayrımını görebilirsiniz. VertiPaq Analyzer ise tablo ve kolon bazında boyut, sözlük büyüklüğü gibi metriklerle cardinality problemlerini yakalamanıza yardımcı olur.

Performans analizinde pratik bir kontrol listesi

• Yavaş görsellerde kullanılan alanlar: yüksek cardinality kolonlar var mı?
• İlişki yönleri: gereksiz çift yön filtre var mı?
• Boyut tabloları: gereksiz metin kolonları taşınıyor mu?
• Ölçüler: iterator’lar büyük tabloda çalışıyor mu, VAR ile sadeleştirilebilir mi?
• Yenileme: folding bozulmuş mu, incremental refresh uygun mu?

Bakım ve ekip standardı: performansın sürdürülebilirliği

Bir model bugün hızlı olabilir; ama yarın yeni bir boyut eklendiğinde yavaşlayabilir. Bu yüzden ekip standardı şarttır: isimlendirme, ölçü katmanlama, ilişki tasarım kuralları, “hangi alanlar yüklenir” politikası. Eğer kurum içinde bu standardı hızla oturtmak istiyorsanız, Power BI eğitimi kapsamında modelleme ve DAX performans pratiklerini ekip senaryolarınıza göre birlikte ele alabilirsiniz.

Örnek optimizasyon senaryosu: yavaş rapordan hızlı rapora

Diyelim ki satış raporunuzda üç problem var: (1) FactSales tablosunda OrderDateTime saniye hassasiyetinde; (2) müşteri tablosunda email gibi yüksek benzersiz değerli alanlar dilimleyicide kullanılıyor; (3) ölçüler SUMX + FILTER ile büyük tabloda gereksiz satır dolaşıyor. Bu senaryoda hızlı kazanımlar şunlar olabilir:

Birinci adım, OrderDateTime’ı modelden çıkarmak veya OrderDate’e indirgemek; gerekiyorsa saat dilimini ayrı bir boyuta taşımak. İkinci adım, dilimleyicileri düşük cardinality alanlara yönlendirmek (segment, şehir, müşteri tipi) ve email gibi alanları “detay sayfası” seviyesine taşımak. Üçüncü adım, ölçüleri basitleştirmek; mümkünse iterator yerine depolama motoru dostu toplamalara geçmek.

Sonuçta model boyutu düşer, görsel etkileşimleri hızlanır ve yenileme süreleri daha öngörülebilir hale gelir. Önemli olan, tek bir “sihirli ayar” aramak yerine; model, DAX ve sorgu katmanını birlikte ele almaktır.

Sonuç: performans, doğru kararların toplamıdır

Power BI performansını iyileştirmek için en etkili yaklaşım, önce veri modelini sadeleştirmek ve cardinality’yi yönetmek; sonra ilişkileri yıldız şema etrafında düzenlemek; ardından DAX ölçülerini daha az iş yapacak şekilde optimize etmektir. Power Query’de folding’i korumak ve incremental refresh gibi stratejilerle yenileme maliyetini düşürmek de büyük fark yaratır.

Bu yazıdaki pratiklerle, raporlarınızı sadece hızlandırmakla kalmaz; aynı zamanda daha anlaşılır, daha yönetilebilir ve büyümeye daha dayanıklı hale getirirsiniz. Performans kazancı bir kerelik değil, sürdürülebilir bir modelleme disiplini olarak ele alındığında gerçek değer üretir.