Del via


Optimeringsvejledning til Power BI

Denne artikel indeholder en vejledning, der gør det muligt for udviklere og administratorer at producere og vedligeholde optimerede Power BI-løsninger. Du kan optimere din løsning på forskellige arkitektoniske lag. Lag omfatter:

  • Datakilderne
  • Datamodellen
  • Visualiseringer, herunder dashboards, Power BI-rapporter og sideinddelte Power BI-rapporter
  • Miljøet, herunder kapaciteter, datagateways og netværket

Optimering af datamodellen

Datamodellen understøtter hele visualiseringsoplevelsen. Datamodeller hostes enten i Power BI-økosystemet eller eksternt (ved hjælp af DirectQuery eller direkte forbindelse), og i Power BI kaldes de semantiske modeller. Det er vigtigt at forstå dine muligheder og vælge den relevante semantiske modeltype til din løsning. Der er tre semantiske tabellagringstilstande for semantiske modeller: Import, DirectQuery og Composite. Du kan få flere oplysninger under Semantiske modeller i Power BI-tjeneste- og Semantiske modeltilstande i Power BI-tjeneste.

Du kan finde en specifik vejledning til lagringstilstand for semantiske modeller i:

Optimering for rapportforfattere og modelforbrugere

Den semantiske model er grundlaget for al rapportering i Power BI. Forbrugere af den semantiske model kan oprette Power BI-rapporter i Power BI Desktop ved at oprette forbindelse til en publiceret semantisk model eller oprette forbindelse til data og oprette en lokal semantisk model. Den semantiske model kan også bruges til at oprette Power BI-rapporter i browseren, oprette Power BI-udforskninger, oprette sideinddelte rapporter, oprette DAX-forespørgsler og oprette rapporter i Excel med Analysér i Excel, oprette forbindelse til Power BI i Excel eller eksportere data fra en rapportvisualisering samt mange andre rapporteringsværktøjer. En semantisk modelforfatter kan hjælpe semantiske modelforbrugere med at forstå og bruge den semantiske model med, hvordan de bygger modellen.

  • Navne: Tabeller, kolonner og målinger i den semantiske model med beskrivende navne. 'Store Sales' som et tabelnavn er f.eks. mere intuitivt end 'Table1'.
  • Beskrivelser: Tabeller, kolonner og målinger i modellen kan føje beskrivelser til dem for at give flere detaljer, end der kan være i navnet. Forklar ikke kun, hvad de omfatter, men hvordan de skal bruges.
  • Skjul: Du kan skjule tabeller, kolonner og målinger i modellen for kun at vise, hvad du forventer, at de skal bruge i en rapport. Relationskolonner kan f.eks. være et id, der ikke er nødvendigt til rapportering, og som kan skjules, da det ikke forventes at blive brugt i en rapport, eller datakolonner, der har en måling til at aggregere kolonnen, kan skjules for at tilskynde til brug af målingen i stedet. Skjulte objekter kan altid vises senere af modelforbrugeren, så de vil stadig være tilgængelige, men hvis du skjuler dem, kan det give fokus.
  • Hierarkier: Du kan oprette hierarkier for at formidle hierarkiet på tværs af flere kolonner. Et kalenderhierarki kan f.eks. indeholde kolonnerne Year, Month, Day, og et produkthierarki kan indeholde kolonnerne Kategori, Underkategori og Produkt. Højreklik på en kolonne for at oprette et hierarki.
  • Målinger: Du kan bruge målinger til at aggregere datakolonner i den semantiske model for at sikre ensartethed på tværs af rapporter. Målinger kan variere fra SUM af en kolonne til et tilstandsindeks, der kombinerer flere sammenlægninger på en bestemt måde eller sammenligner sammenlægninger på tværs af tidsperioder, f.eks. det daglige gennemsnit i denne måned sammenlignet med det daglige gennemsnit for samme måned sidste år. Målinger kan også vises i Power BI-søgning og andre funktioner, f.eks . målepunkter og scorecards.
  • Formater: Du kan som standard angive, hvordan en kolonne eller måling skal vises i en visualisering. Værdier i visualiseringer kan tilpasses yderligere i visualiseringen. Formateringsindstillinger omfatter, hvis det har et komma på tusindtal, hvor mange decimaler, hvordan en dato vises osv. Du kan også anvende brugerdefinerede eller dynamiske formater.
  • Datakategori: Du kan angive en kolonnedatakategori, f.eks. hvis det er en URL-adresse til land eller websted.

Disse er almindelige funktioner i den semantiske Power BI-model, der kan udnyttes til at hjælpe rapportforfattere og modelforbrugere. Der er mange andre, f.eks . beregningsgrupper, feltparametre, what if-parametre og gruppering og gruppering af kolonner, som skal evalueres for at se, om de anvender dine specifikke rapporteringsbehov.

Optimering af visualiseringer

Power BI-visualiseringer kan være dashboards, Power BI-rapporter eller sideinddelte Power BI-rapporter. Hver har forskellige arkitekturer, og så hver har deres egen vejledning.

Dashboards

Det er vigtigt at forstå, at Power BI vedligeholder en cache til dine dashboardfelter – undtagen dynamiske rapportfelter og streamingfelter. Hvis din semantiske model gennemtvinger dynamisk sikkerhed på rækkeniveau, skal du sørge for at forstå konsekvenserne for ydeevnen, da felter cachelagres pr. bruger.

Når du fastgør dynamiske rapportfelter til et dashboard, betjenes de ikke fra forespørgselscachen. I stedet fungerer de som rapporter og opretter forespørgsler til v-kerner på farten.

Som navnet antyder, giver hentning af dataene fra cachen en bedre og mere ensartet ydeevne end at være afhængig af datakilden. En måde at udnytte denne funktionalitet på er ved at have dashboards som den første landingsside for dine brugere. Fastgør ofte anvendte og meget efterspurgte visualiseringer til dashboards. På denne måde bliver dashboards en værdifuld "første forsvarslinje", som leverer ensartet ydeevne med mindre belastning af kapaciteten. Brugerne kan stadig klikke sig igennem til en rapport for at analysere detaljer.

For semantiske DirectQuery- og liveforbindelsesmodeller opdateres cachen periodisk ved at forespørge datakilden. Det sker som standard hver time, selvom du kan konfigurere en anden hyppighed i indstillingerne for semantiske modeller. Hver cacheopdatering sender forespørgsler til den underliggende datakilde for at opdatere cachen. Antallet af forespørgsler, der genereres, afhænger af antallet af visualiseringer, der er fastgjort til dashboards, der er afhængige af datakilden. Bemærk, at hvis sikkerhed på rækkeniveau er aktiveret, oprettes der forespørgsler for hver enkelt sikkerhedskontekst. Overvej f.eks., at der er to forskellige roller, der kategoriserer dine brugere, og de har to forskellige visninger af dataene. Under opdatering af forespørgselscachen genererer Power BI to sæt forespørgsler.

Power BI-rapporter

Der er flere anbefalinger til optimering af Power BI-rapportdesign.

Bemærk

Når rapporter er baseret på en semantisk DirectQuery-model, kan du finde flere optimeringer af rapportdesign under Vejledning til DirectQuery-model i Power BI Desktop (Optimer rapportdesign)....

Anvend de mest restriktive filtre

Jo flere data en visualisering skal vise, jo langsommere er indlæsningen af visualiseringen. Selvom dette princip synes indlysende, er det nemt at glemme. Antag f.eks., at du har en stor semantisk model. Baseret på den semantiske model opretter du en rapport med en tabel. Slutbrugerne bruger udsnitsværktøjer på siden til at få adgang til de ønskede rækker – de er typisk kun interesseret i et par dusin rækker.

En almindelig fejl er at lade standardvisningen af tabellen være ufiltreret – dvs. alle 100 millioner+ rækker. Dataene for disse rækker indlæses i hukommelsen og dekomprimeres ved hver opdatering. Denne behandling skaber enorme behov for hukommelse. Løsningen: Brug filteret "Top N" til at reducere det maksimale antal elementer, der vises i tabellen. Du kan angive det maksimale element til større end det, brugerne har brug for, f.eks. 10.000. Resultatet er, at slutbrugerens oplevelse ikke ændres, men hukommelsesforbrug falder meget. Og det vigtigste er, at ydeevnen forbedres.

En lignende designtilgang til ovenstående anbefales for alle visualiseringer i din rapport. Spørg dig selv, om alle dataene i denne visualisering er nødvendige? Er der måder at filtrere mængden af data, der vises i visualiseringen, med minimal indvirkning på slutbrugeroplevelsen? Husk, at især tabeller kan være dyre.

Begræns visualiseringer på rapportsider

