Del via

Avansert trinnvis oppdatering og sanntidsdata med XMLA-endepunktet

  • Artikkel

Semantiske modeller i en Premium-kapasitet med XMLA-endepunktet aktivert for lese-/skriveoperasjoner tillater mer avansert oppdatering, partisjonsbehandling og bare metadatadistribusjoner gjennom verktøy- og skriptings- og API-støtte. I tillegg er ikke oppdateringsoperasjoner gjennom XMLA-endepunktet begrenset til 48 oppdateringer per dag, og den planlagte tidsgrensen for oppdatering er ikke pålagt.

Partisjoner

Semantiske tabellpartisjoner for semantiske modeller er ikke synlige og kan ikke administreres ved hjelp av Power BI Desktop eller Power Bi-tjeneste. For modeller i et arbeidsområde som er tilordnet en Premium-kapasitet, kan partisjoner administreres gjennom XMLA-endepunktet ved hjelp av verktøy som SQL Server Management Studio (SSMS), tabellredigeringsprogrammet med åpen kildekode, skriptet med Tabular Model Scripting Language (TMSL) og programmatisk med Tabular Object Model (TOM).

Når du først publiserer en modell til Power Bi-tjeneste, har hver tabell i den nye modellen én partisjon. For tabeller uten policy for trinnvis oppdatering inneholder den ene partisjonen alle rader med data for tabellen, med mindre filtre er brukt. For tabeller med en policy for trinnvis oppdatering finnes det bare én innledende partisjon fordi Power BI ennå ikke har brukt policyen. Du konfigurerer den første partisjonen i Power BI Desktop når du definerer dato/klokkeslett-områdefilteret for tabellen basert på RangeStart parameterne og RangeEnd eventuelle andre filtre som brukes i Power Query-redigering. Denne første partisjonen inneholder bare de radene med data som oppfyller filtervilkårene.

Når du utfører den første oppdateringsoperasjonen, oppdaterer tabeller uten trinnvis oppdateringspolicy alle rader i tabellens standard enkeltpartisjon. Oppdatering og historiske partisjoner opprettes automatisk for tabeller med en trinnvis oppdateringspolicy, og rader lastes inn i dem i henhold til dato/klokkeslett for hver rad. Hvis policyen for trinnvis oppdatering inkluderer å hente data i sanntid, legger Power BI også til en DirectQuery-partisjon i tabellen.

Denne første oppdateringsoperasjonen kan ta litt tid, avhengig av mengden data som må lastes inn fra datakilden. Kompleksiteten i modellen kan også være en viktig faktor fordi oppdateringsoperasjoner må utføre mer behandling og omberegning. Denne operasjonen kan være bootstrapped. Hvis du vil ha mer informasjon, kan du se Forhindre tidsavbrudd ved første fullstendige oppdatering.

Partisjoner opprettes for og navngis etter punktumstetthet: År, kvartaler, måneder og dager. De nyeste partisjonene, oppdateringspartisjonene , inneholder rader i oppdateringsperioden du angir i policyen. Historiske partisjoner inneholder rader etter fullstendig periode frem til oppdateringsperioden. Hvis sanntid er aktivert, henter en DirectQuery-partisjon opp eventuelle dataendringer som oppstod etter sluttdatoen for oppdateringsperioden. Detaljnivå for oppdateringer og historiske partisjoner er avhengig av oppdaterings- og historiske perioder du velger når du definerer policyen.

Hvis dagens dato for eksempel er 2. februar 2021 og FactInternetSales-tabellen på datakilden inneholder rader opp til og med i dag, hvis policyen vår angir å inkludere endringer i sanntid, oppdatere rader i den siste oppdateringsperioden på én dag og lagre rader i den historiske perioden de siste tre årene. Deretter opprettes en DirectQuery-partisjon for endringer i fremtiden, en ny importpartisjon opprettes for dagens rader, en historisk partisjon opprettes for i går, en hel dagsperiode, 1. februar 2021. En historisk partisjon opprettes for forrige hele måned (januar 2021), en historisk partisjon opprettes for forrige hele årsperiode (2020), og historiske partisjoner for hele 2019- og 2018-periodene opprettes. Ingen partisjoner for hele kvartalet opprettes fordi vi ennå ikke har fullført det første hele kvartalet i 2021.

