Power BI-bruksscenarioer: Avansert administrasjon av datamodell

Merk

Denne artikkelen er en del av planleggingsserien for power BI-implementering av artikler. Denne serien fokuserer hovedsakelig på Power BI-arbeidsbelastningen i Microsoft Fabric. Hvis du vil ha en innføring i serien, kan du se Planlegging av Power BI-implementering.

Dette bruksscenarioet fokuserer på avansert administrasjon av datamodell, som er når en Power BI-innholdsoppretter er avhengig av et tredjepartsverktøy for å utvikle, administrere eller optimalisere datamodeller. Noen tredjepartsverktøy er eksterne verktøy, som Power BI Desktop støtter direkte. Du kan også administrere en publisert datamodell (semantisk modell – tidligere kalt et datasett) ved å kommunisere direkte med XMLA-endepunktet i Power Bi-tjeneste.

Datamodeller driftes enten i Power Bi-tjeneste, Azure Analysis Services (AAS) eller SQL Server Analysis Services (SSAS). Dette bruksscenariet fokuserer på å bruke XMLA-endepunktet i Power Bi-tjeneste.

Tips

Mange refererer til tredjepartsverktøy som eksterne verktøy. Det finnes imidlertid forskjeller i hvordan ulike verktøy kan brukes. Koble til til en lokal datamodell i Power BI Desktop er den mest litterale tolkningen av begrepet eksternt verktøy. Dette avanserte bruksscenarioet for datamodellbehandling fokuserer på å koble til en ekstern datamodell (en semantisk modell som driftes i Power Bi-tjeneste) ved hjelp av XMLA-endepunktet. Flere detaljer om de ulike måtene å bruke tredjepartsverktøy på, beskrives senere i denne artikkelen.

Du kan oppnå tilkobling til en datamodell ved hjelp av XML-protokollen (XMLA). XMLA-protokollen er en bransjestandardprotokoll som støttes av mer enn 25 leverandører, inkludert Microsoft. Alle verktøy, inkludert tredjepartsverktøy, som samsvarer med XMLA-protokollen, bruker Microsoft-klientbibliotekertil å lese og/eller skrive data til en datamodell. Koble til ivitet oppnås med et XMLA-endepunkt, som er en API som eksponeres av en datamodell som utvider utviklings- og administrasjonsfunksjonene som er tilgjengelige for semantiske modellopprettere.

Merk

Dette avanserte bruksscenarioet for datamodellbehandling er ett av scenarioene for innholdsbehandling og distribusjon . Hvis du vil ha en fullstendig liste over selvbetjente bruksscenarioer, kan du se Power BI-bruksscenarioer.

For kortfattethet dekkes ikke noen aspekter som er beskrevet i emnet innholdssamarbeid og leveringsscenarioer i denne artikkelen. Hvis du vil ha fullstendig dekning, kan du lese disse artiklene først.

Scenariodiagram

Fokuset for dette avanserte bruksscenarioet for datamodellbehandling er å bruke Tabellredigering til å administrere datamodellen. Du kan publisere en datamodell til Power Bi-tjeneste ved hjelp av XMLA-endepunktet, som er tilgjengelig med Power BI Premium.

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.

Tips

Vi anbefaler at du ser gjennom selvbetjent bruksscenario for innholdspublisering hvis du ikke er kjent med det. Det avanserte administrasjonsscenarioet for datamodeller bygger på dette scenarioet.

Merk

Noen ganger brukes begrepene semantisk modell og datamodell om hverandre. Vanligvis, fra et Power Bi-tjeneste perspektiv, kalles det semantisk modell. Fra et utviklingsperspektiv kalles det en datamodell (eller modell for kort). I denne artikkelen har begge begrepene samme betydning. På samme måte har en semantisk modelloppretter og en datamodellerer samme betydning.

Diagrammet nedenfor viser en oversikt på høyt nivå over de vanligste brukerhandlingene og verktøyene som kan hjelpe deg med å utvikle, administrere eller optimalisere datamodeller.

Diagrammet viser avansert administrasjon av datamodell, som handler om å styrke opprettere med avanserte modellerings- og publiseringsfunksjoner. Elementer i diagrammet er beskrevet i tabellen nedenfor.

Tips

Vi oppfordrer deg til å laste ned scenariodiagrammet hvis du vil bygge det inn i presentasjonen, dokumentasjonen eller blogginnlegget, eller skrive det ut som en veggplakat. Fordi det er et SVG-bilde (Scalable Vector Graphics), kan du skalere det opp eller ned uten tap av kvalitet.

Scenariodiagrammet viser følgende brukerhandlinger, verktøy og funksjoner:

Vare Beskrivelse
Element 1. Modellopprettere utvikler datamodeller ved hjelp av Tabellredigering. Det er vanlig at det første utformingsarbeidet (for eksempel Power Query-arbeid) gjøres i Power BI Desktop før du bytter til Tabellredigering (ikke avbildet i scenariodiagrammet).
Element 2. Datamodellen kobler til data fra én eller flere datakilder.
Element 3. Noen datakilder kan kreve en lokal datagateway eller VNet-gateway for dataoppdatering, for eksempel de som befinner seg i et privat organisasjonsnettverk.
Element 4. Datamodellutvikling utføres i Tabellredigering. Redigering av Power Query-skript (M) støttes. Modellopprettere kan bruke C#-skript for å akselerere utviklingen.
Element 5. Når de er klare, publiserer semantiske modellopprettere datamodellen fra Tabellredigering til Power Bi-tjeneste ved hjelp av XMLA-endepunktet for målarbeidsområdet.
Element 6. Datamodellen publiseres til et arbeidsområde som er dedikert til lagring og sikring av delte semantiske modeller. Tilgang til arbeidsområdet ved hjelp av XMLA-endepunktet er bare mulig når lisensmodusen for arbeidsområdet er satt til Fabric-kapasitet, Premium-kapasitet, Premium per bruker eller Embedded.
Element 7. Rapportopprettere oppretter rapporter ved hjelp av en live-tilkobling til den delte semantiske modellen.
Element 8. Rapportopprettere utvikler rapporter i Power BI Desktop. Bortsett fra å skille rapporter fra semantiske modeller med hensikt, følger innholdsopprettere den vanlige prosessen for oppretting av rapporter.
Element 9. Når de er klare, publiserer rapportopprettere Power BI Desktop-filen (PBIX) eller Power BI-prosjektfilen (PBIP) til Power Bi-tjeneste.
Element 10. Rapporter publiseres til et arbeidsområde som er dedikert til lagring og sikring av rapporter og instrumentbord.
Element 11. Publiserte rapporter forblir koblet til den delte semantiske modellen som er lagret i et annet arbeidsområde. Eventuelle endringer i den delte semantiske modellen påvirker alle avhengige rapporter.
Element 12. Tredjepartsverktøy kan bruke XMLA-endepunktet til å spørre den delte semantiske modellen. Andre XMLA-kompatible verktøy, for eksempel DAX Studio, Semantic Link fra Fabric-notatblokker eller Windows PowerShell, kan brukes til å spørre eller oppdatere den delte semantiske modellen. Power BI Desktop, Excel og Report Builder kan også koble til ved hjelp av XMLA-endepunktet (ikke avbildet i scenariodiagrammet).
Element 13. Andre Microsoft- og tredjepartsverktøy kan bruke XMLA-endepunktet til å administrere semantisk modell og gi administrasjon av programlivssyklus. Hvis du vil ha mer informasjon, kan du se XMLA-endepunktbaserte klientverktøy.
Element 14. Fabric-administratorer administrerer tenantinnstillingen for å aktivere bruken av XMLA-endepunktet. Administratoren må aktivere XMLA-endepunktet for stoffkapasiteter, Premium-kapasiteter og Premium per bruker-innstillinger.
Element 15. Fabric-administratorer fører tilsyn med og overvåker aktiviteten i Fabric-portalen.

Viktige punkter

Nedenfor finner du noen viktige punkter for å fremheve det avanserte administrasjonsscenarioet for datamodeller.

Tredjepartsprogrammer og -verktøy

Enterprise BI-team bruker ofte klientverktøy, for eksempel Tabellredigering (avbildet i scenariodiagrammet og beskrevet i neste emne), for å hjelpe dem med å administrere sentraliserte semantiske modeller. Alle semantiske modellopprettere som ønsker å arbeide med avanserte modelleringsfunksjoner, kan imidlertid dra nytte av metodene som er beskrevet i dette bruksscenariet.

Det finnes flere måter å bruke tredjepartsprogrammer på:

  • Koble til til en ekstern datamodell ved hjelp av XMLA-endepunktet: Noen tredjepartsverktøy kan koble direkte til en ekstern datamodell i Power Bi-tjeneste (eller Analysis Services). Når du er koblet til XMLA-endepunktet, støttes alle TOM-operasjoner (Tabular Object Model). Denne fremgangsmåten er hovedfokus for dette bruksscenarioet.
  • Koble til til en lokal datamodell i Power BI Desktop: Noen tredjepartsverktøy kan koble til en lokal datamodell som er åpen i Power BI Desktop (ikke avbildet i scenariodiagrammet). Det finnes imidlertid noen begrensninger, og ikke alle eksterne verktøyfunksjonaliteter støttes offisielt.
  • Koble til til en malfil i Power BI Desktop: Noen tredjepartsverktøy distribuerer funksjonaliteten på en enkel måte ved hjelp av en Power BI Desktop-malfil (PBIT) (ikke avbildet i scenariodiagrammet).

