Power BI'da DirectQuery

Power BI Desktop'ta veya Power BI hizmeti birçok farklı veri kaynağına farklı yollarla bağlanabilirsiniz. Verileri Power BI'a aktarabilirsiniz. Bu, veri almak için en yaygın yöntemdir. Ayrıca directQuery olarak adlandırılan özgün kaynak deposundaki bazı verilere doğrudan bağlanabilirsiniz. Bu makalede öncelikle DirectQuery özellikleri ele alınmaktadır.

Bu makalede şunlar açıklanmaktadır:

• Farklı Power BI veri bağlantısı seçenekleri.
• İçeri aktarma yerine DirectQuery'nin ne zaman kullanılacağına ilişkin yönergeler.
• DirectQuery kullanmanın sınırlamaları ve etkileri.
• DirectQuery'nin başarıyla kullanılması için Öneriler.
• DirectQuery performans sorunlarını tanılama.

Makale, Power BI Desktop'ta rapor oluşturduğunuzda DirectQuery iş akışına odaklanır, ancak Power BI hizmeti DirectQuery aracılığıyla bağlanmayı da kapsar.

Not

DirectQuery, SQL Server Analysis Services'ın da bir özelliğidir. Bu özellik, Power BI'daki Direct Query ile birçok ayrıntıyı paylaşır, ancak önemli farklılıklar da vardır. Bu makale öncelikli olarak SQL Server Analysis Services ile değil Power BI ile DirectQuery'yi kapsar.

SQL Server Analysis Services ile DirectQuery kullanma hakkında daha fazla bilgi için bkz . Power BI anlam modelleri ve Analysis Services (önizleme) için DirectQuery kullanma. PDF DirectQuery'yi SQL Server 2016 Analysis Services'da da indirebilirsiniz.

Power BI veri bağlantısı modları

Power BI, aşağıdakiler gibi çok sayıda farklı veri kaynağına bağlanır:

• Salesforce ve Dynamics 365 gibi çevrimiçi hizmetler.
• SQL Server, Access ve Amazon Redshift gibi veritabanları.
• Excel, JSON ve diğer biçimlerdeki basit dosyalar.
• Spark, web siteleri ve Microsoft Exchange gibi diğer veri kaynakları.

Bu kaynaklardan Power BI'a veri aktarabilirsiniz. Bazı kaynaklar için DirectQuery kullanarak da bağlanabilirsiniz. DirectQuery'yi destekleyen kaynakların özeti için bkz . DirectQuery tarafından desteklenen veri kaynakları. DirectQuery özellikli kaynaklar öncelikli olarak iyi etkileşimli sorgu performansı sunabilen kaynaklardır.

Mümkün olan her yerde Power BI'a veri aktarmanız gerekir. İçeri aktarma, Power BI'ın yüksek performanslı sorgu altyapısından yararlanır ve yüksek oranda etkileşimli, tam özellikli bir deneyim sağlar.

Verileri içeri aktararak hedeflerinizi karşılayamazsanız(örneğin, veriler sık sık değişiyorsa ve raporlar en son verileri yansıtmalıysa) DirectQuery'yi kullanmayı göz önünde bulundurun. DirectQuery yalnızca temel alınan veri kaynağı tipik bir toplama sorgusu için beş saniyeden kısa sürede etkileşimli sorgu sonuçları sağlayabildiği ve oluşturulan sorgu yükünü işleyebildiği durumlarda uygulanabilir. DirectQuery kullanmanın sınırlamalarını ve etkilerini dikkatle göz önünde bulundurun.

Power BI içeri aktarma ve DirectQuery özellikleri zaman içinde gelişir. İçeri aktarılan verileri kullanırken daha fazla esneklik sağlayan değişiklikler, daha sık içeri aktarmanıza olanak sağlar ve DirectQuery kullanmanın bazı dezavantajlarını ortadan kaldırır. İyileştirmelerden bağımsız olarak, DirectQuery kullanılırken temel alınan veri kaynağının performansı önemli bir noktadır. Temel alınan bir veri kaynağı yavaşsa, bu kaynak için DirectQuery kullanılması mümkün değildir.

Aşağıdaki bölümlerde verilere bağlanmak için üç seçenek ele alınıyor: içeri aktarma, DirectQuery ve canlı bağlantı. Makalenin geri kalanı DirectQuery'ye odaklanır.

Bağlantıları içeri aktarma

SQL Server gibi bir veri kaynağına bağlandığınızda ve Power BI Desktop'ta verileri içeri aktardığınızda aşağıdaki sonuçlar oluşur:

• Başlangıçta Veri Al'ı seçtiğinizde, seçtiğiniz her tablo kümesi bir veri kümesi döndüren bir sorgu tanımlar. Verileri yüklemeden önce, örneğin filtreleri uygulamak, verileri toplamak veya farklı tabloları birleştirmek için bu sorguları düzenleyebilirsiniz.

• Yükleme sırasında sorgular tarafından tanımlanan tüm veriler Power BI önbelleğine aktarılır.

• Power BI Desktop'ta görsel oluşturma, önbelleğe alınan verileri sorgular. Power BI deposu sorgunun hızlı olmasını ve görseldeki tüm değişikliklerin hemen yansıtılmasını sağlar.

• Görseller, veri deposundaki temel alınan verilerde yapılan değişiklikleri yansıtmaz. Verileri yenilemek için yeniden içeri aktarmanız gerekir.

• Raporu Power BI hizmeti bir .pbix dosyası olarak yayımlamak, içeri aktarılan verileri içeren bir anlam modeli oluşturur ve karşıya yükler. Daha sonra veri yenilemeyi zamanlayabilirsiniz; örneğin verileri her gün yeniden içeri aktarabilirsiniz. Özgün veri kaynağının konumuna bağlı olarak, yenileme için şirket içi veri ağ geçidinin yapılandırılması gerekebilir.

• Var olan bir raporu açmak veya Power BI hizmeti yeni bir rapor yazmak, içeri aktarılan verileri yeniden sorgulayarak etkileşime geçin.

• Görselleri veya rapor sayfalarının tamamını Power BI hizmeti pano kutucukları olarak sabitleyebilirsiniz. Temel alınan anlamsal model her yenilendiğinde kutucuklar otomatik olarak yenilenir.

DirectQuery bağlantıları

Power BI Desktop'ta bir veri kaynağına bağlanmak için DirectQuery kullandığınızda aşağıdaki sonuçlar oluşur:

• Kaynağı seçmek için Veri Al'ı kullanırsınız. İlişkisel kaynaklar için, mantıksal olarak bir veri kümesi döndüren bir sorgu tanımlayan bir tablo kümesi seçebilirsiniz. SAP Business Warehouse (SAP BW) gibi çok boyutlu kaynaklar için yalnızca kaynağı seçersiniz.

• Yükleme sırasında Power BI deposuna hiçbir veri aktarılmış olmaz. Bunun yerine, bir görsel oluşturduğunuzda Power BI Desktop gerekli verileri almak için temel alınan veri kaynağına sorgular gönderir. Görseli yenilemek için gereken süre, temel alınan veri kaynağının performansına bağlıdır.

• Temel alınan verilerde yapılan değişiklikler mevcut görsellere hemen yansıtılamaz. Yenileme işlemi yine de gereklidir. Power BI Desktop her görsel için gerekli sorguları yeniden gönderin ve görseli gerektiği şekilde güncelleştirin.

• Raporun Power BI hizmeti yayımlanması, içeri aktarma ile aynı şekilde bir anlam modeli oluşturur ve karşıya yükler. Ancak bu anlam modeli veri içermiyor.

• Mevcut bir raporu açmak veya Power BI hizmeti yeni bir rapor yazmak, gerekli verileri almak için temel alınan veri kaynağını sorgular. Özgün veri kaynağının konumuna bağlı olarak, verileri almak için bir şirket içi veri ağ geçidi yapılandırmak gerekebilir.

• Görselleri veya rapor sayfalarının tamamını pano kutucukları olarak sabitleyebilirsiniz. Pano açma işleminin hızlı olduğundan emin olmak için kutucuklar belirli bir zamanlamaya göre (örneğin saatte bir) otomatik olarak yenilenir. Verilerin ne sıklıkta değiştiğine ve en son verileri görmenin önemine bağlı olarak yenileme sıklığını denetleyebilirsiniz.

• Bir panoyu açtığınızda kutucuklar, temel alınan kaynakta yapılan en son değişiklikleri değil, son yenileme sırasındaki verileri yansıtır. Açık bir panoyu güncel olduğundan emin olmak için yenileyebilirsiniz.

Canlı bağlantılar

SQL Server Analysis Services'e bağlandığınızda, verileri içeri aktarmayı veya seçili veri modeline canlı bir bağlantı kullanmayı seçebilirsiniz. Canlı bağlantı kullanmak DirectQuery'ye benzer. Hiçbir veri içeri aktarılır ve temel alınan veri kaynağı görselleri yenilemek için sorgulanır.

Örneğin, SQL Server Analysis Services'e bağlanmak için içeri aktarma özelliğini kullandığınızda, dış SQL Server Analysis Services kaynağına yönelik bir sorgu tanımlar ve verileri içeri aktarırsınız. Canlı bağlantı kurarsanız bir sorgu tanımlamazsınız ve dış modelin tamamı alan listesinde gösterilir.

Bu durum, verileri içeri aktarma seçeneği olmaması dışında aşağıdaki kaynaklara bağlandığınızda da geçerlidir:

• Power BI anlam modelleri, örneğin hizmette zaten yayımlanmış bir Power BI anlam modeline bağlanarak bu model üzerinde yeni bir rapor yazabilirsiniz.

• Microsoft Dataverse.

Canlı bağlantılar kullanan SQL Server Analysis Services raporlarını yayımladığınızda, Power BI hizmeti davranış aşağıdaki yollarla DirectQuery raporlarına benzer:

• Var olan bir raporu açmak veya Power BI hizmeti yeni bir rapor yazmak, büyük olasılıkla şirket içi veri ağ geçidi gerektiren temel SQL Server Analysis Services kaynağını sorgular.

• Pano kutucukları, saatte bir gibi bir zamanlamaya göre otomatik olarak yenilenir.

Canlı bağlantı, DirectQuery'den de farklı şekillerde farklılık gösterir. Örneğin, canlı bağlantılar her zaman raporu açan kullanıcının kimliğini temel SQL Server Analysis Services kaynağına geçirir.

DirectQuery kullanım örnekleri

DirectQuery ile Bağlan aşağıdaki senaryolarda yararlı olabilir. Bu durumların birkaçında, verileri özgün kaynak konumunda bırakmak gerekli veya yararlı olacaktır.

Power BI'da DirectQuery aşağıdaki senaryolarda en büyük avantajları sunar:

• Veriler sık sık değişir ve neredeyse gerçek zamanlı raporlamaya ihtiyacınız vardır.
• Büyük verileri önceden toplamaya gerek kalmadan işlemeniz gerekir.
• Temel alınan kaynak güvenlik kurallarını tanımlar ve uygular.
• Veri hakimiyeti kısıtlamaları geçerlidir.
• Kaynak, SAP BW gibi ölçüler içeren çok boyutlu bir kaynaktır.

Veriler sık sık değişir ve neredeyse gerçek zamanlı raporlamaya ihtiyacınız vardır

Power BI Pro veya Power BI Premium abonelikleriyle saatte en çok bir kez, daha sık içeri aktarılan verilerle modelleri yenileyebilirsiniz. Veriler sürekli değişiyorsa ve raporların en son verileri göstermesi gerekiyorsa, zamanlanmış yenileme ile içeri aktarmayı kullanmak gereksinimlerinizi karşılamayabilir. Bu durum için desteklenen veri birimlerinde sınırlar olsa da, doğrudan Power BI'a veri akışı yapabilirsiniz.

DirectQuery'nin kullanılması, bir raporu veya panoyu açmanın veya yenilemenin her zaman kaynaktaki en son verileri gösterdiği anlamına gelir. Pano kutucukları da 15 dakikada bir daha sık güncelleştirilebilir.

Veriler çok büyük

Veriler çok büyükse, tümünü içeri aktarmak mümkün değildir. DirectQuery, verileri yerinde sorguladığı için büyük veri aktarımı gerektirmez. Ancak, büyük veriler bu temel alınan kaynakta sorguların performansını da çok yavaş hale getirebilir.

Her zaman tam ayrıntılı verileri içeri aktarmanız gerekmez. Power Query Düzenleyicisi, içeri aktarma sırasında verileri önceden toplamayı kolaylaştırır. Teknik olarak, her görsel için tam olarak ihtiyacınız olan toplam verileri içeri aktarmak mümkündür. Büyük verilere yönelik en basit yaklaşım DirectQuery olsa da, temel alınan veri kaynağı DirectQuery için çok yavaşsa toplama verilerini içeri aktarmak bir çözüm sunabilir.

Bu ayrıntılar yalnızca Power BI kullanımıyla ilgilidir. Power BI'da büyük modelleri kullanma hakkında daha fazla bilgi için bkz . Power BI Premium'da büyük anlam modelleri. Verilerin ne sıklıkta yenilenebileceğiyle ilgili bir kısıtlama yoktur.

Temel alınan kaynak güvenlik kurallarını tanımlar

Verileri içeri aktardığınızda Power BI, geçerli kullanıcının Power BI Desktop kimlik bilgilerini veya Power BI hizmeti zamanlanmış yenileme için yapılandırılmış kimlik bilgilerini kullanarak veri kaynağına bağlanır. İçeri aktarılan verileri içeren raporları yayımlama ve paylaşmada, yalnızca verileri görmesine izin verilen kullanıcılarla paylaşmaya dikkat etmeniz veya anlam modelinin bir parçası olarak satır düzeyi güvenlik tanımlamanız gerekir.

DirectQuery, bir rapor görüntüleyicisinin kimlik bilgilerinin temel alınan kaynağa geçirilmesini sağlar ve bu da güvenlik kurallarını uygular. DirectQuery, Azure SQL veri kaynaklarında ve bir veri ağ geçidi aracılığıyla şirket içi SQL sunucularında çoklu oturum açmayı (SSO) destekler. Daha fazla bilgi için bkz . Power BI'da ağ geçitleri için çoklu oturum açmaya (SSO) genel bakış.

Veri hakimiyeti kısıtlamaları geçerlidir

Bazı kuruluşlarda veri hakimiyetiyle ilgili ilkeler vardır ve bu da verilerin kuruluş şirket dışına çıkamama anlamına gelir. Bu veriler, veri içeri aktarmayı temel alan çözümler için sorunlar sunar. DirectQuery ile veriler temel alınan kaynak konumda kalır. Ancak DirectQuery ile bile Power BI hizmeti, kutucukların zamanlanmış yenilemesi nedeniyle bazı veri önbelleklerini görsel düzeyde tutar.

Temel alınan veri kaynağı ölçüleri kullanır

SAP HANA veya SAP BW gibi temel alınan bir veri kaynağı ölçüler içerir. Ölçüler, içeri aktarılan verilerin sorgu tarafından tanımlandığı gibi zaten belirli bir toplama düzeyinde olduğu anlamına gelir. TotalSales by Year gibi daha üst düzey bir toplamada veri isteyen bir görsel, toplama değerini daha da toplar. Bu toplama, Sum ve Min gibi ek ölçüler için uygundur, ancak Average ve DistinctCount gibi eksiz ölçüler için bir sorun olabilir.