Diagram shows the partition naming granularity described in the text.

Med hver oppdateringsoperasjon oppdateres bare partisjonene for oppdateringsperioden, og datofilteret for DirectQuery-partisjonen oppdateres slik at bare de endringene som skjer etter gjeldende oppdateringsperiode. En ny oppdateringspartisjon opprettes for nye rader med en ny dato/klokkeslett i den oppdaterte oppdateringsperioden, og eksisterende rader med en dato/klokkeslett som allerede finnes i eksisterende partisjoner i oppdateringsperioden, oppdateres med oppdateringer. Rader med en dato/klokkeslett som er eldre enn oppdateringsperioden, oppdateres ikke lenger.

Når hele perioder lukkes, slås partisjoner sammen. Hvis for eksempel en oppdateringsperiode på én dag og tre års historisk lagringsperiode er angitt i policyen, slås partisjoner for forrige måned sammen til en månedspartisjon på den første dagen i måneden. På den første dagen i et nytt kvartal slås alle tre forrige måneds partisjoner sammen til en kvartalspartisjon. På den første dagen i et nytt år slås alle de fire forrige kvartalspartisjonene sammen til en årspartisjon.

En modell beholder alltid partisjoner for hele den historiske lagringsperioden pluss hele periodepartisjoner opp gjennom gjeldende oppdateringsperiode. I eksemplet beholdes hele tre år med historiske data i partisjoner for 2018, 2019, 2020 og partisjoner for 2021Q101-månedersperioden, 2021Q10201-dagsperioden og partisjonen for gjeldende dagoppdateringsperiode. Fordi eksemplet beholder historiske data i tre år, beholdes partisjonen for 2018 til den første oppdateringen 1. januar 2022.

Med trinnvis oppdatering av Power BI og sanntidsdata håndterer tjenesten partisjonsbehandlingen for deg basert på policyen. Selv om tjenesten kan håndtere all partisjonsbehandling for deg, kan du selektivt oppdatere partisjoner individuelt, sekvensielt eller parallelt ved hjelp av verktøy gjennom XMLA-endepunktet.

Oppdateringsbehandling med SQL Server Management Studio

SQL Server Management Studio (SSMS) kan brukes til å vise og administrere partisjoner som er opprettet av programmet for policyer for trinnvis oppdatering. Ved å bruke SSMS kan du for eksempel oppdatere en bestemt historisk partisjon som ikke er i den trinnvise oppdateringsperioden, for å utføre en tilbakedatert oppdatering uten å måtte oppdatere alle historiske data. SSMS kan også brukes når du starter opp for å laste inn historiske data for store modeller ved trinnvis å legge til/oppdatere historiske partisjoner i grupper.

Screenshot shows the Partitions window in SSMS.

Overstyr virkemåte for trinnvis oppdatering

Med SSMS har du også mer kontroll over hvordan du aktiverer oppdateringer ved hjelp av tabellmodellskriptspråk og tabellobjektmodellen. Høyreklikk for eksempel en tabell i Objektutforsker i SSMS, og velg deretter menyalternativet Prosesstabell , og velg deretter Skript-knappen for å generere en TMSL-oppdateringskommando.

Screenshot shows the Script button in Process Table dialog.

Disse parameterne kan brukes med TMSL-oppdateringskommandoen for å overstyre standard virkemåte for trinnvis oppdatering:

  • applyRefreshPolicy. Hvis en tabell har definert en policy for trinnvis oppdatering, applyRefreshPolicy bestemmer du om policyen brukes eller ikke. Hvis policyen ikke brukes, lar en prosess fullstendig operasjon partisjonsdefinisjonene være uendret, og alle partisjoner i tabellen oppdateres fullstendig. Standardverdien er sann.

  • effectiveDate. Hvis en policy for trinnvis oppdatering brukes, må den vite gjeldende dato for å bestemme rullende vindusområder for trinnvis oppdatering og historiske perioder. Parameteren effectiveDate lar deg overstyre gjeldende dato. Denne parameteren er nyttig for testing, demonstrasjoner og forretningsscenarioer der data oppdateres trinnvis frem til en dato i fortiden eller fremtiden, for eksempel budsjetter i fremtiden. Standardverdi er gjeldende dato.

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

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

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