Tabellredigering

Tabellredigering er avbildet i scenariodiagrammet. Det er et tredjepartsverktøy som har oppnådd omfattende innføring av Power BI-fellesskapet. Noen fordeler med å administrere tabelldatamodeller med tabellredigering inkluderer:

  • Konfigurasjon av datamodellfunksjoner som ikke støttes i Power BI Desktop: Tabellredigering gir et grensesnitt for å konfigurere sikkerhet på objektnivå (OLS), beregningsgrupper, perspektiver, oversettelser og partisjoner.
  • Støtte for samtidig modellutvikling: Utviklingsverktøy for Microsoft-datamodell, for eksempel Visual Studio med Analysis Services-prosjekter, lagrer hele datamodelldefinisjonen i en Model.bim-fil . Denne enkeltfilen kan gjøre det vanskelig for et team av utviklere å samarbeide på én enkelt datamodell. Tabellredigering har en funksjon kalt Mappe-serialisering. Mappeserieisering dekonstruerer Model.bim-filen til separate objektspesifikke filer i en organisert mappestruktur. Ulike datamodellerere kan deretter arbeide med forskjellige filer med mindre risiko for å overskrive hverandres innsats.
  • Integrasjon med kildekontroll: Mappeserieisering gjør det enkelt for kildekontrollsystemet å oppdage endringer i datamodellen, noe som gjør det enklere å gjøre kildeflettinger og konfliktløsninger.
  • Forbedret datamodellkvalitet og -utforming: Tabellredigering integreres med Analyse av anbefalte fremgangsmåter (BPA). BPA hjelper datamodellerere med et sett med tilpassbare regler som kan forbedre kvaliteten, konsistensen og ytelsen til datamodeller. Du kan laste ned et sett med regler for anbefalte fremgangsmåter (levert av Microsoft) fra GitHub.
  • Økt produktivitet når du utvikler datamodeller: Tabular Editor-grensesnittet gjør det godt egnet for å utføre satsvise redigeringer, feilsøking og visning av datamodellavhengigheter. Tabellredigering er forskjellig fra Power BI Desktop ved at det fungerer i frakoblet modus. Du kan gjøre endringer i datamodell i frakoblet modus og utføre dem som en gruppe med redigeringer. Arbeid på denne måten gir raskere utvikling og validering, spesielt for erfarne datamodellerere. Det er også mulig å opprette C#-skript og lagre dem som makroer. Disse skriptene kan hjelpe deg med å forbedre effektiviteten ved å administrere og synkronisere flere datamodeller.

XMLA-endepunkt

XMLA-endepunktet bruker XMLA-protokollen til å vise alle funksjonene i en tabelldatamodell, inkludert noen datamodelleringsoperasjoner som ikke støttes av Power BI Desktop. Du kan bruke TOM-API-en til å gjøre programmatiske endringer i en datamodell.

XMLA-endepunktet gir også tilkobling. Du kan bare koble til en semantisk modell når arbeidsområdet som har lisensmodusen satt til Premium per bruker, Premium per kapasitet eller Embedded. Når en tilkobling er opprettet, kan et XMLA-kompatibelt verktøy fungere på datamodellen på to måter:

  • Skrive data og metadata: Lese/skrive bruk av XMLA-endepunktet tillater:
    • Datamodelleringsfunksjoner som ikke støttes av Power BI Desktop, for eksempel sikkerhet på objektnivå (OLS), beregningsgrupper, perspektiver, oversettelser og partisjonsbehandling.
    • Mer komplekse distribusjoner. En delvis distribusjon eller bare metadatadistribusjon som publiserer bare ett enkelt nytt mål.
    • Asynkron semantisk modelloppdatering. Du kan for eksempel oppdatere én enkelt tabell eller partisjon.
  • Lesedata og metadata: Skrivebeskyttet bruk av XMLA-endepunktet tillater:
    • Overvåking, feilsøking og sporing av semantiske modeller og spørringer.
    • Tillater tredjeparts datarapporteringsverktøy å visualisere data hentet fra en delt semantisk modell. Denne teknikken er en flott måte å utvide fordelene og investeringene i administrert selvbetjent BI på.

Advarsel!

Når du endrer eller publiserer en semantisk modell ved hjelp av XMLA-endepunktet, kan du ikke lenger laste den ned fra Power Bi-tjeneste som en Power BI Desktop-fil.

XMLA-innstillinger per kapasitet

Hver Power BI Premium-kapasitet og Power BI Embedded-kapasitet har en innstilling for å kontrollere om XMLA-endepunktet er skrivebeskyttet, skrivebeskyttet eller av. Denne innstillingen er også tilgjengelig for alle Premium per bruker-arbeidsområder i Power BI-leieren. Lese-/skrive-XMLA-tilgang må være aktivert for hver kapasitet som inneholder semantiske modeller som du vil administrere med et annet verktøy enn Power BI Desktop.

