Del via

Datareduksjonsteknikker for importmodellering

  • Artikkel

Denne artikkelen er rettet mot Power BI Desktop-datamodellerere som utvikler importmodeller. Den beskriver ulike teknikker for å redusere data som lastes inn i importmodeller.

Importmodeller lastes inn med data som er komprimert og optimalisert og deretter lagret på disk av VertiPaq-lagringsmotoren. Når kildedata lastes inn i minnet, er det mulig å se 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, er det viktig at du forsøker å minimere dataene som skal lastes 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 lese Artikkelen om Power BI Premium-støtte for store semantiske modeller .
  • Mindre modellstørrelser reduserer striden for kapasitetsressurser, spesielt minne. Det gjør at flere modeller kan lastes inn samtidig i lengre perioder, noe som resulterer i lavere utkastelsesfrekvenser.
  • Mindre modeller oppnår raskere dataoppdatering, noe som resulterer i lavere ventetidsrapportering, høyere semantisk modelloppdateringsgjennomstrømming og mindre press på kildesystem og kapasitetsressurser.
  • Mindre antall tabellrader kan resultere i raskere beregningsevalueringer, noe som kan gi bedre generell spørringsytelse.

Viktig

Til tider refererer denne artikkelen til Power BI Premium eller dets kapasitetsabonnementer (P SKU-er). Vær oppmerksom på at Microsoft for øyeblikket konsoliderer kjøpsalternativer og trekker tilbake Power BI Premium per kapasitet sKU-er. Nye og eksisterende kunder bør vurdere å kjøpe Fabric-kapasitetsabonnementer (F SKU-er) i stedet.

Hvis du vil ha mer informasjon, kan du se Viktige oppdateringer som kommer til Power BI Premium-lisensiering og vanlige spørsmål om Power BI Premium.

Det er åtte ulike teknikker for datareduksjon som dekkes i denne artikkelen. Disse teknikkene inkluderer:

Fjern unødvendige kolonner

Modelltabellkolonner tjener to hovedformål:

  • Rapportering, for å oppnå rapportutforminger som passer filter, gruppe og oppsummering av modelldata
  • Modellstruktur, ved å støtte modellrelasjoner, modellberegninger, sikkerhetsroller og til og med datafargeformatering

Kolonner som ikke tjener disse formålene, kan sannsynligvis fjernes. Fjerning av kolonner kalles loddrett filtrering.

Vi anbefaler at du utformer modeller med nøyaktig riktig antall kolonner basert på de kjente rapporteringskravene. 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

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

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 vil resultere i mange mindre modeller, og den kan også eliminere behovet for å definere sikkerhet på radnivå (men vil kreve å gi bestemte semantiske modelltillatelser i Power Bi-tjeneste, og opprette «dupliserte» rapporter som kobler til hver semantiske modell). Du kan dra nytte av bruken av Power Query-parametere og Power BI-malfiler for å forenkle administrasjon og publisering. Hvis du vil ha mer informasjon, kan du lese blogginnlegget Deep Dive i spørringsparametere og Power BI-maler

Filtrering etter tid innebærer å begrense mengden datalogg som lastes inn i faktatypetabeller (og begrense datoradene som lastes inn i modelldatotabellene). Vi foreslår at du ikke laster inn all tilgjengelig logg automatisk, med mindre det er et kjent rapporteringskrav. Det er nyttig å forstå at tidsbaserte Power Query-filtre kan parameteres, og til og med angis for å bruke relative tidsperioder (i forhold til oppdateringsdatoen, for eksempel de siste fem årene). Husk også at retrospektive endringer i tidsfiltre ikke vil bryte rapporter. det vil bare resultere i mindre (eller mer) datalogg tilgjengelig i rapporter.

Grupper etter og oppsummer

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

En faktatabell for kildesalg lagrer for eksempel én rad per ordrelinje. Betydelig datareduksjon kan oppnås ved å oppsummere alle salgsdata, gruppere etter dato, kunde og produkt. Vurder da at en enda mer betydelig datareduksjon kan oppnås ved å gruppere etter dato på månedsnivå. Det kan oppnå en mulig reduksjon på 99 % i modellstørrelse, men rapportering på dagnivå – eller individuelt ordrenivå – er ikke lenger mulig. Det å bestemme seg for å oppsummere faktatypedata innebærer alltid avveininger. Avveining kan reduseres av en blandet modellutforming, og dette alternativet er beskrevet i teknikken Bytt til blandet modus .

Optimaliser kolonnedatatyper

VertiPaq-lagringsmotoren bruker separate datastrukturer for hver kolonne. Ved utforming oppnår disse datastrukturene de høyeste optimaliseringene for numeriske kolonnedata, som bruker verdikoding. Tekst og andre ikke-numeriske data bruker imidlertid hash-koding. Det krever at lagringsmotoren tilordner en numerisk identifikator til hver unike tekstverdi i kolonnen. Det er den numeriske identifikatoren, som deretter lagres 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»). Prefikset kan fjernes, og ordrenummerverdien konverteres til heltall. For store tabeller kan det føre til betydelig datareduksjon, spesielt når kolonnen inneholder unike eller høye kardinalitetsverdier.

I dette eksemplet anbefaler vi at du angir egenskapen Standard oppsummering for kolonnen til «Ikke oppsummer». Det bidrar til å minimere den upassende oppsummeringen av ordrenummerverdiene.

Innstillinger for egendefinerte kolonner

VertiPaq-lagringsmotoren lagrer modellberegnede kolonner (definert i DAX) akkurat som vanlige kolonner med Power Query-kilder. Datastrukturene lagres imidlertid litt annerledes, og oppnår vanligvis mindre effektiv komprimering. De bygges også når alle Power Query-tabeller er lastet 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).

Preferanse bør være å opprette 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 kan være tilfelle 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å-funksjonene for overordnede-underordnede-hierarkier i DAX-artikkelen .

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 spørringen til modellen, må du passe på at du deaktiverer spørringsbelastning i disse forekomstene.

Skjermbilde av Power Query som viser alternativet Aktiver innlasting.

Deaktiver automatisk dato/klokkeslett

Power BI Desktop inneholder et alternativ kalt Automatisk dato/klokkeslett. Når den er aktivert, oppretter den en skjult automatisk dato/klokkeslett-tabell for datokolonner for å støtte 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 veiledning om hvordan du bruker dette alternativet, kan du se autoveiledningen for dato/klokkeslett i Power BI Desktop-artikkelen .

Bytte til blandet modus

I Power BI Desktop produserer en blandet modusutforming en sammensatt modell. I hovedsak kan du bestemme lagringsmodus for hver tabell. Derfor kan hver tabell ha egenskapen Lagringsmodus angitt som Import eller DirectQuery (Dobbel er et annet alternativ).

En effektiv metode for å redusere modellstørrelsen er å angi egenskapen Lagringsmodus for større faktatabell tabeller til DirectQuery. Vurder at denne utformingstilnærmingen kan fungere godt sammen med group by og oppsummere teknikken som ble innført 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 vil detaljvisningssiden inkludere visualobjekter basert på en DirectQuery-tabell for å hente salgsordredataene.

Det er imidlertid mange sikkerhets- og ytelsesimplikasjoner relatert til sammensatte modeller. Hvis du vil ha mer informasjon, kan du lese artikkelen Bruk sammensatte modeller i Power BI Desktop .

Relatert innhold

Hvis du vil ha mer informasjon om utforming av Importmodell for Power BI, kan du se følgende artikler: