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 endast metadata-distributioner via verktyg, skriptning 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.

Partitions

Semantiska modelltabellpartitioner visas inte och kan inte hanteras med hjälp av Power BI Desktop eller Power BI-tjänsten. För modeller i en arbetsyta som tilldelats en Premium-kapacitet kan partitioner hanteras via XMLA-slutpunkten. Du kan använda verktyg som SQL Server Management Studio (SSMS) eller tabellredigeraren med öppen källkod för att hantera partitioner via skript med TMSL (Tabular Model Scripting Language) och programmatiskt med TOM (Tabular Object Model).

När du först publicerar en modell till Power BI-tjänsten har varje tabell i den nya modellen en partition. För tabeller utan inkrementell uppdateringsprincip innehåller den en partition alla rader med data för tabellen, såvida inte filter tillämpas. För tabeller med en inkrementell uppdateringsprincip finns endast en inledande partition eftersom Power BI inte har tillämpat principen ännu. 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 tillämpas 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. Detaljnivån för uppdaterings- och historiska partitioner beror på de uppdateringsperioder och historiska lagringsperioder du väljer när du definierar policyn.

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 och en historisk partition skapas för gårdagen, en hel dags period, 1 februari 2021. En historisk partition skapas för den föregående hela månadsperioden (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 det första hela kvartalet 2021 ännu inte har slutförts den 2 februari.

Med varje uppdateringsåtgärd uppdateras endast partitionerna för uppdateringsperioden. 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. 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.

Vanliga mönster för partitionsuppdatering

När du arbetar med XMLA-slutpunktsåtgärder bör du överväga dessa vanliga mönster för att hantera uppdateringsåtgärder:

• Frekventa små uppdateringar: Kör flera små, riktade uppdateringsåtgärder under kontorstid med hjälp av XMLA-partitionskommandon eller det förbättrade REST-API:et för att hålla de senaste data aktuella utan att bearbeta hela tabellen.
• Selektiva historiska återfyllningar: Utför större historiska partitionsuppdateringar eller engångsdatakorrigeringar under lediga timmar med hjälp av TMSL med applyRefreshPolicy: false för att återskapa specifika historiska perioder utan att påverka det automatiska principbeteendet.
• Stegvisa inledande inläsningar: För stora tidsperioder, dela upp den inledande inläsningen i mindre batchar genom att bearbeta partitioner stegvis för att undvika timeoutar och hantera resursförbrukning.

Med dessa mönster kan du balansera färskheten hos data i realtid med att upprätthålla systemets prestanda och hantera resursbegränsningar.

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 uppdateringspolicy avgör applyRefreshPolicy om policyn 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 effectiveDate parametern 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.

Hantera principer med Tabellredigeraren

Förutom SSMS kan du använda Tabellredigeraren för att skapa och ändra inkrementella uppdateringsprinciper direkt mot semantiska modeller via XMLA-slutpunkten. Med den här metoden kan du justera principinställningar, till exempel uppdateringsperioder, historiska perioder och källuttryck, utan att behöva publicera om modellen från Power BI Desktop. Tabellredigeraren kan också användas för att tillämpa uppdateringsprinciper på befintliga tabeller och hantera RangeStart och RangeEnd parameteruttryck. Mer information finns i Inkrementell uppdatering i dokumentationen för tabellredigeraren.

Uppdatera orkestrering och automatisering

Utöver att använda SSMS, TMSL och TOM för att hantera uppdateringar via XMLA-slutpunkten. Du kan också orkestrera semantiska modelluppdateringsåtgärder med hjälp av Power BI REST-API:et. Det förbättrade uppdaterings-API:et innehåller fler funktioner som uppdatering på tabellnivå och partitionsnivå, logik för återförsök, annullering och anpassad timeout-hantering. Den här metoden är användbar för att integrera uppdateringsåtgärder i automatiserade arbetsflöden och CI/CD-pipelines. Detaljerad vägledning finns i Förbättrad uppdatering med Power BI REST API.

Säkerställa optimal prestanda

Med varje uppdateringsåtgärd kan Power BI-tjänsten 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. Den här nivån kan dock förhindra att data utbyts med andra molnkällor. Om du vill ange sekretessnivån 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 tidsavbrott vid inledande fullständig uppdatering

När du har publicerat till Power BI-tjänsten skapar den inledande 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. Den här metoden minskar 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 är klar tas det andra filtret ProductKey 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, vilken måste inkludera en omberäkning av processen på alla partitioner, från SSMS, uppdateras endast de inkrementella uppdateringspartitionerna i modellen vid efterföljande uppdateringsåtgärder från tjänstuppdateringen.

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 användas för att undvika att den senaste uppdateringskolumnen bevaras i minnesintern cache. Den kan också aktivera scenarier där en konfigurations- eller instruktionstabell förbereds genom ETL-processer (extrahering, transformering och inläsning). Gör att du bara kan flagga 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 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 effektiv. Det undviker dock 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 förändring.

"refreshPolicy": {
    "policyType": "basic",
    "rollingWindowGranularity": "month",
    "rollingWindowPeriods": 120,
    "incrementalGranularity": "month",
    "incrementalPeriods": 120,
    "pollingExpression": "<M expression or name of custom polling query>",
    "sourceExpression": [
    "let ..."
    ]
}

Distribution av endast metadata

När du publicerar en ny version av en .pbix-fil från Power BI Desktop till en arbetsyta. Du ser följande uppmaning om 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 betydligt mindre än den i Power BI-tjänsten. Om modellen i Power BI-tjänsten har en inkrementell uppdateringsprincip kan du förlora flera års historiska data 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 bara lägger 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änsten 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.

Processen omfattar följande steg:

1. 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 - 1565
   

2. Lägg till parametrarna RangeStart och RangeEnd i modelluttrycken. Om det behövs lägger du också till en funktion för att konvertera datum-/tidsvärden till datumnycklar.

3. Definiera ett RefreshPolicy objekt med önskad arkivering (rullande fönster) och inkrementella uppdateringsperioder samt ett källuttryck som filtrerar måltabellen baserat på parametrarna RangeStart och RangeEnd . 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.

4. 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();
        }
    }
}

Relaterat innehåll

• Konfigurera inkrementell uppdatering och realtidsdata
• Felsöka inkrementell uppdatering och realtidsdata
• Förbättrad uppdatering med Power BI REST API
• Partitioner i tabellmodeller
• Externa verktyg i Power BI Desktop
• Konfigurera schemalagd uppdatering