Tips

Innstillingen for XMLA-endepunkt (skrivebeskyttet, skrivebeskyttet eller av) gjelder for alle arbeidsområder og semantiske modeller som er tilordnet en bestemt kapasitet. Du kan konfigurere flere kapasiteter til å desentralisere og/eller tilpasse hvordan innhold administreres for hver kapasitet.

Innstilling for XMLA-leier

I tillegg til XMLA-endepunktinnstillingene må en Power BI-administrator bruke leierinnstillingene for å tillate XMLA-endepunkter og Analyser i Excel med lokale semantiske modeller. Når det er aktivert, kan du tillate at alle brukere, eller bestemte sikkerhetsgrupper, kan bruke XMLA-endepunktfunksjonalitet.

Merk

Alle standard sikkerhets- og databeskyttelsesfunksjoner gjelder fortsatt for å angi hvilke brukere som kan vise og/eller redigere innhold.

Tredjepartsverktøy

Power BI Desktop kan håndtere ende-til-ende-behovene for de fleste selvbetjente innholdsopprettere. Tredjepartsverktøy tilbyr imidlertid andre bedriftsfunksjoner og -funksjoner. Av denne grunn har tredjepartsverktøy, for eksempel Tabellredigering, blitt utbredt i Power BI-fellesskapet, spesielt for avanserte innholdsopprettere, utviklere og IT-eksperter.

Tips

Dette blogginnlegget beskriver hvordan tredjepartsverktøy gjør det mulig for Power BI-produktteamet å revurdere utviklingsprioriteringer, øke rekkevidden til Power BI-plattformen og tilfredsstille mer avanserte og varierte forespørsler fra brukerfellesskapet.

Merk

Noen tredjepartsverktøy krever en betalt lisens, for eksempel Tabellredigering 3. Andre fellesskapsverktøy er gratis og åpen kilde (for eksempel Tabellredigering 2, DAX Studio og ALM Toolkit). Vi anbefaler at du nøye evaluerer funksjonene i hver verktøy-, kostnads- og støttemodell, slik at du kan støtte fellesskapet av innholdsopprettere på en tilstrekkelig måte.

Administrasjon av datamodell

Hovedfokuset for dette bruksscenariet er på innholdsoppretteren som bruker Tabellredigering til å administrere en datamodell. Du kan velge å bruke et verktøy, for eksempel SQL Server Management Studio (SSMS), for å få sjeldne krav til administrasjon av datamodeller, som sporadisk partisjonsbehandling. Det er også mulig for en .NET-utvikler å opprette og administrere Semantiske Power BI-modeller ved hjelp av TOM API-en.

Tips

Når du bruker XMLA-endepunktet for administrasjon av datamodell, anbefaler vi at du aktiverer den store innstillingen for semantisk modelllagringsformat . Når det er aktivert, kan det store semantiske lagringsformatet for semantisk modell forbedre ytelsen for XMLA-skriveoperasjon.

Fordeling av datamodell og rapporter

For at dette bruksscenariet skal lykkes, bør du skille rapporter fra datamodellen. Denne fremgangsmåten resulterer i administrasjon av separate Power BI Desktop-filer som beskrevet i det administrerte selvbetjente BI-bruksscenarioet . Selv om den samme personen er ansvarlig for all utvikling, er separasjon av semantiske modeller og rapporter viktig fordi Tabellredigering ikke har en bevissthet om rapportinnhold.

Konfigurasjon av gateway

Vanligvis kreves det en datagateway når du får tilgang til datakilder som befinner seg i det private organisasjonsnettverket eller et virtuelt nettverk. Den lokale datagatewayen blir relevant når en datamodell publiseres til Power Bi-tjeneste. De to formålene med en gateway er å oppdatere importerte data, eller vise en rapport som spør etter en live-tilkobling eller DirectQuery-semantisk modell (ikke avbildet i scenariodiagrammet).

Merk

En sentralisert datagateway i standardmodus anbefales på det sterkeste over gatewayer i personlig modus. I standardmodus støtter datagatewayen live-tilkobling og DirectQuery-operasjoner (i tillegg til planlagte dataoppdateringsoperasjoner).

Hvis du vil ha mer informasjon, kan du se Lokal datagateway (standardmodus).

Systemtilsyn

Aktivitetsloggen registrerer brukeraktiviteter som forekommer i Power Bi-tjeneste. Power BI-administratorer kan bruke aktivitetsloggdataene som samles inn til å utføre overvåking for å hjelpe dem med å forstå aktiviteter som kobles til via XMLA-endepunkter.

Hvis du vil ha andre nyttige scenarier for å hjelpe deg med implementeringsbeslutninger i Power BI, kan du se artikkelen om bruksscenarioer i Power BI.