Doğrudan kaynaktan bir görsel için gereken doğru toplama verilerini kolayca almak için DirectQuery'de olduğu gibi görsel başına sorgu gönderilmesi gerekir. SAP BW'ye bağlandığınızda DirectQuery'nin seçilmesi ölçülerin bu şekilde işlenmesine olanak tanır. Daha fazla bilgi için bkz . DirectQuery ve SAP BW.

Şu anda SAP HANA üzerinden DirectQuery verileri ilişkisel bir kaynak olarak ele alır ve içeri aktarmaya benzer davranışlar üretir. Daha fazla bilgi için bkz . DirectQuery ve SAP HANA.

DirectQuery sınırlamaları

DirectQuery kullanmanın bazı olumsuz etkileri vardır. Bu sınırlamalardan bazıları, tam olarak kullandığınız kaynağa bağlı olarak biraz farklılık gösterir. Aşağıdaki bölümlerde DirectQuery kullanmanın genel etkileri ve performans, güvenlik, dönüşümler, modelleme ve raporlamayla ilgili sınırlamalar listelenmektedir.

Genel etkiler

DirectQuery kullanmanın bazı genel etkileri ve sınırlamaları şunlardır:

• Veriler değişirse, en son verileri göstermek için yenilemeniz gerekir. Önbellek kullanımı göz önünde bulundurulduğunda görsellerin her zaman en son verileri göstermesinin garantisi yoktur. Örneğin, bir görsel geçmiş gün içindeki işlemleri gösterebilir. Dilimleyici değişikliği, son gelen ve yeni gelen işlemler de dahil olmak üzere son iki güne ilişkin işlemleri göstermek için görseli yenileyebilir. Ancak dilimleyiciyi özgün değerine döndürmek, önbelleğe alınmış önceki değerin yeniden gösterilmesine neden olabilir. Önbellekleri temizlemek ve sayfadaki tüm görselleri yenileyip en son verileri göstermek için Yenile'yi seçin.

• Veriler değişirse görseller arasında tutarlılık garantisi yoktur. Aynı sayfada veya farklı sayfalarda farklı görseller farklı zamanlarda yenilenebilir. Temel alınan kaynaktaki veriler değişiyorsa, her görselin verileri zaman içinde aynı noktada göstermesinin garantisi yoktur.

  Örneğin, tek bir görselde ayrıntıları ve toplamları elde etmek için birden fazla sorgu gerekebileceği göz önünde bulundurulduğunda tek bir görseldeki tutarlılık bile garanti edilmemektedir. Bu tutarlılığı garanti etmek için, herhangi bir görsel yenilendiğinde tüm görsellerin yenilenmesi ve temel alınan veri kaynağında anlık görüntü yalıtımı gibi yüksek maliyetli özelliklerin kullanılması gerekir.

  Sayfadaki tüm görselleri yenilemek için Yenile'yi seçerek bu sorunu büyük ölçüde azaltabilirsiniz. İçeri aktarma modu için bile, birden fazla tablodan veri içeri aktardığınızda tutarlılığı koruma konusunda benzer bir sorun yaşanır.

• Şema değişikliklerini yansıtmak için Power BI Desktop'ta yenilemeniz gerekir. Bir rapor yayımlandıktan sonra Power BI hizmeti yenile seçeneği rapordaki görselleri yeniler. Ancak temel alınan kaynak şema değişirse, Power BI hizmeti kullanılabilir alanlar listesini otomatik olarak güncelleştirmez. Tablolar veya sütunlar temel alınan kaynaktan kaldırılırsa, yenileme sırasında sorgu hatasına neden olabilir. Modeldeki alanları değişiklikleri yansıtacak şekilde güncelleştirmek için raporu Power BI Desktop'ta açmanız ve Yenile'yi seçmeniz gerekir.

• Herhangi bir sorguda 1 milyon satırlık bir sınır döndürülebilir. Temel alınan kaynağa tek bir sorguda döndürebilen 1 milyon satırlık sabit bir sınır vardır. Bu sınırın genellikle pratik bir etkisi yoktur ve görseller bu kadar çok noktayı görüntülemez. Ancak bu sınır, Power BI'ın gönderilen sorguları tam olarak iyileştirmediği ve sınırı aşan bir ara sonuç istediği durumlarda ortaya çıkabilir.

  Sınır, daha makul bir son duruma giden yolda bir görsel oluştururken de oluşabilir. Örneğin, siz filtre uygulayana kadar 1 milyondan fazla müşteri varsa Customer ve TotalSalesQuantity dahil olmak bu sınıra gelebilir. Döndüren hata: Dış veri kaynağına yapılan sorgunun sonuç kümesi izin verilen en büyük '1000000' satır boyutunu aştı.

  Not

  Premium kapasiteler, bir milyon satır sınırını aşmanıza olanak verir. Daha fazla bilgi için bkz . en fazla ara satır kümesi sayısı.

• Modeli içeri aktarma modundan DirectQuery moduna değiştiremezsiniz. Gerekli tüm verileri içeri aktarırsanız modeli DirectQuery modundan içeri aktarma moduna geçirebilirsiniz. Öncelikle DirectQuery modunun desteklemediği özellik kümesi nedeniyle DirectQuery moduna geri dönmek mümkün değildir. SAP BW gibi çok boyutlu kaynaklar için, dış ölçülerin farklı işlenmesi nedeniyle DirectQuery'den içeri aktarma moduna da geçemezsiniz.

Performans ve yük etkileri

DirectQuery kullandığınızda, genel deneyim temel alınan veri kaynağının performansına bağlıdır. Dilimleyici değerini değiştirdikten sonra her görselin yenilenmesi beş saniyeden kısa sürüyorsa, deneyim makuldür, ancak içeri aktarılan verilerle anında yanıtla karşılaştırıldığında yavaş görünebilir. Kaynağın yavaşlığı tek tek görsellerin yenilenmesinin on saniyeden uzun sürmesine neden oluyorsa, deneyim mantıksız bir şekilde kötüleşir. Sorgular zaman aşımına bile neden olabilir.

Temel alınan kaynağın performansıyla birlikte, kaynağa yerleştirilen yük de performansı etkiler. Paylaşılan raporu açan her kullanıcı ve yenilenen her pano kutucuğu, temel alınan kaynağa görsel başına en az bir sorgu gönderir. Kaynak, makul performansı korurken böyle bir sorgu yükünü işleyebilmelidir.

Güvenlik etkileri

Temel alınan veri kaynağı SSO kullanmıyorsa, DirectQuery raporu Power BI hizmeti yayımlandıktan sonra kaynağa bağlanmak için her zaman aynı sabit kimlik bilgilerini kullanır. DirectQuery raporunu yayımladıktan hemen sonra, kullanılacak kullanıcının kimlik bilgilerini yapılandırmanız gerekir. Kimlik bilgilerini yapılandırana kadar raporu Power BI hizmeti açmaya çalışmak hatayla sonuçlanır.

Kullanıcı kimlik bilgilerini sağladıktan sonra Power BI, raporu açan kişi için bu kimlik bilgilerini içeri aktarılan verilerle aynı şekilde kullanır. Satır düzeyi güvenlik raporun bir parçası olarak tanımlanmadığı sürece her kullanıcı aynı verileri görür. Temel alınan kaynakta tanımlanmış güvenlik kuralları olsa bile, içeri aktarılan veriler için olduğu gibi raporu paylaşmaya da dikkat etmeniz gerekir.