Hvis du vil lære mer om å overstyre standard virkemåte for trinnvis oppdatering med TMSL, kan du se Oppdater-kommandoen.

Sikre optimal ytelse

For hver oppdateringsoperasjon kan Power Bi-tjeneste sende initialiseringsspørringer til datakilden for hver partisjon for trinnvis oppdatering. Du kan kanskje forbedre ytelsen for trinnvis oppdatering ved å redusere antall initialiseringsspørringer ved å sikre følgende konfigurasjon:

  • Tabellen du konfigurerer trinnvis oppdatering for, skal hente data fra én enkelt datakilde. Hvis tabellen henter data fra mer enn én datakilde, multipliseres antall spørringer som sendes av tjenesten for hver oppdateringsoperasjon, med antall datakilder, noe som kan redusere oppdateringsytelsen. Kontroller at spørringen for tabellen for trinnvis oppdatering er for én enkelt datakilde.
  • For løsninger med både trinnvis oppdatering av importpartisjoner og sanntidsdata med Direct Query, må alle partisjoner spørre etter data fra én enkelt datakilde.
  • Hvis sikkerhetskravene tillater det, angir du innstillingen for personvernnivået for datakilden til Organisasjon eller Offentlig. Personvernnivået er privat som standard, men dette nivået kan forhindre at data utveksles med andre skykilder. Hvis du vil angi personvernnivået, velger du Flere alternativer-menyen og velger deretter Innstillinger> Datakildelegitimasjon>Rediger>legitimasjon for personvernnivå for denne datakilden. Hvis personvernnivået er angitt i Power BI Desktop-modellen før publisering til tjenesten, overføres den ikke til tjenesten når du publiserer. Du må fortsatt angi den i semantiske modellinnstillinger i tjenesten. Hvis du vil ha mer informasjon, kan du se Personvernnivåer.
  • Hvis du bruker en lokal datagateway, må du kontrollere at du bruker versjon 3000.77.3 eller nyere.

Forhindre tidsavbrudd ved første fullstendige oppdatering

Når du har publisert til Power Bi-tjeneste, oppretter den første fullstendige oppdateringsoperasjonen for modellen partisjoner for tabellen for trinnvis oppdatering, laster inn og behandler historiske data for hele perioden som er definert i policyen for trinnvis oppdatering. For noen modeller som laster inn og behandler store mengder data, kan tiden den første oppdateringsoperasjonen tar, overskride oppdateringstidsgrensen som kreves av tjenesten eller en tidsbegrensning for spørringen som datakilden pålegger.

Bootstrapping av den første oppdateringsoperasjonen gjør det mulig for tjenesten å opprette partisjonsobjekter for tabellen for trinnvis oppdatering, men ikke laste inn og behandle historiske data i noen av partisjonene. SSMS brukes deretter til selektivt å behandle partisjoner. Avhengig av mengden data som skal lastes inn for hver partisjon, kan du behandle hver partisjon sekvensielt eller i små grupper for å redusere potensialet for at én eller flere av disse partisjonene kan føre til et tidsavbrudd. Følgende metoder fungerer for alle datakilder.

Bruk oppdateringspolicy

Verktøyet for tabellredigering med åpen kildekode 2 gir en enkel måte å starte en første oppdateringsoperasjon på. Når du har publisert en modell med en policy for trinnvis oppdatering definert for den fra Power BI Desktop til tjenesten, kobler du til modellen ved hjelp av XMLA-endepunktet i lese-/skrivemodus. Kjør Bruk oppdateringspolicy i tabellen for trinnvis oppdatering. Når bare policyen brukes, opprettes partisjoner, men ingen data lastes inn i dem. Koble deretter til SSMS for å oppdatere partisjonene sekvensielt eller i grupper for å laste inn og behandle dataene. Hvis du vil ha mer informasjon, kan du se Trinnvis oppdatering i dokumentasjonen for tabellredigeringsprogrammet.

Screenshot show the Tabular Editor with Apply Refresh Policy selected.

Power Query-filter for tomme partisjoner

