Import ve DirectQuery Modu: Hangi Durumda Hangisi Seçilir?

Seçimin özü: veri nerede duruyor?

Power BI'da bir kaynağa bağlanırken ilk karar, verinin modele kopyalanıp kopyalanmayacağıdır. Import (içe aktarma) modunda tabloların bir anlık görüntüsü Power BI'ın bellek içi motoruna yüklenir; rapor açıldığında görseller bu önbellekten çalışır, yeni veri için modelin yenilenmesi gerekir. DirectQuery modunda ise veri kaynakta kalır; her görsel yüklendiğinde Power BI, DAX sorgusunu kaynağın kendi diline (örneğin SQL) çevirip kaynağa gönderir ve sonucu çizer.

Microsoft'un DirectQuery rehberi tavsiyeyi açık yazar: Varsayılan olarak Import kullanın; çünkü Power BI'ın yüksek performanslı bellek içi motorunu ve en zengin özellik setini sunar. Import'tan uzaklaşmak ancak gecikme, boyut, yönetişim, güvenlik ya da mimari gibi somut bir kısıt varsa gerekçelidir.

Bu nedenle sorunun doğru biçimi "hangi mod daha iyi" değil, "hangi kısıt beni Import'tan uzaklaştırıyor" olmalıdır. Aşağıdaki bölümler, kısıtları ve modun getirdiği bedelleri ele alır.

Import modunu seçmek için nedenler

Import modu şu durumlarda doğal tercihtir:

• Etkileşim hızı önemlidir. Görsellerin tamamı bellek içi önbellekten yanıtlanır; dilimleyici, çapraz filtreleme ve ayrıntıya gitme anında tepki verir.
• Dönüşümler karmaşıktır. Power Query'nin tüm dönüşümleri ve DAX'in tüm işlevleri kullanılabilir; kaynağa çevrilebilir olma zorunluluğu yoktur.
• Veri, saatler ya da günlük aralıklarla yenilense yeterlidir. Gerçek zamanlı değişim izlenmiyorsa yenileme sıklığı yeterlidir.
• Birden çok kaynağı tek modelde birleştirmeniz gerekir.
• Kaynak sistem yoğun çalışmaktadır ve her kullanıcı etkileşiminde ona sorgu atılması istenmez.

Bedelleri de vardır: Veri, yenilenene kadar eskidir. Pro lisansta zamanlanmış yenileme sayısı sınırlıdır; Premium ve Premium per user daha sık yenileme sunar. Model boyutu belleği doldurabilir; bu durumda artımlı yenileme, toplulaştırma (aggregation) ya da büyük model depolama biçimi devreye girer. Şirket içi kaynaklar için çoğunlukla bir veri ağ geçidi de gerekir.

DirectQuery'yi seçmek için nedenler

Rehber, DirectQuery'yi şu senaryolar için en yararlı bulur:

• Veri, en yüksek yenileme sıklığıyla bile yetişilemeyecek kadar sık değişiyor ve düşük gecikmeli görünürlük gerekiyor.
• Veri hacmi ya da yönetişim koşulları tüm veriyi içeri almayı pratik dışı bırakıyor.
• Satır düzeyinde ince güvenlik kuralları kaynakta tanımlı ve kaynağın yetkisi son söz olmalı. DirectQuery, destekleniyorsa kullanıcı kimliğini kaynağa iletir (tekli oturum açma).
• Veri egemenliği ya da mevzuat, tam kopyanın başka yerde tutulmasını kısıtlıyor.
• Kaynak çok boyutlu ya da ölçü merkezli (örneğin SAP BW); sunucuda tanımlı ölçülerin her görselde sunucuda çözülmesi gerekiyor.

Bedelleri: Görsel gecikmesi tamamen kaynağın performansına, eşzamanlı kullanıcıya ve gerekiyorsa ağ geçidine bağlıdır. Her kullanıcı etkileşimi kaynağa sorgu üretir; çok kullanıcı, çok görsel ve çok kutucuk kaynakta ciddi yük oluşturabilir. Dönüşümler kısıtlıdır, bazı DAX işlevleri hesaplanmış sütunlarda ve RLS kurallarında desteklenmez. Farklı görseller kaynağa biraz farklı anlarda sorgu attığı için zaman bakımından tutarsız görünebilirler. Rehberin sınırları arasında, tek bir sorgunun ya da ara işlemin döndürebileceği satır sayısı için bir üst sınır da vardır; Premium kapasitede bu sınır yükseltilebilir.

Karar akışı: sorularla seçim

Seçimi şu sırayla ilerleterek yapın:

• Veri kaç dakikada bir değişiyor ve kullanıcı bu gecikmeyi kabul edebilir mi? Kabul ediyorsa Import ve zamanlanmış yenileme yeterlidir.
• Veri belleğe sığmayacak kadar mı büyük? Önce artımlı yenileme, toplulaştırma ve filtrelenmiş alt küme gibi Import seçeneklerini deneyin.
• Kaynak yük ve gecikmeye dayanıklı mı? DirectQuery kaynağın hızına bağlıdır; kaynak yavaşsa seçim sorunu çözmez.
• Güvenlik kaynakta mı yönetilmek zorunda? O zaman DirectQuery (ve tekli oturum açma) gündeme gelir.
• Modelde ihtiyaç duyduğum dönüşümler kaynağa çevrilebiliyor mu? Çevrilemiyorsa DirectQuery güç bela kullanılır.

