Power BI Performans Optimizasyonu: DAX, Modeller ve Sorgular

Yüklenmesi 15 saniye süren bir Power BI raporu, kullanıcıların kullanmayı bıraktığı bir rapordur. Performans teknik bir ayrıntı değildir; BI'nın benimsenmesi ile BI'nın terk edilmesi arasındaki farktır. Rapor yükleme süresinin her saniyesi, kullanıcı etkileşimini ölçülebilir şekilde azaltır. Araştırmalar, etkileşimli kontrol panellerinin (yükleme süresi 3 saniyenin altında) yavaş olanlara (10 saniyenin üzerinde) kıyasla 4-5 kat daha fazla görüntüleme aldığını ve sürekli yavaşlama yaşayan kullanıcıların 30 gün içinde manuel işlemlere geri döndüğünü sürekli olarak göstermektedir.

İyi haber şu ki Power BI performans sorunları neredeyse her zaman çözülebilir. Yüzlerce Power BI ortamını optimize etme deneyimimize göre, performans sorunlarının %90'ı beş temel nedenden birine dayanmaktadır: verimsiz DAX ölçümleri, büyük boyutlu veri modelleri, zayıf ilişki tasarımı, DirectQuery'nin uygunsuz kullanımı veya iş yükü için yetersiz kapasite. Bu kılavuz, bu sorunların her birinin tanılanması ve çözülmesi için sistematik bir yaklaşım sağlar.

Power BI ortamınız ekibinizin dahili olarak çözemeyeceği performans sorunları yaşıyorsa Power BI performans optimizasyon hizmetlerimiz uygulamalı analiz ve iyileştirme sağlar.

Önemli Çıkarımlar

• Power BI Desktop'taki Performans Çözümleyicisi hangi görsellerin ve sorguların yavaş olduğunu belirler --- iyileştirmeden önce her zaman buradan başlayın
• DAX Studio, yavaş sorguların Depolama Motorunda (veri tarama) veya Formül Motorunda (hesaplama) darboğaz olup olmadığını ortaya koyuyor; düzeltme önemli ölçüde farklılık gösteriyor
• En yaygın DAX performansı hataları, gereksiz HESAPLAMA iç içe yerleştirme, toplayıcıların yeterli olduğu yerde yineleyicilerin kullanılması ve büyük ara tabloların gerçekleştirilmesidir.
• Model boyutu performansı doğrudan etkiler: kullanılmayan sütunların kaldırılması, önem derecesinin azaltılması ve veri türlerinin optimize edilmesi, modelleri %40-70 oranında küçültebilir
• Toplama tabloları, özet verileri önceden hesaplayarak büyük veri kümeleri için sorgu performansında 10-100 kat iyileştirme sağlar
• DirectQuery, etkileşimli raporlar için İçe Aktarma modundan 10-100 kat daha yavaştır --- bunu yalnızca veri güncelliği gereksinimleri gerçekten gerektirdiğinde kullanın
• Optimizasyon etkisini kanıtlamak ve gerilemeyi önlemek için belgelenmiş metriklerle karşılaştırma öncesi/sonrası önemlidir

---

Teşhis Araçları ve Metodolojisi

Performans Analizörü

Performans Analizcisi, Power BI Desktop'ın yerleşik tanılama aracıdır. Bir rapor sayfasındaki her görsel tarafından oluşturulan her sorgunun yürütme süresini kaydeder ve zamanı üç bileşene ayırır:

Performans Analizörü nasıl kullanılır:

1. Raporunuzu Power BI Desktop'ta açın.
2. Görünüm > Performans Analizcisi'ne gidin.
3. "Kaydı başlat"ı tıklayın.
4. Raporla etkileşim kurun (filtreleri değiştirin, sayfalarda gezinin, dilimleyicileri uygulayın).
5. "Durdur"u tıklayın.
6. Toplam süreye göre sıralanmış sonuçları inceleyin.

Sonuçların yorumlanması:

• DAX sorgu süresi hakimse sorun ölçümlerinizde veya modelinizdedir. Daha derin analiz için DAX Studio'yu kullanın.
• Görsel görüntüleme süresi baskınsa sorun görsel yapılandırmadadır (çok fazla veri noktası, karmaşık koşullu biçimlendirme veya düşük performans gösteren özel görsel).
• "Diğer" zaman baskınsa sorun altyapıdadır (DirectQuery için ağ gecikmesi, ağ geçidi darboğazları veya kapasite kısıtlaması).

Çoğu kişinin atladığı kritik adım: DAX sorgusunu Performans Analiz Aracı'ndan kopyalayın (sağ tıklama > "Sorguyu kopyala") ve DAX Studio'ya yapıştırın. Performans Analizcisi size hangi görselin yavaş olduğunu söyler. DAX Studio size bunun nedenini anlatır.