Ovenstående princip gælder ligeligt for antallet af visualiseringer, der føjes til en rapportside. Det anbefales på det kraftigste, at du begrænser antallet af visualiseringer på en bestemt rapportside til det, der er nødvendigt. Detaljeadgangssider og værktøjstip til rapportsider er fantastiske måder at give yderligere oplysninger på uden at blokere flere visualiseringer på siden.

Evaluer ydeevnen for brugerdefinerede visualiseringer

Sørg for at sætte hver brugerdefineret visualisering gennem sine tempoer for at sikre høj ydeevne. Dårligt optimerede Power BI-visualiseringer kan påvirke hele rapportens ydeevne negativt.

Sideinddelte power BI-rapporter

Design af sideinddelte rapporter i Power BI kan optimeres ved at anvende bedste praksisdesign på rapportens datahentning. Du kan finde flere oplysninger under Vejledning til datahentning for sideinddelte rapporter.

Sørg også for, at din kapacitet har tilstrækkelig hukommelse allokeret til arbejdsbelastningen for sideinddelte rapporter.

Optimering af miljøet

Du kan optimere Power BI-miljøet ved at konfigurere kapacitetsindstillinger, tilpasse størrelsen på datagateways og reducere netværksventetiden.

Kapacitetsindstillinger

Når du bruger kapaciteter – der er tilgængelige med P-SKU'er (Power BI Premium), Premium pr. bruger-licenser eller Power BI Embedded (A-SKU'er, A4-A6) – kan du administrere kapacitetsindstillinger. Du kan få flere oplysninger under Microsoft Fabric-kapacitetslicenser og Administration af Premium-kapaciteter.

Vigtigt

Denne artikel henviser til tider Power BI Premium eller dens kapacitetsabonnementer (P-SKU'er). Vær opmærksom på, at Microsoft i øjeblikket konsoliderer købsmuligheder og udfaser Power BI Premium pr. kapacitets-SKU'er. Nye og eksisterende kunder bør overveje at købe Fabric-kapacitetsabonnementer (F SKU'er) i stedet.

Du kan få flere oplysninger under Vigtige opdateringer, der kommer til Power BI Premium-licenser og Ofte stillede spørgsmål om Power BI Premium.

Størrelse på gateway

Der kræves en gateway, når Power BI skal have adgang til data, der ikke er tilgængelige direkte via internettet. Du kan installere datagatewayen i det lokale miljø på en server i det lokale miljø eller VM-hostet IaaS (Infrastructure as a-Service).

Hvis du vil forstå gatewayarbejdsbelastninger og tilpasningsanbefalinger, skal du se Størrelse på datagateway i det lokale miljø.

Netværksventetid

Netværksventetid kan påvirke rapportens ydeevne ved at øge den tid, det tager for anmodninger at nå Power BI-tjeneste, og for at svar kan leveres. Lejere i Power BI tildeles til et bestemt område.

Tip

Hvis du vil finde ud af, hvor din lejer er placeret, skal du se Hvor er min Power BI-lejer placeret?

Når brugere fra en lejer får adgang til Power BI-tjeneste, dirigeres deres anmodninger altid til dette område. Når anmodninger når Power BI-tjeneste, kan tjenesten derefter sende yderligere anmodninger, f.eks. til den underliggende datakilde eller en datagateway, som også er underlagt netværksventetid.

Værktøjer som Azure Speed Test giver en indikation af netværksventetid mellem klienten og Azure-området. For at minimere virkningen af netværksventetid skal du generelt bestræbe dig på at holde datakilder, gateways og din Power BI-kapacitet så tæt som muligt. De skal helst være placeret i det samme område. Hvis netværksventetid er et problem, kan du prøve at finde gateways og datakilder, der er tættere på din Power BI-kapacitet, ved at placere dem på virtuelle maskiner, der hostes i cloudmiljøet.

Overvågning af ydeevne

Du kan overvåge ydeevnen for at identificere flaskehalse. Langsomme forespørgsler – eller rapportvisualiseringer – bør være omdrejningspunktet for fortsat optimering. Overvågning kan udføres på designtidspunktet i Power BI Desktop eller på produktionsarbejdsbelastninger i Power BI Premium-kapaciteter. Du kan få mere at vide under Overvågning af rapportens ydeevne i Power BI.

Du kan få flere oplysninger om denne artikel i følgende ressourcer: