Çok büyük Power BI veri modellerini optimize etmek için sıcak ve soğuk tablo bölümlerini kullanma

Bu makalede, çok büyük veri modellerini iyileştirmek için sıcak ve soğuk tablo bölümlerinin nasıl kullanılacağı açıklanmaktadır. Bölümler, tablonun verilerini ayrı alt kümelere bölmenin bir yolunu sağlar. Bölümler standart Power BI veri modelleme araçlarında doğrudan kullanıma sunulmaz , ancak Power BI Desktop'ta artımlı yenileme ilkesi yapılandırarak gelişmiş bölümleme yöntemlerinden yararlanabilirsiniz. Artımlı yenileme, Veri kümeleri için Artımlı Yenileme ve Gerçek Zamanlı Veriler bölümünde açıklandığı üzere, bölümlere dayanır. Ancak, sıcak ve soğuk tablo bölümlerini bölümlendirmek, artımlı yenileme politikasının gerçekleştirebileceği işlemlerin ötesine geçer ve tipik tablo bölümleme düzenleri ile XMLA tabanlı araçlar hakkında bilgi sahibi olduğunuzu varsayar.

Önkoşullar

Bu bölümleme tekniğinin göreli karmaşıklığı nedeniyle, aşağıdaki alanlarda deneyimli ileri düzey kullanıcılar için en uygundur:

1. Tablo bölümleme kavramlarını, içeri aktarma modu bölümlerinin, DirectQuery modunun ve İkili modun nasıl çalıştığını anlama.

2. XMLA tabanlı araçları kullanarak karma tablolar oluşturma hakkında bilgi. Karma tablolar bir veya daha fazla içeri aktarma modu bölümü ve bir DirectQuery bölümü kullanır.

3. DAX işlevlerini belirtmek için kullanabileceğiniz DataCoverageDefinition gereksinimleri hakkındaki bilgi. Bu, DirectQuery bölümlerinin karma tablonun DirectQuery bölümünün hangi verileri içerdiğini açıklayan yeni bir özelliktir, böylece Power BI altyapısı bu bölümü uygun olduğunda sorgu işlemenin dışında tutabilir. DirectQuery bölümünün dışlanması gereksiz veri kaynağı sorgularını önlemeye ve DAX sorgu işleme performansını geliştirmeye yardımcı olabilir.

4. Normal ve sınırlı tablo ilişkileri arasındaki farkı anlama. Örneğin, bir olgular tablosu bölümünün veri kapsamını ilgili tarih boyutu tablosundaki değerlere göre tanımlamak istiyorsanız RELATED işlevi yararlıdır. Gerçekler tablosu bölümünün, RELATED işlevinin değerleri getiremediği tarih tablosuyla kısıtlı bir ilişki olasılığı olan bir DirectQuery bölümü olduğunu unutmayın. Bu senaryoda RELATED yalnızca tarih boyutu tablosu çift tablo olduğunda çalışır. Tarih tablosunun DirectQuery veya İkili modda olması gerekir. Katıksız ithalat olmamalı.

Bilin ki yanlış tanımlanmış bir DataCoverageDefinition işlemi, Power BI'nin DirectQuery bölümünü sorgu işlemlerinden yanlışlıkla hariç tutmasına ve bu nedenle yanlış sonuçlara yol açmasına neden olabilir. Bu nedenle, sonuçların DataCoverageDefinition ile ve olmadan karşılaştırıldığında uygun olduğunu kontrol edin.

Sıcak ve soğuk tablo bölümlerini ne zaman kullanmalıyız?

Burada, sıcak ve soğuk bölümlerin geçmiş analiz için karma tabloya ince ayar yapılmasına yardımcı olabileceği bir örnek verilmiştir. Uzun yıllar boyunca birikmiş çok büyük bir veri kaynağınız olduğunu varsayalım. Birincil kullanım, son birkaç yılın en son verilerini analiz etmektir. Bazen eski verileri de analiz etmek istersiniz. Belki de son zamanlarda yıldan yıla keskin bir satış artışı fark etmişsinizdir. Bu daha önce oldu mu? Satış takibinin başlangıcından bu yana en yüksek satış artışı mı?

