Del via

Optimaliseringsveiledning for Power BI

  • Artikkel

Denne artikkelen gir veiledning som gjør det mulig for utviklere og administratorer å produsere og vedlikeholde optimaliserte Power BI-løsninger. Du kan optimalisere løsningen på ulike arkitektoniske lag. Lag inkluderer:

  • Datakilden(e)
  • datamodellen
  • Visualiseringer, inkludert instrumentbord, Power BI-rapporter og sideformaterte Power BI-rapporter
  • Miljøet, inkludert kapasiteter, datagatewayer og nettverket

Optimalisering av datamodellen

Datamodellen støtter hele visualiseringsopplevelsen. Datamodeller driftes enten i Power BI-økosystemet eller eksternt (ved hjelp av DirectQuery eller Live Connection), og i Power BI kalles de semantiske modeller. Det er viktig å forstå alternativene dine og velge riktig semantisk modelltype for løsningen. Det finnes tre semantiske tabelllagringsmoduser for semantiske modeller: Import, DirectQuery og Composite. Hvis du vil ha mer informasjon, kan du se Semantic-modeller i Power Bi-tjeneste- og Semantic-modellmodusene i Power Bi-tjeneste.

Hvis du vil ha spesifikk veiledning for semantisk modelltabelllagringsmodus, kan du se:

Optimalisering for rapportforfattere og modellforbrukere

Den semantiske modellen er grunnlaget for all rapportering i Power BI. Forbrukere av den semantiske modellen kan opprette Power BI-rapporter i Power BI Desktop ved å koble til en publisert semantisk modell eller koble til data og opprette en lokal semantisk modell. Den semantiske modellen kan også brukes til å opprette Power BI-rapporter i nettleseren, opprette Power BI-utforskninger, opprette paginerte rapporter, opprette DAX-spørringer og opprette rapporter i Excel med Analyser i Excel, koble til Power BI i Excel eller eksportere data fra et visualobjekt for rapporter samt mange andre rapporteringsverktøy. En semantisk modellforfatter kan hjelpe semantiske modellforbrukere med å forstå og bruke den semantiske modellen med hvordan de bygger modellen.

  • Navn: Tabeller, kolonner og mål i den semantiske modellen med beskrivende navn. Butikksalg som tabellnavn er for eksempel mer intuitivt enn Tabell1.
  • Beskrivelser: Tabeller, kolonner og mål i modellen kan ha beskrivelser lagt til i dem for å gi flere detaljer enn det som passer inn i navnet. Forklar ikke bare hva de inkluderer, men hvordan de skal brukes.
  • Skjul: Du kan skjule tabeller, kolonner og mål i modellen for å vise bare det du forventer at de skal bruke i en rapport. Relasjonskolonner kan for eksempel være en ID som ikke er nødvendig for rapportering, og som kan skjules fordi den ikke forventes å brukes i en rapport, eller datakolonner som har et mål for å aggregere kolonnen, kan skjules for å oppmuntre til bruk av målet i stedet. Skjulte objekter kan alltids vises senere av modellforbrukeren, slik at de fremdeles vil være tilgjengelige, men skjuling kan gi fokus.
  • Hierarkier: Du kan opprette hierarkier for å formidle hierarkiet på tvers av flere kolonner. Et kalenderhierarki kan for eksempel inneholde kolonnene År, Måned, Dag og Et produkthierarki kan inneholde kategori-, underkategori- og produktkolonner. Høyreklikk på en kolonne for å opprette et hierarki.
  • Mål: Du kan bruke mål til å aggregere datakolonner i den semantiske modellen for å gi konsekvens på tvers av rapporter. Mål kan variere fra SUMMER i en kolonne, til en tilstandsindeks som kombinerer flere aggregasjoner på en bestemt måte eller sammenligner aggregasjoner på tvers av tidsperioder, for eksempel daglig gjennomsnitt denne måneden sammenlignet med det daglige gjennomsnittet i samme måned i fjor. Mål kan også vises i Power BI-søk og andre funksjoner, for eksempel måledata og målstyringer.
  • Formater: Du kan angi hvordan en kolonne eller et mål skal vises i et visualobjekt, som standard. Verdier i visualobjekter kan tilpasses ytterligere i visualobjektet. Formatalternativer inkluderer hvis det har tusenvis av komma, hvor mange desimaler, hvordan en dato vises osv. Du kan også bruke egendefinerte eller dynamiske formater.
  • Datakategori: Du kan angi en kolonnedatakategori, for eksempel hvis det er en nettadresse for land eller nettadresse.

Dette er vanlige funksjoner i semantisk Power BI-modell som kan utnyttes for å hjelpe rapportforfattere og modellforbrukere. Det finnes mange andre, for eksempel beregningsgrupper, feltparametere, hva om parametere og grupperings- og binningkolonner, som bør evalueres for å se om de bruker dine spesifikke rapporteringsbehov.

Optimalisere visualiseringer

Power BI-visualiseringer kan være instrumentbord, Power BI-rapporter eller Sideformaterte Power BI-rapporter. Hver har forskjellige arkitekturer, og så hver har sin egen veiledning.

Instrumentbord

Det er viktig å forstå at Power BI opprettholder en hurtigbuffer for instrumentbordflisene – bortsett fra dynamiske rapportfliser og strømming av fliser. Hvis den semantiske modellen håndhever dynamisk sikkerhet på radnivå (RLS), må du passe på å forstå ytelsesimplikasjoner ettersom fliser bufres per bruker.

Når du fester dynamiske rapportfliser til et instrumentbord, blir de ikke servert fra hurtigbufferen for spørringen. I stedet oppfører de seg som rapporter, og gjør spørringer til v-kjerner på farten.

Som navnet antyder, gir henting av data fra hurtigbufferen bedre og mer konsekvent ytelse enn å stole på datakilden. Én måte å dra nytte av denne funksjonaliteten på er å få instrumentbord til å være den første målsiden for brukerne. Fest ofte brukte og svært etterspurte visualobjekter til instrumentbordene. På denne måten blir instrumentbord en verdifull «første forsvarslinje», som gir konsekvent ytelse med mindre belastning på kapasiteten. Brukere kan fortsatt klikke gjennom til en rapport for å analysere detaljer.

For Semantiske modeller for DirectQuery og live-tilkobling oppdateres hurtigbufferen med jevne mellomrom ved å spørre datakilden. Som standard skjer det hver time, men du kan konfigurere en annen frekvens i innstillingene for semantisk modell. Hver oppdatering av hurtigbufferen sender spørringer til den underliggende datakilden for å oppdatere hurtigbufferen. Antall spørringer som genereres, avhenger av antall visualobjekter som er festet til instrumentbord som er avhengige av datakilden. Legg merke til at hvis sikkerhet på radnivå er aktivert, genereres spørringer for hver forskjellige sikkerhetskontekst. Tenk deg for eksempel at det finnes to forskjellige roller som kategoriserer brukerne, og de har to forskjellige visninger av dataene. Under oppdatering av hurtigbuffer for spørring genererer Power BI to sett med spørringer.

Power BI-rapporter

Det finnes flere anbefalinger for optimalisering av rapportutforminger for Power BI.

Merk

Når rapporter er basert på en Semantisk DirectQuery-modell, kan du se Veiledning for DirectQuery-modell i Power BI Desktop (optimalisere rapportutforminger).

Bruke de mest restriktive filtrene

Jo flere data et visualobjekt må vise, jo langsommere er det at visualobjektet lastes inn. Selv om dette prinsippet virker åpenbart, er det lett å glemme. La oss for eksempel si at du har en stor semantisk modell. Basert på den semantiske modellen bygger du en rapport med en tabell. Sluttbrukere bruker slicere på siden for å få tilgang til radene de ønsker – vanligvis er de bare interessert i noen få dusin rader.

En vanlig feil er å la standardvisningen av tabellen være ufiltrert , det vil si alle 100M + rader. Dataene for disse radene lastes inn i minnet og dekomprimeres ved hver oppdatering. Denne behandlingen skaper store krav til minne. Løsningen: Bruk «Topp N»-filteret til å redusere maksimalt antall elementer som tabellen viser. Du kan angi det maksimale elementet til større enn det brukerne trenger, for eksempel 10 000. Resultatet er at sluttbrukeropplevelsen ikke endres, men minnebruken synker sterkt. Og viktigst av alt er at ytelsen forbedres.