DAX Stüdyosu

DAX Studio, Power BI'ın temelini oluşturan Analiz Hizmetleri motoru için ayrıntılı tanılama yetenekleri sağlayan ücretsiz, açık kaynaklı bir araçtır. Herhangi bir Power BI performans mühendisinin araç setindeki en önemli araçtır.

Temel DAX Studio özellikleri:

Sunucu Zamanlamaları: Depolama Motoru (SE) ve Formül Motoru (FE) sorgu süresi arasındaki dökümü gösterir.

• Storage Engine (SE) sorguları sütunlu depolamaya (VertiPaq motoru) karşı yürütülen veri taramalarıdır. Oldukça paralelleştirilmiş ve hızlıdırlar. SE sorguları izlemede xmSQL ifadeleri olarak görünür.
• Formül Motoru (FE) işlemleri, SE sorgularının sonuçları üzerinde gerçekleştirilen tek iş parçacıklı hesaplamalardır. FE işlemleri, yavaş DAX ölçümlerinin çoğunda birincil darboğazdır.

Optimizasyon hedefi, Depolama Motoruna mümkün olduğunca fazla iş göndermek ve Formül Motoru işlemlerini en aza indirmektir.

Sorgu planları: DAX Studio, motorun ölçümünüzü tam olarak nasıl işlediğini gösteren mantıksal ve fiziksel sorgu planları görüntüleyebilir. İleri düzey kullanıcılar için sorgu planları, yalnızca zamanlama verilerinde görünmeyen optimizasyon fırsatlarını ortaya çıkarır.

VertiPaq Analizörü: Veri modelinin tamamını tarar ve her tablodaki her sütun için sütun boyutunu, önem derecesini, kodlama türünü ve sözlük boyutunu raporlar. Modelinizi şişiren büyük boyutlu sütunları ve tabloları bu şekilde tespit edersiniz.

Sistematik Optimizasyon Metodolojisi

1. Temel: Performans Analizcisi'ni kullanarak her sayfanın yükleme sürelerini kaydedin. Belge modeli boyutu (Dosya > Bilgi > Dosya Boyutunu Küçült > Analiz Et). Premium/Fabric kullanıyorsanız kapasite ölçümlerini kaydedin.

2. Tanımlayın: Performans Analizcisi sonuçlarını toplam süreye göre sıralayın. En yavaş ilk 5 görsele odaklanın; bunlar optimize edildiğinde en fazla etkiyi sağlar.

3. Teşhis Et: Her yavaş sorguyu DAX Studio'ya kopyalayın. SE ve FE zamanını analiz edin. FE darboğazlarına neden olan belirli DAX kalıplarını belirleyin.

4. Optimize edin: Hedeflenen düzeltmeleri uygulayın (aşağıda ayrıntılı olarak ele alınmıştır). Etkisini ölçmek için her değişikliği ayrı ayrı test edin.

5. Doğrulama: Performans Analiz Aracı'nı yeniden çalıştırın ve temel değerle karşılaştırın. Her optimizasyon için iyileştirmeyi belgeleyin.

6. İzleme: Gerilemeyi önlemek için sürekli performans izlemeyi (kapasite ölçümleri, kullanıcı tarafından bildirilen sorunlar, periyodik Performans Analizörü kontrolleri) ayarlayın.

---

Yavaş DAX Kalıpları ve Düzeltmeleri

Desen 1: Gereksiz HESAPLAMA Yuvalama

Sorun:

Bad Measure =
CALCULATE(
    CALCULATE(
        SUM(Sales[Amount]),
        FILTER(ALL(Products), Products[Category] = "Electronics")
    ),
    Date[Year] = 2025
)

İç içe CALCULATE ifadeleri güç katmaz; kafa karışıklığı ve bazen de performans yükü eklerler. Her CALCULATE yeni bir filtre bağlamı oluşturur ve bunların iç içe yerleştirilmesi beklenmedik sonuçlar üretebilir ve Formül Motorunu gereksiz bağlam geçişleri gerçekleştirmeye zorlayabilir.

Düzeltme:

Good Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics",
    Date[Year] = 2025
)

Filtre bağımsız değişkenlerini tek bir HESAPLAMA işleminde birleştirin. Birden fazla filtre bağımsız değişkeni aynı anda uygulanır (kesişme). Bu, daha temiz yürütmeyle aynı sonucu üretir.

Desen 2: Doğrudan Sütun Filtreleri Yerine TÜMÜ ile FİLTRELEME

Sorun:

Slow Measure =
CALCULATE(
    SUM(Sales[Amount]),
    FILTER(ALL(Products), Products[Category] = "Electronics")
)

FILTER(ALL(Ürünler), ...) motoru, Formül Motorundaki Ürünler tablosunun tamamını gerçekleştirmeye zorlar, ardından filtreyi uygulamak için her satırı yineler. Milyonlarca satırı olan bir tablo için bu olağanüstü derecede yavaştır.

Düzeltme:

Fast Measure =
CALCULATE(
    SUM(Sales[Amount]),
    Products[Category] = "Electronics"
)

CALCULATE'deki doğrudan sütun filtreleri Depolama Motorunda çözümlenir, bu da çok daha hızlıdır. FİLTRE'yi yalnızca basit bir sütun karşılaştırması olarak ifade edilemeyen karmaşık bir koşulu uygulamanız gerektiğinde kullanın (örneğin, bir ölçüm değerine göre filtreleme veya birden fazla sütun içeren bir koşul).

Temel kural: FİLTRE koşulunuz basit bir karşılaştırmayla tek bir sütuna başvuruyorsa, bunu doğrudan HESAPLAMA filtre bağımsız değişkeniyle değiştirin. Gerçekten karmaşık koşullar için FİLTRE'yi ayırın.

Desen 3: Toplayıcıların Yeterli Olduğu Yineleyiciler

Sorun:

Slow Total = SUMX(Sales, Sales[Quantity] * Sales[UnitPrice])

SUMX, Satış tablosunun her satırında yinelenir ve Formül Motoru'ndaki her satırın ifadesini değerlendirir. 10 milyon satırlık bir Satış tablosu için bu, 10 milyon FE işlemi anlamına gelir.

Düzeltme:

Hesaplama iki sütunun basit çarpımıysa, bunu hesaplanmış bir sütun olarak önceden hesaplayın:

-- Add calculated column: Sales[LineTotal] = Sales[Quantity] * Sales[UnitPrice]
-- Then use aggregator:
Fast Total = SUM(Sales[LineTotal])

SUM, sütunlu verileri yüksek düzeyde optimize edilmiş gruplar halinde işleyen Depolama Motorunda çalışır. Hesaplanan sütun, model boyutunu artırır ancak sorgu süresini önemli ölçüde azaltır.

SUMX ne zaman saklanmalı: Satır düzeyinde koşullu mantığa ihtiyacınız olduğunda (ör. SUMX(Sales, IF(Sales[Type] = "Return", -Sales[Amount], Sales[Amount]))) veya küçük bir tablo (milyonlarca değil binlerce satır içeren boyut tabloları) üzerinde yineleme yaparken SUMX'i kullanın.

Desen 4: Büyük Ara Tablolar

Sorun:

Slow Measure =
SUMX(
    SUMMARIZE(Sales, Products[Category], Date[Month]),
    [Complex Calculation]
)

SUMMARIZE, Formül Motorunda bir ara tablo oluşturur. Kategori ve Ay kombinasyonu 10.000 satır üretirse ve [Karmaşık Hesaplama] her satır için ek SE sorgularını tetiklerse, sonuç 10.000'den fazla sorgu olur; bu, "SE sorgu fırtınaları" olarak bilinen yıkıcı bir performans modelidir.

Düzeltme:

Fast Measure =
VAR SalesTable =
    ADDCOLUMNS(
        SUMMARIZE(Sales, Products[Category], Date[Month]),
        "@SubTotal", CALCULATE(SUM(Sales[Amount]))
    )
RETURN
    SUMX(SalesTable, [@SubTotal] * [SomeMultiplier])

Alt toplamı ADDCOLUMNS içinde gerçekleştirerek (bağlam geçişini verimli bir şekilde kullanır), @SubTotal'a yapılan sonraki referanslar ek SE sorgularını tetiklemez. Değişkenler (VAR), tabloya birden çok kez başvurulsa bile yalnızca bir kez değerlendirilmesini de sağlar.

Model 5: Satır Düzeyinde Güvenlik Performans Etkisi

Sorun:

Karmaşık DAX ifadelerine sahip RLS, her sorguyu değerlendirerek görselleri birleştiren ek yük ekler. Kötü yazılmış bir RLS kuralı, rapor yükleme sürelerini iki veya üç katına çıkarabilir.

Yaygın RLS performansını olumsuz etkileyen faktörler:

• RLS filtrelerinde LOOKUPVALUE (satır başına FE değerlendirmesini zorunlu kılar)
• Büyük tablolarda CONTAINS veya IN operatörleri
• Basit sütun filtreleri yerine ölçümlere referans veren RLS kuralları
• Çapraz filtre yönü sorunları olan çok tablolu RLS

Düzeltme:

• Basit sütun karşılaştırmalarını kullanın: [TenantId] = USERNAME() veya [Region] IN VALUES(SecurityTable[Region])
• Doğrudan ilişkiler içeren özel bir boyut tablosunda güvenlik eşlemelerini önceden hesaplayın
• RLS kurallarındaki önlemlerden kaçının --- yalnızca sütun düzeyinde filtreler kullanın
• RLS etkinken ve RLS etkin değilken sorgu sürelerini karşılaştırarak RLS performansını DAX Studio ile test edin

---

Model Boyutu Küçültme

Model Boyutu Neden Önemlidir

Power BI İçe Aktarma modu, verileri yüksek oranda sıkıştırılmış sütunlu biçimde (VertiPaq motoru) depolar. Model boyutu doğrudan şunları etkiler:

• Bellek tüketimi: Modelin tamamı belleğe sığmalıdır. Premium/Fabric'te daha büyük modeller daha fazla kapasite tüketir ve bellek basıncının azaltılmasını tetikleyebilir.
• Yenileme süresi: Daha fazla verinin işlenmesi, sıkıştırılması ve yüklenmesi gerektiğinden daha büyük modellerin yenilenmesi daha uzun sürer.
• Sorgu performansı: Daha büyük modeller daha büyük taramalar üretir, bu da iyi optimize edilmiş DAX için bile sorgu süresini artırır.
• Dosya boyutu: Büyük modellere sahip PBIX dosyalarının kaydedilmesi, yayınlanması ve indirilmesi yavaştır.

Model Boyutuna Katkıda Bulunanları Belirleme

En büyük tabloları ve sütunları belirlemek için DAX Studio'nun VertiPaq Çözümleyicisini (Gelişmiş > Metrikleri Görüntüle) kullanın:

Optimizasyon Teknikleri

Kullanılmayan sütunları kaldırın:

En yüksek etkili tek optimizasyon. Modelinizdeki her sütun, kullanılsa da kullanılmasa da bellek tüketir. Modelinizi denetleyin ve görsel, ölçüm, ilişki veya RLS kuralında referans verilmeyen tüm sütunları kaldırın.

Tipik etki: %20-40 model boyutunda azalma.

Metin sütununun önem düzeyini azaltın:

Pek çok benzersiz değere (açıklamalar, adresler, notlar) sahip metin sütunları yeterince sıkıştırılmıyor. Sütun yalnızca görüntüleme için gerekliyse (filtreleme veya gruplandırma için değil), onu yalnızca ayrıntı içeren bir tabloya taşımayı veya uzun değerleri kısaltmayı düşünün.

Gruplandırma/filtrelemede kullanılan sütunlar için gruplandırmayı düşünün: 50.000 benzersiz ürün adı yerine, tek tek ürün ayrıntıları için ayrı bir arama tablosuyla 500 ürün kategorisi halinde gruplandırın.

Veri türlerini optimize edin:

• Değerler tam sayı olduğunda Ondalık yerine Tamsayı kullanın (sütun başına %50 tasarruf sağlar)
• Zaman gerekmediğinde DateTime yerine Date kullanın (önem derecesini azaltır)
• Sayısal değerleri metin olarak saklamaktan kaçının (metin, sayılardan çok daha kötü sıkıştırılır)
• Evet/hayır veya doğru/yanlış sütunları için metin yerine Boolean kullanın

Tipik etki: %10-20 model boyutunda azalma.

Büyük tabloları ayırın:

100 milyon satırlık bir olgu tablosu, aktif verilere (her yenilemede yüklenen cari yıl) ve geçmiş verilere (önceki yıllar, daha az sıklıkta yüklenen veya toplu olarak depolanan) bölünebilir. Bu hem model boyutunu hem de yenileme süresini azaltır.

Toplama tabloları (aşağıda ayrıntılı olarak ele alınmıştır):

Büyük olgu tabloları için toplama tabloları, özet verileri yaygın olarak sorgulanan ayrıntı düzeylerinde önceden hesaplayarak en büyük performans artışını sağlar.

---

Toplama Tabloları

Toplama Tabloları Nedir?

Toplama tabloları, Power BI'ın tüm ayrıntı tablosunu taramak yerine sorguladığı, önceden hesaplanmış özet tablolardır. Bir kullanıcı bölgeye göre aylık geliri gösteren bir grafiği görüntülediğinde Power BI, ayrıntı tablosu (50 milyon işlem satırına sahip olabilir) yerine toplama tablosunu (120 satıra sahip olabilir: 10 bölge x 12 ay) sorgular.

Toplama tablolarının gücü, tüketicileri raporlamak için şeffaf olmalarıdır. Kullanıcılar aynı görseller ve ölçümlerle etkileşime girer. Power BI, sorgu ayrıntı düzeyi eşleştiğinde sorguları otomatik olarak toplama tablosuna yönlendirir ve detaya inme veya ayrıntı düzeyindeki sorgular için ayrıntı tablosuna geçer.

Toplama Tablolarını Tasarlama

1. Adım: Toplama ayrıntı düzeyini belirleyin.