Sık erişimli ve soğuk bölümler için destek olmadan, bu tür bir geçmiş analiz, tüm geçmiş verileri ve daha yeni verileri olgular tablosuna aktarmanızı gerektirir. En iyi durumda, bu kaynakların verimsiz kullanımıdır çünkü birincil analiz eski geçmiş verilerden hiçbirini kullanmaz. En kötü ihtimalle veri hacmi o kadar büyüktür ki tam olarak içeri aktarılamaz bile. Veri modelini DirectQuery moduna geçirmeniz ve içeri aktarma moduna kıyasla bir performans cezası kabul etmek zorunda kalırsınız ya da ayrı modeller oluşturup kullanıcılarınızı raporlar arasında geçiş yapmaya zorlayabilirsiniz. Sık erişimli ve soğuk bölümleri olan karma bir tablo size daha iyi bir seçenek sunar.

Sıcak ve soğuk tablo bölümlerini kullanma

İlk olarak, aşağıdaki diyagramda AdventureWorks örnek veri modelinin FactInternetSales tablosunda gösterildiği gibi, satış tablosunu en son veriler için sık erişimli içeri aktarma modu bölümüyle yapılandırın ve eski verileri soğuk bir DirectQuery bölümünde tutun. OrderDateKey değeri 20200101'e eşit veya daha büyük olan tüm satırlar, hızlı içe aktarma modu bölümü aracılığıyla veri modeline aktarılır. OrderDateKey değeri 20200101 küçük olan satırlar, soğuk DirectQuery bölümüyle kaplanır. Power BI, ana kullanım senaryolarını içeri aktarma moduyla hızlı bir şekilde sunabilir ve DirectQuery bölümü bu durumu ele aldığı için sadece ara sıra analiz ettiğiniz yüksek hacimli geçmiş verileri içeri aktarmanız gerekmez.

Bir AdventureWorks örnek veri ambarı varsa ve bunu takip etmek istiyorsanız, genel adımlar şunlardır:

1. Veri kümesini oluşturun. Bir AdventureWorks veri kümesi ve raporu oluşturmak için Power BI Desktop'ı kullanın. Tüm tabloları saf DirectQuery moduna ekleyin. Ardından, tablo dışındaki FactInternetSales tüm tabloları İkili moda dönüştürün. FactInternetSales Tabloyu DirectQuery modunda bırakın.

2. Veri kümesini yükleyiniz. Yazma işlemleri için etkinleştirilmiş XMLA uç noktasıyla Power BI Premium'da barındırılan bir çalışma alanı kullanın.

3. Uyumluluk düzeyini güncelleştirin. SQL Server Management Studio'da (SSMS) AdventureWorks veri kümenizle çalışma alanını açın. AdventureWorks veri kümesine>Veritabanı Betiği Olarak>Oluştur veya Değiştiriçin sağ tıklayın, ve Yeni Sorgu Düzenleyici Penceresi'ni seçin. compatibilityLevel özelliğini 1603 (veya üzeri) olarak ayarlayın. Yürüt'e tıklayın veya F5 tuşuna basın. İşlemin başarıyla tamamlandığını doğrulayın.

   

4. FactInternetSales tablo bölümlerini yapılandırın. AdventureWorks veri kümesi>Betik>Veritabanı Betiğini Olarak BetikleOluştur veya Değiştir'e sağ tıklayın ve Yeni sorgu düzenleyicisi penceresi'ni seçin. Bölümler kısmının tamamını aşağıdaki kısımla değiştirin. Sql.Database satırlarını ortamınızdaki AdventureWorksDW veritabanına işaret eden şekilde güncelleştirdiğinizden emin olun. Yürüt'e tıklayın veya F5 tuşuna basın. İşlemin başarıyla tamamlandığını doğrulayın.

      "partitions": [ 
       { 
         "name": "FactInternetSales-DQ-Partition", 
         "mode": "directQuery", 
         "dataView": "full", 
         "source": { 
           "type": "m", 
           "expression": [ 
             "let", 
             "    Source = Sql.Database(\"demo.database.windows.net\", \"AdventureWorksDW\"),", 
             "    dbo_FactInternetSales = Source{[Schema=\"dbo\",Item=\"FactInternetSales\"]}[Data],", 
             "    #\"Filtered Rows\" = Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] < 20200101)", 
             "in", 
             "    #\"Filtered Rows\"" 
           ] 
         } 
       }, 
       { 
         "name": "FactInternetSales-Import-Partition", 
         "mode": "import", 
         "source": { 
           "type": "m", 
           "expression": [ 
             "let", 
             "    Source = Sql.Database(\"demo.database.windows.net\", \"AdventureWorksDW\"),", 
             "    dbo_FactInternetSales = Source{[Schema=\"dbo\",Item=\"FactInternetSales\"]}[Data],", 
             "    #\"Filtered Rows\" = Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] >= 20200101)", 
             "in", 
             "    #\"Filtered Rows\"" 
           ] 
         } 
       } 
     ],    
   

