Avanceret trinvis opdatering og data i realtid med XMLA-slutpunktet
Semantiske modeller i en Premium-kapacitet med XMLA-slutpunktet aktiveret til læse-/skrivehandlinger giver mulighed for mere avancerede opdateringer, partitionsstyring og kun metadatainstallationer via værktøj, scripting og API-understøttelse. Desuden er opdateringshandlinger via XMLA-slutpunktet ikke begrænset til 48 opdateringer pr. dag, og den planlagte opdateringstidsgrænse er ikke pålagt.
Partitioner
Semantiske modeltabelpartitioner er ikke synlige og kan ikke administreres ved hjælp af Power BI Desktop eller Power BI-tjeneste. For modeller i et arbejdsområde, der er tildelt en Premium-kapacitet, kan partitioner administreres via XMLA-slutpunktet ved hjælp af værktøjer som SQL Server Management Studio (SSMS), tabular editor med åben kildekode, scriptet med TMSL (Tabular Model Scripting Language) og programmeringsmæssigt med TOM (Tabular Object Model).
Når du først publicerer en model til Power BI-tjeneste, har hver tabel i den nye model én partition. For tabeller uden en politik for trinvis opdatering indeholder den ene partition alle rækker med data for den pågældende tabel, medmindre der er anvendt filtre. For tabeller med en trinvis opdateringspolitik findes der kun én indledende partition, fordi Power BI endnu ikke har anvendt politikken. Du konfigurerer den indledende partition i Power BI Desktop, når du definerer dato-/klokkeslætsintervalfilteret for din tabel baseret på parametrene RangeStart og RangeEnd og eventuelle andre filtre, der anvendes i Power Query-editor. Denne indledende partition indeholder kun de rækker med data, der opfylder dine filterkriterier.
Når du udfører den første opdateringshandling, opdateres alle rækker i tabellens standardpartition uden en trinvis opdateringspolitik. For tabeller med en trinvis opdateringspolitik oprettes der automatisk opdatering og historiske partitioner, og rækker indlæses i dem i henhold til dato/klokkeslæt for hver række. Hvis politikken for trinvis opdatering omfatter hentning af data i realtid, føjer Power BI også en DirectQuery-partition til tabellen.
Denne første opdateringshandling kan tage temmelig lang tid, afhængigt af den mængde data, der skal indlæses fra datakilden. Modellens kompleksitet kan også være en vigtig faktor, fordi opdateringshandlinger skal udføre mere behandling og genberegning. Denne handling kan startes. Du kan få flere oplysninger under Forbyd timeout ved indledende fuld opdatering.
Partitioner oprettes for og navngives efter periodegranularitet: År, kvartaler, måneder og dage. De seneste partitioner, opdateringspartitionerne , indeholder rækker i den opdateringsperiode, du angiver i politikken. Historiske partitioner indeholder rækker efter hele perioden op til opdateringsperioden. Hvis realtid er aktiveret, registrerer en DirectQuery-partition eventuelle dataændringer, der er foretaget efter slutdatoen for opdateringsperioden. Granularitet for opdatering og historiske partitioner afhænger af de opdateringsperioder og historiske perioder (butik), du vælger, når du definerer politikken.
Hvis dags dato f.eks. er den 2. februar 2021, og tabellen FactInternetSales i datakilden indeholder rækker op til i dag, hvis vores politik angiver, at ændringerne skal medtages i realtid, opdatere rækker i den sidste opdateringsperiode på én dag og gemme rækker i den seneste tre års historiske periode. Med den første opdateringshandling oprettes der derefter en DirectQuery-partition til fremtidige ændringer, der oprettes en ny importpartition for rækkerne i dag. Der oprettes en historisk partition for i går, en periode på hele dagen, den 1. februar 2021. Der oprettes en historisk partition for den forrige hele månedsperiode (januar 2021), der oprettes en historisk partition for den forrige hele årsperiode (2020), og der oprettes historiske partitioner for 2019 og 2018 for hele årsperioder. Der oprettes ingen partitioner for hele kvartalet, fordi vi endnu ikke har fuldført det første hele kvartal af 2021.
Ved hver opdateringshandling opdateres kun partitionerne for opdateringsperioden, og datofilteret for DirectQuery-partitionen opdateres, så det kun er de ændringer, der sker efter den aktuelle opdateringsperiode. Der oprettes en ny opdateringspartition for nye rækker med en ny dato/et nyt klokkeslæt inden for den opdaterede opdateringsperiode, og eksisterende rækker med en dato/et klokkeslæt, der allerede findes i eksisterende partitioner i opdateringsperioden, opdateres med opdateringer. Rækker med en dato/et klokkeslæt, der er ældre end opdateringsperioden, opdateres ikke længere.
Når hele perioder lukkes, flettes partitioner. Hvis der f.eks. er angivet en en-dages opdateringsperiode og en 3-årig historisk lagerperiode i politikken, flettes alle dagspartitioner for den forrige måned på den første dag i måneden til en månedspartition. På den første dag i et nyt kvartal flettes alle tre foregående månedspartitioner til en kvartalspartition. På den første dag i et nyt år flettes alle fire foregående partitioner med en årspartition.
En model bevarer altid partitioner for hele den historiske lagerperiode plus partitioner med hele perioden op gennem den aktuelle opdateringsperiode. I eksemplet gemmes hele tre års historiske data i partitioner for 2018, 2019, 2020 og også partitioner for månedsperioden 2021Q101, dagsperioden 2021Q10201 og partitionen for den aktuelle dags opdateringsperiode. Da eksemplet bevarer historiske data i tre år, bevares partitionen for 2018 indtil den første opdatering den 1. januar 2022.
Med trinvis opdatering af Power BI og data i realtid håndterer tjenesten partitionsstyringen for dig baseret på politikken. Selvom tjenesten kan håndtere al partitionsstyring for dig, kan du ved hjælp af værktøjer via XMLA-slutpunktet selektivt opdatere partitioner individuelt, sekventielt eller parallelt.
Opdateringsstyring med SQL Server Management Studio
SQL Server Management Studio (SSMS) kan bruges til at få vist og administrere partitioner, der er oprettet ved hjælp af politikker for trinvis opdatering. Ved hjælp af SSMS kan du f.eks. opdatere en bestemt historisk partition, der ikke er i den trinvise opdateringsperiode, for at udføre en tilbagedateret opdatering uden at skulle opdatere alle historiske data. SSMS kan også bruges ved bootstrapping til at indlæse historiske data for store modeller ved trinvis tilføjelse/opdatering af historiske partitioner i batches.
Tilsidesæt funktionsmåden for trinvis opdatering
Med SSMS har du også mere kontrol over, hvordan du aktiverer opdateringer ved hjælp af Scriptsprog for tabellarisk model og tabelobjektmodellen. I SSMS skal du f.eks. højreklikke på en tabel i Object Explorer og derefter vælge menuindstillingen Behandl tabel og derefter vælge knappen Script for at generere en TMSL-opdateringskommando.
Disse parametre kan bruges sammen med TMSL-opdateringskommandoen til at tilsidesætte standardfunktionsmåden for trinvis opdatering:
applyRefreshPolicy. Hvis en tabel har defineret en trinvis opdateringspolitik, bestemmer,
applyRefreshPolicyom politikken anvendes eller ej. Hvis politikken ikke anvendes, forbliver partitionsdefinitionerne uændrede for en fuld proces, og alle partitioner i tabellen opdateres fuldt ud. Standardværdien er true.effectiveDate. Hvis der anvendes en politik for trinvis opdatering, skal den kende den aktuelle dato for at bestemme intervaller for rullende vinduer for den trinvise opdatering og historiske perioder. Parameteren
effectiveDategiver dig mulighed for at tilsidesætte den aktuelle dato. Denne parameter er nyttig til test, demoer og forretningsscenarier, hvor data opdateres trinvist op til en dato i fortiden eller fremtiden, f.eks. budgetter i fremtiden. Standardværdien er dags dato.
{
"refresh": {
"type": "full",
"applyRefreshPolicy": true,
"effectiveDate": "12/31/2013",
"objects": [
{
"database": "IR_AdventureWorks",
"table": "FactInternetSales"
}
]
}
}
Hvis du vil vide mere om tilsidesættelse af standardfunktionsmåden for trinvis opdatering med TMSL, skal du se Opdater kommando.
Sikring af optimal ydeevne
Med hver opdateringshandling kan Power BI-tjeneste sende initialiseringsforespørgsler til datakilden for hver trinvis opdateringspartition. Du kan muligvis forbedre ydeevnen for trinvis opdatering ved at reducere antallet af initialiseringsforespørgsler ved at sikre følgende konfiguration:
- Den tabel, du konfigurerer trinvis opdatering for, skal hente data fra en enkelt datakilde. Hvis tabellen henter data fra mere end én datakilde, multipliceres antallet af forespørgsler, der sendes af tjenesten for hver opdateringshandling, med antallet af datakilder, hvilket kan reducere opdateringsydeevnen. Sørg for, at forespørgslen for den trinvise opdateringstabel er for en enkelt datakilde.
- For løsninger med både trinvis opdatering af importpartitioner og data i realtid med Direct Query skal alle partitioner forespørge om data fra en enkelt datakilde.
- Hvis dine sikkerhedskrav tillader det, skal du angive indstillingen Niveau for beskyttelse af personlige oplysninger for datakilde til Organisatorisk eller Offentlig. Niveauet for beskyttelse af personlige oplysninger er som standard Privat, men dette niveau kan forhindre, at data udveksles med andre kilder i cloudmiljøet. Hvis du vil angive niveauet for beskyttelse af personlige oplysninger, skal du vælge menuen Flere indstillinger og derefter vælge Indstillinger> Indstillinger for legitimationsoplysninger>for datakilde Rediger legitimationsoplysninger Niveau for beskyttelse af personlige oplysninger>for denne datakilde. Hvis niveauet for beskyttelse af personlige oplysninger er angivet i Power BI Desktop-modellen, før den publiceres til tjenesten, overføres den ikke til tjenesten, når du publicerer. Du skal stadig angive den i semantiske modelindstillinger i tjenesten. Du kan få mere at vide under Niveauer for beskyttelse af personlige oplysninger.
- Hvis du bruger en datagateway i det lokale miljø, skal du sørge for, at du bruger version 3000.77.3 eller nyere.
Undgå timeout ved indledende fuld opdatering
Når du har publiceret til Power BI-tjeneste, opretter den indledende fulde opdateringshandling for modellen partitioner for den trinvise opdateringstabel, indlæser og behandler historiske data for hele den periode, der er defineret i politikken for trinvis opdatering. For nogle modeller, der indlæser og behandler store mængder data, kan den tid, det tager at udføre den indledende opdatering, overskride den opdateringsfrist, der er pålagt af tjenesten, eller en forespørgselstidsgrænse, der er pålagt af datakilden.
Bootstrapping af den indledende opdateringshandling gør det muligt for tjenesten at oprette partitionsobjekter for den trinvise opdateringstabel, men ikke indlæse og behandle historiske data i nogen af partitionerne. SSMS bruges derefter til selektivt at behandle partitioner. Afhængigt af mængden af data, der skal indlæses for hver partition, kan du behandle hver partition sekventielt eller i små batches for at reducere risikoen for, at en eller flere af disse partitioner forårsager timeout. Følgende metoder fungerer for alle datakilder.
Anvend opdateringspolitik
Værktøjet Tabular Editor 2 med åben kildekode gør det nemt at starte en indledende opdateringshandling. Når du har publiceret en model med en politik for trinvis opdatering, der er defineret for den fra Power BI Desktop til tjenesten, skal du oprette forbindelse til modellen ved hjælp af XMLA-slutpunktet i læse-/skrivetilstand. Kør Anvend opdateringspolitik i den trinvise opdateringstabel. Når kun politikken er anvendt, oprettes der partitioner, men der indlæses ingen data i dem. Opret derefter forbindelse med SSMS for at opdatere partitionerne sekventielt eller i batches for at indlæse og behandle dataene. Du kan få flere oplysninger i Trinvis opdatering i dokumentationen til tabular editor.
Power Query-filter til tomme partitioner
Før du publicerer modellen til tjenesten, skal du i Power Query-editor føje et andet filter til kolonnenProductKey, der filtrerer alle andre værdier end 0 ud, effektivt eller filtrerer alle data fra tabellen FactInternetSales.
Når du har valgt Luk & anvend i Power Query-editor, defineret politikken for trinvis opdatering og gemt modellen, publiceres modellen til tjenesten. Fra tjenesten køres den indledende opdateringshandling på modellen. Partitioner for tabellen FactInternetSales oprettes i henhold til politikken, men ingen data indlæses og behandles, fordi alle data er filtreret fra.
Når den indledende opdateringshandling er fuldført, fjernes det andet filter ProductKey på kolonnen tilbage i Power Query-editor. Når du har valgt Luk & anvend i Power Query-editor og gemt modellen, udgives modellen ikke igen. Hvis modellen publiceres igen, overskriver den politikindstillingerne for trinvis opdatering og gennemtvinger en fuld opdatering af modellen, når der udføres en efterfølgende opdateringshandling fra tjenesten. Udfør i stedet kun installation af metadata ved hjælp af ALM Toolkit (Application Lifecycle Management), der fjerner filteret på kolonnen ProductKey fra modellen. SSMS kan derefter bruges til selektivt at behandle partitioner. Når alle partitioner er blevet behandlet fuldt ud, hvilket skal omfatte en procesgenberegning på alle partitioner, fra SSMS, opdaterer efterfølgende opdateringshandlinger på modellen fra tjenesten kun de trinvise opdateringspartitioner.
Tip
Sørg for at se videoer, blogs og meget mere fra Power BI's community af BI-eksperter.
Du kan få mere at vide om behandling af tabeller og partitioner fra SSMS under Behandl database, tabel eller partitioner (Analysis Services). Hvis du vil vide mere om behandling af modeller, tabeller og partitioner ved hjælp af TMSL, skal du se Opdater kommando (TMSL).
Brugerdefinerede forespørgsler til registrering af dataændringer
TMSL og TOM kan bruges til at tilsidesætte funktionsmåden for registrerede dataændringer. Denne metode kan ikke kun bruges til at undgå, at kolonnen med den seneste opdatering bevares i cachen i hukommelsen, den kan aktivere scenarier, hvor en konfigurations- eller instruktionstabel forberedes ved at udtrække, transformere og indlæse (ETL)-processer til kun at markere de partitioner, der skal opdateres. Denne metode kan oprette en mere effektiv trinvis opdateringsproces, hvor det kun er de påkrævede perioder, der opdateres, uanset hvor længe siden dataopdateringerne fandt sted.
pollingExpression er beregnet til at være et letvægts M-udtryk eller navnet på en anden M-forespørgsel. Den skal returnere en skalarværdi og udføres for hver partition. Hvis den returnerede værdi er forskellig fra den, der blev returneret sidste gang, en trinvis opdatering fandt sted, er partitionen markeret til fuld behandling.
Følgende eksempel dækker alle 120 måneder i den historiske periode for tilbageførte ændringer. Hvis du angiver 120 måneder i stedet for 10 år, betyder datakomprimering muligvis ikke helt så effektiv, men undgår at skulle opdatere et helt historisk år, hvilket ville være dyrere, når en måned ville være tilstrækkelig til en tilbageført ændring.
"refreshPolicy": {
"policyType": "basic",
"rollingWindowGranularity": "month",
"rollingWindowPeriods": 120,
"incrementalGranularity": "month",
"incrementalPeriods": 120,
"pollingExpression": "<M expression or name of custom polling query>",
"sourceExpression": [
"let ..."
]
}
Tip
Sørg for at se videoer, blogs og meget mere fra Power BI's community af BI-eksperter.
Kun installation af metadata
Når du publicerer en ny version af en .pbix-fil fra Power BI Desktop til et arbejdsområde, bliver du bedt om at erstatte den eksisterende model, hvis der allerede findes en model med det samme navn.
I nogle tilfælde vil du muligvis ikke erstatte modellen, især ikke med trinvis opdatering. Modellen i Power BI Desktop kan være meget mindre end den i Power BI-tjeneste. Hvis der er anvendt en politik for trinvis opdatering af modellen i Power BI-tjeneste, kan den have flere års historiske data, der går tabt, hvis modellen erstattes. Det kan tage timer at opdatere alle historiske data, og det kan medføre systemstop for brugerne.
I stedet er det bedre kun at udføre en udrulning af metadata, hvilket gør det muligt at udrulle nye objekter uden at miste de historiske data. Hvis du f.eks. har tilføjet nogle få målinger, kan du kun udrulle de nye målinger uden at skulle opdatere dataene, hvilket sparer tid.
For arbejdsområder, der er tildelt en Premium-kapacitet, der er konfigureret til XMLA-slutpunktet med læse-/skriveadgang, aktiverer kompatible værktøjer kun installation af metadata. ALM Toolkit er f.eks. et skemadiffværktøj til Power BI-modeller og kan kun bruges til at udføre udrulning af metadata.
Download og installér den nyeste version af ALM Toolkit fra Git-lageret til Analysis Services. Trinvis vejledning til brug af ALM Toolkit er ikke inkluderet i Microsoft-dokumentationen. ALM Toolkit-dokumentationslinks og oplysninger om support er tilgængelige på båndet i Hjælp . Hvis du kun vil udføre en udrulning af metadata, skal du udføre en sammenligning og vælge den kørende Power BI Desktop-forekomst som kilde, og den eksisterende model i Power BI-tjeneste som destination. Overvej de viste forskelle, og spring opdateringen af tabellen over med trinvise opdateringspartitioner, eller brug dialogboksen Indstillinger til at bevare partitioner til tabelopdateringer. Valider markeringen for at sikre målmodellens integritet, og opdater derefter.
Tilføjelse af en trinvis opdateringspolitik og data i realtid programmeringsmæssigt
Du kan også bruge TMSL og TOM til at føje en politik for trinvis opdatering til en eksisterende model via XMLA-slutpunktet.
Bemærk
Hvis du vil undgå kompatibilitetsproblemer, skal du sørge for at bruge den nyeste version af Analysis Services-klientbibliotekerne. Hvis du f.eks. vil arbejde med hybridpolitikker, skal versionen være 19.27.1.8 eller nyere.
Processen omfatter følgende trin:
Sørg for, at målmodellen har det påkrævede minimumkompatibilitetsniveau. Højreklik på kompatibilitetsniveauet [modelnavn]>Egenskaber>i SSMS. Hvis du vil øge kompatibilitetsniveauet, skal du enten bruge et createOrReplace TMSL-script eller kontrollere følgende TOM-eksempelkode for et eksempel.
a. Import policy - 1550 b. Hybrid policy - 1565Føj parametrene
RangeStartogRangeEndtil modeludtryk. Hvis det er nødvendigt, kan du også tilføje en funktion for at konvertere dato-/klokkeslætsværdier til datonøgler.Definer et
RefreshPolicyobjekt med den ønskede arkivering (rullende vindue) og trinvise opdateringsperioder samt et kildeudtryk, der filtrerer måltabellen baseret på parametreneRangeStartogRangeEnd. Indstil politiktilstanden for opdatering til Import eller Hybrid , afhængigt af dine datakrav i realtid. Hybrid medfører, at Power BI føjer en DirectQuery-partition til tabellen for at hente de seneste ændringer fra datakilden, der opstod efter sidste opdateringstidspunkt.Føj opdateringspolitikken til tabellen, og udfør en fuld opdatering, så Power BI partitioner tabellen i henhold til dine krav.
Følgende kodeeksempel viser, hvordan du udfører de forrige trin ved hjælp af TOM. Hvis du vil bruge dette eksempel, som det er, skal du have en kopi til Databasen AdventureWorksDW og importere tabellen FactInternetSales til en model. Kodeeksemplet forudsætter, at parametrene RangeStart og RangeEnd og funktionen DateKey ikke findes i modellen. Du skal blot importere tabellen FactInternetSales og publicere modellen til et arbejdsområde i Power BI Premium. Opdater workspaceUrl derefter , så kodeeksemplet kan oprette forbindelse til din model. Opdater flere kodelinjer efter behov.
using System;
using TOM = Microsoft.AnalysisServices.Tabular;
namespace Hybrid_Tables
{
class Program
{
static string workspaceUrl = "<Enter your Workspace URL here>";
static string databaseName = "AdventureWorks";
static string tableName = "FactInternetSales";
static void Main(string[] args)
{
using (var server = new TOM.Server())
{
// Connect to the dataset.
server.Connect(workspaceUrl);
TOM.Database database = server.Databases.FindByName(databaseName);
if (database == null)
{
throw new ApplicationException("Database cannot be found!");
}
if(database.CompatibilityLevel < 1565)
{
database.CompatibilityLevel = 1565;
database.Update();
}
TOM.Model model = database.Model;
// Add RangeStart, RangeEnd, and DateKey function.
model.Expressions.Add(new TOM.NamedExpression {
Name = "RangeStart",
Kind = TOM.ExpressionKind.M,
Expression = "#datetime(2021, 12, 30, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
});
model.Expressions.Add(new TOM.NamedExpression
{
Name = "RangeEnd",
Kind = TOM.ExpressionKind.M,
Expression = "#datetime(2021, 12, 31, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
});
model.Expressions.Add(new TOM.NamedExpression
{
Name = "DateKey",
Kind = TOM.ExpressionKind.M,
Expression =
"let\n" +
" Source = (x as datetime) => Date.Year(x)*10000 + Date.Month(x)*100 + Date.Day(x)\n" +
"in\n" +
" Source"
});
// Apply a RefreshPolicy with Real-Time to the target table.
TOM.Table salesTable = model.Tables[tableName];
TOM.RefreshPolicy hybridPolicy = new TOM.BasicRefreshPolicy
{
Mode = TOM.RefreshPolicyMode.Hybrid,
IncrementalPeriodsOffset = -1,
RollingWindowPeriods = 1,
RollingWindowGranularity = TOM.RefreshGranularityType.Year,
IncrementalPeriods = 1,
IncrementalGranularity = TOM.RefreshGranularityType.Day,
SourceExpression =
"let\n" +
" Source = Sql.Database(\"demopm.database.windows.net\", \"AdventureWorksDW\"),\n" +
" dbo_FactInternetSales = Source{[Schema=\"dbo\",Item=\"FactInternetSales\"]}[Data],\n" +
" #\"Filtered Rows\" = Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] >= DateKey(RangeStart) and [OrderDateKey] < DateKey(RangeEnd))\n" +
"in\n" +
" #\"Filtered Rows\""
};
salesTable.RefreshPolicy = hybridPolicy;
model.RequestRefresh(TOM.RefreshType.Full);
model.SaveChanges();
}
Console.WriteLine("{0}{1}", Environment.NewLine, "Press [Enter] to exit...");
Console.ReadLine();
}
}
}