Power BI'da Bileşik Modeller: İçe Aktarma ve DirectQuery'yi Karıştırma

Power BI uygulayıcıları yıllarca seçim yapmak zorunda kaldı: içe aktarma modu (hızlı, ancak veriler yalnızca son yenileme kadar taze) veya DirectQuery (her zaman güncel, ancak potansiyel olarak yavaş ve sorgu sınırlı). Bileşik modeller, her iki depolama modunun, mod sınırını aşan ilişkilerle tek bir modelde bir arada var olmasına izin vererek bu hesabı değiştirdi.

Bu özellik, daha önce imkansız olan senaryoların kilidini açar: bir DirectQuery kaynağından alınan bugünün gerçek zamanlı verilerinin yanı sıra, bir içe aktarma bölümünden dünün tüm işlem geçmişini gösteren bir kontrol paneli, tümü talep üzerine sorgulanan canlı bir Salesforce fırsat tablosuna birleştirilir. Bileşik modellerin nasıl çalıştığını ve çözdüklerinden daha fazla sorun yarattıklarını anlamak, herhangi bir ileri düzey Power BI uygulayıcısı için temel bilgidir.

Önemli Çıkarımlar

Bileşik modeller, içe aktarma, DirectQuery ve İkili depolama modlarını tek bir anlamsal modelde birleştirir

İçe aktarma modu, geçmiş veriler için VertiPaq sıkıştırması ve bellek içi sorgu performansı sağlar

DirectQuery modu kaynağı gerçek zamanlı olarak sorgular — tazelik mükemmeldir ancak performans kaynağa bağlıdır

İkili mod tabloları, sorgu bağlamına bağlı olarak içe aktarma veya DirectQuery işlevi görebilir

Depolama modu sınırlarını aşan ilişkiler sorgu karmaşıklığını artırır ve performans sorunlarına neden olabilir

Bileşik modellerdeki toplama tabloları DirectQuery sorgu performansını önemli ölçüde artırır

Power BI veri kümeleri için DirectQuery (zincirleme), paylaşılan anlamsal modeller üzerine oluşturulan bileşik modellere olanak tanır

İçe aktarma ve DirectQuery tabloları arasındaki sınırlı ilişkiler belirli DAX işlevlerini kısıtlar

Depolama Modları: İçe Aktarma, DirectQuery ve İkili

Bileşik modelleri anlamadan önce her depolama modunun ayrı ayrı anlaşılması gerekir.

İçe aktarma modu, kaynak sistemdeki verileri Power BI'ın bellek içi VertiPaq depolama motoruna yükler. Veriler sıkıştırılır (genellikle 10:1 veya daha iyisi) ve analitik sorguları son derece hızlı (genellikle yüz milyonlarca satıra kadar veri kümelerindeki sorguların çoğu için milisaniyeler içinde) yürüten sütunlu veriler olarak depolanır. Sınırlama: Veriler yalnızca en son programlanan veya manuel yenileme kadar günceldir.

DirectQuery modu, kullanıcı bir raporla etkileşimde bulunduğunda kaynak sistemi gerçek zamanlı olarak sorgular. Power BI motoru, DAX sorgularını yerel kaynak sorgularına (ilişkisel veritabanları için SQL vb.) dönüştürür ve bunları kaynağa karşı yürütür. Veriler her zaman günceldir ancak performans tamamen kaynak sistemin sorgu performansına bağlıdır. A well-indexed, dedicated analytical database will handle DirectQuery queries well; Ağır işlem yükü altındaki bir OLTP üretim veritabanı, yavaş ve tutarsız sonuçlar üretebilir.