• Power BI anlam modellerine Bağlan ve DirectQuery modunda Analysis Services her zaman SSO kullanır, bu nedenle güvenlik Analysis Services'e yönelik canlı bağlantılara benzer.

• Power BI Desktop'tan SQL Server'a DirectQuery bağlantıları yapılırken alternatif kimlik bilgileri desteklenmez. Geçerli Windows kimlik bilgilerinizi veya veritabanı kimlik bilgilerinizi kullanabilirsiniz.

• Bileşik modelleri kullanarak DirectQuery modelinde birden çok veri kaynağı kullanabilirsiniz. Birden çok veri kaynağı kullandığınızda, temel alınan veri kaynakları arasında verilerin nasıl ileri geri hareket ettiğiyle ilgili güvenlik etkilerini anlamak önemlidir.

Veri dönüştürme sınırlamaları

DirectQuery, Power Query Düzenleyicisi içinde uygulayabileceğiniz veri dönüşümlerini sınırlar. İçeri aktarılan verilerle, görseller oluşturmak için kullanmadan önce verileri temizlemek ve yeniden şekillendirmek için gelişmiş bir dönüştürme kümesi kolayca uygulayabilirsiniz. Örneğin, JSON belgelerini ayrıştırabilir veya bir sütundaki verileri satır formuna özetleyebilirsiniz. Bu dönüşümler DirectQuery'de daha sınırlıdır.

SAP BW gibi bir çevrimiçi analitik işleme (OLAP) kaynağına bağlandığınızda, hiçbir dönüştürme tanımlayamazsınız ve dış modelin tamamı kaynaktan alınır. SQL Server gibi ilişkisel kaynaklar için sorgu başına bir dizi dönüştürme tanımlamaya devam edebilirsiniz, ancak bu dönüşümler performans nedeniyle sınırlıdır.

Tüm dönüştürmeler, veri yenilemede bir kez değil, temel alınan kaynağa yapılan her sorguya uygulanmalıdır. Dönüştürmelerin tek bir yerel sorguya makul bir şekilde çevrilebilmesi gerekir. Çok karmaşık bir dönüştürme kullanıyorsanız, silinmesi veya bağlantı modelinin içeri aktarılacak şekilde değiştirilmesi gerektiğini belirten bir hata alırsınız.

Ayrıca, Veri Al iletişim kutusu veya Power Query Düzenleyicisi, bir görselin verilerini almak için oluşturdukları ve gönderdikleri sorgularda alt seçimleri kullanır. Power Query Düzenleyicisi içinde tanımlanan sorgular bu bağlamda geçerli olmalıdır. Özellikle, ortak tablo ifadeleriyle bir sorgu kullanmak veya saklı yordamları çağıran bir sorgu kullanmak mümkün değildir.

Modelleme sınırlamaları

Bu bağlamda modelleme terimi, verileri kullanarak rapor yazmanın bir parçası olarak ham verileri iyileştirme ve zenginleştirme eylemi anlamına gelir. Modelleme örnekleri şunlardır:

• Tablolar arasındaki ilişkileri tanımlama.
• Hesaplanmış sütunlar ve ölçüler gibi yeni hesaplamalar ekleme.
• Sütunları ve ölçüleri yeniden adlandırma ve gizleme.
• Hiyerarşileri tanımlama.
• Sütun biçimlendirmesini, varsayılan özetlemeyi ve sıralama düzenini tanımlama.
• Değerleri gruplandırma veya kümeleme.

DirectQuery kullanırken bu model zenginleştirmelerinin çoğunu yapmaya devam edebilir ve ham verileri zenginleştirme ilkesini kullanarak daha sonraki tüketimi geliştirebilirsiniz. Ancak bazı modelleme özellikleri kullanılamaz veya DirectQuery ile sınırlıdır. Performans sorunlarını önlemek için sınırlamalar uygulanır.

Aşağıdaki sınırlamalar tüm DirectQuery kaynakları için ortaktır. Tek tek kaynaklar için daha fazla sınırlama geçerli olabilir.

• Yerleşik tarih hiyerarşisi yok: İçeri aktarılan verilerle, her tarih/tarih saat sütununda varsayılan olarak kullanılabilen yerleşik bir tarih hiyerarşisi de vardır. Örneğin, OrderDate sütunu içeren bir satış siparişleri tablosunu içeri aktarır ve bir görselde OrderDate kullanırsanız, yıl, ay veya gün gibi kullanılacak uygun tarih düzeyini seçebilirsiniz. Bu yerleşik tarih hiyerarşisi DirectQuery ile kullanılamaz. Birçok veri ambarında yaygın olarak olduğu gibi, temel alınan kaynakta bir Date tablosu varsa, Veri Çözümleme İfadeleri (DAX) akıllı zaman gösterimi işlevlerini her zamanki gibi kullanabilirsiniz.

• Yalnızca saniye düzeyine kadar tarih/saat desteği: Zaman sütunlarını kullanan anlamsal modeller için Power BI, temel alınan DirectQuery kaynağına milisaniye değil yalnızca saniye ayrıntı düzeyine kadar sorgular verir. Kaynak sütunlarınızdan milisaniyelik verileri kaldırın.

• Hesaplanan sütunlardaki sınırlamalar: Hesaplanan sütunlar yalnızca satır içi olabilir; başka bir deyişle, herhangi bir toplama işlevi kullanmadan yalnızca aynı tablonun diğer sütunlarının değerlerine başvurabilir. Ayrıca, gibi LEFT()izin verilen DAX skaler işlevleri, temel alınan kaynağa gönderilebilen işlevlerle sınırlıdır. İşlevler, kaynağın tam özelliklerine bağlı olarak değişir. Desteklenmeyen işlevler, hesaplanan sütun için DAX sorgusu yazarken otomatik tamamlamada listelenmez ve kullanılırsa hataya neden olur.

• Üst-alt DAX işlevleri için destek yok: DirectQuery modundayken, genellikle hesap grafikleri veya çalışan hiyerarşileri gibi üst-alt yapıları işleyen işlev ailesini DAX PATH() kullanmak mümkün değildir.

• Kümeleme yok: DirectQuery kullandığınızda, grupları otomatik olarak bulmak için kümeleme özelliğini kullanamazsınız.

Raporlama sınırlamaları

DirectQuery modelleri için neredeyse tüm raporlama özellikleri desteklenir. Temel alınan kaynak uygun bir performans düzeyi sunduğu sürece, içeri aktarılan verilerle aynı görselleştirme kümesini kullanabilirsiniz.

Genel sınırlamalardan biri, DirectQuery anlam modelleri için bir metin sütunundaki en fazla veri uzunluğunun 32.764 karakter olmasıdır. Uzun metinlerin raporlanması hatayla sonuçlanır.

Aşağıdaki Power BI raporlama özellikleri DirectQuery tabanlı raporlarda performans sorunlarına neden olabilir:

• Ölçü filtreleri: Ölçüleri veya sütun toplamlarını kullanan görseller, bu ölçülerde filtreler içerebilir. Örneğin, aşağıdaki grafikte Kategoriye göre SalesAmount gösterilir, ancak yalnızca 20M'den fazla satışa sahip kategoriler için gösterilir.

  

  Bu yaklaşım, temel alınan kaynağa iki sorgu gönderilmesine neden olur:

  • İlk sorgu 20 milyondan büyük SalesAmount koşulunu karşılayan kategorileri alır.
  • İkinci sorgu, koşula uygun WHERE kategorileri içeren görsel için gerekli verileri alır.

  Bu örnekte olduğu gibi yüzlerce veya binlerce kategori varsa bu yaklaşım genellikle iyi çalışır. Kategori sayısı çok daha fazlaysa performans düşebilir. Bir milyondan fazla kategori varsa sorgu başarısız olur.

• TopN filtreleri: Yalnızca bir ölçüye göre derecelenmiş üst veya alt N değerleri filtrelemek için gelişmiş filtreler tanımlayabilirsiniz. Örneğin, filtreler ilk 10 kategoriyi içerebilir. Bu yaklaşım yine temel alınan kaynağa iki sorgu gönderir. Ancak, ilk sorgu temel alınan kaynaktan tüm kategorileri döndürür ve ardından TopN döndürülen sonuçlara göre belirlenir. Söz konusu sütunun kardinalitesine bağlı olarak, bu yaklaşım sorgu sonuçlarındaki bir milyon satır sınırı nedeniyle performans sorunlarına veya sorgu hatalarına yol açabilir.

• Ortanca: veya Count Distinctgibi Sum tüm toplamalar temel alınan kaynağa gönderilir. Ancak, genellikle median toplama temel alınan kaynak tarafından desteklenmez. için median, ayrıntı verileri temel alınan kaynaktan alınır ve döndürülen sonuçlardan ortanca değer hesaplanır. Bu yaklaşım, ortanca değeri görece az sayıda sonuç üzerinden hesaplamak için makuldür.

  Bir milyon satır sınırı nedeniyle kardinalite büyükse performans sorunları veya sorgu hataları ortaya çıkabilir. Örneğin, Ortanca Ülke/Bölge Popülasyonu için sorgulama makul olabilir, ancak Ortanca Satış Fiyatı makul olmayabilir.

• 'contains' gibi gelişmiş metin filtreleri: Metin sütununda gelişmiş filtreleme, ve begins withgibi contains filtrelere izin verir. Bu filtreler bazı veri kaynakları için performansın düşmesine neden olabilir. Özellikle, tam eşleşmeye ihtiyacınız varsa varsayılan contains filtreyi kullanmayın. Gerçek verilere bağlı olarak sonuçlar aynı olsa da, dizinler nedeniyle performans önemli ölçüde farklı olabilir.

• Çoklu seçim dilimleyicileri: Dilimleyiciler varsayılan olarak yalnızca tek bir seçim yapmaya izin verir. Filtrelerde çoklu seçime izin vermek performans sorunlarına neden olabilir. Örneğin, kullanıcı ilgilendiği 10 ürünü seçerse, her yeni seçim kaynağa sorgu gönderilmesine neden olur. Kullanıcı sorgu tamamlanmadan önce bir sonraki öğeyi seçebilir, ancak bu yaklaşım temel alınan kaynakta ek yüke neden olur.

• Tablo görsellerindeki toplamlar: Varsayılan olarak, tablolar ve matrisler toplamları ve alt toplamları görüntüler. Çoğu durumda, bu tür toplamların değerlerini almak için temel alınan kaynağa ayrı sorgular gönderilmesi gerekir. Bu gereksinim, toplama kullandığınızda DistinctCount veya SAP BW veya SAP HANA üzerinden DirectQuery kullanan her durumda geçerlidir. Biçim bölmesini kullanarak bu tür toplamları kapatabilirsiniz.

DirectQuery önerileri

Bu bölüm, etkileri göz önünde bulundurulduğunda DirectQuery'yi başarıyla kullanma konusunda üst düzey rehberlik sağlar.

Temel alınan veri kaynağı performansı

Makul bir etkileşimli deneyim sağlamak için basit görsellerin beş saniye içinde yenilendiğini doğrulayın. Görsellerin yenilenmesi 30 saniyeden uzun sürüyorsa, rapor yayınını izleyen diğer sorunların çözümün çalışılamaz hale gelmesi olasıdır.

Sorgular yavaşsa, temel alınan kaynağa gönderilen sorguları ve yavaş performansın nedenini inceleyin. Daha fazla bilgi için bkz. Performans tanılama.

Bu makale, tüm olası temel kaynaklar genelinde çok çeşitli veritabanı iyileştirme önerilerini kapsamaz. Çoğu durumda aşağıdaki standart veritabanı uygulamaları geçerlidir:

• Daha iyi performans için, diğer veri türlerinin sütunlarını birleştirmek yerine tamsayı sütunlarını temel alan ilişkiler.

• Uygun dizinleri oluşturun. Dizin oluşturma genellikle sütun deposu dizinlerini destekleyen kaynaklarda (örneğin SQL Server) kullanmak anlamına gelir.

• Kaynaktaki tüm gerekli istatistikleri güncelleştirin.

Model tasarımı

Modeli tanımlarken şu yönergeleri izleyin:

• Power Query Düzenleyicisi karmaşık sorgulardan kaçının. Power Query Düzenleyicisi karmaşık bir sorguyu tek bir SQL sorgusuna çevirir. Tek sorgu, o tabloya gönderilen her sorgunun alt seçiminde görünür. Bu sorgu karmaşıksa, gönderilen her sorguda performans sorunlarına neden olabilir. Power Query Düzenleyicisi uygulanan adımlar'ın altındaki son adıma sağ tıklayıp Yerel Sorguyu Görüntüle'yi seçerek bir dizi adım için gerçek SQL sorgusunu alabilirsiniz.

• Ölçüleri basit tutun. En azından başlangıçta ölçüleri basit toplamalarla sınırlayın. Ölçüler tatmin edici bir şekilde çalışırsa, daha karmaşık ölçüler tanımlayabilir, ancak performansa dikkat edebilirsiniz.

• Hesaplanmış sütunlardaki ilişkilerden kaçının. Çok sütunlu birleşimler yapmanız gereken veritabanlarında Power BI, birincil anahtar veya yabancı anahtar olarak birden çok sütuna dayalı ilişkilere izin vermez. Yaygın geçici çözüm, hesaplanmış bir sütun kullanarak sütunları birleştirmek ve birleştirmeyi bu sütuna dayandırmaktır.

  Bu geçici çözüm, içeri aktarılan veriler için makuldür, ancak DirectQuery için bir ifadede birleştirmeyle sonuçlanır. Bu sonuç genellikle dizin kullanılmasını engeller ve düşük performansa neden olur. Tek geçici çözüm, birden çok sütunu temel alınan veri kaynağındaki tek bir sütunda gerçekleştirmektir.

• 'uniqueidentifier' sütunlarında ilişkilerden kaçının. Power BI bir veri türünü yerel olarak desteklemez uniqueidentifier . Sütunlar arasında uniqueidentifier ilişki tanımlamak, atama içeren bir birleşim içeren bir sorguyla sonuç alır. Bu yaklaşım genellikle düşük performansa yol açar. Tek geçici çözüm, temel alınan veri kaynağında alternatif türde sütunların gerçekleştirilmesidir.

• İlişkilerde 'to' sütununu gizleyin. İlişkilerdeki to sütun genellikle tablodaki to birincil anahtardır. Bu sütun gizli olmalıdır, ancak gizlenirse alan listesinde görünmez ve görsellerde kullanılamaz. Genellikle ilişkilerin temel aldığı sütunlar aslında sistem sütunlarıdır, örneğin bir veri ambarında vekil anahtarlar. Yine de en iyisi bu sütunları gizlemektir.

  Sütunun anlamı varsa, görünür ve basit bir ifadeyle birincil anahtara eşit olan bir hesaplanmış sütun ekleyin, örneğin:

      ProductKey_PK   (Destination of a relationship, hidden)
      ProductKey (= [ProductKey_PK],   visible)
      ProductName
      ...
  

• Tüm hesaplanmış sütunları ve veri türü değişikliklerini inceleyin. Bileşik modellerle DirectQuery kullanırken hesaplanan tabloları kullanabilirsiniz. Bu özellikler zararlı olmayabilir, ancak sütunlara basit başvurular yerine ifadeler içeren sorgularla sonuçlanır. Bu sorgular dizinlerin kullanılmamasıyla sonuçlanabilir.

