Nagyon nagy Power BI-adatmodellek optimalizálása meleg és hidegtáblás partíciók használatával

Ez a cikk azt ismerteti, hogyan lehet hideg és meleg táblapartíciókat használni a nagyon nagy adatmodellek optimalizálásához. A partíciók lehetővé teszik a tábla adatainak különálló részhalmazokra való felosztását. A partíciók közvetlenül nem érhetők el a szabványos Power BI-adatmodellezési eszközökben, de a speciális particionálási módszerek előnyeit kihasználhatja egy növekményes frissítési szabályzat konfigurálásával a Power BI Desktopban. A növekményes frissítés partíciókra támaszkodik, ahogyan azt a növekményes frissítés és az adathalmazok valós idejű adatai ismertetik. A forró és hideg táblapartíciók konfigurálása azonban túlmutat azon, amit a növekményes frissítési szabályzat elérhet, és feltételezi, hogy ismeri a tipikus táblaparticionálási sémákat és az XMLA-alapú eszközöket.

Előfeltételek

A particionálási technika viszonylagos összetettsége miatt az alábbi területeken jártos, haladó felhasználók számára a legmegfelelőbb:

1. A táblapartíciós fogalmak, az importálási mód partícióinak, a DirectQuery módnak és a kettős módnak a ismertetése.

2. Ismerje meg, hogyan hozhat létre hibrid táblákat XMLA-alapú eszközökkel. A hibrid táblák egy vagy több importálási módú partíciót és egy DirectQuery-partíciót használnak.

3. A DAX-függvények követelményeinek ismerete lehetővé teszi, hogy megadjon egy DataCoverageDefinition. Ez a DirectQuery-partíciók új tulajdonsága, amely leírja, hogy a hibrid tábla DirectQuery-partíciója milyen adatokat tartalmaz, hogy a Power BI-motor szükség esetén kizárhassa ezt a partíciót a lekérdezésfeldolgozásból. A DirectQuery-partíció kizárásával elkerülheti a szükségtelen adatforrás-lekérdezéseket, és javíthatja a DAX-lekérdezések feldolgozásának teljesítményét.

4. A normál és a korlátozott táblakapcsolatok közötti különbség megértése. A RELATED függvény például akkor hasznos, ha egy ténytáblapartíció adatlefedettségét szeretné meghatározni egy kapcsolódó dátumdimenzió-tábla értékei alapján. Ne feledje, hogy a Tények táblapartíció egy DirectQuery-partíció , amely korlátozott kapcsolattal rendelkezik ahhoz a dátumtáblához, amelyre a RELATED függvény nem tud értékeket lekérni. Ebben a forgatókönyvben a RELATED csak akkor működik, ha a dátum dimenziótáblája kettős tábla. A dátumtáblának DirectQuery vagy Kettős módban kell lennie. Nem lehet tiszta importálás.

Vegye figyelembe, hogy a helytelenül definiált DataCoverageDefinition eredmények helytelen eredményekhez vezethetnek, mert a Power BI helytelenül kizárhatja a DirectQuery-partíciót a lekérdezésfeldolgozásból. Ezért győződjön meg arról, hogy összehasonlítja az eredményeket a DataCoverageDefinition-val és anélkül, hogy biztosan összeadódjanak.

Mikor érdemes hideg és meleg táblapartíciókat használni?

Íme egy példa, amelyben a forró és hideg partíciók segíthetnek a hibrid táblák finomhangolásában történeti elemzés céljából. Tegyük fel, hogy nagyon nagy adatforrással rendelkezik, amely sok év alatt halmozódott fel. Az elsődleges használat az elmúlt néhány év legfrissebb adatainak elemzése. Időnként a régebbi adatokat is elemezni szeretné. Talán észrevette, hogy az értékesítési növekedés az előző évhez képest élesen megnőtt a közelmúltban. Előfordult már korábban? Ez a legmagasabb értékesítési csúcs az értékesítések nyomon követése óta?

Forró és hideg partíciók támogatása nélkül az ilyen jellegű előzményelemzéshez szükség van arra, hogy az összes előzményadatot a legfrissebb adatokkal együtt importálja a ténytáblába. Legjobb esetben ez az erőforrások nem hatékony használata, mivel az elsődleges elemzés nem is használja a régebbi előzményadatokat. Legrosszabb esetben az adatmennyiség olyan nagy, hogy nem is importálható teljes egészében. Vagy át kell állítania az adatmodellt DirectQuery módra, és el kell fogadnia a teljesítményre vonatkozó büntetést az importálási módhoz képest, vagy létrehozhat különálló modelleket, és kényszerítheti a felhasználókat a jelentések közötti váltásra. Egy forró és hideg partíciókkal rendelkező hibrid tábla jobb lehetőséget biztosít.

