Avancerad inkrementell uppdatering med XMLA-slutpunkten

Datauppsättningar i en Premium-kapacitet med XMLA-slutpunkten aktiverad för läs- och skrivåtgärder tillåter mer avancerad uppdatering av datauppsättning, partitionshantering och endast metadatadistributioner via verktyg, skript och API-stöd. Dessutom är uppdateringsåtgärder via XMLA-slutpunkten inte begränsade till 48uppdateringar per dag och tidsgränsen för schemalagd uppdatering tillämpas inte.

Partitioner

Datamängdstabellpartitioner visas inte och kan inte hanteras i tjänsten. För datauppsättningar på en arbetsyta som tilldelats till en Premium-kapacitet kan partitioner hanteras via XMLA-slutpunkten med hjälp av verktyg som SQL Server Management Studio (SSMS), tabular-redigeraren med öppen källkod, skriptat med TMSL (Tabular Model Scripting Language) och programmatiskt med tabellobjektsmodellen (TOM).

Första gången du publicerar en modell till tjänsten har varje tabell i den nya datauppsättningen en partition. För tabeller utan inkrementell uppdateringsprincip innehåller den partitionen alla datarader för tabellen (såvida inte filter har tillämpats). För tabeller med en princip för inkrementell uppdatering innehåller en partition endast de rader med data som definieras av datum-/tidsintervallfiltret baserat på parametrarna RangeStart och RangeEnd och eventuella andra filter som tillämpas i Power Query Editor.

När du utför den första uppdateringsåtgärden för datauppsättningen uppdaterar tabeller utan inkrementell uppdateringsprincip alla rader som finns i den tabellens standardpartition. För tabeller med en princip för inkrementell uppdatering skapas uppdateringar och historiska partitioner automatiskt och rader läses in i dem enligt datum/tid för varje rad.

Den första uppdateringsåtgärden kan ta en stund 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 ytterligare bearbetning och omberäkning. Den här åtgärden kan bootstrappas. Mer information finns i Förhindra tidsgränser vid inledande fullständig uppdatering senare i den här artikeln.

Partitioner skapas för och namnges efter periodkornighet: År, kvartal, månader och dagar. De senaste partitionerna, uppdateringspartitionerna, innehåller rader i uppdateringsperioden som du anger i principen. Historiska partitioner innehåller rader efter fullständig period fram till uppdateringsperioden. Detaljnivå för uppdatering och historiska partitioner är beroende av de uppdaterings- och historiska (lagrings)-perioder som du väljer när du definierar principen.

Om dagens datum till exempel är 2 februari 2021 och vår FactInternetSales-tabell vid datakällan innehåller rader fram till idag, om vår princip anger uppdateringsrader under den senaste dagen (uppdateringsperiod) och lagrar rader under de senaste tre åren (historisk period), skapas sedan en ny partition för dagens rader med den första uppdateringsåtgärden. en historisk partition skapas för gårdagen, en hel dagsperiod (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 helt årsperiod (2020) och historiska partitioner för hela år 2019 och 2018 skapas. Inga partitioner för hela kvartalet skapas eftersom vi ännu inte har slutfört det första fullständiga kvartalet 2021.

För varje uppdateringsåtgärd uppdateras endast uppdateringsperiodens partitioner. En ny partition skapas för nya rader med ett nytt datum/tid och befintliga rader med ett datum/tid som redan finns i befintliga partitioner i uppdateringsperioden uppdateras med uppdateringar. Rader med ett datum/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 sammanfogas alla dagpartitioner för föregående månad i 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 i en kvartalspartition. Den första dagen på ett nytt år sammanfogas alla fyra föregående kvartalspartitioner med en årspartition.

En datauppsättning behåller alltid partitioner för hela den historiska lagringsperioden plus hela periodpartitioner upp till den aktuella uppdateringsperioden. I vårt exempel ovan bevaras hela tre års historiska data i partitioner för 2018, 2019, 2020 och partitioner för 2021Q101-månadsperioden, 2021Q10201-dagsperioden och den aktuella daguppdateringsperiodens partition. Eftersom vi valde att behålla historiska data i tre år bevaras partitionen 2018 fram till den första uppdateringen den 1 januari 2022.

Med Power BI inkrementell uppdatering hanterar tjänsten partitionshanteringen åt dig baserat på principen. Om du någonsin har arbetat med Analysis Services vet du att effektiv partitionering innebär att skapa en programmatisk lösning ofta med tusentals rader kod. 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 (SSMS)

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 är inom 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 datamängder genom att stegvis lägga till/uppdatera historiska partitioner i batchar.

Åsidosätt stegvisa uppdateringar

Med SSMS har du också mer kontroll över hur du anropar uppdateringar med hjälp av TMSL (Tabular Model Scripting Language) och TOM (Tabular Object Model). I SSMS går du till Object Explorer, högerklickar på en tabell och väljer menyalternativet Bearbeta tabell och klickar sedan på 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 stegvis uppdateringsprincip kommer applyRefreshPolicy att avgöra om principen tillämpas eller inte. Om principen inte tillämpas lämnar en fullständig processåtgärd partitionsdefinitioner oförändrade och alla partitioner i tabellen uppdateras helt och hållet. Standardvärdet är True.

• effectiveDate – Om en princip för inkrementell uppdatering tillämpas måste den känna till det aktuella datumet för att fastställa rullande fönsterintervall för den inkrementella uppdateringen och historiska perioder. Med parametern effectiveDate kan du åsidosätta det aktuella datumet. Den här parametern är användbar för testning, demonstrationer och affärsscenarier där data stegvis uppdateras fram till ett tidigare eller framtida datum (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" 
      }
    ]
  }
}

Om du vill läsa mer om hur du åsidosätter standardvärdet för stegvis uppdatering med TMSL, se Uppdateringskommando.

Säkerställa optimala prestanda

Med varje uppdateringsåtgärd kan Power BI skicka initieringsfrågor till datakällan för varje inkrementell uppdateringspartition. Du kan kanske förbättra prestandan för inkrementell uppdatering genom att minska antalet initieringsfrågor genom att se till att följande:

• 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 fler ä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 den inkrementella uppdateringstabellen gäller för en enskild 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 data från att utbytas med andra molnkällor. Ange sekretessnivå i Datauppsättning Inställningar > Autentiseringsuppgifter för > datakälla Redigera autentiseringsuppgifter > Sekretessnivåinställning för den här datakällan. Om Sekretessnivå anges i Power BI Desktop innan du publicerar till tjänsten överförs den inte till tjänsten när du publicerar. Du måste fortfarande ange den i datauppsättningsinställningarna i tjänsten. Mer information finns i Sekretessnivåer.
• Om du använder en lokal datagateway måste du använda version 3000.77.3 eller senare.

Förhindra tidsgränser vid första fullständiga uppdatering

När du har publicerat till tjänsten skapar den första fullständiga uppdateringsåtgärden för datauppsättningen 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 datauppsättningar som kommer att läsa in och bearbeta stora mängder data kan den tid som den första uppdateringsåtgärden tar överskrida den tidsgräns för uppdatering som införts av tjänsten eller en tidsgräns för frågor som införts av datakällan.

Start av den första uppdateringsåtgärden gör att tjänsten kan skapa partitionsobjekt för den inkrementella uppdateringstabellen, men inte läsa in och bearbeta historiska data i någon av partitionerna. SSMS används sedan för att selektivt bearbeta partitioner. Beroende på hur mycket 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 tidsgräns. 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 bootstrapa en inledande uppdateringsåtgärd. När du har publicerat en modell med en definierad princip för inkrementell uppdatering från Power BI Desktop till tjänsten ansluter du till datauppsättningen med hjälp av XMLA-slutpunkten i läs-/skrivläge. Kör Tillämpa uppdateringsprincip på den inkrementella uppdateringstabellen. När endast principen tillämpas 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 dokument om tabellredigeraren.