• İlişkilerde çift yönlü çapraz filtrelemeden kaçının. Çift yönlü çapraz filtrelemenin kullanılması, iyi performans göstermeyen sorgu deyimlerine yol açabilir. Çift yönlü çapraz filtreleme hakkında daha fazla bilgi için bkz. Power BI Desktop'ta DirectQuery için çift yönlü çapraz filtrelemeyi etkinleştirme veya çift yönlü çapraz filtreleme teknik incelemesini indirme. Makaledeki örnekler SQL Server Analysis Services'e yöneliktir, ancak temel noktalar Power BI için de geçerlidir.

• Bilgi tutarlılığı varsay ayarını deneme. İlişkilerde Bilgi tutarlılığı varsay ayarı, sorguların deyimler yerine OUTER JOIN kullanmasını INNER JOIN sağlar. Bu kılavuz genellikle sorgu performansını geliştirir, ancak veri kaynağının özelliklerine bağlıdır.

• Power Query Düzenleyicisi göreli veri filtrelemesini kullanmayın. Power Query Düzenleyicisi göreli tarih filtrelemesi tanımlamak mümkündür. Örneğin, tarihin son 14 gün içindeki satırları filtreleyebilirsiniz.

  

  Ancak bu filtre, yerel sorguda görebileceğiniz gibi, sabit bir tarihe (örneğin, sorgunun yazıldığı saat) göre bir filtreye çevrilir.

  

  Bu veriler büyük olasılıkla istediğiniz veriler değildir. Filtrenin raporun çalıştığı tarihe göre uygulandığından emin olmak için, rapora tarih filtresini uygulayın. işlevini kullanarak DAX DATE() gün sayısını hesaplayan bir hesaplanmış sütun oluşturabilir ve bu hesaplanan sütunu filtrede kullanabilirsiniz.

Rapor tasarımı

DirectQuery bağlantısı kullanan bir rapor oluşturduğunuzda şu yönergeleri izleyin:

• Sorgu azaltma seçeneklerini kullanmayı göz önünde bulundurun: Power BI daha az sorgu göndermek ve sonuçta elde edilen sorguların çalışması uzun sürerse kötü bir deneyime neden olan belirli etkileşimleri devre dışı bırakmak için rapor seçenekleri sağlar. Bu seçenekler, Power BI Desktop'ta raporunuzla etkileşim kurarken ve kullanıcılar raporu Power BI hizmeti kullanırken de geçerlidir.

  Power BI Desktop'ta bu seçeneklere erişmek için Dosya>Seçenekleri ve ayarlar>Seçenekler'egidin ve Sorgu azaltma'yı seçin.

  

  Sorgu azaltma ekranındaki seçimler, dilimleyiciler veya filtre seçimleri için Uygula düğmesini göstermenizi sağlar. Filtrede veya dilimleyicide Uygula düğmesini seçene kadar sorgu gönderilmez. Sorgular daha sonra verileri filtrelemek için seçimlerinizi kullanır. Bu düğme, uygulamadan önce birkaç dilimleyici ve filtre seçimi yapmanıza olanak tanır.

• Önce filtreleri uygula: Görsel oluşturmanın başlangıcında her zaman geçerli filtreleri uygulayın. Örneğin, TotalSalesAmount ve ProductName öğelerini sürükleyip belirli bir yıla göre filtrelemek yerine, başlangıçtaki Yıl filtresine uygulayın.

  Görsel oluşturmanın her adımı bir sorgu gönderir. İlk sorgu tamamlanmadan önce başka bir değişiklik yapmak mümkün olsa da, bu yaklaşım temel alınan kaynakta yine de gereksiz yük bırakır. Filtrelerin erken uygulanması genellikle bu ara sorguların daha az maliyetli olmasını sağlar. Filtrelerin erken uygulanamaması, bir milyon satır sınırına erişmeye neden olabilir.

• Sayfadaki görsel sayısını sınırlayın: Bir sayfayı açtığınızda veya sayfa düzeyi dilimleyiciyi veya filtreyi değiştirdiğinizde, sayfadaki tüm görseller yenilenir. Paralel sorgu sayısında bir sınır vardır. Görsel sayısı arttıkça, bazı görseller seri olarak yenilenir ve bu da sayfayı yenileme süresini artırır. Bu nedenle, tek bir sayfadaki görsellerin sayısını sınırlamak ve bunun yerine daha basit sayfalara sahip olmak en iyisidir.

• Görseller arasındaki etkileşimi kapatmayı göz önünde bulundurun: Varsayılan olarak, rapor sayfasındaki görselleştirmeler sayfadaki diğer görselleştirmeleri çapraz filtrelemek ve çapraz vurgulamak için kullanılabilir. Örneğin, pasta grafikte 1999'ı seçerseniz, sütun grafik 1999'un kategoriye göre satışlarını göstermek için çapraz vurgulanır.

  

  DirectQuery'de çapraz filtreleme ve çapraz vurgulama, sorguların temel alınan kaynağa gönderilmesini gerektirir. Kullanıcıların seçimlerine yanıt verme süresi makul olmayan bir şekilde uzunsa bu etkileşimi kapatmalısınız.

  Raporunuzun tamamında veya büyük/küçük harf temelinde çapraz vurgulama özelliğini devre dışı bırakmak için Sorgu azaltma ayarlarını kullanabilirsiniz. Daha fazla bilgi için bkz . Power BI raporunda görsellerin birbirine çapraz filtre uygulama şekli.

En fazla bağlantı sayısı

DirectQuery'nin temel alınan her veri kaynağı için açtığı en fazla bağlantı sayısını ayarlayabilirsiniz ve bu da her veri kaynağına eşzamanlı olarak gönderilen sorgu sayısını denetler.

DirectQuery varsayılan en fazla 10 eşzamanlı bağlantı açar. Power BI Desktop'ta geçerli dosyanın en fazla sayısını değiştirmek için Dosya>Seçenekleri ve Ayarlar> Seçenekler'e gidin ve sol bölmenin Geçerli Dosya bölümünde DirectQuery'yi seçin.

Ayar yalnızca geçerli raporda en az bir DirectQuery kaynağı olduğunda etkinleştirilir. Bu değer tüm DirectQuery kaynaklarına ve bu rapora eklenen tüm yeni DirectQuery kaynaklarına uygulanır.

Veri kaynağı başına en fazla bağlantı sayısını artırmak , temel alınan veri kaynağına belirtilen en fazla sayıda sorgu gönderilmesine olanak tanır. Bu yaklaşım, birden çok görsel tek bir sayfada olduğunda veya birçok kullanıcı aynı anda bir rapora eriştiğinde kullanışlıdır. Bağlantı sayısı üst sınırına ulaşıldığında, bağlantı kullanılabilir duruma gelene kadar başka sorgular kuyruğa alınır. Daha yüksek bir sınır temel alınan kaynakta daha fazla yüke neden olur, bu nedenle ayarın genel performansı geliştirmesi garanti değildir.

Bir raporu Power BI hizmeti yayımladığınızda eşzamanlı sorgu sayısı üst sınırı, raporun yayımlandığı hedef ortamda ayarlanan sabit sınırlara da bağlıdır. Power BI, Power BI Premium ve Power BI Rapor Sunucusu farklı sınırlar uygular. Aşağıdaki tabloda, her Power BI ortamı için veri kaynağı başına etkin bağlantıların üst sınırları listelenmiştir. Bu sınırlar bulut veri kaynakları ve SQL Server, Oracle ve Teradata gibi şirket içi veri kaynakları için geçerlidir.

Ortam	Veri kaynağı başına üst sınır
Power BI Pro	10 etkin bağlantı
Power BI Premium	Anlamsal model SKU sınırlamalarına bağlıdır
Power BI Rapor Sunucusu	10 etkin bağlantı

Not

En fazla DirectQuery bağlantısı sayısı ayarı, Power BI Desktop'ta oluşturulan tüm modeller için varsayılan ayar olan gelişmiş meta verileri etkinleştirdiğinizde tüm DirectQuery kaynakları için geçerlidir.

Power BI hizmeti DirectQuery

Tüm DirectQuery veri kaynakları Power BI Desktop'ta desteklenir ve bazı kaynaklar doğrudan Power BI hizmeti içinden de kullanılabilir. bir iş kullanıcısı, Örneğin Salesforce'taki verilerine bağlanmak için Power BI'ı kullanabilir ve Power BI Desktop'ı kullanmadan hemen bir pano alabilir.

Doğrudan Power BI hizmeti yalnızca aşağıdaki iki DirectQuery özellikli kaynak kullanılabilir:

• Spark
• Azure Synapse Analytics (eski adı SQL Veri Ambarı)

Bu iki kaynak için bile en iyisi Power BI Desktop'ta DirectQuery kullanımını başlatmaktır. başlangıçta Power BI hizmeti bağlantı oluşturmak kolay olsa da, sonuçta elde edilen raporun daha da geliştirilmesiyle ilgili sınırlamalar vardır. Örneğin, hizmette herhangi bir hesaplama oluşturmak veya birçok analitik özellik kullanmak ya da temel şemadaki değişiklikleri yansıtmak için meta verileri yenilemek mümkün değildir.

Power BI hizmeti bir DirectQuery raporunun performansı, temel alınan veri kaynağına yerleştirilen yükün derecesine bağlıdır. Yük aşağıdakilere bağlıdır:

• Raporu ve panoyu paylaşan kullanıcı sayısı.
• Raporun karmaşıklığı.
• Raporun satır düzeyi güvenliği tanımlayıp tanımlamadığı.

Power BI hizmeti rapor davranışı

Power BI hizmeti bir rapor açtığınızda, görünür durumdaki sayfadaki tüm görseller yenilenir. Her görsel, temel alınan veri kaynağına en az bir sorgu gerektirir. Bazı görseller birden fazla sorgu gerektirebilir. Örneğin, bir görsel iki farklı olgu tablosundaki toplam değerleri gösterebilir veya daha karmaşık bir ölçü içerebilir ya da Ayrı Say gibi eksiz bir ölçünün toplamlarını içerebilir. Yeni bir sayfaya geçmek bu görselleri yeniler. Yenileme, temel alınan kaynağa yeni bir sorgu kümesi gönderir.

Rapordaki her kullanıcı etkileşimi görsellerin yenilenmesine neden olabilir. Örneğin, dilimleyicide farklı bir değer seçmek, etkilenen tüm görselleri yenilemek için yeni bir sorgu kümesi göndermeyi gerektirir. Diğer görselleri çapraz vurgulamak için bir görsel seçmek veya filtreyi değiştirmek için de aynı durum geçerlidir. Benzer şekilde, raporun oluşturulması veya düzenlenmesi, son görseli oluşturmak için yoldaki her adım için sorguların gönderilmesini gerektirir.

Bazı sonuçları önbelleğe alma işlemi vardır. Yakın zamanda tam olarak aynı sonuçlar elde edildiyse görselin yenilenmesi anında gerçekleşir. Satır düzeyi güvenlik tanımlanmışsa, bu önbellekler kullanıcılar arasında paylaşılamaz.

DirectQuery'nin kullanılması, Power BI hizmeti yayımlanan raporlar için sunduğu bazı özelliklerde bazı önemli sınırlamalar uygular:

• Hızlı içgörüler desteklenmez: Power BI hızlı içgörüleri, ilgi çekici olabilecek içgörüleri keşfetmek için bir dizi karmaşık algoritma uygularken semantik modelinizin farklı alt kümelerini arar. Hızlı içgörüler yüksek performanslı sorgular gerektirdiğinden, bu özellik DirectQuery kullanan anlam modellerinde kullanılamaz.

• Excel'de Keşfet özelliğinin kullanılması performansın düşmesine neden olur: Excel'de özet tablolar ve özet grafikler oluşturmanıza olanak tanıyan Excel'de Keşfet özelliğini kullanarak anlamsal modeli keşfedebilirsiniz. Bu özellik DirectQuery kullanan anlam modelleri için desteklenir, ancak Performans Power BI'da görsel oluşturmaya göre daha yavaştır. Senaryolarınız için Excel kullanmak önemliyse, DirectQuery'yi kullanıp kullanmamaya karar verirken bu sorunu hesaba ekleyin.

• Excel hiyerarşileri göstermez: Örneğin, Excel'de Çözümle'yi kullandığınızda, Excel Azure Analysis Services modellerinde veya DirectQuery kullanan Power BI anlam modellerinde tanımlanan hiyerarşileri göstermez.

Pano yenileme

Power BI hizmeti tek tek görselleri veya sayfaların tamamını panolara kutucuk olarak sabitleyebilirsiniz. DirectQuery semantik modellerini temel alan kutucuklar, temel alınan veri kaynaklarına bir zamanlamaya göre sorgu göndererek otomatik olarak yenilenir. Varsayılan olarak, anlamsal modeller saatte bir yenilenir, ancak anlam modeli ayarlarının bir parçası olarak haftalık ile 15 dakikada bir yenileme yapılandırabilirsiniz.

Modelde satır düzeyi güvenlik tanımlanmadıysa, her kutucuk bir kez yenilenir ve sonuçlar tüm kullanıcılar arasında paylaşılır. Satır düzeyi güvenlik kullanıyorsanız, her kutucuk temel alınan kaynağa kullanıcı başına ayrı sorgular gönderilmesini gerektirir.

Büyük bir çarpan etkisi olabilir. 10 kullanıcıyla paylaşılan, satır düzeyi güvenlikli DirectQuery kullanılarak anlamsal modelde oluşturulan 10 kutucuklu pano, her yenileme için temel alınan veri kaynağına en az 1000 sorgu gönderilmesine neden olur. Satır düzeyi güvenliğin kullanımına ve yenileme zamanlamasının yapılandırmasına dikkat edin.

Sorgu zaman aşımları

dört dakikalık bir zaman aşımı, Power BI hizmeti tek tek sorgular için geçerlidir. Dört dakikadan uzun süre devam eden sorgular başarısız olur. Bu sınır, fazla uzun yürütme sürelerinin neden olduğu sorunları önlemeye yöneliktir. DirectQuery'nin yalnızca etkileşimli sorgu performansı sağlayabilen kaynaklar için kullanılması gerekir.

Performans tanılama

Bu bölümde performans sorunlarını tanılama veya raporlarınızı iyileştirmek için daha ayrıntılı bilgi alma işlemleri açıklanmaktadır.

Power BI hizmeti yerine Power BI Desktop'ta performans sorunlarını tanılamaya başlayın. Performans sorunları genellikle temel alınan kaynağın performansına bağlıdır. Daha yalıtılmış Power BI Desktop ortamındaki sorunları daha kolay tanımlayabilir ve tanılayabilirsiniz.

Bu yaklaşım başlangıçta Power BI ağ geçidi gibi belirli bileşenleri ortadan kaldırır. Performans sorunları Power BI Desktop'ta oluşmazsa raporun ayrıntılarını Power BI hizmeti inceleyebilirsiniz.

Power BI Desktop Performans çözümleyicisi , sorunları tanımlamak için kullanışlı bir araçtır. Sayfadaki birçok görsel yerine sorunları tek bir görselde yalıtmaya çalışın. Power BI Desktop sayfasındaki tek bir görsel yavaşsa, Power BI Desktop'ın temel alınan kaynağa gönderdiği sorguları analiz etmek için Performans çözümleyicisini kullanın.

