Datareduksjonsteknikker for importmodellering

Denne artikkelen er rettet mot Power BI Desktop-datamodellerere som utvikler og publiserer semantiske modeller for Power BI. Nærmere bestemt beskriver den ulike teknikker for å redusere data som lastes inn i importmodeller.

Importmodeller lastes inn med data som er komprimert og optimalisert, og lagres deretter på disken av VertiPaq-lagringsmotoren. Når kildedata lastes inn i minnet, er det mulig å oppnå 10x komprimering, og derfor er det rimelig å forvente at 10 GB kildedata kan komprimere til omtrent 1 GB i størrelse. Videre, når vedvarende disk en ekstra 20% reduksjon kan oppnås.

Til tross for effektiviteten som oppnås av VertiPaq-lagringsmotoren, bør du strebe etter å minimere dataene som er lastet inn i modellene dine. Det gjelder spesielt for store modeller, eller modeller som du forventer vil vokse til å bli store over tid. Fire overbevisende grunner inkluderer:

• Større modellstørrelser støttes kanskje ikke av kapasiteten. Delt kapasitet kan være vert for modeller på opptil 1 GB, mens Premium-kapasiteter kan være vert for større modeller avhengig av SKU-en. Hvis du vil ha mer informasjon, kan du se Store semantiske modeller i Power BI Premium.
• Mindre modellstørrelser reduserer striden for kapasitetsressurser, spesielt minne. Mange mindre modeller i en kapasitet kan lastes inn samtidig i lengre perioder, noe som resulterer i lavere utkastelsesfrekvenser.
• Mindre modellstørrelser oppnår raskere dataoppdatering, noe som resulterer i lavere ventetidsrapportering, høyere gjennomstrømming av semantisk modelloppdatering og mindre press på kildesystem og kapasitetsressurser.
• Mindre antall tabellrader kan føre til raskere beregningsevalueringer, noe som resulterer i bedre generell spørringsytelse.

Fjern unødvendige kolonner

Modelltabellkolonner tjener to hovedformål:

• Reportingfor å oppnå rapportutforminger som riktig filtrerer, grupperer og oppsummerer modelldata.
• modellstruktur, ved å støtte modellrelasjoner, modellberegninger, sikkerhetsroller og til og med datafargeformatering.

Du kan sannsynligvis fjerne alle kolonner som ikke tjener noen av disse formålene. Hvis du fjerner en kolonne fra en tabell, kalles det noen ganger loddrett filtrering.

Vi anbefaler at du utformer modeller med nøyaktig riktig antall kolonner basert på dine kjente rapporteringskrav. Kravene kan endres over tid, men husk at det er enklere å legge til kolonner senere enn det er å fjerne dem senere. Hvis du fjerner kolonner, kan du bryte rapporter eller modellstrukturen.

Fjerne unødvendige rader

Du bør laste inn modelltabeller med så få rader som mulig. Du kan oppnå dette ved å laste inn filtrerte radsett i modelltabeller av to ulike årsaker: å filtrere etter tid eller etter enhet. Fjerning av rader kalles noen ganger vannrett filtrering.

• Filtrering etter tid innebærer å begrense mengden datalogg lastet inn i faktatabeller (og begrense datoradene som er lastet inn i modelldatotabellene). Vi anbefaler at du ikke laster inn all tilgjengelig logg som standard, med mindre det er et kjent rapporteringskrav. Du kan implementere tidsbaserte Power Query-filtre med parametere, og til og med angi at de skal bruke relative tidsperioder (i forhold til oppdateringsdatoen – for eksempel de siste fem årene). Husk også at en retrospektiv endring av tidsfiltre ikke bryter rapporter. det vil bare resultere i mindre (eller mer) datalogg tilgjengelig i rapporter.
• Filtrering etter enhet innebærer å laste inn et delsett av kildedata i modellen. I stedet for å laste inn salgsfakta for alle salgsområder, laster du for eksempel bare inn fakta for ett enkelt område. Denne utformingstilnærmingen resulterer i mange mindre modeller, og den kan også eliminere behovet for å definere sikkerhet på radnivå (RLS)– men det krever å gi bestemte semantiske modelltillatelser i Power BI-tjenesten, og opprette dupliserte rapporter som kobler til hver semantiske modell. Du kan bruke Power Query-parametere og Power BI-malfiler for å forenkle administrasjon og publisering. Hvis du vil ha mer informasjon, kan du se Opprette og bruke rapportmaler i Power BI Desktop.

Grupper etter og oppsummer

Kanskje den mest effektive teknikken for å redusere en modellstørrelse er å laste inn forhåndsoppsummerte data. Du kan bruke denne teknikken til å heve kornet av faktatabeller. Det er en distinkt avveining, men resulterer i tap av detaljer.

Vurder et eksempel der en faktatabell for kildesalg lagrer én rad per ordrelinje. Betydelig datareduksjon kan oppnås ved å oppsummere alle salgsdata, gruppere etter dato, kunde og produkt. En enda viktigere datareduksjon kan oppnås ved å gruppere etter dato på månedsnivå. Selv om det kan oppnå en mulig 99% reduksjon i modellstørrelse, er rapportering på dagnivå eller individuelt ordrelinjenivå ikke lenger mulig. Å bestemme seg for å oppsummere faktadata innebærer alltid avveininger. Avveining kan reduseres av en modellutforming som inneholder noen tabeller i DirectQuery-lagringsmodus, som beskrives senere i denne artikkelen.