Hogyan használjunk meleg és hideg táblapartíciókat

Először konfigurálja az értékesítési táblát egy forró importálási módú partícióval a legutóbbi adatokhoz, és tartsa meg a régebbi adatokat egy hidegDirectQuery-partícióban, ahogyan az AdventureWorks mintaadatmodell FactInternetSales tábláját szemlélteti. A rendszer azokat a sorokat, amelyek OrderDateKey értéke nagyobb vagy egyenlő 20200101-nél, a forró import módú partíción keresztül importálja az adatmodellbe. Az OrderDateKey 20200101-nál kisebb sorokat a hideg DirectQuery-partíció fedi le. Most a Power BI gyorsan képes az elsődleges használati eseteket importálni az importálási móddal, és nem kell olyan nagy mennyiségű előzményadatot importálnia, amelyeket csak alkalmanként elemez, mert a DirectQuery-partícióra ez vonatkozik.

Ha rendelkezik egy AdventureWorks-mintaadatraktárral , és követni szeretné a lépéseket, az alábbi általános lépéseket kell elvégeznie:

1. Hozza létre az adathalmazt. AdventureWorks-adatkészlet és jelentés létrehozása a Power BI Desktop használatával. Adja meg az összes táblát tiszta DirectQuery módban. Ezután konvertálja az összes táblát, kivéve a FactInternetSales táblázatot kettős módúra. Hagyja a táblát FactInternetSalesDirectQuery módban.

2. Töltse fel az adathalmazt. A Power BI Premiumban üzemeltetett munkaterület használata az írási műveletekhez engedélyezett XMLA-végponttal.

3. Frissítse a kompatibilitási szintet. Nyissa meg a munkaterületet az AdventureWorks-adatkészlettel az SQL Server Management Studióban (SSMS). Kattintson a jobb gombbal az AdventureWorks-adatkészletre>Script>Adatbázis szkriptekéntlétrehozás vagy csere, és válassza az új lekérdezésszerkesztő ablakot. Állítsa a kompatibilitási szint tulajdonságot 1603 -ra (vagy magasabbra). Válassza a Végrehajtás vagy az F5 billentyűkombinációt. Ellenőrizze, hogy a művelet sikeresen befejeződött-e.

   

4. Konfigurálja a FactInternetSales táblapartíciókat. Kattintson a jobb gombbal az AdventureWorks-adatkészlet>adatbázis szkripteként>létrehozás vagy lecserélés, és válassza az Új lekérdezésszerkesztő ablakot. Cserélje le a teljes partíciószakaszt a következő szakaszra. Frissítse az Sql.Database sorokat úgy, hogy a környezetében lévő AdventureWorksDW-adatbázisra mutassanak. Válassza a Végrehajtás vagy az F5 billentyűkombinációt. Ellenőrizze, hogy a művelet sikeresen befejeződött-e.

      "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. Az adatmodell feldolgozása. A Power BI portálon nyissa meg a munkaterületet az AdventureWorks-adatkészlettel , és végezze el az adathalmaz igény szerinti frissítését az importálási partíció adatokkal való betöltéséhez.

6. Ellenőrizze, hogy a jelentések a legutóbbi és az előzményadatokat jelenítik-e meg. Nyissa meg az AdventureWorkset , és ellenőrizze, hogy a jelentés képes-e megjeleníteni az értékesítési tranzakciók eredményeit 2020. január 1. előtt és után, ahogyan az alábbi képernyőképen is látható.

A DirectQuery-partíció adatlefedettségének meghatározása

A megoldás zökkenőmentesen működik a legutóbbi és az előzményadatokon. Alapértelmezés szerint azonban a Power BI lekérdezi az összes táblapartíciót, mert nem tudja, hogy az egyes partíciók milyen adatokat fednek le. Ezért a Power BI még azokban az években is lekérdezi a DirectQuery-partíciót, amelyekre a DirectQuery-partíció nem terjed ki. Az értékesítési adatok könnyen elérhetők az importálási partícióban, és a DirectQuery-partíció nem ad hozzá sorokat, de ez a felesleges forráslekérdezés továbbra is jelentős terhelést okozhat az adatforráson, és késleltetheti a DAX-lekérdezések feldolgozását. A felesleges forrás lekérdezésének elkerülése érdekében használja a DataCoverageDefinition.

Ahogy az alábbi képernyőképen látható, a Power BI-jelentés továbbra is több szükségtelen SQL-lekérdezést küld 2020-ra vonatkozóan az adatforrásnak. Mivel az egyes vizualizációk DAX-lekérdezései miatt a Power BI lekérdezi a DirectQuery partíciót.

