Användningsscenarier för Power BI: Avancerad datamodellhantering

Kommentar

Den här artikeln är en del av planeringsserien för Power BI-implementering. Den här serien fokuserar främst på Power BI-arbetsbelastningen i Microsoft Fabric. En introduktion till serien finns i Implementeringsplanering för Power BI.

Det här användningsscenariot fokuserar på avancerad datamodellhantering, vilket är när en Power BI-innehållsskapare förlitar sig på ett verktyg från tredje part för att utveckla, hantera eller optimera datamodeller. Vissa verktyg från tredje part är externa verktyg som Power BI Desktop har direkt stöd för. Du kan också hantera en publicerad datamodell (semantisk modell, tidigare känd som en datamängd) genom att kommunicera direkt med XMLA-slutpunkten i Power BI-tjänst.

Datamodeller finns i antingen Power BI-tjänst, Azure Analysis Services (AAS) eller SQL Server Analysis Services (SSAS). Det här användningsscenariot fokuserar på att använda XMLA-slutpunkten i Power BI-tjänst.

Dricks

Många kallar verktyg från tredje part för externa verktyg. Det finns dock skillnader i hur olika verktyg kan användas. Anslut till en lokal datamodell i Power BI Desktop är den mest bokstavliga tolkningen av termen externt verktyg. Det här scenariot för hantering av avancerade datamodeller fokuserar på att ansluta till en fjärrdatamodell (en semantisk modell som finns i Power BI-tjänst) med hjälp av XMLA-slutpunkten. Mer information om olika sätt att använda verktyg från tredje part beskrivs senare i den här artikeln.

Du kan uppnå anslutning till en datamodell med hjälp av XMLA-protokollet (XML for Analysis). XMLA-protokollet är ett branschstandardprotokoll som stöds av fler än 25 leverantörer, inklusive Microsoft. Alla verktyg, inklusive verktyg från tredje part, som är kompatibla med XMLA-protokollet använder Microsofts klientbibliotek för att läsa och/eller skriva data till en datamodell. Anslut ivity uppnås med en XMLA-slutpunkt, som är ett API som exponeras av en datamodell som breddar de utvecklings- och hanteringsfunktioner som är tillgängliga för semantiska modellskapare.

Kommentar

Det här scenariot för hantering av avancerade datamodeller är ett av scenarierna för innehållshantering och distribution . En fullständig lista över användningsscenarier med självbetjäning finns i Användningsscenarier för Power BI.

I korthet beskrivs inte vissa aspekter som beskrivs i avsnittet om innehållssamarbete och leveransscenarier i den här artikeln. För fullständig täckning, läs dessa artiklar först.

Scenariodiagram

Fokus för det här scenariot för hantering av avancerade datamodeller ligger på att använda Tabellredigeraren för att hantera datamodellen. Du kan publicera en datamodell till Power BI-tjänst med hjälp av XMLA-slutpunkten, som är tillgänglig med Power BI Premium.

Viktigt!

Ibland refererar den här artikeln till Power BI Premium eller dess kapacitetsprenumerationer (P SKU:er). Tänk på att Microsoft för närvarande konsoliderar köpalternativ och drar tillbaka Power BI Premium per kapacitets-SKU:er. Nya och befintliga kunder bör överväga att köpa kapacitetsprenumerationer för Infrastrukturresurser (F SKU:er) i stället.

Mer information finns i Viktig uppdatering som kommer till Power BI Premium-licensiering och Vanliga frågor och svar om Power BI Premium.

Dricks

Vi rekommenderar att du granskar användningsscenariot för självbetjäningsinnehållspublicering om du inte är bekant med det. Scenariot för hantering av avancerade datamodeller bygger på det scenariot.

Kommentar

Ibland används termerna semantisk modell och datamodell på ett utbytbart sätt. I allmänhet kallas det för semantisk modell ur ett Power BI-tjänst perspektiv. Ur ett utvecklingsperspektiv kallas det för en datamodell (eller modell för kort). I den här artikeln har båda termerna samma betydelse. På samma sätt har en semantisk modellskapare och en datamodellerare samma betydelse.

Följande diagram visar en översikt på hög nivå över de vanligaste användaråtgärderna och verktygen som kan hjälpa dig att utveckla, hantera eller optimera datamodeller.

Dricks

Vi rekommenderar att du laddar ned scenariodiagrammet om du vill bädda in det i presentationen, dokumentationen eller blogginlägget eller skriva ut det som en väggaffisch. Eftersom det är en SVG-bild (Scalable Vector Graphics) kan du skala upp eller ned den utan någon kvalitetsförlust.

Scenariodiagrammet visar följande användaråtgärder, verktyg och funktioner:

Artikel	Beskrivning
	Modellskapare utvecklar datamodeller med hjälp av Tabellredigeraren. Det är vanligt att det första designarbetet (till exempel Power Query-arbete) utförs i Power BI Desktop innan du byter till Tabellredigeraren (visas inte i scenariodiagrammet).
	Datamodellen ansluter till data från en eller flera datakällor.
	Vissa datakällor kan kräva en lokal datagateway eller VNet-gateway för datauppdatering, som de som finns i ett privat organisationsnätverk.
	Datamodellutveckling görs i Tabellredigeraren. Redigering av Power Query-skript (M) stöds. Modellskapare kan använda C#-skript för att påskynda utvecklingen.
	När de är klara publicerar semantiska modellskapare datamodellen från Tabellredigeraren till Power BI-tjänst med hjälp av XMLA-slutpunkten för målarbetsytan.
	Datamodellen publiceras till en arbetsyta som är dedikerad till att lagra och skydda delade semantiska modeller. Åtkomst till arbetsytan med hjälp av XMLA-slutpunkten är endast möjlig när arbetsytans licensläge är inställt på Infrastrukturkapacitet, Premium-kapacitet, Premium per användare eller Inbäddad.
	Rapportskapare skapar rapporter med hjälp av en live-anslutning till den delade semantiska modellen.
	Rapportskapare utvecklar rapporter i Power BI Desktop. Förutom att avsiktligt separera rapporter från semantiska modeller följer innehållsskapare den typiska processen för att skapa rapporter.
	När de är klara publicerar rapportskaparna sin Power BI Desktop-fil (.pbix) eller Power BI-projektfil (.pbip) till Power BI-tjänst.
	Rapporter publiceras till en arbetsyta som är dedikerad för att lagra och skydda rapporter och instrumentpaneler.
	Publicerade rapporter förblir anslutna till den delade semantiska modellen som lagras på en annan arbetsyta. Alla ändringar som görs i den delade semantiska modellen påverkar alla beroende rapporter.
	Verktyg från tredje part kan använda XMLA-slutpunkten för att fråga den delade semantiska modellen. Andra XMLA-kompatibla verktyg, till exempel DAX Studio, Semantic Link från Fabric Notebooks eller Windows PowerShell, kan användas för att fråga efter eller uppdatera den delade semantiska modellen. Power BI Desktop, Excel och Report Builder kan också ansluta med hjälp av XMLA-slutpunkten (visas inte i scenariodiagrammet).
	Andra Microsoft- och tredjepartsverktyg kan använda XMLA-slutpunkten för att hantera den semantiska modellen och tillhandahålla livscykelhantering för program. Mer information finns i XMLA-slutpunktsbaserade klientverktyg.
	Infrastrukturadministratörer hanterar klientinställningen för att aktivera användningen av XMLA-slutpunkten. Administratören måste aktivera XMLA-slutpunkten för Infrastrukturkapaciteter, Premium-kapaciteter och Premium per användare-inställningar.
	Infrastrukturadministratörer övervakar och övervakar aktivitet i Infrastrukturresursportalen.

Huvudpunkter

Följande är några viktiga punkter att betona om scenariot för hantering av avancerade datamodeller.

Program och verktyg från tredje part

Enterprise BI-team använder ofta klientverktyg, till exempel Tabellredigeraren (som visas i scenariodiagrammet och beskrivs i nästa avsnitt) för att hjälpa dem att hantera centraliserade semantiska modeller. Alla semantiska modellskapare som vill arbeta med avancerade modelleringsfunktioner kan dock dra nytta av de metoder som beskrivs i det här användningsscenariot.

Det finns flera sätt att använda program från tredje part:

• Anslut till en fjärrdatamodell med hjälp av XMLA-slutpunkten: Vissa verktyg från tredje part kan ansluta direkt till en fjärrdatamodell i Power BI-tjänst (eller Analysis Services). När du är ansluten till XMLA-slutpunkten stöds alla TOM-åtgärder (Tabular Object Model). Den här metoden är det primära fokuset i det här användningsscenariot.
• Anslut till en lokal datamodell i Power BI Desktop: Vissa verktyg från tredje part kan ansluta till en lokal datamodell som är öppen i Power BI Desktop (visas inte i scenariodiagrammet). Det finns dock vissa begränsningar och inte alla externa verktygsfunktioner stöds officiellt.
• Anslut till en mallfil i Power BI Desktop: Vissa verktyg från tredje part distribuerar sina funktioner på ett enkelt sätt med hjälp av en Power BI Desktop-mallfil (.pbit) (visas inte i scenariodiagrammet).

Tabular Editor

Tabellredigeraren visas i scenariodiagrammet. Det är ett verktyg från tredje part som har implementerats i stor utsträckning av Power BI-communityn. Några fördelar med att hantera tabelldatamodeller med Tabellredigeraren är:

• Konfigurera datamodellfunktioner som inte stöds i Power BI Desktop: Tabellredigeraren tillhandahåller ett gränssnitt för att konfigurera säkerhet på objektnivå (OLS), beräkningsgrupper, perspektiv, översättningar och partitioner.
• Stöd för samtidig modellutveckling: Utvecklingsverktyg för Microsoft-datamodeller, till exempel Visual Studio med Analysis Services-projekt, lagrar hela datamodelldefinitionen i en Model.bim-fil . Den här enskilda filen kan göra det svårt för ett team med utvecklare att arbeta tillsammans med en enda datamodell. Tabellredigeraren har en funktion som heter Mapp serialisering. Mapp serialisering dekonstruerar filen Model.bim i separata objektspecifika filer i en ordnad mappstruktur. Olika datamodellerare kan sedan arbeta med olika filer med mindre risk för att skriva över varandras arbete.
• Integrering med källkontroll: Mapp serialisering gör det möjligt för källkontrollsystemet att enkelt identifiera datamodelländringar, vilket gör källsammanslagningar och konfliktlösning enklare att göra.
• Förbättrad datamodellkvalitet och design: Tabellredigeraren integreras med BPA (Best Practices Analyzer). BPA hjälper datamodellerare med en uppsättning anpassningsbara regler som kan förbättra datamodellernas kvalitet, konsekvens och prestanda. Du kan ladda ned en uppsättning regelverk (tillhandahålls av Microsoft) från GitHub.
• Ökad produktivitet vid utveckling av datamodeller: Gränssnittet i tabellredigeraren gör att det passar bra för att utföra batchredigeringar, felsökning och visning av datamodellberoenden. Tabellredigeraren skiljer sig från Power BI Desktop eftersom den fungerar i frånkopplat läge. Du kan göra ändringar i datamodellen i frånkopplat läge och checka in dem som en batch med redigeringar. Att arbeta på det här sättet möjliggör snabbare utveckling och validering, särskilt för erfarna datamodellerare. Det går också att skapa C#-skript och spara dem som makron. Dessa skript kan hjälpa dig att förbättra effektiviteten i att hantera och synkronisera flera datamodeller.

XMLA-slutpunkt

XMLA-slutpunkten använder XMLA-protokollet för att exponera alla funktioner i en tabelldatamodell, inklusive vissa datamodelleringsåtgärder som inte stöds av Power BI Desktop. Du kan använda TOM-API:et för att göra programmässiga ändringar i en datamodell.

XMLA-slutpunkten ger också anslutning. Du kan bara ansluta till en semantisk modell när arbetsytan som har sitt licensläge inställt på Premium per användare, Premium per kapacitet eller Inbäddad. När en anslutning har upprättats kan ett XMLA-kompatibelt verktyg fungera på datamodellen på två sätt:

• Skriva data och metadata: Läs-/skrivanvändning av XMLA-slutpunkten tillåter:
  • Datamodelleringsfunktioner som inte stöds av Power BI Desktop, till exempel säkerhet på objektnivå (OLS), beräkningsgrupper, perspektiv, översättningar och partitionshantering.
  • Mer komplexa distributioner. Till exempel en partiell distribution eller en distribution med endast metadata som endast publicerar ett enda nytt mått.
  • Asynkron uppdatering av semantisk modell. Du kan till exempel uppdatera en enskild tabell eller partition.
• Läsdata och metadata: Skrivskyddad användning av XMLA-slutpunkten tillåter:
  • Övervakning, felsökning och spårning av semantiska modeller och frågor.
  • Tillåta datarapporteringsverktyg från tredje part att visualisera data som kommer från en delad semantisk modell. Den här tekniken är ett bra sätt att utöka fördelarna och investeringarna i hanterad bi med självbetjäning.

Varning

När du har modifierat eller publicerat en semantisk modell med hjälp av XMLA-slutpunkten kan du inte längre ladda ned den från Power BI-tjänst som en Power BI Desktop-fil.

XMLA-inställningar per kapacitet

Varje Power BI Premium-kapacitet och Power BI Embedded-kapacitet har en inställning för att styra om XMLA-slutpunkten är skrivskyddad, skrivskyddad eller inaktiverad. Den här inställningen är också tillgänglig för alla Premium-arbetsytor per användare i Power BI-klientorganisationen. XMLA-åtkomst för läsning/skrivning måste vara aktiverad för varje kapacitet som innehåller semantiska modeller som du vill hantera med ett annat verktyg än Power BI Desktop.