5. Veri modelini işleme. Power BI portalında AdventureWorks veri kümenizle çalışma alanını açın ve içeri aktarma bölümünü verilerle yüklemek için veri kümesinde isteğe bağlı yenileme gerçekleştirin.

6. Raporların son ve geçmiş verileri gösterdiğini doğrulayın. AdventureWorks'ünüzü açın ve raporun aşağıdaki ekran görüntüsünde gösterildiği gibi 1 Ocak 2020'den önceki ve sonraki satış işlemlerinin sonuçlarını gösterebildiğinden emin olun.

DirectQuery bölümünün veri kapsamını tanımlama

Çözüm, son ve geçmiş veriler üzerinde sorunsuz bir şekilde çalışır. Ancak, her bölümün hangi verileri kapsadığını bilmediği için Power BI varsayılan olarak tüm tablo bölümlerini sorgular. Bu nedenle Power BI, DirectQuery bölümünün kapsamadığı yıllar için bile DirectQuery bölümünü sorgular. Satış verileri içeri aktarma bölümünde kullanılabilir ve DirectQuery bölümü herhangi bir satıra katkıda bulunmaz, ancak bu gereksiz kaynak sorgulaması yine de veri kaynağında fark edilebilir yüke neden olabilir ve DAX sorgu işlemesinde gecikmelere neden olabilir. Bu gereksiz kaynak sorgulamasını önlemek için kullanın DataCoverageDefinition.

Aşağıdaki ekran görüntüsünde gösterildiği gibi, her görselin DAX sorgusu Power BI'ın DirectQuery bölümünü sorgulamasına neden olduğundan Power BI raporu yine de 2020 için birkaç gereksiz SQL sorgusu gönderir.

dataCoverageDefinition özelliğini DirectQuery bölümüne aşağıdaki TMSL kod parçacığı gibi ayarlayarak bu SQL sorgularından kaçınılır. Ancak veri kapsamı tanımını uyguladıktan veya değiştirdikten sonra veri kümesini yenilemeniz gerektiğini unutmayın. Veri kapsamı tanımını değerlendirmek için işlem yeniden hesaplaması yeterlidir. Bu adımı unutursanız, bölüme dokunan sorgular "Son bir değişiklikten sonra '[Tablo Adı]' tablosundaki DQ bölümünün DataCoverageDefinition değeri henüz hesaplanmamıştır." şeklinde bir hata mesajı ile başarısız olur. Yeniden işlenmesi gerekiyor".

        { 
          "name": "FactInternetSales-DQ-Partition", 
          "mode": "directQuery", 
          "dataView": "full", 
          "source": { 
            "type": "m", 
            "expression": [ 
              "let", 
              "    Source = Sql.Database(\"demopm.database.windows.net\", \"AdventureWorksDW2020\"),", 
              "    dbo_FactInternetSales = Source{[Schema=\"dbo\",Item=\"FactInternetSales\"]}[Data],", 
              "    #\"Filtered Rows\" = Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] < 20200101)", 
              "in", 
              "    #\"Filtered Rows\"" 
            ] 
          },  
"dataCoverageDefinition": {  
                  "description": "DQ partition with all sales from 2017, 2018, and 2019.",  
                  "expression": "RELATED('DimDate'[CalendarYear]) IN {2017,2018,2019}"  
                }  
        } 

Daha önce belirtildiği gibi özelliği gereksiz dataCoverageDefinition veri kaynağı yükünü ortadan kaldırmaya yardımcı olur. Power BI artık DirectQuery bölümünü uygun olduğunda DAX sorgu işlemesinin dışında tutabildiğinden son verilerin analiz performansını da artırır. Tek değerler için basit veri kapsamı ifadelerinin yanı sıra basit AND, OR ve NOT işleçlerine sahip aralıklar tanımlayabilirsiniz. İlişkili işlevini, olgu tablosuyla normal ilişkisi olan bir boyut tablosundaki bir sütunu temel alarak veri kapsamını tanımlamak için de kullanabilirsiniz. Veri kapsamı ifadesi boyut tablosundaki sütunları kullanıyorsa, boyut tablosunun çift modda olduğundan emin olun. Veri kapsamını olgu tablosunun kendisinden gelen sütunları temel alarak da tanımlayabilirsiniz. Desteklenen işlemler için üç gruba ayrılmış aşağıdaki tabloya bakın. 

Türü	Comments	Örnekler
Tek koşul (değer tabanlı)	Eşitlik, eşitsizlik ve IN işleçleri Hem boyut hem de olgu tablolarını destekleme	RELATED('Date'[Year]) = 2020 İLGİLİ DEĞİL('Tarih'[Yıl]) = 2020 RELATED('Date'[Year]) IN {2020, 2021, 2022} InternetSales'[SalesAmt] = CURRENCY(100.0) NOT InternetSales'[SalesAmt] = CURRENCY(100.0) InternetSales'[SalesAmt] IN {CURRENCY(100.0), CURRENCY(200.0)}
Tek öncül (aralık tabanlı)	>, <, >=, <= gibi karşılaştırma işleçleri olabilir Boyut tablosunun İkili modda olmasını gerektir	RELATED('Date'[Year]) > 2020 RELATED('Date'[Year]) <= 2020
Birden fazla predikat	Eşitlik, eşitsizlik ve karşılaştırma IN işlecini desteklemez İkili modda tek boyutlu tabloyla sınırlı	RELATED('Date'[Year]) > 2010 ve RELATED('Date'[Year]) > 2020 RELATED('Date'[Year]) = 2020 ve RELATED('Date'[Calendar Quarter]) = 1 RELATED('Date'[Year]) > 2020 && NOT RELATED('Date'[Calendar Quarter]) = 1 RELATED('Date'[Year]) 2020 && RELATED('Date'[Calendar Quarter]) 3 RELATED('Date'[Year]) > 2020 &&(RELATED('Date'[Calendar Quarter]) = 1 || RELATED('Date'[Calendar Quarter]) = 2)

DirectQuery bölümlerindeki DataCoverageDefinition özelliği, veri kaynağını gereksiz sorgulamaktan kaçınarak içeri aktarma modundaki sık erişimli bölümlere ve DirectQuery modundaki soğuk bölümlere dayalı olan en büyük Power BI veri modellerini bile optimize etmenize olanak tanır. Bu kaynak sorgu azaltma, sık erişimli verileri analiz ederken rapor performansını artırmaya yardımcı olur. Ayrıca veri kaynağı üzerindeki yükü azaltmaya yardımcı olur ve bu şekilde veri kaynağınızın ölçeğini en üst düzeye çıkarmaya yardımcı olur. Ancak, özelliğini kullanarak bir veri modelini iyileştirmenin dataCoverageDefinition hala gelişmiş bir senaryo olduğunu unutmayın. Sonuçları dikkatle doğruladığınızdan emin olun.

Dikkat edilmesi gerekenler ve sınırlamalar

• Şu anda DataCoverageDefinition bölümlerindeki özellik RELATED('Date'[Year]) = 2020 veya RELATED('Date'[Year]) IN {2020, 2021, 2022} gibi statik değerler gerektirir. RELATED('Date'[DateKey]) = TODAY() gibi dinamik atamalar desteklenmez.

• Gerçek zamanlı verilerle artımlı yenileme özelliğinden DataCoverageDefinition yararlanmaz. DirectQuery (gerçek zamanlı) bir bölüme veri kapsamı tanımı uygularsanız, Artımlı Yenileme bölümü yeniden oluşturduğunda veri kapsamı tanımını kaldırır.