A dataCoverageDefinition tulajdonságának a következő TMSL-kódrészlethez hasonlóan történő beállításával ezek az SQL-lekérdezések elkerülhetők. Ne feledje azonban, hogy egy adatlefedettségi definíció alkalmazása vagy módosítása után frissítenie kell az adathalmazt. A folyamat újraszámítása elegendő az adatlefedettség definíciójának kiértékeléséhez. Ha elfelejti ezt a lépést, a partíciót érintő lekérdezések meghiúsulnak, és a következő hibaüzenet jelenik meg: "A(z) [Tábla neve] tábla DQ-partíciójának DataCoverageDefinition értéke még nincs kiszámítva a legutóbbi módosítás után. Újra fel kell dolgozni".

        { 
          "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}"  
                }  
        } 

Ahogy korábban említettük, a tulajdonság segít kiküszöbölni a dataCoverageDefinition szükségtelen adatforrás-terhelést. Emellett javítja a legutóbbi adatok elemzési teljesítményét is, mivel a Power BI mostantól lehetőség szerint kizárhatja a DirectQuery-partíciót a DAX-lekérdezésfeldolgozásból. Egyszerű adatlefedettségi kifejezéseket definiálhat önálló értékekhez, valamint egyszerű ÉS, OR és NOT operátorokkal rendelkező tartományokhoz. A RELATED függvénnyel is definiálhatja az adatlefedettségeket egy olyan dimenziótábla oszlopa alapján, amely rendszeres kapcsolatban áll a ténytáblával. Ha egy adatlefedettségi kifejezés dimenziótáblából származó oszlopokat használ, győződjön meg arról, hogy a dimenziótábla kettős módban van. Az adatlefedettséget a ténytábla oszlopai alapján is meghatározhatja. A támogatott műveletekhez tekintse meg az alábbi táblázatot, amely három csoportra van kategorizálva. 

Típus	Comments	Példák
Egy predikátum (értékalapú)	Egyenlőség, egyenlőtlenség és IN operátorok Dimenzió- és ténytáblák támogatása	RELATED('Date'[Year]) = 2020 NOT RELATED('Date'[Year]) = 2020 RELATED('Date'[Year]) IN {2020, 2021, 2022} InternetSales'[SalesAmt] = CURRENCY(100.0) NEM InternetSales'[SalesAmt] = CURRENCY(100.0) InternetSales'[SalesAmt] IN {CURRENCY(100.0), CURRENCY(200.0)}
Egy predikátum (tartományalapú)	Lehetnek összehasonlító operátorok, például >: , <>=, <= A dimenziótáblának kettős módban kell lennie	RELATED('Date'[Year]) > 2020 RELATED('Date'[Year]) <= 2020
Több predikátum	Egyenlőség, egyenlőtlenség és összehasonlítás Nem támogatja az IN operátort Egyetlen dimenziótáblára van korlátozva kétmódusú üzemmódban	RELATED('Date'[Year]) > 2010 &> RELATED('Date'[Year]) > 2020 RELATED('Date'[Year]) = 2020 &> 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'[Naptári negyedév]) = 2)

A DataCoverageDefinitionDirectQuery-partíciók tulajdonsága lehetővé teszi még a legnagyobb Power BI-adatmodellek optimalizálását az importálási módban lévő gyakori partíciók és a DirectQuery módban lévő hideg partíciók alapján, elkerülve az adatforrás szükségtelen lekérdezését. Ez a lekérdezéscsökkentés segít javítani a jelentés teljesítményét a gyakori elérésű adatok elemzésekor. Emellett segít csökkenteni az adatforrás terhelését, és így maximalizálhatja az adatforrás méretet. Ne feledje azonban, hogy az adatmodellek dataCoverageDefinition tulajdonságának használatával történő optimalizálása még mindig egy fejlett forgatókönyv. Győződjön meg arról, hogy gondosan ellenőrzi az eredményeket.

Megfontolások és korlátok

• DataCoverageDefinition A DirectQuery-partíciók tulajdonságához jelenleg statikus értékek szükségesek, például RELATED('Date'[Year]) = 2020 vagy RELATED('Date'[Year]) IN {2020, 2021, 2022}. A dinamikus hozzárendelések nem támogatottak, például RELATED('Date'[DateKey]) = TODAY().

• A valós idejű adatokkal végzett növekményes frissítés nem használja ki a tulajdonságot DataCoverageDefinition . Ha egy DirectQuery-partícióra (valós idejű) adatlefedettségi definíciót alkalmaz, a növekményes frissítés elveti az adatlefedettségi definíciót a partíció újra létrehozásakor.