Avanceret trinvis opdatering og data i realtid med XMLA-slutpunktet

Datasæt i en Premium-kapacitet, hvor XMLA-slutpunktet er aktiveret til læse-/skrivehandlinger , gør det muligt at opdatere mere avancerede datasæt, partitionsstyring og metadata kun udrulninger via værktøj, scripting og API-understøttelse. Derudover er opdateringshandlinger via XMLA-slutpunktet ikke begrænset til 48 opdateringer pr. dag, og den planlagte opdateringstidsgrænse er ikke pålagt.

Partitioner

Datasættabelpartitioner er ikke synlige og kan ikke administreres ved hjælp af Power BI Desktop eller Power BI-brugergrænsefladen i browseren. For datasæt 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 publicerer en model til tjenesten første gang, har hver tabel i det nye datasæt én partition. For tabeller uden en trinvis opdateringspolitik 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 konfigurerede den indledende partition i Power BI Desktop, da du definerede 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 for datasæt, opdateres alle rækker i den pågældende tabels standardpartition i tabeller uden en trinvis opdateringspolitik. For tabeller med en trinvis opdateringspolitik oprettes der automatisk opdaterings- 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 et stykke tid, afhængigt af mængden af data, der skal indlæses fra datakilden. Modellens kompleksitet kan også være en vigtig faktor, fordi opdateringshandlinger skal udføre yderligere behandling og genberegning. Denne handling kan startes. Du kan få mere at vide under Undgå timeout ved indledende komplette opdateringer senere i denne artikel.

Partitioner oprettes for og navngives efter periodegranularitet: År, kvartaler, måneder og dage. Den eller de nyeste 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 er afhængig af de opdaterings- 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 der skal medtages ændringer i realtid, opdatere rækker i den sidste én dag (opdateringsperiode) og gemme rækker i de sidste tre år (historisk periode), oprettes der en DirectQuery-partition med henblik på ændringer i fremtiden, Der oprettes en ny importpartition for rækkerne i dag, der oprettes en historisk partition for i går, en periode på hele dagen (1. februar 2021), en historisk partition oprettes 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 året. Der oprettes ingen partitioner for hele kvartalet, fordi vi endnu ikke har fuldført det første hele kvartal af 2021.

Partition naming granularity

Ved hver opdateringshandling opdateres kun partitionerne for opdateringsperioden, og datofilteret for DirectQuery-partitionen opdateres, så det kun omfatter de ændringer, der forekommer 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 perioderne lukkes, flettes partitioner. Hvis der f.eks. er angivet en opdateringsperiode på én dag og en 3-års historisk butiksperiode i politikken, flettes partitioner for hele dagen for den foregående måned til en månedspartition. På den første dag i et nyt kvartal flettes alle tre tidligere partitioner i en kvartalspartition. På den første dag i et nyt år flettes alle fire partitioner i det foregående kvartal til en årspartition.

Et datasæt bevarer altid partitioner for hele den historiske lagerperiode plus partitioner for hele perioden op gennem den aktuelle opdateringsperiode. I vores eksempel ovenfor bevares hele tre års historiske data i partitioner for 2018, 2019, 2020 og også partitioner for 2021Q101-månedsperioden, 2021Q10201-dagsperioden og partitionen for den aktuelle dags opdateringsperiode. Da vi har valgt at bevare historiske data i tre år, bevares partitionen i 2018 indtil den første opdatering den 1. januar 2022.

Med trinvis opdatering af Power BI og data i realtid håndterer tjenesten partitionsadministrationen for dig baseret på politikken. Hvis du nogensinde har arbejdet med Analysis Services, ved du, at effektiv partitionering omfatter oprettelse af en programmatisk løsning ofte med tusindvis af kodelinjer. 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.

Administration af opdatering med SQL Server Management Studio (SSMS)

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 datasæt ved trinvist at tilføje/opdatere historiske partitioner i batches.

Partitions in SSMS

Tilsidesæt funktionsmåde for trinvis opdatering

Med SSMS har du også mere kontrol over, hvordan du aktiverer opdateringer ved hjælp af TMSL (Tabular Model Scripting Language) og TOM (Tabular Object Model). I SSMS skal du f.eks. højreklikke på en tabel i Object Explorer og derefter vælge menuindstillingen Behandl tabel og derefter klikke på knappen Script for at generere en TMSL-opdateringskommando.

Script button in Process Table dialog

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 applyRefreshPolicy, om politikken anvendes eller ej. Hvis politikken ikke anvendes, efterlader en Behandl komplet-handling partitionsdefinitionerne uændrede, og der udføres en fuld opdatering af alle partitioner i tabellen. 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 vindue for den trinvise opdatering og historiske perioder. Parameteren effectiveDate gør det muligt for dig 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 den aktuelle dato.

{ 
  "refresh": {
    "type": "full",

    "applyRefreshPolicy": true,
    "effectiveDate": "12/31/2013",

    "objects": [
      {
        "database": "IR_AdventureWorks", 
        "table": "FactInternetSales" 
      }
    ]
  }
}

Du kan få mere at vide om, hvordan du tilsidesætter standardfunktionen til trinvis opdatering med TMSL, under Opdater kommando.

Sikring af optimal ydeevne

Med hver opdateringshandling kan Power BI-tjenesten 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:

  • 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 ydeevnen for opdateringer. 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 niveauet for beskyttelse af personlige oplysninger for datakilden 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. Angiv niveauet for beskyttelse af personlige oplysninger i Indstillinger for>datasætLegitimationsoplysninger> for datakildeRediger legitimationsoplysningerIndstillingerfor 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 under indstillinger for datasæt 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

Efter publicering til tjenesten opretter den indledende fulde opdateringshandling for datasættet 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 datasæt, der indlæser og behandler store mængder data, kan den tid, som den indledende opdateringshandling tager, overskride den opdateringstidsgrænse, 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 trinvis opdateringspolitik, der er defineret for den fra Power BI Desktop til tjenesten, skal du oprette forbindelse til datasættet ved hjælp af XMLA-slutpunktet i læse-/skrivetilstand. Kør Anvend opdateringspolitik på 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å mere at vide under Trinvis opdatering i dokumentationen til Tabular Editor.

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 kolonnen ProductKey, der filtrerer alle andre værdier end 0, effektivt eller filtrering af alle data fra tabellen FactInternetSales.

Filter out product key

Når du har klikket på 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å datasættet. Partitioner for tabellen FactInternetSales oprettes i henhold til politikken, men der indlæses og behandles ingen data, fordi alle data er filtreret ud.

Når den indledende opdatering er fuldført, fjernes det ekstra filter på kolonnen ProductKey tilbage i Power Query-editor. Når du har klikket på Luk & Anvend i Power Query-editor og gemt modellen, udgives modellen ikke igen. Hvis modellen blev publiceret igen, overskrives politikindstillingerne for trinvis opdatering, og der gennemtvinges en fuld opdatering af datasættet, når der udføres en efterfølgende opdateringshandling fra tjenesten. Udfør i stedet kun en installation af metadata ved hjælp af ALM Toolkit, der fjerner filteret på kolonnen ProductKey fra datasættet. 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å datasættet fra tjenesten kun partitionerne for trinvis opdatering.

Tip

Sørg for at se videoer, blogs og meget mere fra Power BI's community af BI-eksperter.

Hvis du vil vide mere om behandling af tabeller og partitioner fra SSMS, skal du se Behandle database, tabel eller partitioner (Analysis Services). Hvis du vil vide mere om behandling af datasæt, tabeller og partitioner ved hjælp af TMSL, skal du se Kommandoen Opdater (TMSL).

Brugerdefinerede forespørgsler om registrering af dataændringer

TMSL og/eller 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 sidste opdatering bevares i cachen i hukommelsen, men den kan også aktivere scenarier, hvor en konfigurations-/instruktionstabel er forberedt af 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 M-letvægtsudtryk eller et navn på en anden M-forespørgsel. Det skal returnere en skalaværdi og udføres for hver partition. Hvis den returnerede værdi er forskellig fra den værdi, der blev returneret, sidste gang en trinvis opdatering forekom, er partitionen markeret med henblik på fuld behandling.

Følgende eksempel dækker alle 120 måneder i den historiske periode for tilbageførte ændringer. Angivelse af 120 måneder i stedet for 10 år betyder, at datakomprimering muligvis ikke er 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 backdated æ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 det eksisterende datasæt, hvis der allerede findes et datasæt med det samme navn.

Replace dataset prompt

I nogle tilfælde vil du muligvis ikke erstatte datasættet, især ikke med trinvis opdatering. Datasættet i Power BI Desktop kan være meget mindre end det, der er i tjenesten. Hvis der er anvendt en politik for trinvis opdatering på datasættet i tjenesten, kan det indeholde flere års historiske data, der går tabt, hvis datasættet erstattes. Opdatering af alle historiske data kan tage flere timer og resultere i systemnedetid for brugerne.

I stedet er det bedre kun at udføre en installation af metadata, som 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 meget tid.

I forbindelse med arbejdsområder, der er tildelt en Premium kapacitet, der er konfigureret til skrivebeskyttet XMLA-slutpunkt, aktiverer kompatible værktøjer kun installation af metadata. ALM Toolkit er f. eks. et skemasammenligningsværktøj til Power BI-datasæt og kan kun bruges til udrulning af metadata.

Hent 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. Dokumentationslinks til ALM Toolkit og oplysninger om support er tilgængelige på båndet Hjælp. Hvis du vil udføre en udrulning udelukkende af metadata, skal du udføre en sammenligning og vælge den kørende Power BI Desktop-instans som kilde og det eksisterende datasæt i tjenesten 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 valget for at sikre destinationsmodellens integritet, og opdater derefter.

ALM Toolkit

Tilføjelse af en trinvis opdateringspolitik og data i realtid programmatisk

Du kan også bruge TMSL og TOM til at føje en politik for trinvis opdatering til et eksisterende datasæt 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:

  1. Kontrollér, at destinationsdatasættet har det påkrævede minimumkompatibilitetsniveau. Højreklik på kompatibilitetsniveauet [datasætnavn] > 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 - 1565
    
  2. Føj parametrene RangeStart og RangeEnd til udtryk for datasæt. Hvis det er nødvendigt, kan du også tilføje en funktion for at konvertere dato-/klokkeslætsværdier til datonøgler.

  3. Definer et RefreshPolicy-objekt med den ønskede arkivering (rullende vindue) og trinvise opdateringsperioder samt et kildeudtryk, der filtrerer måltabellen baseret på parametrene RangeStart og RangeEnd . Angiv politiktilstanden for opdatering til Importér 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 det seneste opdateringstidspunkt.

  4. Føj opdateringspolitikken til tabellen, og udfør en komplet 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 AdventureWorksDW-databasen og importere tabellen FactInternetSales til et datasæt. Kodeeksemplet forudsætter, at parametrene RangeStart og RangeEnd og funktionen DateKey ikke findes i datasættet. Du skal blot importere tabellen FactInternetSales og publicere datasættet til et arbejdsområde på Power BI Premium. Opdater derefter workspaceUrl, så kodeeksemplet kan oprette forbindelse til dit datasæt. Opdater eventuelle yderligere 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();
        }
    }
}

Næste trin

Partitioner i tabelmodeller
Eksterne værktøjer til Power BI
Konfigurer planlagt opdatering
Foretag fejlfinding af trinvis opdatering