Optimaliser kolonnedatatyper

VertiPaq-lagringsmotoren bruker separate interne datastrukturer for hver kolonne. Disse datastrukturene oppnår de høyeste optimaliseringene for numeriske kolonnedata, som bruker verdikoding. Tekst og andre ikke-numeriske data bruker imidlertid hash-koding. Hash-koding krever at lagringsmotoren tilordner en numerisk identifikator til hver unike verdi i kolonnen. Det er den numeriske identifikatoren da, som er lagret i datastrukturen, som krever et hash-oppslag under lagring og spørring.

I noen bestemte tilfeller kan du konvertere kildetekstdata til numeriske verdier. Et salgsordrenummer kan for eksempel konsekvent prefikseres av en tekstverdi (for eksempel SO123456). I dette tilfellet kan prefikset SO fjernes, og ordrenummerverdien konverteres til et heltall. For store tabeller kan denne endringen føre til betydelig datareduksjon, spesielt når kolonnen inneholder unike verdier eller verdier med høy kardinalitet.

I dette eksemplet anbefaler vi at du angir standard summeringsegenskap for kolonnen til Do Not Summarize. Det bidrar til å unngå upassende oppsummering av ordrenummerverdiene.

Innstillinger for egendefinerte kolonner

VertiPaq-lagringsmotoren lagrer modellen beregnede kolonner (definert i DAX) akkurat som vanlige kolonner med Power Query-kilder. De interne datastrukturene lagres imidlertid litt annerledes, og oppnår vanligvis mindre effektiv komprimering. Datastrukturene bygges også når alle Power Query-tabeller lastes inn, noe som kan resultere i utvidede dataoppdateringstider. Det er derfor mindre effektivt å legge til tabellkolonner som beregnede kolonner enn beregnede kolonner i Power Query (definert i M).

Når det er mulig, bør du angi hvordan du oppretter egendefinerte kolonner i Power Query. Når kilden er en database, kan du oppnå større belastningseffektivitet på to måter: Beregningen kan defineres i SQL-setningen (ved hjelp av leverandørens opprinnelige spørringsspråk), eller den kan materialiseres som en kolonne i datakilden.

I noen tilfeller kan imidlertid modellberegnede kolonner være det beste valget. Det er sant når formelen innebærer evaluering av mål, eller det krever spesifikk modelleringsfunksjonalitet som bare støttes i DAX-funksjoner. Hvis du vil ha informasjon om et slikt eksempel, kan du se Forstå funksjoner for overordnede og underordnede hierarkier i DAX-.

Deaktiver innlasting av Power Query-spørring

Power Query-spørringer som er ment å støtte dataintegrering med andre spørringer, bør ikke lastes inn i modellen. Hvis du vil unngå å laste inn disse spørringene til modellen, må du kontrollere at du deaktiverer spørringsbelastningen i disse forekomstene.

Deaktiver automatisk dato/klokkeslett

Power BI Desktop inneholder et alternativ kalt Automatisk dato/klokkeslett. Når den er aktivert, opprettes skjulte tabeller for automatisk dato/klokkeslett for hver datokolonne i modellen. Dette alternativet støtter rapportforfattere når du konfigurerer filtre, gruppering og neddrillingshandlinger for kalenderperioder. De skjulte tabellene er faktisk beregnede tabeller som øker størrelsen på modellen.

Hvis du vil ha mer informasjon, kan du se Veiledning for automatisk dato/klokkeslett i Power BI Desktop.

Bruk DirectQuery-lagringsmodus

DirectQuery-lagringsmodus er et alternativ til importlagringsmodus. DirectQuery-modelltabeller importerer ikke data. I stedet består de bare av metadata som definerer tabellstrukturen. Når tabellen blir spurt, brukes opprinnelige spørringer til å hente data fra den underliggende datakilden. Når du kombinerer import- og DirectQuery-lagringsmodustabeller i én enkelt modell, kalles den en sammensatt modell.

En effektiv teknikk for å redusere modellstørrelsen er å angi lagringsmodus for større faktatabeller til DirectQuery. Tenk på at denne utformingstilnærmingen ofte fungerer bra med Grupper etter, og oppsummer teknikk som ble introdusert tidligere. Summerte salgsdata kan for eksempel brukes til å oppnå sammendragsrapportering med høy ytelse. En ekstraheringsside kan vise detaljert salg for spesifikk (og smal) filterkontekst, som viser alle salgsordrer i kontekst. I dette eksemplet kan detaljvisningssiden inkludere visualobjekter basert på en DirectQuery-modelltabell for å hente salgsordredataene.

Det er imidlertid mange sikkerhets- og ytelsesimplikasjoner relatert til DirectQuery-lagringsmodus og sammensatte modeller. Hvis du vil ha mer informasjon, kan du se Bruke sammensatte modeller i Power BI Desktop.

Relatert innhold

Hvis du vil ha mer informasjon om denne artikkelen, kan du se følgende artikler:

• semantiske modellmoduser i Power BI-tjenesten
• Lagringsmodus i Power BI Desktop
• Spørsmål? Prøv å spørre Fabric Community
• Forslag? Bidra med ideer for å forbedre Fabric