Dricks

XMLA-slutpunktsinställningen (läsning/skrivning, skrivskyddad eller av) gäller för alla arbetsytor och semantiska modeller som tilldelats en viss kapacitet. Du kan konfigurera flera kapaciteter för att decentralisera och/eller anpassa hur innehåll hanteras för varje kapacitet.

XMLA-klientinställning

Förutom XMLA-slutpunktsinställningarna måste en Power BI-administratör använda klientinställningarna för att tillåta XMLA-slutpunkter och analysera i Excel med lokala semantiska modeller. När det är aktiverat kan du tillåta att alla användare eller specifika säkerhetsgrupper använder XMLA-slutpunktsfunktioner.

Kommentar

Alla standardfunktioner för säkerhet och dataskydd gäller fortfarande för att ange vilka användare som kan visa och/eller redigera innehåll.

Verktyg från tredje part

Power BI Desktop kan hantera behoven från slutpunkt till slutpunkt för de flesta innehållsskapare med självbetjäning. Verktyg från tredje part erbjuder dock andra företagsfunktioner. Därför har verktyg från tredje part, till exempel Tabellredigeraren, blivit vanliga i Power BI-communityn, särskilt för avancerade innehållsskapare, utvecklare och IT-proffs.

Dricks

Det här blogginlägget beskriver hur verktyg från tredje part gör det möjligt för Power BI-produktteamet att omvärdera sina utvecklingsprioriteringar, öka räckvidden för Power BI-plattformen och uppfylla mer avancerade och mångsidiga begäranden från användarcommunityn.

Kommentar

Vissa verktyg från tredje part kräver en betald licens, till exempel Tabellredigeraren 3. Andra communityverktyg är kostnadsfria och öppen källkod (till exempel Tabellredigeraren 2, DAX Studio och ALM Toolkit). Vi rekommenderar att du noggrant utvärderar funktionerna i varje verktyg, kostnad och supportmodell så att du på ett tillfredsställande sätt kan stödja din community med innehållsskapare.

Hantering av datamodeller

Det primära fokuset i det här användningsscenariot ligger på den innehållsskapare som använder Tabellredigeraren för att hantera en datamodell. För sällan avancerade krav för hantering av datamodeller, till exempel enstaka partitionshantering, kan du välja att använda ett verktyg som SQL Server Management Studio (SSMS). Det är också möjligt för en .NET-utvecklare att skapa och hantera Power BI-semantiska modeller med hjälp av TOM-API:et.

Dricks

När du använder XMLA-slutpunkten för datamodellhantering rekommenderar vi att du aktiverar inställningen för lagringsformat för stor semantisk modell. När det är aktiverat kan det stora semantiska modelllagringsformatet förbättra prestanda för XMLA-skrivåtgärder.

Separation av datamodell och rapporter

För att det här användningsscenariot ska lyckas bör du separera rapporter från datamodellen. Den här metoden resulterar i att du hanterar separata Power BI Desktop-filer enligt beskrivningen i det hanterade bi-användningsscenariot med självbetjäning. Även om samma person ansvarar för all utveckling är separationen av semantiska modeller och rapporter viktig eftersom Tabellredigeraren inte har någon medvetenhet om rapportinnehåll.

Gateway-konfiguration

Normalt krävs en datagateway vid åtkomst till datakällor som finns i det privata organisationsnätverket eller ett virtuellt nätverk. Den lokala datagatewayen blir relevant när en datamodell publiceras till Power BI-tjänst. De två syftena med en gateway är att uppdatera importerade data eller visa en rapport som frågar efter en live-anslutning eller DirectQuery-semantisk modell (visas inte i scenariodiagrammet).

Kommentar

En centraliserad datagateway i standardläge rekommenderas starkt för gatewayer i personligt läge. I standardläge stöder datagatewayen live-anslutning och DirectQuery-åtgärder (utöver schemalagda datauppdateringsåtgärder).

Mer information finns i Lokal datagateway (standardläge).

Systemtillsyn

Aktivitetsloggen registrerar användaraktiviteter som inträffar i Power BI-tjänst. Power BI-administratörer kan använda de aktivitetsloggdata som samlas in för att utföra granskning för att hjälpa dem att förstå aktiviteter som ansluter via XMLA-slutpunkter.

Relaterat innehåll

Andra användbara scenarier som hjälper dig med beslut om Power BI-implementering finns i artikeln Om Power BI-användningsscenarier .