Power Query för tomma partitioner

Innan du publicerar modellen till tjänsten lägger du i Power Query Editor till ytterligare ett filter i kolumnen ProductKey som filtrerar ut ett annat värde än 0, eller filtrerar bort alla data från tabellen FactInternetSales.

När du klickar & På Power Query-redigeraren, definierar principen för inkrementell uppdatering och sparar modellen publiceras modellen till tjänsten. Från tjänsten körs den första uppdateringsåtgärden på datauppsättningen. Partitioner för tabellen FactInternetSales skapas enligt principen, men inga data läses in och bearbetas eftersom alla data filtreras bort.

När den inledande uppdateringsåtgärden är klar tas det ytterligare filtret Power Query productkey-kolumnen bort i Power Query Editor. När du har klickat & på & tillämpa i Power Query-redigeraren och sparat modellen publiceras modellen inte igen. Om modellen publicerades igen skulle den skriva över principinställningarna för inkrementell uppdatering och tvinga fram en fullständig uppdatering av datauppsättningen när en efterföljande uppdateringsåtgärd utförs från tjänsten. I stället utför du en distribution med endast metadata med ALM Toolkit som tar bort filtret på kolumnen ProductKey från datauppsättningen . SSMS kan sedan användas för att selektivt bearbeta partitioner. När alla partitioner har bearbetats fullständigt (som måste innehålla en omberäkning av processen på alla partitioner) från SSMS, uppdaterar efterföljande uppdateringsåtgärder på datauppsättningen från tjänsten endast de inkrementella uppdateringspartitionerna.

Mer information om hur du bearbetar tabeller och partitioner från SSMS finns i Bearbeta databas, tabell eller partitioner (Analysis Services). Mer information om hur du bearbetar datauppsättningar, tabeller och partitioner med hjälp av TMSL finns i Uppdatera kommando (TMSL).

Anpassade frågor för att identifiera dataändringar

TMSL och/eller 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 cacheminnet i minnet. Den kan även möjliggöra scenarier där en konfigurations-/instruktionstabell förbereds av ETL-processer för att endast 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 avsedd att vara ett enkelt M-uttryck eller ett namn på en annan M-fråga. Det måste returnera ett skalvärde och kommer att köras för varje partition. Om det returnerade värdet är annorlunda mot den senaste stegvisa uppdateringen flaggas partitionen för fullständig bearbetning.

I följande exempel omfattar alla 120 månader i den historiska perioden för backdated ä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 räcker för en bakåtkomprimerad ä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, uppmanas du att ersätta den befintliga datauppsättningen om det redan finns en datauppsättning med samma namn.

I vissa fall kanske du inte vill ersätta datauppsättningen, särskilt med inkrementell uppdatering. Datauppsättningen i Power BI Desktop kan vara mycket mindre än den i tjänsten. Om datauppsättningen i tjänsten har en tillämpad princip för stegvis uppdatering, kan flera år av historiska data gå förlorade om datauppsättningen ersätts. Det kan ta flera timmar att uppdatera alla historiska data vilket kan leda till systemstillestånd för användare.

I stället är det bättre att utföra en distribution med endast 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 mycket tid.

För arbetsytor som tilldelats till en Premium kapacitet som konfigurerats för xmla-slutpunkter möjliggör kompatibla verktyg endast distribution av metadata. ALM Toolkit är till exempel ett schema differentieringsverktyg för Power BI-datauppsättningar och kan bara användas för att utföra distribution av metadata.

Hämta och installera den senaste versionen av ALM Toolkit från Analysis Services-gitlagringsplatsen. Stegvisa anvisningar 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 aktiva Power BI Desktop-instansen som källa och den befintliga datauppsättningen i 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. Bekräfta valet för att säkerställa integriteten för målmodellen och uppdatera den sedan.

Se även

Partitioner i tabellmodeller
Externa verktyg för Power BI
Konfigurera schemalagd uppdatering
Felsöka inkrementell uppdatering