En yaygın sorgu ayrıntılarını belirlemek için raporlarınızı analiz edin. Satış panosu için:

• Ay + Bölge + Ürün Kategorisi düzeyinde çoğu yönetici görsel sorgusu
• Hafta + Mağaza + Ürün düzeyinde yönetici görselleri sorgusu
• Bireysel işlem düzeyinde ayrıntılı tablo sorgusu

En sık sorgulanan ayrıntı düzeylerinde bir veya iki toplama tablosu tasarlayın.

2. Adım: Toplama tablosunu oluşturun.

Power Query'de, olgu tablonuzu toplama ayrıntı düzeyine göre gruplandıran yeni bir tablo oluşturun:

3. Adım: Toplama eşlemelerini yapılandırın.

Power BI Desktop'ta toplama tablosunu seçin, Özellikler > Toplamaları Yönet'e gidin ve her toplama sütununu karşılık gelen ayrıntı tablosu sütunu ve işleviyle eşleyin:

4. Adım: Toplama tablosunu gizleyin.

Kullanıcılar toplama tablosuyla doğrudan etkileşimde bulunmamalıdır. Rapor görünümünden gizleyin. Power BI bunu otomatik ve şeffaf bir şekilde kullanır.

Toplama Performans Etkisi

Bu iyileştirmeler rapor sayfalarında birleşiyor. Her biri detay tablosu yerine toplama tablosunu sorgulayan 10 görselin yer aldığı bir sayfa 30 saniye yerine 1 saniyede yüklenebilir.

Toplama Tablosu Bakımı

• Tutarlılığı korumak için toplama tablolarını ayrıntı tablolarıyla aynı programda yenileyin
• DAX Studio'yu kullanarak toplama isabet oranlarını izleyin (izleme etkinlikleri, sorguların toplamaya mı ulaştığını yoksa başarısız mı olduğunu gösterir)
• Ek ortak sorgu kalıplarını belirledikçe yeni toplama tabloları ekleyin
• İsabet oranı %50'nin altına düşen toplama tablolarını kaldırın (yeterli fayda sağlamadan yer kaplarlar)

---

DirectQuery Optimizasyonu

DirectQuery Gerekli Olduğunda

DirectQuery, verileri Power BI'ın bellek içi motoruna aktarmak yerine kaynak veritabanını gerçek zamanlı olarak sorgular. Aşağıdaki durumlarda gereklidir:

• Veri güncelliği gereksinimleri bir dakikadan kısa gecikme gerektirir (hisse senedi alım satımı, Nesnelerin İnterneti izleme, dolandırıcılık tespiti)
• Veri kümesi, Power BI'ın model boyutu sınırlarını aşıyor (Premium P1'de 10 GB, P2'de 25 GB vb.)
• Uyumluluk veya güvenlik, verilerin kaynak sistemden asla ayrılmamasını gerektirir
• Kaynak veritabanında halihazırda kapsamlı materyalleştirilmiş görünümler ve toplama altyapısı bulunmaktadır

Diğer tüm senaryolar için İçe Aktarma modu kesinlikle tercih edilir. İçe aktarma modu, etkileşimli sorgular için 10-100 kat daha hızlıdır ve daha iyi bir kullanıcı deneyimi sağlar.

DirectQuery Performans Stratejileri

Sayfa başına görsel sayısını azaltın.

DirectQuery modundaki her görsel, kaynak veritabanına ayrı bir sorgu oluşturur. 20 görsel içeren bir sayfa, sayfa yüklendiğinde 20 eşzamanlı sorgunun yanı sıra filtreler değiştiğinde ek sorgular oluşturur. DirectQuery sayfalarını maksimum 8-10 görselle sınırlandırın.

Kaynak veritabanını optimize edin.

Power BI, kaynağa SQL sorguları (veya SQL dışı kaynaklar için yerel sorgular) gönderir. Kaynak veritabanının performansı doğrudan rapor performansını belirler. Şunlardan emin olun:

• Filtreler, ilişkiler ve hesaplamalarda kullanılan tüm sütunlarda dizinler bulunur
• Sorgulanan tablolarda istatistikler günceldir
• Veritabanı sunucusu, operasyonel iş yüklerinin yanı sıra eşzamanlı analitik sorgular için yeterli CPU ve belleğe sahiptir
• Yaygın sorgu kalıpları için somutlaştırılmış görünümler veya dizine alınmış görünümler oluşturmayı düşünün

Sorgu azaltma seçeneklerini etkinleştirin.

Power BI Desktop > Seçenekler > Sorgu azaltma'da şunları etkinleştirin:

• "Çapraz vurgulama sorguları göndermeyerek gönderilen sorgu sayısını azaltın": Görseller arasındaki çapraz filtrelemenin ek sorgular oluşturmasını engeller
• "Her dilimleyiciye bir Uygula düğmesi ekleyin": Kullanıcılar, sorgular yürütülmeden önce birden fazla dilimleyiciyi ayarlayarak toplam sorgu hacmini azaltır
• "Filtre bölmesine Uygula düğmesi ekleyin": Filtre bölmesi için aynı prensip

İkili depolama modunu stratejik olarak kullanın.

Tablolar, verileri hem İçe Aktarma modunda depolayan (hızlı yerel sorgular için) hem de DirectQuery bağlantısını koruyan (DirectQuery tablolarıyla ilişkiler için) "İkili" moda ayarlanabilir. DirectQuery'de büyük olgu tablolarını korurken boyut tablolarını (Ürünler, Müşteriler, Tarihler) İkili moda ayarlayın. Bu, olgu tablolarındaki veri tazeliğinden ödün vermeden filtre ve dilimleyici performansını önemli ölçüde artırır.

Sorgu önbelleğe almayı uygulayın.

Power BI Hizmeti veri kümesi ayarlarında "Sorguyu önbelleğe almayı" etkinleştirin. Bu, yapılandırılabilir bir süre boyunca sorgu sonuçlarını önbelleğe alır ve aynı sorgular için önbelleğe alınmış sonuçları sunar. Sorgu önbelleğe alma, aynı filtrelerle birçok kullanıcı tarafından görüntülenen kontrol panelleri (örneğin, şirket genelindeki ölçümleri gösteren bir yönetici kontrol paneli) için özellikle etkilidir.

---

Kapasite Performansı İzleme

Temel Kapasite Metrikleri

Premium veya Fabric kapasitesine sahip kuruluşlar için altyapı performansı, rapor tasarımı kadar önemlidir. Kapasite kısıtlaması, iyi optimize edilmiş raporların bile kötü performans göstermesine neden olabilir.

İzlenecek ölçümler:

Microsoft Fabric Kapasite Metrikleri Uygulaması

Microsoft, Power BI Hizmetinde özel bir kapasite izleme uygulaması sağlar. AppSource'tan yükleyin ve kapasitenize bağlayın. Şunları sağlar:

• İş yükü türüne göre dökümle birlikte gerçek zamanlı ve geçmiş CPU kullanımı
• Hangi işlemlerin azaltmayı tetiklediğini gösteren etkileşimli azaltma analizi
• Tahliye geçmişiyle birlikte veri kümesine göre bellek tüketimi
• Performans trendlerini yenileyin
• Performans yüzdeliklerini sorgulayın

Bu uygulamayı optimizasyon aşamaları sırasında haftalık olarak, kararlı durum sırasında ise aylık olarak inceleyin.

Kapasiteyi Doğru Boyutlandırma

Yetersiz sağlanan kapasite, kısıtlamaya ve kötü kullanıcı deneyimine neden olur. Aşırı tedarik edilen kapasite para israfına neden olur. Doğru boyutlandırma, iş yükü düzeninizi anlamayı gerektirir:

• Yoğun kullanım saatleri: Çoğu kuruluş, iş saatlerinde geceye kıyasla 2-3 kat daha fazla yük görüyor. Zirveye göre boyutlandırma yapıyorsanız ve Fabric F SKU'larınız varsa, gece boyunca duraklatmayı veya çalışma saatleri dışında ölçeklendirmeyi düşünün.
• Yenileme ve etkileşimli çakışma: Veri yenilemeleri ve etkileşimli sorgular aynı kapasite kaynakları için rekabet eder. Yoğun yenilemeleri etkileşimin yoğun olduğu saatlerin dışında planlayın. Bu mümkün değilse yenileme ve etkileşimli iş yükleri için ayrı kapasiteleri göz önünde bulundurun.
• Büyüme tahmini: 6-12 aylık büyümeyi planlayın. Model boyutu, kullanıcı sayısı ve sorgu karmaşıklığının tümü zamanla artma eğilimindedir. Kapasite boyutlandırmasında %30-50 boşluk payı oluşturun.

---

Karşılaştırmadan Önce/Sonra

Karşılaştırma Neden Önemlidir

Ölçümsüz optimizasyon tahmine dayalıdır. Öncesi/sonrası kıyaslama, performansın arttığını kanıtlar, paydaşlar için iyileşmeyi ölçer ve gelecekteki gerilemeyi tespit etmek için bir temel oluşturur.

Karşılaştırma Metodolojisi

1. Adım: Metrikleri tanımlayın.

2. Adım: Taban çizgisini kaydedin.

Herhangi bir değişiklik yapmadan önce tüm ölçümleri kaydedin. Önbellek ısınmasını ve değişkenliği hesaba katmak için Performans Çözümleyicisi'ni 10 kez çalıştırın. Her ölçüm için medyanı (P50) ve 95. yüzdelik dilimini (P95) kaydedin.

3. Adım: Değişiklikleri aşamalı olarak uygulayın.

Her seferinde bir optimizasyon yapın ve her değişiklikten sonra yeniden ölçün. Bu, hangi optimizasyonların en fazla etkiyi sağladığını belirler ve gerilemenin başka bir yerde iyileştirmeyle maskelenmesini önler.

4. Adım: Optimizasyon sonrası ölçümleri kaydedin.

Tüm optimizasyonlardan sonra aynı metodolojiyi kullanarak aynı ölçümleri kaydedin. Sonuçları bir karşılaştırma tablosunda sunun:

5. Adım: Devam eden izlemeyi planlayın.

Veriler büyüdükçe, yeni ölçümler eklendikçe ve yeni görseller oluşturuldukça performans zamanla düşer. Gerilemeyi erken yakalamak için aynı metodolojiyi kullanarak üç aylık performans incelemeleri planlayın.

ECOSIRE, belgelenmiş öncesi/sonrası ölçümleriyle sistematik performans optimizasyonuna ihtiyaç duyan kuruluşlar için DAX Studio analizi, model optimizasyonu ve kapasite ayarlaması da dahil olmak üzere kapsamlı Power BI performans hizmetleri sağlar.

---

Gelişmiş Optimizasyon Teknikleri

Hesaplama Grupları

Hesaplama grupları, tekrarlanan hesaplama değişkenlerini yeniden kullanılabilir hesaplama mantığıyla değiştirir. Her temel ölçü için MTD, QTD, YTD, Önceki Yıl ve Yıllık Büyüme için ayrı ölçümler oluşturmak yerine, bir hesaplama grubu bu dönüşümleri dinamik olarak uygular.

Performans avantajı: Modelde daha az ölçüm, daha küçük meta veri alanı ve daha hızlı model yükleme anlamına gelir. Daha da önemlisi, hesaplama grupları, karmaşık hepsi bir arada ölçümlerden daha iyi performans gösterme eğiliminde olan daha basit temel ölçümleri teşvik eder.

Kompozit Modeller

Bileşik modeller, İçe Aktarma modunu ve DirectQuery tablolarını tek bir modelde birleştirir. Boyut tabloları ve sık sorgulanan olgu tabloları için İçe Aktarma modunu, İçe Aktarma için çok sık değişen çok büyük tablolar için DirectQuery'yi kullanın.

Performans avantajı: Boyut aramaları ve filtre işlemleri İçe Aktarma hızında (mikrosaniye), olgu tablosu sorguları ise DirectQuery hızında (yüzlerce milisaniye ila saniye) çalışır. Net sonuç, saf DirectQuery'den önemli ölçüde daha iyidir.

Artımlı Yenileme

Artımlı yenileme, yenileme sırasında veri kümesinin tamamını yeniden yüklemek yerine yalnızca yeni ve değiştirilmiş verileri yükler. Günde yalnızca 100.000 satırın değiştiği 100 milyon satırlık bir tablo için artımlı yenileme, yenileme süresini %99 oranında azaltır.

Yapılandırma: Power Query'de RangeStart ve RangeEnd parametresini tanımlayın. Kaç gün/ay verinin yenileneceğini ve ne kadar geçmiş verinin tutulacağını belirtmek için artımlı yenileme ilkesini yapılandırın. Power BI, veri kümesini otomatik olarak bölümlere ayırır ve yalnızca etkin bölümleri yeniler.

Performans avantajı: Yenileme sırasında yenileme süresinde ve kapasite tüketiminde önemli azalma. Ayrıca Fabric kapasitesinde DirectQuery bölümleriyle gerçek zamanlı yenilemeye olanak tanır.

Sorgu Katlama

Sorgu katlama, Power Query dönüşümlerini kaynak veritabanına geri göndererek bunları Power Query altyapısı yerine yerel SQL olarak yürütür. Katlanmış sorgular çok daha hızlı çalışır çünkü veritabanı motoru bunları yerel olarak optimize eder ve yürütür.

Nasıl doğrulanır: Power Query Düzenleyicisi'nde herhangi bir adıma sağ tıklayın ve "Yerel Sorguyu Görüntüle" seçeneğinin mevcut olup olmadığını kontrol edin. Öyleyse sorgu o adıma katlanır. Gri renkteyse katlama bir önceki adımda bozuldu.

Ortak katlama ayırıcıları: M ifadelerine sahip özel sütunlar, farklı kaynaklardan alınan tabloların birleştirilmesi, belirli dönüşümler (döndürme, karmaşık tür dönüştürmeleri). Katlamalar kesildiğinde, sonraki tüm dönüşümler Power Query motorunda yürütülür; bu, büyük veri kümeleri için önemli ölçüde daha yavaştır.

---

SSS

Power BI rapor yükleme süresi için iyi bir hedef nedir?

Sık kullanılan gösterge tabloları için 3 saniyenin altında, ayrıntılı analitik raporlar için ise 5 saniyenin altında hedefleyin. Bu hedefler, kullanıcıların web uygulamalarından beklentileriyle uyumludur ve etkileşimi yüksek tutar. Sürekli olarak 10 saniyeyi aşan raporlara optimizasyon için öncelik verilmelidir. Yükleme süresini yalnızca DAX sorgu süresine göre değil, kullanıcının bakış açısına göre (ağ ve oluşturma dahil) ölçün. Performans Analizörü DAX sorgu süresi artı görsel oluşturma süresinin, 8-10 görselle 3 saniyelik bir sayfa yüklemesi elde etmesi için her görsel için toplamı 2 saniyenin altında olmalıdır.

DirectQuery yerine her zaman İçe Aktarma modunu mu tercih etmeliyim?

İş kullanıcıları tarafından tüketilen etkileşimli raporlar için evet --- İçe aktarma modu neredeyse her zaman daha iyi bir seçimdir. İçe aktarma modu sorgular için 10-100 kat daha hızlıdır, rapor görüntüleme sırasında kaynak veritabanı performansına bağlı değildir ve tüm DAX işlevlerini ve AI özelliklerini destekler. DirectQuery'yi yalnızca bir dakikadan kısa sürede veri güncelliğine yönelik gerçek bir gereksiniminiz olduğunda, veri kümeniz İçe Aktarma boyutu sınırlarını aştığında veya uyumluluk, verilerin kaynak sistemde kalmasını gerektirdiğinde kullanın. Bileşik modelleri bir orta yol olarak düşünün: Boyutları ve sık sık sorgulanan gerçekleri içe aktarın; DirectQuery yalnızca gerçekten gerçek zamanlı güncelliğe ihtiyaç duyan tabloları içe aktarın.

Power BI raporlarımda performans denetimlerini ne sıklıkla çalıştırmalıyım?

Üretim raporları için üç ayda bir kapsamlı bir performans denetimi gerçekleştirin. Denetimler arasında kapasite ölçümlerini haftalık olarak izleyin ve kullanıcı tarafından bildirilen yavaşlıkları derhal araştırın. Acil bir denetimi tetiklemesi gereken başlıca olaylar şunları içerir: önemli veri hacmi büyümesi (%25'ten fazla artış), yeni rapor sayfalarının veya karmaşık DAX ölçümlerinin eklenmesi, kullanıcı eşzamanlılığında değişiklikler (lansman sonrası kullanıcı artışı) ve kapasite değişiklikleri (yükseltme, düşürme veya geçiş).

Raporlarımı değiştirmeden Power BI performansını optimize edebilir miyim?

Evet, bir dereceye kadar. Altyapı düzeyindeki optimizasyonlar şunları içerir: kapasite SKU'sunun yükseltilmesi, Hizmet ayarlarında sorgu önbelleğe almanın etkinleştirilmesi, yoğun yenilemelerin yoğun saatlerin dışında planlanması, daha iyi verim için ağ geçidi kümelemesinin yapılandırılması ve kaynak veritabanının optimize edilmesi (dizinler, istatistikler, gerçekleştirilmiş görünümler). Bu değişiklikler rapor dosyalarına dokunmadan performansı artırır. Ancak en etkili optimizasyonlar genellikle rapor düzeyinde değişiklikleri içerir: DAX ölçüsünün yeniden yazılması, model boyutunun küçültülmesi, toplama tabloları ve görsel sayının azaltılması. Altyapı optimizasyonu kapasite kısıtlamalarını ele alır; rapor optimizasyonu verimliliği ele alır.

Power BI raporlarının zamanla yavaşlamasına neden olan şey nedir?

Beş yaygın neden: (1) Veri hacminin büyümesi — tablolar 1 milyondan 10 milyon satıra çıktıkça aynı sorgular daha uzun sürer. (2) Ölçü birikimi — mevcut ölçüler optimize edilmeden yeni ölçüler eklenir ve ölçüler arasındaki etkileşimler karmaşıklığı artırır. (3) Görsel yayılma --- kullanıcılar sayfa başına daha fazla görsel ekler ve bunların her biri ek sorgular oluşturur. (4) Model şişkinliği --- kullanılmayan sütunlar ve tablolar kaldırılmadan yeni sütunlar ve tablolar eklenir. (5) Eşzamanlı kullanıcı büyümesi — aynı kapasite kaynakları için rekabet eden daha fazla kullanıcı. Üç aylık performans denetimleri, görsel sayımı sınırlayan ve karmaşıklığı ölçen yönetişim politikaları ve proaktif kapasite izleme ile bu sorunları giderin.