Ayrıca, bazı temel alınan veri kaynaklarının yaydığı izlemeleri ve tanılama bilgilerini de görüntüleyebilirsiniz. Kaynaktan hiçbir izleme olmasa bile, izleme dosyası sorgunun nasıl çalıştığına ve nasıl geliştirebileceğinize ilişkin yararlı ayrıntılar içerebilir. Power BI'ın gönderdiği sorguları ve bunların yürütme sürelerini görüntülemek için aşağıdaki işlemi kullanabilirsiniz.

Sorguları görmek için SQL Server Profiler kullanma

Varsayılan olarak, Power BI Desktop belirli bir oturum sırasındaki olayları FlightRecorderCurrent.trc adlı bir izleme dosyasına kaydeder. İzleme dosyası, geçerli kullanıcının Power BI Desktop klasöründe, AnalysisServicesWorkspaces adlı bir klasörde yer alır.

Bazı DirectQuery kaynakları için bu izleme dosyası, temel alınan veri kaynağına gönderilen tüm sorguları içerir. Aşağıdaki veri kaynakları günlüğe sorgular gönderir:

• SQL Server
• Azure SQL Veritabanı
• Azure Synapse Analytics (eski adı SQL Veri Ambarı)
• Oracle
• Teradata
• SAP HANA

İzleme dosyalarını, ücretsiz indirme SQL Server Management Studio'nun bir parçası olan SQL Server Profiler'ı kullanarak okuyabilirsiniz.

Geçerli oturumun izleme dosyasını açmak için:

1. Power BI Desktop oturumu sırasında Dosya>Seçenekleri ve ayarlar>Seçenekler'i ve ardından Tanılama'yı seçin.

2. Kilitlenme Dökümü Koleksiyonu altında Kilitlenme dökümü/izlemeler klasörünü aç'ı seçin.

   

   Power BI Desktop\Traces klasörü açılır.

3. Üst klasöre gidin ve ardından Power BI Desktop'ın her açık örneği için bir çalışma alanı klasörü içeren AnalysisServicesWorkspaces klasörüne gidin. Bu klasörler AnalysisServicesWorkspace2058279583 gibi bir tamsayı son eki ile adlandırılır. çalışma alanı klasörü, ilişkili Power BI Desktop oturumu sona erdiğinde silinir.

   Geçerli Power BI oturumunun çalışma alanı klasörünün içindeki \Data klasörü FlightRecorderCurrent.trc izleme dosyasını içerir. Yerleşimi not edin.

4. SQL Server Profiler'ı açın ve Dosya İzleme Dosyasını> Aç'ı>seçin.

5. Geçerli Power BI oturumu için izleme dosyasına gidin veya bu dosyanın yolunu girin ve FlightRecorderCurrent.trc dosyasını açın.

SQL Server Profiler geçerli oturumdaki tüm olayları görüntüler. Aşağıdaki ekran görüntüsünde sorgu için bir olay grubu vurgulanır. Her sorgu grubu aşağıdaki olaylara sahiptir:

• Query Begin Power BI kullanıcı arabirimindeki bir görseli veya filtreyi değiştirerek ya da Power Query Düzenleyicisi verileri filtreleme veya dönüştürme yoluyla oluşturulan bir DAX sorgusunun başlangıç ve bitişini temsil eden bir ve Query End olayı.

• DAX sorgusunu değerlendirmenin DirectQuery Begin bir parçası olarak temel alınan veri kaynağına gönderilen sorguları temsil eden bir veya daha fazla ve DirectQuery End olayı çifti.

Birden çok DAX sorgusu paralel olarak çalıştırılabilir, bu nedenle farklı gruplardan olaylar araya eklenebilir. Aynı gruba ait olan olayları belirlemek için değerini kullanabilirsiniz ActivityID .

Aşağıdaki sütunlar da ilgi çekicidir:

• TextData: Olayın metinsel ayrıntısı. ve Query End olayları için Query Begin ayrıntı DAX sorgusudur. ve DirectQuery End olayları için DirectQuery Begin ayrıntı, temel alınan kaynağa gönderilen SQL sorgusudur. Seçili durumdaki olayın TextData'sı ekranın en altındaki bölmede de görünür.
• EndTime: Olayın tamamlandığı saat.
• Süre: Milisaniye cinsinden dax veya SQL sorgusunu çalıştırmak için geçen süre.
• Hata: Hata oluşup oluşmadığı, bu durumda olayın kırmızı olarak da görüntülenip görüntülenmeyeceği.

Olası bir performans sorununu tanılamaya yardımcı olacak bir izleme yakalamak için:

1. Birden çok çalışma alanı klasörünün karışıklığını önlemek için tek bir Power BI Desktop oturumu açın.

2. Power BI Desktop'ta ilgilendiğim eylemler kümesini yapın. İlgilenilen olayların izleme dosyasına boşaltıldığından emin olmak için birkaç eylem daha ekleyin.

3. SQL Server Profiler'ı açın ve izlemeyi inceleyin. Power BI Desktop'ın kapatılmasının izleme dosyasını sildiğini unutmayın. Ayrıca, Power BI Desktop'taki diğer eylemler hemen görünmez. Yeni olayları görmek için izleme dosyasını kapatıp yeniden açmalısınız.

Bireysel oturumları yüzlerce değil, 10 saniyelik eylemleri makul ölçüde küçük tutun. Bu yaklaşım izleme dosyasını yorumlamayı kolaylaştırır. İzleme dosyasının boyutu üzerinde de bir sınır vardır. Uzun oturumlar için erken olayların bırakılması olasılığı vardır.

Sorguların biçimini anlama

Power BI Desktop sorgularının genel biçimi, başvurdıkları her tablo için alt seçimleri kullanır. Power Query Düzenleyicisi sorgusu, alt seçim sorgularını tanımlar. Örneğin, SQL Server'da aşağıdaki TPC-DS tablolarına sahip olduğunuzu varsayalım:

Aşağıdaki sorguyu çalıştırma:

SalesAmount (SUMX(Web_Sales, [ws_sales_price]*[ws_quantity]))
by Item[i_category]
for Date_dim[d_year] = 2000

Power BI'da aşağıdaki görselin sonuçları:

Bu görsel yenilendiğinde aşağıdaki görüntüde SQL sorgusu oluşturulur. Görsel yalnızca dört sütuna başvursa bile, her biri ilgili tablodaki tüm sütunları döndüren , Itemve Date_dimiçin üç alt seçim sorgusu Web_Salesvardır.

Power Query Düzenleyicisi tam alt seçim sorgularını tanımlar. Bu alt seçim sorgusu kullanımının DirectQuery'nin desteklediği veri kaynaklarının performansını etkilediği gösterilmemiştir. SQL Server gibi veri kaynakları, diğer sütunlara yapılan başvuruları iyileştirir.

Analist SQL sorgusunu doğrudan sağladığından Power BI bu düzeni kullanır. Power BI, sorguyu yeniden yazmaya çalışmadan, sağlanan şekilde kullanır.

İlgili içerik

Power BI'da DirectQuery hakkında daha fazla bilgi için bkz:

• Power BI Desktop'ta DataQuery kullanma

Bu makalede DirectQuery'nin tüm veri kaynaklarında ortak olan yönleri açıklanmıştır. Belirli kaynaklar hakkındaki ayrıntılar için aşağıdaki makalelere bakın:

• DirectQuery ve SAP HANA
• DirectQuery ve SAP BW
• Power BI anlam modelleri ve Analysis Services için DirectQuery kullanma