Rehberin hızlı karar özeti de bu mantığa uyar. En yüksek etkileşim ve dönüşüm esnekliği için Import; yakın tarihli olgu verisinde neredeyse gerçek zamanlı değişim ile geçmiş bağlam için karma (hybrid) tablo; dağıtık kaynaklara tam alım olmadan erişim için bileşik modelde DirectQuery; hazır ve yönetişimli kurumsal modeli yeniden kullanmak için canlı bağlantı; Fabric ortamında lakehouse ya da ambar ölçeğinde düşük gecikmeli okuma için Direct Lake.

Ara yollar: Dual, Hybrid ve bileşik model

İki mod arasındaki seçim ikili olmak zorunda değildir. Belge, tablo bazında depolama modunu ele alır ve Dual ile Hybrid'i tanıtır.

Bileşik model (composite model): Modeldeki tablolar farklı depolama modlarında olabilir. Tipik düzen, büyük olgu tablosunu DirectQuery, küçük boyut tablolarını (tarih, müşteri, coğrafya) Import ya da Dual tutmaktır.

Dual: Tablo, sorguya göre hem Import hem DirectQuery gibi davranır. Boyut tablolarını Dual yapmak, DirectQuery olgu tablosuyla ilişkilerin kısıtlı (limited) kalmasını önler ve performansı iyileştirir; çünkü kısıtlı ilişkilerde birleştirme mantığı kaynağa itilemez. Dual tabloların işlevsel kısıtları DirectQuery ile aynıdır.

Hybrid: Artımlı yenilemeli Import tablosunun en son bölümü DirectQuery olur; böylece geçmiş önbellekte, en yeni veri sorgu anında gelir. Gerçek zamanlı bölüm yalnızca Premium, Premium per user ve Embedded için desteklenir.

Depolama modunu Model görünümünde tabloyu seçip Özellikler bölmesinde Advanced altından görürsünüz. Çoğu tablo için mod yalnızca tabloyu eklerken seçilir. DirectQuery bir tabloyu sonradan Import ya da Dual'e çevirebilirsiniz, ama geri DirectQuery'ye döndüremezsiniz; web modelleme ve canlı düzenleme gibi sürüm denetimi olan ortamlar bunun istisnasıdır.

Her iki modda performans ve model tasarımı

DirectQuery'de performans iyileştirmesi çoğunlukla kaynakta yapılır: Birleştirme ve filtre sütunlarında uygun indeksler, görünüm ya da hazırlanmış tablolar, kaynak sistemin sorgu önbelleği ve ağ gecikmesi. Rehber, kaynak bazlı farkları da sayar: Örneğin PostgreSQL'de tırnaklı tanımlayıcılar büyük küçük harfe duyarlıdır; birleştirme ve filtre sütunlarına uygun b-tree indeksleri gerekir. Bulut ambarlarında ilk sorguda soğuk başlangıç gecikmesi olabilir.

Power Query'de dönüşümlerin kaynağa çevrilip çevrilmediğini View Native Query ile denetleyin; çevrilmiyorsa DirectQuery ya çalışmaz ya da yavaşlar. Büyük küçük harf duyarlı kaynaklarda Power BI'ın duyarsız olduğunu unutmayın: Yalnızca harf büyüklüğüyle ayrışan iki değer, Power BI'a göre mükerrerdir ve sonuç belirsizleşebilir; kaynakta büyük küçük harfi normalize edin.

Import'ta ise yıldız şema, gereksiz sütunların çıkarılması, yüksek benzersizlikli sütunlardan kaçınma ve gerekirse artımlı yenileme öne çıkar. Hangi mod olursa olsun Performans Analizörü, yavaşlığın DAX sorgusundan mı, kaynaktan mı, çizimden mi geldiğini gösterir.

Sık hatalar

Birincisi, "canlı veri iyidir" varsayımıyla DirectQuery'ye başlamak. Gerçek bir gecikme gereksinimi yoksa Import hem daha hızlı hem daha az kısıtlıdır.

İkincisi, kaynağın hızını hesaba katmamak. DirectQuery, kaynağın bir uzantısı gibi çalışır; yavaş bir kaynak yavaş bir rapor demektir.

Üçüncüsü, hazır bir modeli DirectQuery'ye çevirmeye çalışmak. Belge, Import'ta kurulu bir modelin bütününü tek hamlede DirectQuery'ye geçiremeyeceğinizi belirtir; yeni bir DirectQuery bağlantısı eklemek, bileşik model kurmak ya da yeniden inşa etmek gerekir.

Dördüncüsü, çok görsel ve çok kullanıcılı bir sayfayı DirectQuery'de tasarlayıp kaynağı yormak. Sayfadaki görsel sayısı, her etkileşimde üretilen sorgu sayısıdır.

Beşincisi, kutucukları ve zamanlamayı unutmak. DirectQuery panolarında kutucuk sonuçları zamanlanmış yenilemeyle önbelleğe alınır ve el ile yenilenmedikçe son zamanlanmış yenilemedeki değeri gösterir.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Depolama modu kararı, model mimarisini belirleyen veri modelleyicilerin ve BI mimarlarının işidir; kurumsal bir veri ambarına bağlanan raporlama ekipleri için doğrudan karşılık bulur.

Power BI Veri Modelleme programının "Veri Modelleme Temelleri ve Motor Mantığı", "İleri Model Mimarisi ve Ölçeklendirme" ve "Power BI Premium ve Kurumsal Dağıtım" başlıkları bu kararın arka planını kurar. Power BI İleri Düzey ve DAX programındaki performans optimizasyonu ve güvenlik modülleri ise seçtiğiniz modun sonuçlarını (sorgu hızı, RLS) ele alır.