Avancerad inkrementell uppdatering och realtidsdata med XMLA-slutpunkten
Semantiska modeller i en Premium-kapacitet med XMLA-slutpunkten aktiverad för läs-/skrivåtgärder tillåter mer avancerad uppdatering, partitionshantering och metadata endast distributioner via verktyg, skript och API-stöd. Dessutom är uppdateringsåtgärder via XMLA-slutpunkten inte begränsade till 48 uppdateringar per dag och tidsgränsen för schemalagd uppdatering har inte införts.
Partitioner
Semantiska modelltabellpartitioner visas inte och kan inte hanteras med hjälp av Power BI Desktop eller Power BI-tjänst. För modeller i en arbetsyta som tilldelats en Premium-kapacitet kan partitioner hanteras via XMLA-slutpunkten med hjälp av verktyg som SQL Server Management Studio (SSMS), tabular Editor med öppen källkod, skript med TMSL (Tabular Model Scripting Language) och programmatiskt med tabellobjektmodellen (TOM).
När du först publicerar en modell till Power BI-tjänst har varje tabell i den nya modellen en partition. För tabeller utan inkrementell uppdateringsprincip innehåller den en partitionen alla rader med data för tabellen, såvida inte filter har tillämpats. För tabeller med en inkrementell uppdateringsprincip finns endast en inledande partition eftersom Power BI ännu inte har tillämpat principen. Du konfigurerar den första partitionen i Power BI Desktop när du definierar datum-/tidsintervallfiltret för tabellen baserat på parametrarna RangeStart och RangeEnd och eventuella andra filter som används i Power Query-redigeraren. Den här inledande partitionen innehåller endast de rader med data som uppfyller dina filtervillkor.
När du utför den första uppdateringsåtgärden uppdaterar tabeller utan inkrementell uppdateringsprincip alla rader i tabellens standardpartition. För tabeller med en inkrementell uppdateringsprincip skapas uppdaterings- och historiska partitioner automatiskt och rader läses in i dem enligt datum/tid för varje rad. Om principen för inkrementell uppdatering inkluderar att hämta data i realtid lägger Power BI även till en DirectQuery-partition i tabellen.
Den här första uppdateringsåtgärden kan ta ganska lång tid beroende på hur mycket data som behöver läsas in från datakällan. Modellens komplexitet kan också vara en viktig faktor eftersom uppdateringsåtgärder måste utföra mer bearbetning och omberäkning. Den här åtgärden kan startas. Mer information finns i Förhindra tidsgränser vid den första fullständiga uppdateringen.
Partitioner skapas för och namnges efter periodkornighet: År, kvartal, månader och dagar. De senaste partitionerna, uppdateringspartitionerna , innehåller rader under den uppdateringsperiod som du anger i principen. Historiska partitioner innehåller rader efter fullständig period fram till uppdateringsperioden. Om realtid är aktiverat hämtar en DirectQuery-partition alla dataändringar som har inträffat efter slutdatumet för uppdateringsperioden. Kornigheten för uppdaterings- och historiska partitioner är beroende av de uppdateringsperioder och historiska perioder (store) som du väljer när du definierar principen.
Om dagens datum till exempel är den 2 februari 2021 och tabellen FactInternetSales i datakällan innehåller rader upp till och med i dag, om vår princip anger att inkludera realtidsändringar, uppdatera rader under den senaste endagsuppdateringsperioden och lagra rader under den senaste treårsperioden. Sedan med den första uppdateringsåtgärden skapas en DirectQuery-partition för ändringar i framtiden, en ny importpartition skapas för dagens rader, en historisk partition skapas för igår, en hel dag period, 1 februari 2021. En historisk partition skapas för föregående hela månadsperiod (januari 2021), en historisk partition skapas för föregående helårsperiod (2020) och historiska partitioner för hela 2019 och 2018 skapas. Inga hela kvartalspartitioner skapas eftersom vi ännu inte har slutfört det första hela kvartalet 2021.
Med varje uppdateringsåtgärd uppdateras endast uppdateringsperiodpartitionerna och datumfiltret för DirectQuery-partitionen uppdateras så att endast de ändringar som inträffar efter den aktuella uppdateringsperioden inkluderas. En ny uppdateringspartition skapas för nya rader med ett nytt datum/tid inom den uppdaterade uppdateringsperioden, och befintliga rader med ett datum/en tid som redan finns i befintliga partitioner under uppdateringsperioden uppdateras med uppdateringar. Rader med ett datum/en tid som är äldre än uppdateringsperioden uppdateras inte längre.
När hela perioder stängs sammanfogas partitioner. Om till exempel en uppdateringsperiod på en dag och en historisk lagringsperiod på tre år anges i principen, slås alla dagpartitioner för föregående månad samman till en månadspartition den första dagen i månaden. Den första dagen i ett nytt kvartal sammanfogas alla tre föregående månadspartitioner till en kvartalspartition. På den första dagen av ett nytt år sammanfogas alla fyra partitioner för föregående kvartal till en årspartition.
En modell behåller alltid partitioner för hela den historiska lagringsperioden plus hela periodpartitioner upp till den aktuella uppdateringsperioden. I exemplet behålls hela tre års historiska data i partitioner för 2018, 2019, 2020 och även partitioner för 2021Q101-månadsperioden, 2021Q10201-dagarsperioden och den aktuella uppdateringsperiodens partition. Eftersom exemplet behåller historiska data i tre år behålls partitionen 2018 fram till den första uppdateringen den 1 januari 2022.
Med inkrementell uppdatering och realtidsdata i Power BI hanterar tjänsten partitionshanteringen åt dig baserat på principen. Tjänsten kan hantera all partitionshantering åt dig, men genom att använda verktyg via XMLA-slutpunkten kan du selektivt uppdatera partitioner individuellt, sekventiellt eller parallellt.
Uppdateringshantering med SQL Server Management Studio
SQL Server Management Studio (SSMS) kan användas för att visa och hantera partitioner som skapats av tillämpningen av inkrementella uppdateringsprinciper. Genom att använda SSMS kan du till exempel uppdatera en specifik historisk partition som inte ingår i den inkrementella uppdateringsperioden för att utföra en bakåtdaterad uppdatering utan att behöva uppdatera alla historiska data. SSMS kan också användas vid start för att läsa in historiska data för stora modeller genom att stegvis lägga till/uppdatera historiska partitioner i batchar.
Åsidosätt inkrementell uppdatering
Med SSMS har du också mer kontroll över hur du anropar uppdateringar med hjälp av Skriptspråk för tabellmodell och tabellobjektmodell. I SSMS högerklickar du till exempel på en tabell i Object Explorer och väljer menyalternativet Processtabell och väljer sedan knappen Skript för att generera ett TMSL-uppdateringskommando.
Dessa parametrar kan användas med TMSL-uppdateringskommandot för att åsidosätta standardbeteendet för inkrementell uppdatering:
applyRefreshPolicy. Om en tabell har en definierad inkrementell uppdateringsprincip avgör
applyRefreshPolicydu om principen tillämpas eller inte. Om principen inte tillämpas lämnar en fullständig processåtgärd partitionsdefinitionerna oförändrade och alla partitioner i tabellen uppdateras fullständigt. Standardvärdet är sant.effectiveDate. Om en inkrementell uppdateringsprincip tillämpas måste den känna till det aktuella datumet för att fastställa rullande fönsterintervall för inkrementell uppdatering och historiska perioder. Med
effectiveDateparametern kan du åsidosätta det aktuella datumet. Den här parametern är användbar för testning, demonstrationer och affärsscenarier där data uppdateras stegvis fram till ett datum tidigare eller i framtiden, till exempel budgetar i framtiden. Standardvärdet är det aktuella datumet.
{
"refresh": {
"type": "full",
"applyRefreshPolicy": true,
"effectiveDate": "12/31/2013",
"objects": [
{
"database": "IR_AdventureWorks",
"table": "FactInternetSales"
}
]
}
}
Mer information om hur du åsidosätter standardbeteendet för inkrementell uppdatering med TMSL finns i Kommandot Uppdatera.
Säkerställa optimal prestanda
Med varje uppdateringsåtgärd kan Power BI-tjänst skicka initieringsfrågor till datakällan för varje inkrementell uppdateringspartition. Du kanske kan förbättra prestanda för inkrementell uppdatering genom att minska antalet initieringsfrågor genom att säkerställa följande konfiguration:
- Tabellen som du konfigurerar inkrementell uppdatering för ska hämta data från en enda datakälla. Om tabellen hämtar data från mer än en datakälla multipliceras antalet frågor som skickas av tjänsten för varje uppdateringsåtgärd med antalet datakällor, vilket kan minska uppdateringsprestandan. Kontrollera att frågan för tabellen för inkrementell uppdatering är för en enda datakälla.
- För lösningar med både inkrementell uppdatering av importpartitioner och realtidsdata med Direct Query måste alla partitioner köra frågor mot data från en enda datakälla.
- Om dina säkerhetskrav tillåter anger du inställningen Sekretessnivå för datakälla till Organisation eller Offentlig. Som standard är sekretessnivån Privat, men den här nivån kan förhindra att data utbyts med andra molnkällor. Om du vill ange sekretessnivå väljer du menyn Fler alternativ och väljer sedan Inställningar> Datakällans autentiseringsuppgifter>Redigera autentiseringsuppgifter>Sekretessnivåinställning för den här datakällan. Om sekretessnivån anges i Power BI Desktop-modellen innan den publiceras till tjänsten överförs den inte till tjänsten när du publicerar. Du måste fortfarande ange den i semantiska modellinställningar i tjänsten. Mer information finns i Sekretessnivåer.
- Om du använder en lokal datagateway kontrollerar du att du använder version 3000.77.3 eller senare.
Förhindra timeouter vid inledande fullständig uppdatering
När du har publicerat till Power BI-tjänst skapar den första fullständiga uppdateringsåtgärden för modellen partitioner för den inkrementella uppdateringstabellen, läser in och bearbetar historiska data för hela perioden som definierats i principen för inkrementell uppdatering. För vissa modeller som läser in och bearbetar stora mängder data kan den tid som den inledande uppdateringsåtgärden tar överskrida den tidsgräns för uppdatering som tjänsten har infört eller en frågetidsgräns som datakällan har infört.
Genom att starta den inledande uppdateringsåtgärden kan tjänsten skapa partitionsobjekt för den inkrementella uppdateringstabellen, men inte läsa in och bearbeta historiska data till någon av partitionerna. SSMS används sedan för att selektivt bearbeta partitioner. Beroende på mängden data som ska läsas in för varje partition kan du bearbeta varje partition sekventiellt eller i små batchar för att minska risken för att en eller flera av dessa partitioner orsakar en timeout. Följande metoder fungerar för alla datakällor.
Tillämpa uppdateringsprincip
Verktyget Tabular Editor 2 med öppen källkod är ett enkelt sätt att starta en inledande uppdateringsåtgärd. När du har publicerat en modell med en inkrementell uppdateringsprincip som definierats för den från Power BI Desktop till tjänsten ansluter du till modellen med hjälp av XMLA-slutpunkten i läs- och skrivläge. Kör Tillämpa uppdateringsprincip i tabellen för inkrementell uppdatering. Med endast principen tillämpad skapas partitioner men inga data läses in i dem. Anslut sedan med SSMS för att uppdatera partitionerna sekventiellt eller i batchar för att läsa in och bearbeta data. Mer information finns i Inkrementell uppdatering i dokumentationen för tabellredigeraren.
Power Query-filter för tomma partitioner
Innan du publicerar modellen till tjänsten lägger du i Power Query-redigeraren till ytterligare ett filter ProductKey i kolumnen som filtrerar bort andra värden än 0, effektivt eller filtrerar bort alla data från tabellen FactInternetSales.
När du har valt Stäng och tillämpa i Power Query-redigeraren, definierat principen för inkrementell uppdatering och sparat modellen publiceras modellen till tjänsten. Från tjänsten körs den första uppdateringsåtgärden på modellen. Partitioner för tabellen FactInternetSales skapas enligt principen, men inga data läses in och bearbetas eftersom alla data filtreras bort.
När den första uppdateringsåtgärden ProductKey är klar tas det andra filtret i kolumnen bort i Power Query-redigeraren. När du har valt Stäng och tillämpa i Power Query-redigeraren och sparat modellen publiceras inte modellen igen. Om modellen publiceras igen skriver den över principinställningarna för inkrementell uppdatering och tvingar fram en fullständig uppdatering av modellen när en efterföljande uppdateringsåtgärd utförs från tjänsten. Utför i stället endast en distribution av metadata med hjälp av verktyget Application Lifecycle Management (ALM) som tar bort filtret i ProductKey kolumnen från modellen. SSMS kan sedan användas för att selektivt bearbeta partitioner. När alla partitioner har bearbetats fullständigt, vilket måste innehålla en processomberäkning på alla partitioner, från SSMS, uppdateras efterföljande uppdateringsåtgärder på modellen från tjänstuppdateringen endast de inkrementella uppdateringspartitionerna.
Dricks
Se till att kolla in videor, bloggar och mer som tillhandahålls av Power BI:s community med BI-experter.
Mer information om hur du bearbetar tabeller och partitioner från SSMS finns i Processdatabas, tabell eller partitioner (Analysis Services). Mer information om hur du bearbetar modeller, tabeller och partitioner med hjälp av TMSL finns i Uppdatera kommando (TMSL).
Anpassade frågor för att identifiera dataändringar
TMSL och TOM kan användas för att åsidosätta beteendet för identifierade dataändringar. Den här metoden kan inte bara användas för att undvika att den senaste uppdateringskolumnen bevaras i minnesintern cache, den kan aktivera scenarier där en konfigurations- eller instruktionstabell förbereds genom ETL-processer (extrahering, transformering och inläsning) för att flagga endast de partitioner som behöver uppdateras. Den här metoden kan skapa en effektivare inkrementell uppdateringsprocess där endast de nödvändiga perioderna uppdateras, oavsett hur länge sedan datauppdateringarna ägde rum.
pollingExpression är avsett att vara ett enkelt M-uttryck eller ett namn på en annan M-fråga. Det måste returnera ett skalärt värde och kommer att köras för varje partition. Om värdet som returneras skiljer sig från vad det var senast en inkrementell uppdatering inträffade flaggas partitionen för fullständig bearbetning.
I följande exempel beskrivs alla 120 månader i den historiska perioden för bakåtdaterade ändringar. Att ange 120 månader i stället för 10 år innebär att datakomprimering kanske inte är lika effektivt, men undviker att behöva uppdatera ett helt historiskt år, vilket skulle vara dyrare när en månad skulle vara tillräcklig för en bakåtdaterad ändring.
"refreshPolicy": {
"policyType": "basic",
"rollingWindowGranularity": "month",
"rollingWindowPeriods": 120,
"incrementalGranularity": "month",
"incrementalPeriods": 120,
"pollingExpression": "<M expression or name of custom polling query>",
"sourceExpression": [
"let ..."
]
}
Dricks
Se till att kolla in videor, bloggar och mer som tillhandahålls av Power BI:s community med BI-experter.
Distribution av endast metadata
När du publicerar en ny version av en .pbix-fil från Power BI Desktop till en arbetsyta uppmanas du att ersätta den befintliga modellen om det redan finns en modell med samma namn.
I vissa fall kanske du inte vill ersätta modellen, särskilt inte med inkrementell uppdatering. Modellen i Power BI Desktop kan vara mycket mindre än den i Power BI-tjänst. Om modellen i Power BI-tjänst har en inkrementell uppdateringsprincip kan den ha flera års historiska data som går förlorade om modellen ersätts. Det kan ta timmar att uppdatera alla historiska data och leda till systemavbrott för användarna.
I stället är det bättre att endast utföra en distribution av metadata, vilket gör det möjligt att distribuera nya objekt utan att förlora historiska data. Om du till exempel har lagt till några mått kan du bara distribuera de nya måtten utan att behöva uppdatera data, vilket sparar tid.
För arbetsytor som har tilldelats en Premium-kapacitet som konfigurerats för XMLA-slutpunktsläsning/-skrivning aktiverar kompatibla verktyg endast distribution av metadata. ALM Toolkit är till exempel ett schemadiffverktyg för Power BI-modeller och kan endast användas för att utföra distribution av metadata.
Ladda ned och installera den senaste versionen av ALM Toolkit från Analysis Services Git-lagringsplatsen. Stegvis vägledning om hur du använder ALM Toolkit ingår inte i Microsoft-dokumentationen. ALM Toolkit-dokumentationslänkar och information om support finns i menyfliksområdet Hjälp . Om du bara vill utföra en distribution av metadata utför du en jämförelse och väljer den Power BI Desktop-instans som körs som källa och den befintliga modellen i Power BI-tjänst som mål. Överväg skillnaderna som visas och hoppa över uppdateringen av tabellen med inkrementella uppdateringspartitioner eller använd dialogrutan Alternativ för att behålla partitioner för tabelluppdateringar. Verifiera markeringen för att säkerställa målmodellens integritet och uppdatera sedan.
Lägga till en inkrementell uppdateringsprincip och realtidsdata programmatiskt
Du kan också använda TMSL och TOM för att lägga till en inkrementell uppdateringsprincip i en befintlig modell via XMLA-slutpunkten.
Kommentar
För att undvika kompatibilitetsproblem kontrollerar du att du använder den senaste versionen av Analysis Services-klientbiblioteken. Om du till exempel vill arbeta med hybridprinciper måste versionen vara 19.27.1.8 eller senare.
Processen omfattar följande steg:
Se till att målmodellen har den lägsta kompatibilitetsnivå som krävs. I SSMS högerklickar du på [modellnamnet]>Egenskaper>Kompatibilitetsnivå. Om du vill öka kompatibilitetsnivån använder du antingen ett createOrReplace TMSL-skript eller kontrollerar följande TOM-exempelkod för ett exempel.
a. Import policy - 1550 b. Hybrid policy - 1565Lägg till parametrarna
RangeStartochRangeEndi modelluttrycken. Om det behövs lägger du också till en funktion för att konvertera datum-/tidsvärden till datumnycklar.Definiera ett
RefreshPolicyobjekt med önskad arkivering (rullande fönster) och inkrementella uppdateringsperioder samt ett källuttryck som filtrerar måltabellen baserat på parametrarnaRangeStartochRangeEnd. Ange uppdateringsprincipläget till Import eller Hybrid beroende på dina datakrav i realtid. Hybrid gör att Power BI lägger till en DirectQuery-partition i tabellen för att hämta de senaste ändringarna från datakällan som inträffade efter den senaste uppdateringstiden.Lägg till uppdateringsprincipen i tabellen och utför en fullständig uppdatering så att Power BI partitioner tabellen enligt dina krav.
Följande kodexempel visar hur du utför föregående steg med hjälp av TOM. Om du vill använda det här exemplet som det är måste du ha en kopia för AdventureWorksDW-databasen och importera tabellen FactInternetSales till en modell. Kodexemplet förutsätter att parametrarna RangeStart och RangeEnd och DateKey funktionen inte finns i modellen. Importera tabellen FactInternetSales och publicera modellen till en arbetsyta på Power BI Premium. Uppdatera workspaceUrl sedan så att kodexemplet kan ansluta till din modell. Uppdatera eventuella fler kodrader 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();
}
}
}