İkili mod kompozit modellerde bulunan özel bir hibrittir. Çift modlu bir tablo, fiziksel olarak içe aktarma olarak depolanır (VertiPaq'a yüklenen veriler) ancak sorgu bağlamı gerektirdiğinde DirectQuery aracılığıyla da sorgulanabilir. Bu öncelikle hem içe aktarma hem de DirectQuery olgu tablolarıyla ilişkilere katılması gereken paylaşılan boyut tabloları için kullanılır.

Kompozit Modeller Ne Zaman Kullanılmalı

Bileşik modeller belirli senaryolar için uygundur. Daha basit mimariler gereksinimleri karşıladığında haklı gösterilmeyecek bir karmaşıklık katıyorlar.

Kompozit modelleri şu durumlarda kullanın:

Senaryo	Mimarlık
Gerçek zamanlı güncel veriler + geçmiş analiz	Günümüzün olgu tablosu için DirectQuery, Geçmiş için içe aktarma
Çok büyük geçmiş veriler + orta büyüklükte boyutlar	İçe aktarma boyutlarıyla DirectQuery gerçekleri (toplu model)
Farklı tazelik gereksinimlerine sahip çoklu kaynak sistemleri	Farklı kaynaklardan DirectQuery'yi içe aktarın
Paylaşılan bir anlamsal modeli temel alma (Power BI veri kümesi)	Power BI Veri Kümeleri zincirleme için DirectQuery
Toplama tablolarıyla üstün kapasite	Kullanıcı tanımlı toplamalarla karma mod

Aşağıdaki durumlarda kompozit modelleri kullanmayın:

Tam içe aktarma modeli yeterince hızlı yenilenir ve veri gecikmesi kabul edilebilir düzeydedir (çoğu durumda)
DirectQuery kaynağı sorgu yükünü işleyemiyor (üretim OLTP veritabanları)
Karmaşık DAX hesaplamaları gereklidir — bileşik modeller belirli DAX işlevlerini sınırlar
Satır düzeyinde güvenliğin depolama modu sınırını kapsaması gerekir (karmaşık uygulama)

Depolama Modlarını Yapılandırma

Power BI Desktop'ta depolama modu tablo başına ayarlanır. Model görünümü → Özellikler → Gelişmiş → Depolama modunda bir tabloya sağ tıklayın.

DirectQuery'de büyük bir olgu tablosuna ve İçe Aktarma'da boyutlara sahip tipik bir bileşik model için:

FactSales → Depolama modunu ayarlayın: DirectQuery
DimDate → Depolama modunu ayarlayın: İkili (hem içe aktarma hem de DirectQuery sorgularına hizmet eder)
DimProduct → Depolama modunu ayarlayın: İçe Aktarma (küçük tablo, tamamen önbelleğe alınmış)
DimCustomer → Depolama modunu ayarlayın: İkili (kaynaklar arası ilişkilerde kullanılır)
RealtimeSales (bugünün verileri) → Depolama modunu ayarlayın: DirectQuery

Bir tabloyu DirectQuery olarak yapılandırdığınızda veya depolama modlarını değiştirdiğinizde Power BI, ilişkiler ve olası sınırlamalar hakkında uyarılar görüntüler. Bunları dikkatlice inceleyin; model davranışının salt içe aktarma modelinden nerede farklı olabileceğini gösterirler.

Bileşik Modellerde İlişkiler

Farklı depolama modlarına ait tablolar arasındaki ilişkiler, aynı mod ilişkilerinden farklı davranır ve bu farklılıkları anlamak, doğru sonuçlar üreten modeller oluşturmak için kritik öneme sahiptir.

Düzenli ilişkiler, "çok" tarafının filtrelemek için "bir" tarafı kullanabileceği iki tabloyu birbirine bağlar. İçe aktarma modellerinde her iki tablo da bellektedir ve ilişki bellekte hızlı bir şekilde gerçekleştirilir. Bir içe aktarma tablosu ve bir DirectQuery tablosu içeren bileşik modellerde ilişki, bir tablonun taranmasına neden olur ve bu tablo daha sonra diğerini filtrelemek için kullanılır; bu da potansiyel olarak büyük modlar arası sorgular oluşturur.

Sınırlı ilişkiler, DirectQuery tablosunun içe aktarma tablosuyla çoktan çoğa ilişkisi olduğunda veya diğer bazı çapraz mod senaryolarında otomatik olarak oluşturulur. Sınırlı ilişkiler, çift yönlü filtreleri desteklemez ve belirli DAX işlevlerini (örneğin, ilişki filtresi yoluna dayanan işlevler) kısıtlar. Power BI, sınırlı ilişkileri model görünümünde düz çizgi yerine noktalı çizgiyle bildirir.

Kaynaklar arası ilişkiler tamamen farklı veri kaynaklarından gelen tabloları birbirine bağlar (örneğin, SQL Server'dan DirectQuery aracılığıyla bağlanan bir tablo ve Salesforce'tan başka bir DirectQuery bağlantısı aracılığıyla bağlanan bir tablo). Bu ilişkiler bir tarafın Çift modlu bir tablo olmasını gerektirir; Power BI'ın ilişkinin bir tarafını diğerine katılabilmek için bellekte gerçekleştirebilmesi gerekir.

Bu ilişki türlerinin pratik etkisi: Saf içe aktarma modelinde doğru şekilde çalışan DAX ölçümleri, bileşik modelde beklenmeyen sonuçlara veya hatalara neden olabilir. Depolama modlarını değiştirdikten sonra, özellikle KULLANICI İLİŞKİSİ, ÇAPRAZ FİLTRE, ilişkiyle ilgili filtre işlevleriyle HESAPLAMA ve ilgili tablolar üzerindeki toplamaları içeren tüm önlemleri dikkatlice test edin.

Toplama Tabloları: Çekirdek Bileşik Model Modeli

En değerli bileşik model modeli, büyük bir DirectQuery olgu tablosunu, verileri daha yüksek düzeyde önceden özetleyen bir içe aktarma modu toplama tablosuyla birleştirir.

Sorun: DirectQuery'deki 500 milyon satırlık satış verileri tablosu, çoğu kaynak sistemin etkileşimli olarak sorgulaması için çok büyük; kaynak pahalı toplu sorgular yürüttüğünden her grafik 10+ saniye sürüyor.

Çözüm: Durumu günlük/aylık/ürün kategorisine göre toplayan bir özet tablosunu önceden oluşturun ve bu özet tablosunu Power BI'a aktarın. Sorguların çoğu (aylık, üç aylık veya kategori düzeyinde olan) hızlı içe aktarma toplama işlemine tabi tutulur. Yalnızca bireysel işlem düzeyine inen sorgular DirectQuery'ye geri döner.

Toplamaları ayarlama:

Öncelikle veri ambarınızda toplama tablosunu oluşturun:

CREATE TABLE SalesByDayProduct AS
SELECT
    SaleDateKey,
    ProductKey,
    CustomerSegmentKey,
    RegionKey,
    SUM(SalesAmount) as SalesAmount,
    SUM(Quantity) as Quantity,
    SUM(Cost) as Cost,
    COUNT(*) as TransactionCount
FROM FactSales
GROUP BY SaleDateKey, ProductKey, CustomerSegmentKey, RegionKey;

Bu tabloyu Power BI'a aktarın ve depolama modunu İçe Aktar olarak ayarlayın.

Ardından Power BI'da toplamayı yapılandırın:

SalesByDayProduct → Toplamaları yönet'e sağ tıklayın
Her sütunu ayrıntı tablosuyla ve özetleme işleviyle (Toplam, Ortalama, Sayım vb.) ilişkisiyle eşleştirin.
"Özetleme" sütununu ayarlayın (SalesAmount → Sum, FactSales[SalesAmount] → Sum ile eşleşir)

Power BI'ın sorgu motoru artık mümkün olduğunda sorguları otomatik olarak toplama tablosuna yönlendiriyor ve yalnızca sorgu, toplamanın sağlamadığı satır düzeyinde ayrıntı gerektirdiğinde DirectQuery ayrıntı tablosuna geri dönüyor.

Performans sonucu dramatiktir: Daha önce 15 saniye süren kategori düzeyinde ve zaman düzeyinde toplamalar artık 1 saniyenin altında geri dönerken, bireysel işlemlere yönelik detaylandırma seçeneği hâlâ kullanılabilir durumdadır.

Power BI Veri Kümeleri için DirectQuery

Power BI, Power BI Veri Kümeleri için DirectQuery'yi ("bileşik modellerle canlı bağlantı" veya kısaca "paylaşılan veri kümelerindeki bileşik modeller" olarak da bilinir) kullanıma sundu. Bu, geliştiricinin DirectQuery kaynağı olarak mevcut bir yayınlanmış Power BI veri kümesini kullanan yeni bir rapor veya veri kümesi oluşturmasına ve aynı zamanda yeni tablolar, hesaplanmış ölçümler ve yerel içe aktarma verileri eklemesine olanak tanır.

Önemli kullanım durumu: Bir kuruluşun, temel finans ve satış verilerini kapsayan sertifikalı bir kurumsal anlamsal modeli vardır. Belirli bir analiz üzerinde çalışan bir ekibin, sertifikalı kurumsal modeli değiştirmeden bazı yerel verileri (proje kodlarını içeren bir CSV dosyası, hedefleri içeren bir Excel dosyası) eklemesi gerekir. Power BI Veri Kümeleri için DirectQuery'yi kullanarak, DirectQuery aracılığıyla kurumsal modele referans veren ve yerel tablolarını içe aktarma verileri olarak ekleyen bileşik bir model oluştururlar.

Bu, aşağıdaki durumlarda yönetilen bir analitik mimarisine olanak tanır:

Merkezi veri ekibi sertifikalı kurumsal veri kümelerini korur
İş ekipleri ayrı, tutarsız modeller oluşturmadan bu veri kümelerini yerel bağlamla genişletiyor
Kurumsal model, paylaşılan ölçümler için tek gerçek kaynak olmaya devam ediyor

Sınırlamalar: Power BI Veri Kümeleri için DirectQuery, normal DirectQuery'nin tüm sınırlamalarını devralır; bazı DAX işlevleri sınırlıdır, bileşik model boyunca yayılacak şekilde satır düzeyinde güvenliğin uygun şekilde yapılandırılması gerekir ve kaynak veri kümesine bağlantı, bir sorgu işleme katmanı ekler.

Kompozit Modeller için Performans Optimizasyonu

Bileşik modeller, saf içe aktarma modellerine göre daha dikkatli performans ayarı gerektirir. Aşağıdaki optimizasyonlar en etkili olanlardır:

Modlar arası sorguları azaltın: Depolama modu sınırını aşan her ilişki geçişi gecikmeyi artırır. Boyut tablolarını İkili modda tutarak (modlar arası geçiş olmadan hem içe aktarma hem de DirectQuery sorgularına hizmet edebilirler) ve modeli çoğu sorgunun tek bir modda kalacağı şekilde yapılandırarak bunları en aza indirin.

Kaynakta önceden toplama: DirectQuery kaynağından Power BI'ın daha verimli şekilde yapabileceği toplamaları yapmasını istemeyin. Kaynak veritabanında, raporlarınızın gerçekte ihtiyaç duyduğu düzeyde önceden toplanan görünümler veya somutlaştırılmış görünümler oluşturun.

Sorgu planını Performans Analizörü ile izleyin: Power BI Desktop'ta Görünüm → Performans Analizörü, her görselin DAX sorgusu ve sonraki kaynak sorgusu (DirectQuery ise) için geçen süreyi kaydeder. Bu, hangi görsellerin yavaş olduğunu ve yavaş sorgunun DAX katmanında mı yoksa kaynak sorgu katmanında mı olduğunu ortaya çıkarır.

Sorgu azaltma ayarlarını kullanın: Power BI Desktop → Seçenekler → Sorgu azaltma bölümünde, dilimleyicilere ve filtrelere Uygula düğmeleri ekleme seçeneklerini etkinleştirin. Bu, her dilimleyici etkileşiminin anında bir kaynak sorgusu başlatmasını önler; özellikle her sorgunun ağ ve kaynak yürütme gecikmesine sahip olduğu DirectQuery raporları için önemlidir.

DirectQuery bağlantılarının sayısını sınırlayın: Bileşik modeldeki her farklı DirectQuery kaynağı, ayrı bir bağlantı havuzu oluşturur. Mümkün olduğunda 1-2 DirectQuery kaynağıyla sınırlandırın; 3'ten fazlası model karmaşıklığını ve potansiyel performans sorunlarını önemli ölçüde artırır.

Kompozit Modellerde Satır Düzeyinde Güvenlik

Bileşik modellerde satır düzeyinde güvenlik (RLS), özellikle RLS, DirectQuery tablosuyla ilişkisi olan bir içe aktarma tablosunda tanımlandığında dikkatli planlama gerektirir.

RLS filtresine sahip bir kullanıcı bir raporu sorguladığında Power BI, filtreyi uygun tabloya uygular. Filtrelenen tablo içe aktarma modundaysa ve bir DirectQuery tablosuyla ilişkisi varsa Power BI'ın içe aktarma filtresini DirectQuery kaynağına gönderilebilecek bir filtreye çevirmesi gerekir. Bu çoğu durumda işe yarar ancak karmaşık filtre hiyerarşilerinde beklenmeyen sonuçlar doğurabilir.

En iyi uygulama: RLS'yi içe aktarma modu boyut tablolarında tanımlayın (DirectQuery olgu tablolarında değil). Filtre, güvenilir bir şekilde çalışan ilişki aracılığıyla boyuttan gerçeğe yayılır. RLS'yi doğrudan DirectQuery tablolarında tanımlamak mümkündür ancak test edilmesi ve hata ayıklaması daha zordur.

Power BI Veri Kümeleri için DirectQuery kullanan bileşik modeller için, kaynak veri kümesinde tanımlanan RLS, söz konusu veri kümesi sorgulandığında otomatik olarak uygulanır. Bileşik model katmanında ek RLS tanımlanabilir. Bu katmanlı RLS yaklaşımı, filtrelerin doğru şekilde birleşiminden emin olmak için dikkatli testler gerektirir.

Sıkça Sorulan Sorular

Tamamen farklı veritabanı platformlarından gelen verileri bileşik bir modelde karıştırabilir miyim?

Evet. Bileşik model, SQL Server'dan (DirectQuery), Salesforce'tan (DirectQuery), Azure Blob Depolama dosyasından (Import) ve Snowflake'ten (DirectQuery) aynı anda tablolar içerebilir. Her kaynak kendi bağlantısını korur. Farklı kaynaklardan gelen tablolar arasındaki ilişkilerde, kaynaklar arası birleştirmeleri kolaylaştırmak için en az bir Çift modlu tablo bulunmalıdır. Her ek kaynakla performans ve karmaşıklık artar; çoğu uygulama için 2-3 kaynakla sınırlamak pratiktir.

Bileşik modellerde hangi DAX işlevleri çalışmıyor?

Bazı DAX işlevleri kısıtlanmıştır veya DirectQuery tablolarına sahip bileşik modellerde farklı davranır. Sınırlı ilişkilerle çalışmayan işlevler arasında SUMMARIZE (belirli bağlamlarda), TOPN (DirectQuery tablolarında) ve bazı zaman zekası işlevleri bulunur. USERELATIONSHIP çalışır ancak modlar arası sorgulara neden olabilir. Sınırlamaların tam listesi Microsoft'un Power BI belgelerinde "DirectQuery sınırlamaları" altında belgelenmiştir. DirectQuery tablolarını ekledikten sonra tüm kritik önlemlerin test edilmesi önemle tavsiye edilir.

Artımlı yenileme kompozit modellerde nasıl çalışır?

Artımlı yenileme, bileşik model içindeki içe aktarma modu bölümlerine uygulanır. DirectQuery olarak yapılandırılan tablolar artımlı yenileme kullanmaz; her etkileşimde kaynağı gerçek zamanlı olarak sorgularlar. En yaygın kombinasyon, geçerli dönem verileri için DirectQuery'ye sahipken içe aktarma modundaki geçmiş bölümlerde artımlı yenileme kullanmaktır; bu, tek bir tablo içinde bileşik modellemenin belirli bir biçimi olan hibrit tablolar özelliğidir.

Kompozit modellerin saf içe aktarmaya göre performans etkisi nedir?

DirectQuery bileşenlerine sahip bileşik modeller, eşdeğer sorgular için eşdeğer salt içe aktarma modellerinden her zaman daha yavaş olacaktır. Performans farkı, kaynak sistem performansına ve DirectQuery'yi etkileyen sorguların oranına ve içe aktarma bölümlerine bağlıdır. İyi tasarlanmış toplama tablolarıyla, çoğu kullanıcı sorgusu içe aktarma toplamasına ulaşır ve 1 saniyeden kısa sürede geri döner, bu da performansı kabul edilebilir hale getirir. DirectQuery ayrıntılarına giden sorgular, kaynak performansına bağlı olarak 3-15 saniye sürebilir.

Bileşik modeller mi kullanmalıyım yoksa daha sık yenileme planlamalı mıyım?

"Neredeyse gerçek zamanlı"nın kabul edilebilir olduğu çoğu kullanım durumu için daha sık yenilemeler (içe aktarma modu için her 15 dakikada bir) yeterlidir. DirectQuery içeren kompozit modeller önemli ölçüde karmaşıklık katar; bunları yalnızca şu durumlarda kullanın: (a) gerçekten dakika veya saniye güncel olan verilere ihtiyaç duyduğunuzda, (b) veri kümesi, artımlı yenilemeyle bile mevcut pencere içinde yenilenemeyecek kadar büyük olduğunda veya (c) tek bir ambar yenilemesinde birleştirilemeyen kaynaklardan gelen verileri birleştirmeniz gerektiğinde.

Sonraki Adımlar

Bileşik modeller, gelişmiş Power BI mimarileri için güçlü bir araçtır; ancak performans ve doğrulukla ilgili tuzaklardan kaçınmak için dikkatli bir tasarım gerektirirler. En başarılı uygulamalar, varsayılan bir mimari yerine belirli, gerekçelendirilmiş senaryolar için bileşik modelleri kullanır.

ECOSIRE'ın Power BI veri modelleme hizmetleri bileşik model tasarımı, toplama tablosu uygulaması ve performans optimizasyonunu içerir. Bileşik modellerin spesifik veri güncelliği ve performans gereksinimleriniz için doğru çözüm olup olmadığını değerlendirmek için bizimle iletişime geçin.

Composite Models in Power BI: Mixing Import and DirectQuery