Tekniker för dataminskning för importmodellering

Den här artikeln riktar sig till Power BI Desktop-datamodellerare som utvecklar och publicerar Power BI-semantiska modeller. Mer specifikt beskrivs olika tekniker för att minska data som läses in i importmodeller.

Importmodeller läses in med data som komprimeras och optimeras och sedan lagras på disk av VertiPaq-lagringsmotorn. När källdata läses in i minnet är det möjligt att uppnå 10x komprimering, så det är rimligt att förvänta sig att 10 GB källdata kan komprimeras till cirka 1 GB i storlek. Dessutom kan en extra minskning på 20 % uppnås när disken sparas.

Trots de effektivitetsvinster som uppnås av VertiPaq-lagringsmotorn bör du sträva efter att minimera de data som läses in i dina modeller. Det gäller särskilt för stora modeller eller modeller som du förväntar dig kommer att bli stora med tiden. Fyra övertygande orsaker är:

• Större modellstorlekar kanske inte stöds av din kapacitet. Delad kapacitet kan vara värd för modeller upp till 1 GB i storlek, medan Premium-kapaciteter kan vara värd för större modeller beroende på SKU:n. Mer information finns i Stora semantiska modeller i Power BI Premium.
• Mindre modellstorlekar minskar konkurrensen om kapacitetsresurser, särskilt minne. Många mindre modeller inom en kapacitet kan laddas samtidigt under längre tidsperioder, vilket resulterar i lägre utkastningsfrekvens.
• Mindre modellstorlekar ger snabbare datauppdatering, vilket resulterar i rapportering med lägre svarstid, högre dataflöde för semantisk modelluppdatering och mindre tryck på källsystem och kapacitetsresurser.
• Mindre antal tabellrader kan leda till snabbare beräkningsutvärderingar, vilket ger bättre övergripande frågeprestanda.

Viktigt!

Den här artikeln refererar till Power BI Premium eller dess kapacitetsprenumerationer (P SKU:er). För närvarande konsoliderar Microsoft köpalternativ och drar tillbaka SKU:erna för Power BI Premium per kapacitet. Nya och befintliga kunder bör överväga att köpa kapacitetsprenumerationer för Infrastrukturresurser (F SKU:er) i stället.

Mer information finns i Viktig uppdatering som kommer till Power BI Premium-licensiering och Vanliga frågor och svar om Power BI Premium.

Ta bort onödiga kolumner

Modelltabellkolumner har två huvudsakliga syften:

• Rapportering, för att uppnå rapportdesign som filtrerar, grupperar och sammanfattar modelldata på lämpligt sätt.
• Modellstruktur genom att stödja modellrelationer, modellberäkningar, säkerhetsroller och till och med datafärgformatering.

Du kan förmodligen ta bort alla kolumner som inte tjänar något av dessa syften. Att ta bort en kolumn från en tabell kallas ibland för lodrät filtrering.

Vi rekommenderar att du utformar modeller med exakt rätt antal kolumner baserat på dina kända rapporteringskrav. Dina krav kan ändras med tiden, men tänk på att det är enklare att lägga till kolumner senare än att ta bort dem senare. Om du tar bort kolumner kan rapporter eller modellstrukturen brytas.

Ta bort onödiga rader

Du bör läsa in modelltabeller med så få rader som möjligt. Du kan uppnå det genom att läsa in filtrerade raduppsättningar i modelltabeller av två olika skäl: att filtrera efter tid eller entitet. Att ta bort rader kallas ibland för vågrät filtrering.

• Filtrering efter tid innebär att begränsa mängden datahistorik som läses in i faktatabeller (och begränsa datumrader som läses in i modelldatumtabellerna). Vi rekommenderar att du inte läser in all tillgänglig historik som standard, såvida det inte är ett känt rapporteringskrav. Du kan implementera tidsbaserade Power Query-filter med parametrar och till och med ange att de ska använda relativa tidsperioder (i förhållande till uppdateringsdatumet, till exempel de senaste fem åren). Tänk också på att en bakåtblickande ändring av tidsfilter inte bryter rapporter. Det resulterar bara i mindre (eller mer) datahistorik som är tillgänglig i rapporter.
• Filtrering efter entitet innebär att en delmängd av källdata läses in i modellen. I stället för att läsa in försäljningsfakta för alla försäljningsregioner läser du till exempel bara in fakta för en enda region. Den här designmetoden resulterar i många mindre modeller, och det kan också eliminera behovet av att definiera säkerhet på radnivå (RLS) , men det kräver att specifika semantiska modellbehörigheter beviljas i Power BI-tjänsten och dubbletter av rapporter som ansluter till varje semantisk modell. Du kan använda Power Query-parametrar och Power BI-mallfiler för att förenkla hanteringen och publiceringen. Mer information finns i Skapa och använda rapportmallar i Power BI Desktop.

Gruppera efter och sammanfatta

Den kanske mest effektiva tekniken för att minska modellstorleken är att läsa in försammanfattningsbaserade data. Du kan använda den här tekniken för att öka kornigheten för faktatabeller. Det finns dock en distinkt kompromiss som resulterar i förlust av detaljer.