En lignende utformingstilnærming til ovennevnte foreslås for hvert visualobjekt i rapporten. Spør deg selv, er alle dataene i dette visualobjektet nødvendig? Finnes det måter å filtrere mengden data som vises i visualobjektet med minimal innvirkning på sluttbrukeropplevelsen? Husk at tabeller spesielt kan være dyre.

Begrense visualobjekter på rapportsider

Prinsippet ovenfor gjelder likt for antall visualobjekter som er lagt til på en rapportside. Det anbefales på det sterkeste at du begrenser antallet visualobjekter på en bestemt rapportside til bare det som er nødvendig. Ekstraheringssider og verktøytips for rapportsider er gode måter å gi flere detaljer uten å få flere visualobjekter på siden.

Evaluer ytelse for egendefinert visuell effekt

Pass på å sette hvert egendefinerte visualobjekt gjennom sine skritt for å sikre høy ytelse. Dårlig optimaliserte Power BI-visualobjekter kan påvirke ytelsen til hele rapporten negativt.

Sideformaterte rapporter i Power BI

Power BI paginerte rapportutforminger kan optimaliseres ved å bruke utforming av anbefalt fremgangsmåte på rapportens datahenting. Hvis du vil ha mer informasjon, kan du se Veiledning for datahenting for paginerte rapporter.

Sørg også for at kapasiteten har nok minne til arbeidsbelastningen for paginerte rapporter.

Optimalisere miljøet

Du kan optimalisere Power BI-miljøet ved å konfigurere kapasitetsinnstillinger, endre størrelse på datagatewayer og redusere nettverksventetid.

Kapasitetsinnstillinger

Når du bruker kapasiteter – tilgjengelig med Power BI Premium (P SKU-er), Premium-lisenser per bruker (PPU) eller Power BI Embedded (A SKU-er, A4-A6)– kan du administrere kapasitetsinnstillinger. Hvis du vil ha mer informasjon, kan du se Microsoft Fabric-kapasitetslisenser og Administrere Premium-kapasiteter.

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.

Gateway-skalering

En gateway kreves når Power BI må få tilgang til data som ikke er tilgjengelig direkte over Internett. Du kan installere den lokale datagatewayen på en lokal server eller IaaS (Vm-hosted Infrastructure-as-a-Service).

Hvis du vil forstå gateway-arbeidsbelastninger og skaleringsanbefalinger, kan du se Lokal datagateway-størrelse.

Nettverksventetid

Nettverksventetid kan påvirke rapportytelsen ved å øke tiden som kreves for forespørsler om å nå Power Bi-tjeneste, og for svar som skal leveres. Leiere i Power BI er tilordnet til et bestemt område.

Tips

Hvis du vil finne ut hvor leieren er plassert, kan du se Hvor er Power BI-leieren min plassert?

Når brukere fra en leier får tilgang til Power Bi-tjeneste, rutes alltid forespørslene deres til dette området. Når forespørsler kommer til Power Bi-tjeneste, kan tjenesten deretter sende flere forespørsler– for eksempel til den underliggende datakilden eller en datagateway – som også er underlagt nettverksventetid.

Verktøy som Azure Speed Test gir en indikasjon på nettverksventetid mellom klienten og Azure-området. Generelt sett, for å minimere virkningen av nettverksventetid, bør du arbeide for å holde datakilder, gatewayer og Power BI-kapasiteten så nær som mulig. Fortrinnsvis befinner de seg innenfor samme område. Hvis nettverksventetid er et problem, kan du prøve å finne gatewayer og datakilder nærmere Power BI-kapasiteten ved å plassere dem i skybaserte virtuelle maskiner.

Overvåkingsytelse

Du kan overvåke ytelsen for å identifisere flaskehalser. Trege spørringer – eller visualobjekter for rapporter – bør være et fokuspunkt for fortsatt optimalisering. Overvåking kan gjøres på utformingstidspunktet i Power BI Desktop, eller på produksjonsarbeidsbelastninger i Power BI Premium-kapasiteter. Hvis du vil ha mer informasjon, kan du se Overvåke rapportytelse i Power BI.

Relatert innhold

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