Før du publiserer modellen til tjenesten, legger du i Power Query-redigering til et annet filter ProductKey i kolonnen som filtrerer ut en annen verdi enn 0, effektivt eller filtrerer ut alle data fra FactInternetSales-tabellen.

Screenshot shows the Power Query Editor with code that filters out the product key.

Når du har valgt Lukk og bruk i Power Query-redigering, definert policyen for trinnvis oppdatering og lagring av modellen, publiseres modellen til tjenesten. Fra tjenesten kjøres den første oppdateringsoperasjonen på modellen. Partisjoner for FactInternetSales-tabellen opprettes i henhold til policyen, men ingen data lastes inn og behandles fordi alle data filtreres ut.

Når den første oppdateringsoperasjonen er fullført, fjernes det andre filteret ProductKey i kolonnen i Power Query-redigering. Når du har valgt Lukk og bruk i Power Query-redigering og lagret modellen, publiseres ikke modellen på nytt. Hvis modellen publiseres på nytt, overskriver den policyinnstillingene for trinnvis oppdatering og tvinger frem en fullstendig oppdatering på modellen når en etterfølgende oppdateringsoperasjon utføres fra tjenesten. Utfør i stedet bare en distribusjon av metadata ved hjelp av verktøyet for programlivssyklusbehandling (ALM) som fjerner filteret ProductKey på kolonnen fra modellen. SSMS kan deretter brukes til selektivt å behandle partisjoner. Når alle partisjoner er fullstendig behandlet, som må inkludere en prosessberegning på alle partisjoner, fra SSMS, vil etterfølgende oppdateringsoperasjoner på modellen fra tjenesteoppdateringen bare være de trinnvise oppdateringspartisjonene.

Tips

Pass på å sjekke ut videoer, blogger og mer levert av Power BIs fellesskap av BI-eksperter.

Hvis du vil lære mer om behandling av tabeller og partisjoner fra SSMS, kan du se Prosessdatabase, tabell eller partisjoner (Analysis Services). Hvis du vil lære mer om behandling av modeller, tabeller og partisjoner ved hjelp av TMSL, kan du se Oppdater-kommandoen (TMSL).

Egendefinerte spørringer for å oppdage dataendringer

TMSL og TOM kan brukes til å overstyre virkemåten for oppdagede dataendringer. Ikke bare kan denne metoden brukes til å unngå å beholde den siste oppdateringskolonnen i minnehurtigbufferen, og den kan aktivere scenarioer der en konfigurasjons- eller instruksjonstabell klargjøres ved å trekke ut, transformere og laste inn (ETL)-prosesser for å flagge bare partisjonene som må oppdateres. Denne metoden kan opprette en mer effektiv trinnvis oppdateringsprosess der bare de nødvendige periodene oppdateres, uansett hvor lenge siden dataoppdateringer fant sted.

Er pollingExpression ment å være et lett M-uttrykk eller navn på en annen M-spørring. Den må returnere en skalarverdi og kjøres for hver partisjon. Hvis den returnerte verdien er forskjellig fra det som var siste gang en trinnvis oppdatering oppstod, flagges partisjonen for full behandling.

Eksemplet nedenfor dekker alle 120 månedene i den historiske perioden for tilbakedaterte endringer. Å angi 120 måneder i stedet for 10 år betyr at datakomprimering kanskje ikke er fullt så effektivt, men unngår å måtte oppdatere et helt historisk år, noe som ville vært dyrere når en måned ville være tilstrekkelig for en tilbakedatert endring.

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

Tips

Pass på å sjekke ut videoer, blogger og mer levert av Power BIs fellesskap av BI-eksperter.

Bare metadatadistribusjon

Når du publiserer en ny versjon av en PBIX-fil fra Power BI Desktop til et arbeidsområde, blir du bedt om å erstatte den eksisterende modellen hvis en modell med samme navn allerede finnes.

Screenshot shows the Replace model dialog.

I noen tilfeller vil du kanskje ikke erstatte modellen, spesielt med trinnvis oppdatering. Modellen i Power BI Desktop kan være mye mindre enn den i Power Bi-tjeneste. Hvis modellen i Power Bi-tjeneste har en policy for trinnvis oppdatering, kan det ha flere år med historiske data som vil gå tapt hvis modellen erstattes. Oppdatering av alle historiske data kan ta timer og føre til systemstans for brukere.

I stedet er det bedre å utføre bare metadatadistribusjon, noe som gjør det mulig å distribuere nye objekter uten å miste de historiske dataene. Hvis du for eksempel har lagt til noen mål, kan du distribuere bare de nye målene uten å måtte oppdatere dataene, noe som sparer tid.

For arbeidsområder som er tilordnet en Premium-kapasitet som er konfigurert for XMLA-endepunkt lest/skrevet, aktiverer kompatible verktøy bare distribusjon av metadata. ALM Toolkit er for eksempel et skjema diff-verktøy for Power BI-modeller og kan brukes til å utføre bare distribusjon av metadata.

Last ned og installer den nyeste versjonen av ALM Toolkit fra Analysis Services Git-repositoriet. Trinnvis veiledning om bruk av ALM Toolkit er ikke inkludert i Microsoft-dokumentasjonen. ALM-verktøysettdokumentasjonskoblinger og informasjon om støtte er tilgjengelig på Hjelp-båndet. Hvis du bare vil utføre en distribusjon av metadata, utfører du en sammenligning og velger den kjørende Power BI Desktop-forekomsten som kilde, og den eksisterende modellen i Power Bi-tjeneste som mål. Vurder forskjellene som vises, og hopp over oppdateringen av tabellen med trinnvise oppdateringspartisjoner, eller bruk dialogboksen Alternativer til å beholde partisjoner for tabelloppdateringer. Valider utvalget for å sikre integriteten til målmodellen og deretter oppdatere.

Screenshot shows the ALM Toolkit window.

Legge til en policy for trinnvis oppdatering og sanntidsdata programmatisk

Du kan også bruke TMSL og TOM til å legge til en trinnvis oppdateringspolicy i en eksisterende modell gjennom XMLA-endepunktet.

Merk

Hvis du vil unngå kompatibilitetsproblemer, må du kontrollere at du bruker den nyeste versjonen av Analysis Services-klientbibliotekene. Hvis du for eksempel vil arbeide med hybridpolicyer, må versjonen være 19.27.1.8 eller nyere.

Prosessen omfatter følgende trinn:

  1. Kontroller at målmodellen har det nødvendige minimumskompatibilitetsnivået. Høyreklikk på kompatibilitetsnivået [modellnavn]>Egenskaper>i SSMS. Hvis du vil øke kompatibilitetsnivået, bruker du enten et createOrReplace TMSL-skript eller kontrollerer følgende TOM-eksempelkode for eksempel.

    a. Import policy - 1550
b. Hybrid policy - 1565

  2. RangeStart Legg til og RangeEnd parameterne i modelluttrykkene. Hvis det er nødvendig, kan du også legge til en funksjon for å konvertere dato/klokkeslett-verdier til datonøkler.

  3. Definer et RefreshPolicy objekt med ønsket arkivering (rullende vindu) og trinnvise oppdateringsperioder samt et kildeuttrykk som filtrerer måltabellen RangeStart basert på og RangeEnd parameterne. Angi oppdateringspolicymodusen til Importer eller Hybrid , avhengig av datakravene i sanntid. Hybrid fører til at Power BI legger til en DirectQuery-partisjon i tabellen for å hente de siste endringene fra datakilden som oppstod etter forrige oppdateringstidspunkt.

  4. Legg til oppdateringspolicyen i tabellen, og utfør en fullstendig oppdatering slik at Power BI partisjonerer tabellen i henhold til dine krav.

Følgende kodeeksempel viser hvordan du utfører de forrige trinnene ved hjelp av TOM. Hvis du vil bruke dette eksemplet som det er, må du ha en kopi for AdventureWorksDW-databasen og importere FactInternetSales-tabellen til en modell. Kodeeksempelet RangeStart forutsetter at parameterne RangeEnd og DateKey funksjonen ikke finnes i modellen. Bare importer FactInternetSales-tabellen og publiser modellen til et arbeidsområde på Power BI Premium. workspaceUrl Oppdater deretter slik at kodeeksempelet kan koble til modellen. Oppdater flere kodelinjer etter 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();
        }
    }
}

Relatert innhold