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 Koble til ion), og i Power BI kalles de semantiske modeller – tidligere kalt datasett. Det er viktig å forstå alternativene dine og velge riktig semantisk modelltype for løsningen. Det finnes tre semantiske modellmoduser: 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 modellmodus, kan du se:

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: