Avanceret trinvis opdatering med XMLA-slutpunktet

Datasæt i en Premium-kapacitet med XMLA-slutpunktet, der er aktiveret til læse-/skrivehandlinger, muliggør mere avanceret opdatering af datasæt, partitionsadministration og udrulninger udelukkende metadata via værktøjs-, scripting- og API-understøttelse. Derudover er opdateringshandlinger via XMLA-slutpunktet ikke begrænset til 48opdateringer pr. dag, og tidsgrænsen for planlagt opdatering er ikke pålagt.

Partitioner

Tabelpartitioner i datasæt er ikke synlige og kan ikke administreres i tjenesten. For de datasæt i et arbejdsområde, der er tildelt til 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, der er scriptet med TMSL (Tabular Model Scripting Language) og programmeringsmæssig med TOM (Tabular Object Model).

Hver tabel i det nye datasæt har én partition, første gang du publicerer en model til tjenesten. For tabeller, der ikke har en politik for trinvis opdatering, at én partition indeholder alle rækker med data for den pågældende tabel (medmindre der er anvendt filtre). For tabeller med en politik for trinvis opdatering indeholder denne ene partition kun de rækker med data, der er defineret af dato-/tidsintervalfilteret baseret på parametrene RangeStart og RangeEnd og eventuelle andre filtre, der er anvendt i Power Query Editor.

Når du udfører den første opdateringshandling for datasæt, opdateres alle rækker, der er indeholdt i den enkelte standardpartition, i tabeller uden trinvis opdateringspolitik. For tabeller med en politik for trinvis opdatering oprettes opdatering og historiske partitioner automatisk, og rækker indlæses i dem i henhold til dato/klokkeslæt for hver række.

Denne første opdateringshandling kan tage et stykke tid, afhængigt af den mængde data, der skal indlæses fra datakilden. Modellens kompleksitet kan også være en vigtig faktor, da opdateringshandlinger skal udføre yderligere behandling og genberegning. Denne handling kan aktiveres. Du kan få mere at vide under Undgå timeout ved indledende fuld opdatering 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 en komplet periode op til opdateringsperioden. Granularitet i forbindelse med opdaterings- og historiske partitioner er afhængig af de opdaterings- og historikperioder (lager), du vælger, når politikken defineres.

Hvis dags dato f.eks. er 2. februar 2021, og tabellen FactInternetSales på datakilden indeholder rækker, der er oprettet i dag, indeholder politikken opdateringsrækker for den sidste én dag (opdateringsperiode) og gemmer rækker i de sidste tre år (historisk periode), og med den første opdateringshandling oprettes der en ny partition for dags rækker, Der oprettes en historisk partition for i går, en periode på en hel dag (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 året (2020), og der oprettes historiske partitioner for 2019 og hele år 2018. Der oprettes ikke hele kvartalspartitioner, fordi vi endnu ikke har gennemført det første hele kvartal i 2021.

Ved hver opdateringshandling opdateres kun partitionerne for opdateringsperioden. Der oprettes en ny partition for nye rækker med en ny dato/klokkeslæt, og eksisterende rækker med en dato/klokkeslæt,der allerede findes i eksisterende partition(er) i opdateringsperioden, opdateres med opdateringer. Rækker med en dato/klokkeslæt, der er ældre end opdateringsperioden, opdateres ikke længere.

Når hele perioder er lukket, flettes partitioner. Hvis der f.eks. er angivet en opdateringsperiode på én dag og tre års historisk lagerperiode i politikken, flettes alle partitioner 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 forrige måneds partitioner til en kvartalspartition. På den første dag i et nyt år flettes alle fire partitioner i forrige kvartal til en år-partition.

Et datasæt bevarer altid partitioner for hele den historiske lagerperiode plus hele periodepartitioner op til den aktuelle opdateringsperiode. Ved hjælp af vores eksempel ovenfor bevares en fuld treårs historiske data i partitioner for 2018, 2019, 2020 og også partitioner for månedsperioden 2021Q101, 2021Q10201 dags periode og den aktuelle dags opdateringsperiode. Da vi har valgt at bevare historiske data i tre år , bevares partitionen for 2018 indtil den første opdatering den 1. januar 2022.

Med Power BI trinvis opdatering håndterer tjenesten partitionsadministrationen for dig på baggrund af politikken. Hvis du har prøvet at arbejde Analysis Services, ved du, at effektiv partitionering involverer oprettelse af en programløsning ofte med tusindvis af kodelinjer. Selvom tjenesten kan håndtere al partitionsadministration for dig, kan du ved hjælp af værktøjer via XMLA-slutpunktet opdatere partitioner selektivt 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 anvendelse af politikker for trinvis opdatering. Ved hjælp af SSMS kan du f.eks. opdatere en bestemt historisk partition, der ikke i den trinvise opdateringsperiode, for at udføre en tilbagedateret opdatering uden at skulle opdatere alle historiske data. SSMS kan også bruges ved bootstrap til at indlæse historiske data i store datasæt ved trinvist at tilføje/opdatere historiske partitioner i batches.

Tilsidesæt funktionsmåde for trinvis opdatering

Med SSMS får 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 kan du f.eks. Object Explorer højreklikke på en tabel og derefter vælge menupunktet Bearbejde tabel og derefter klikke på 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 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 det rullende vindues intervaller for trinvise opdateringsperioder 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 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

Ved hver opdateringshandling kan Power BI sende initialiseringsforespørgsler til datakilden for hver partition med trinvis opdatering. Du kan forbedre ydeevnen for trinvis opdatering ved at reducere antallet af forespørgsler i forbindelse med initialisering 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 af opdateringen. Kontrollér, at forespørgslen for den trinvise opdateringstabel er for en enkelt datakilde.
• Hvis dine sikkerhedskrav tillader det, skal du angive indstillingen Niveau for beskyttelse af personlige oplysninger for datakilden til Organisation eller Offentlig. Niveauet for beskyttelse af personlige oplysninger er som standard Privat, men dette niveau kan forhindre, at data udveksles med andre cloudkilder. Angiv niveauet for beskyttelse af personlige oplysninger i Indstillinger Legitimationsoplysninger for datakilde Rediger indstillinger for niveau for beskyttelse af personlige oplysninger for denne > > > datakilde. Hvis Niveauet for beskyttelse af personlige oplysninger er angivet Power BI Desktop den samme model, før den publicerer til tjenesten, overføres den ikke til tjenesten, når du publicerer den. 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.

Forbyd timeout ved indledende fuld opdatering

Når du har publiceret til tjenesten, opretter den indledende komplette opdateringshandling for datasættet partitioner for tabellen med trinvis opdatering, 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 mængde tid, det tager at køre den indledende opdateringshandling, overskride den opdateringstidsgrænse, der er pålagt af tjenesten, eller en grænse for forespørgselstiden, der pålægges af datakilden.

Bootstrap 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 medfører timeout. Følgende metoder fungerer for enhver datakilde.

Anvend opdateringspolitik

Værktøjet Tabular Editor 2 i åben kildekode er en nem måde at starte en indledende opdateringshandling på. Når du har publiceret en model med en politik for trinvis opdatering, som er defineret for den fra Power BI Desktop til tjenesten, kan 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 politikken kun er anvendt, oprettes der partitioner, men der indlæses ingen data i dem. Opret derefter forbindelse til 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.

Power Query filtrere efter tomme partitioner

Før du publicerer modellen til tjenesten, skal du i Power Query Editor føje et andet filter til kolonnen ProductKey, som filtrerer andre værdier end 0, eller effektivt filtrere alle data fra tabellen FactInternetSales.

Når du har klikket & Anvend i Power Query editor, definerer politikken for trinvis opdatering og gemmer modellen, publiceres modellen i 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 opdateringshandling er fuldført, fjernes Power Query Editor for produktnøglekolonnen. Når du har klikket & Anvend i Power Query editor og gemmer modellen, publiceres modellen ikke igen. Hvis modellen blev publiceret igen, overskrives politikindstillingerne for trinvis opdatering og gennemtvinger en fuld opdatering af datasættet, når der udføres en efterfølgende opdateringshandling fra tjenesten. Udfør i stedet en udrulning udelukkende 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 genberegning af en proces på alle partitioner) fra SSMS, er det kun partitionerne for trinvis opdatering, der er de efterfølgende opdateringshandlinger for datasættet fra tjenesten, der opdateres.

Du kan få mere at vide om behandling af tabeller og partitioner fra SSMS under Bearbejde database, tabel eller partitioner (Analysis Services). Du kan få mere at vide om behandling af datasæt, tabeller og partitioner ved hjælp af TMSL under Opdater kommando (TMSL).

Brugerdefinerede forespørgsler om registrering af dataændringer

TMSL og/eller TOM kan bruges til at tilsidesætte funktionsmåden for de registrerede dataændringer. Denne metode kan ikke kun bruges til at undgå, at kolonnen med den seneste opdatering i cachen i hukommelsen bevares, men det kan gøre det muligt at aktivere scenarier, hvor en konfigurations-/instruktionstabel klargjort af ETL-processer kun markerer de partitioner, der skal opdateres. Denne metode kan oprette en mere effektiv trinvis opdateringsproces, hvor kun de påkrævede perioder opdateres, uanset hvor længe det er, 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 tilbageejede ændringer. Hvis du angiver 120 måneder i stedet for 10 år, er datakomprimering muligvis ikke helt lige så effektiv, men du undgår at skulle opdatere et helt historisk år, hvilket ville være dyrere, og en måned ville være tilstrækkelig til en tilbagelagt ændring.

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

Udrulning kun 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.

I nogle tilfælde vil du muligvis ikke erstatte datasættet, især i tilfælde af 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.

Det er bedre at udføre en udrulning udelukkende af metadata, hvilket muliggør udrulning af nye objekter uden at miste de historiske data. Hvis du f.eks. har tilføjet et par målinger, kan du kun udrulle de nye målinger uden at skulle opdatere dataene, hvilket sparer meget tid.

For arbejdsområder, der er tildelt til en Premium, der er konfigureret til læse-/skrive-adgang til XMLA-slutpunkter, aktiverer kompatible værktøjer kun udrulning 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 i brug af ALM Toolkit er ikke inkluderet i Microsofts dokumentation. Du kan finde links til og oplysninger om support til ALM Toolkit-dokumentation 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 forskelle, der vises, og spring over opdateringen af tabellen med partitionerne med trinvise opdatering, eller brug dialogboksen Indstillinger til at bevare partitioner til tabelopdateringer. Valider valget for at sikre destinationsmodellens integritet, og opdater derefter.

Se også

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