Tänk dig ett exempel där en faktatabell för källförsäljning lagrar en rad per orderrad. Betydande dataminskning kan uppnås genom att summera alla försäljningsmått, gruppering efter datum, kund och produkt. En ännu större dataminskning kan uppnås genom gruppering efter datum på månadsnivå. Även om det skulle kunna uppnå en möjlig 99-% minskning av modellstorleken, är det inte längre möjligt att rapportera på dagnivå eller enskild orderradsnivå. Att bestämma sig för att sammanfatta faktadata innebär alltid kompromisser. Kompromissen kan minimeras av en modelldesign som innehåller vissa tabeller i DirectQuery-lagringsläge, vilket beskrivs senare i den här artikeln.

Optimera kolumndatatyper

VertiPaq-lagringsmotorn använder separata interna datastrukturer för varje kolumn. De här datastrukturerna uppnår avsiktligt de högsta optimeringarna för numeriska kolumndata, som använder värdekodning. Text och andra icke-numeriska data använder dock hash-kodning. Hash-kodning kräver att lagringsmotorn tilldelar en numerisk identifierare till varje unikt värde som finns i kolumnen. Det är då den numeriska identifieraren som lagras i datastrukturen, vilket kräver en hash-sökning under lagring och frågor.

I vissa specifika fall kan du konvertera källtextdata till numeriska värden. Ett försäljningsordernummer kan till exempel konsekvent prefixeras av ett textvärde (till exempel SO123456). I det här fallet kan prefixet SO tas bort och ordernumret konverteras till ett heltal. För stora tabeller kan den här ändringen resultera i betydande dataminskning, särskilt när kolumnen innehåller unika värden eller värden med hög kardinalitet.

I det här exemplet rekommenderar vi att du anger kolumnens standardsammanfattningsegenskap till Do Not Summarize. Det hjälper till att undvika olämplig sammanfattning av ordernummervärdena.

Inställningar för anpassade kolumner

VertiPaq-lagringsmotorn lagrar modellberäknade kolumner (definierade i DAX) precis som vanliga Power Query-kolumner. De interna datastrukturerna lagras dock något annorlunda och ger vanligtvis mindre effektiv komprimering. Dessutom skapas datastrukturerna när alla Power Query-tabeller har lästs in, vilket kan resultera i utökade datauppdateringstider. Det är därför mindre effektivt att lägga till tabellkolumner som beräknade kolumner än power query-beräknade kolumner (definierade i M).

När det är möjligt kan du skapa anpassade kolumner i Power Query. När källan är en databas kan du uppnå större belastningseffektivitet på två sätt: Beräkningen kan definieras i SQL-instruktionen (med providerns interna frågespråk) eller materialiseras som en kolumn i datakällan.

I vissa fall kan dock modellberäkningen av kolumner vara det bättre valet. Det stämmer när formeln omfattar utvärdering av mått eller kräver specifika modelleringsfunktioner som endast stöds i DAX-funktioner. Information för mer om ett exempel som detta finns i Förståelse för funktioner för överordnade och underordnade hierarkier i DAX.

Inaktivera Power Query-frågeinläsning

Power Query-frågor som är avsedda att stödja dataintegrering med andra frågor bör inte läsas in i modellen. Se till att du inaktiverar frågebelastningen i dessa instanser för att undvika att läsa in dessa frågor till modellen.

Inaktivera automatiskt datum/tid

Power BI Desktop innehåller ett alternativ som kallas Automatiskt datum/tid. När den är aktiverad skapas dolda automatiska datum-/tidstabeller för varje datumkolumn i modellen. Det här alternativet stöder rapportförfattare när du konfigurerar filter, gruppering och åtgärder för ökad detaljnivå för kalendertidsperioder. De dolda tabellerna är faktiskt beräknade tabeller som ökar modellens storlek.

Mer information finns i Vägledning för automatisk datum/tid i Power BI Desktop.

Använda DirectQuery-lagringsläge

DirectQuery-lagringsläge är ett alternativ till Importera lagringsläge. DirectQuery-modelltabeller importerar inte data. I stället består de bara av metadata som definierar tabellstrukturen. När tabellen efterfrågas används interna frågor för att hämta data från den underliggande datakällan. När du kombinerar tabeller för import- och DirectQuery-lagringsläge i en enda modell kallas det för en sammansatt modell.

En effektiv teknik för att minska modellstorleken är att ange lagringsläget för större faktatabeller till DirectQuery. Tänk på att den här designmetoden ofta fungerar bra med tekniken Group by and summarize som introducerades tidigare. Sammanfattade försäljningsdata kan till exempel användas för att uppnå sammanfattningsrapporter med höga prestanda. En genomdragningssida kan visa detaljerad försäljning för specifika (och begränsade) filterkontexter, som visar alla försäljningsorder i kontexten. I det här exemplet kan visningssidan innehålla visuella objekt baserat på en DirectQuery-modelltabell för att hämta försäljningsorderdata.

Det finns dock många säkerhets- och prestandakonsekvenser som rör DirectQuery-lagringsläge och sammansatta modeller. Mer information finns i Använda sammansatta modeller i Power BI Desktop.

Relaterat innehåll

Mer information om den här artikeln finns i följande artiklar:

• Semantiska modelllägen i Power BI-tjänst
• Lagringsläge i Power BI Desktop
• Frågor? Prova att fråga Fabric-gemenskapen
• Förslag? Bidra med idéer för att förbättra Fabric