Güncelleme: 6.11.2019 Gerçek zamanlı raporlamayla ilgili Power BI Meetup grubunda yaptığımız webinar kaydı için link.
Güncelleme: 12 Ağustos 2018, Power BI Ağustos güncellemesiyle birlikte aynı anda hem Direct Query hem de Import modu aynı anda kullanılabilir hale geldi. Komposit modellemeyle ilgili yeni bir yazı yayınlandığında bu posta güncellenecektir.
Power BI ile ilişkisel veri tabanlarına bağlanırken iki farklı yöntem kullanabiliriz: Import veya Direct Query.
Varsayılan (default) yöntem olan Import’u kullandığımızda veriyi modelin içine almış oluyoruz ve bu modeli buluta bastığımızda veri de buluta çıkıyor. Bu şekilde hazırlanmış bir modeldeki raporlar tamamen Power BI’ın tabular engine’nini (eski adıyla Vertipaq) kullanır, tüm hesaplamalar bu engine tarafından yapılır, veri kaynaklarıyla arada bir trafik -verilerin güncellenmesi haricinde- oluşmaz.
Direct Query, ilişkisel veri kaynağına doğrudan ve canlı bağlanmamızı sağlar. Rapor tarafında kullanıcının yaptığı her “tık”, her hareket, arka taraftaki veri kaynağına bir sorgu gönderir. Bu yöntemi kullandığımızda veri modelin içinde değildir, bağlandığımız veri kaynağındadır, yani buluta çıkmaz, dolayısıyla kullanıcının yaptığı her hareketin görüntülenebilmesi için veri kaynağının her zaman erişilebilir olmasını gerektirir. Tüm hesaplamalar veri kaynağı tarafında gerçekleştirilir, aggregate sonuçlar PBI tarafında görüntülenir.
Direct Query’yi destekleyen veri kaynakları, SQL (Azure SQL, DW dahil), Oracle, SAP BW, SAP HANA gibi veri tabanları. Güncel liste için buraya göz atabilirsiniz. OData, Excel gibi veri kaynakları bugün itibariyle desteklenmiyor.
Bir SQL veritabanına ne şekilde bağlanacağımızı Get Data –> SQL Server dediğimizde karşımıza çıkan ekranda belirliyoruz.
Aynı veritabanına import ve direct query ile iki farklı bağlantı yaptığımızda karşımıza çıkan dosya büyüklüklerinin farkı yüksek. Import, tüm verinin modelin içine alınması anlamına geldiğinden dosya büyüklüğü veri miktarına göre değişecektir. Direct Query ise terabayt seviyesinde bir veritabanına da bağlansanız çok küçük olacaktır.
Direct Query modu, gerçek zamanlı raporlama yapmaya imkan verdiğinden cazip görünüyor. Bu konu aynı zamanda bir çok BI/ERP uygulamasının da bir mit’i.
Eğer projenizde kullanmayı düşünüyorsanız öncesinde bazı avantaj ve dezavantajları değerlendirmenizde fayda var.
Pro ve ücretsiz Power BI lisansı için geçerli maksimum dosya büyüklüğü olan 1 GB limitine takılıyorsanız deneyebileceğiniz opsiyonlardan biri Direct Query ile model kurmak. Veriler veri kaynağında kaldığından, yani buluta çıkmadığından dosya büyüklüğü gibi bir sorununuz olmaz.
Diğer taraftan Direct Query ile aynı anda sadece tek bir veri kaynağına bağlanabilirsiniz. Kullanacağınız tüm verileri aynı veri kaynağında toplamanız gerekir.
Son bir hafta, belki son bir ay gibi limitli bir zaman periyodundaki verileri gerçek zamanlı raporlamak mantıklı olabilir ama son 3-5 yılın verisi üzerinden kapsamlı raporlar almaya çalışırsanız muhtemelen performans sorunu yaşarsınız. DQ ile bağlantı yaptığınızda, her bir görseldeki her bir değer, metrik, sütun değeri vs. kendi sorgusunu veri tabanına gönderir. Tek bir rapor sayfasında 8 görseliniz varsa, bu sayfayı açtığınızda veri tabanına en iyi ihtimalle 8 sorgu göndermiş olursunuz. Aynı sayfayı aynı anda açan başka kullanıcıların yaptığı hareketlerin her biri de gene ayrı ayrı sorgular olarak veri tabanına gönderilir. Arada bir “cache” mekanizması yok, her hareket canlı, gerçek zamanlı veri tabanından sorgulanıyor. Performans sorunu yaşamanız halinde donanım yatırımı haricinde buna yapılabilecek tek şey SQL indexlerini kullanmak olabilir.
DQ ile kurduğunuz modellerde Power Query ve DAX’ın tüm yeteneklerinden, fonksiyonlarından faydalanamayabilirsiniz.
PowerQuery tarafındaki bazı transformasyonlar desteklenmiyor. Aşağıdaki örnekte, veri kaynağına bağlanılmış, bir kaç desteklenen step oluşturulmuş, fakat “Capitalize Each Word” transformasyonu desteklenmediği için hata mesajı veriyor. Power Query tarafı biraz ya hep ya hiç modunda, desteklenmeyen bir transformasyonu kullanmanıza kesinlikle müsade etmiyor ve çalışmayı reddediyor. Native Query‘sini oluşturamadığı hiç bir stepin oluşmasına izin vermiyor diyebiliriz.
Bunun anlamı biraz da şu kapıya çıkıyor: DQ kullanacaksanız, lazım olan verileri öncesinde bir veri ambarına taşımanız, düzeltmeniz, temizlemeniz gerekebilir. Bu da SSIS gibi başka ETL araçları kullanmanızı gerektirecektir. (Proje süresi uzadı)
Ayrı bir veri ambarı kurmak, transaction tabanlı OLTP veri tabanının performans sorunlarını azaltıp OLAP tasarımlı bir veritabanına geçmek için de lazım olacak muhtemelen.
DQ ile hazırlanmış bir raporda kullanıcının yaptığı her hareket doğrudan bir sorgu olarak veri tabanına gönderilir demiştim, bu sorguların gönderilme anını -bazen de sayısını- belirlemek için PBI Desktop opsiyonlarından “Query Reductions” bölümündeki seçenekleri kullanabilirsiniz. En azından filtreler veya slicer’lardaki her bir seçimin ayrı ayrı sorgular olarak gönderilmesini bir nebze kontrol etmiş olursunuz.
Bazı DAX fonksiyonları DQ modunda doğrudan desteklenmeyebilir. Örneğin “time intelligence” grubu fonksiyonları -by default- desteklenmiyor. Satışları ay/tarih bazında kümülatif olarak göstermek için kullanabileceğimiz TOTALYTD fonksiyonuna bir örnek verelim;
Import opsiyonunu kullanarak model oluştursaydık gayet sorunsuz çalışacak aşağıdaki formül, DQ modunda desteklenmediği için hata veriyor:
DAX tarafındaki bu gibi durumların üstesinden gelebilmek için bazen formülü farklı şekillerde yazmamız gerekebilir. Yukarıdaki kümülatif satışları hesaplaması gereken formülü ancak aşağıdaki gibi yazarsak çalışır.
Kümülatif Satışlar DQ =
CALCULATE (
[Satışlar],
FILTER (
ALL ( 'Tarih' ),
'Tarih'[Yıl] = MAX ( 'Tarih'[Yıl] ) &&
'Tarih'[Tarih] <= MAX('Tarih'[Tarih] )
)
)
Ya da, PBI Desktop opsiyonlarından, DAX fonksiyonlarıyla ilgili kısıtı kaldırmalıyız.
Bunu yaptığımızda daha önce hata veren formül “sorunsuz” çalışıyor.
Tabii “sorunsuz” göreceli bir kavram; bir kısım DAX fonksiyonları Direct Query için optimize edilmemiş (TOTALYTD gibi) , bu yüzden varsayılan durum, bu fonksiyonların kısıtlanması yönünde. Kısıtları kaldırınca çalışsalar bile bu fonksiyonların veri kaynağını barındıran sunucuya “ağır” sorgular gönderme ihtimali olduğunu not etmek lazım.
Direct Query, Power BI’ın diğer yetenekleri gibi sıklıkla güncellenen özelliklerinden biri. Örneğin ilk çıktığında desteklenmeyen Row Level Security gibi özellikler artık destekleniyor. Bu yüzden güncellemeleri takip etmekte fayda var. DQ için DAX tarafındaki güncel durumu buradan takip edebilirsiniz.
DQ sadece Power BI’a ait bir özellik değil, aynı zamanda SQL Server Analysis Service (SSAS) Azure-OnPrem versiyonlarında da var. Yazıyı çok uzatmamak adına bu kısma şimdilik girmeyeceğim. Benzer şekilde DQ modundaki modellerin dashboard’larının güncellemesiyle ilgili sürenin minimum 15 dakika olması, sorgu sonucunda dönen maksimum satır sayısının 1 milyonu geçemiyor olması, veri kaynağına gönderilen sorgunun maksimum 4 dakika gibi bir “time out” süresinin olması, PBI’ın REST API’sinin de gerçek zamanlı raporlama için kullanılabileceği gibi bir çok başka detay var.
Import ile oluşturduğunuz bir modeli direct query’ye çeviremezsiniz, ama direct query olarak oluşturduğunuz bir modeli daha sonra import moduna çevirebilirsiniz. Aynı modelde sadece tek bir modu kullanabilirsiniz, hibrid bir yapı -şimdilik- kullanamıyoruz. Şimdilik dedim, çünkü takip ettiğim kadarıyla PBI geliştirme takımından birileri PASS Summit’te hibrid bir demo örneği yaptı, fakat henüz resmi bir duyuru yol haritasında gözükmüyor.
Eğer gerçek zamanlı raporlama yapacaksanız yukarıda bahsettiğim en temel durumları nasıl çözeceğinizi baştan belirlemelisiniz.
Gerçeğe yakın zamanlı raporlama için Power BI servisindeki günde 8 kerelik otomatik güncelleme size yeterli gelmiyorsa, modelinizi SSAS’te tabular olarak kurup, partition’lar oluşturabilirsiniz. Bu partition’ları da dilediğiniz sıklıkta güncelleyebilirsiniz.
Eğer sık güncellenen limitli bir veri setini analiz edecekseniz veya 1 gb limitine takılıyorsanız DQ denenmesi gereken bir opsiyon.
Direct Query için önereceğim şeylerden biri de SSRS raporları hakkında: SSRS’te hazırladığınız raporların hepsini DQ ile Power BI’da yapın, eminim çok daha hızlı, sorunsuz ve daha kaliteli bir şekilde yaparsınız.