Geavanceerd incrementeel vernieuwen met het XMLA-eindpunt

Gegevenssets in een Premium-capaciteit met het XMLA-eindpunt ingeschakeld voor lees-/schrijfbewerkingen maken geavanceerdere vernieuwing van gegevenssets, partitiebeheer en alleen implementaties van metagegevens mogelijk via hulpprogramma-, script- en API-ondersteuning. Bovendien zijn vernieuwingsbewerkingen via het XMLA-eindpunt niet beperkt tot 48vernieuwingen per dag en wordt de geplande vernieuwingstijdslimiet niet opgelegd.

Partities

Gegevenssettabelpartities zijn niet zichtbaar en kunnen niet worden beheerd in de service. Voor gegevenssets in een werkruimte die is toegewezen aan een Premium-capaciteit, kunnen partities worden beheerd via het XMLA-eindpunt met behulp van hulpprogramma's zoals SQL Server Management Studio (SSMS), de opensource Tabular Editor, scripted met Tabular Model Scripting Language (TMSL) en programmatisch met het Tabular Object Model (TOM).

Wanneer u voor het eerst een model naar de service publiceert, heeft elke tabel in de nieuwe gegevensset één partitie. Voor tabellen zonder beleid voor incrementeel vernieuwen bevat die ene partitie alle rijen met gegevens voor die tabel (tenzij er filters zijn toegepast). Voor tabellen met een beleid voor incrementeel vernieuwen bevat die ene partitie alleen de rijen met gegevens die zijn gedefinieerd door het datum-/tijdbereikfilter op basis van de parameters RangeStart en RangeEnd en andere filters die zijn toegepast in Power Query Editor.

Wanneer u de eerste vernieuwingsbewerking voor gegevenssets hebt uitgevoerd, worden alle rijen in de standaardpartitie van die tabel vernieuwd door tabellen zonder incrementeel vernieuwingsbeleid. Voor tabellen met een beleid voor incrementeel vernieuwen worden automatisch vernieuwingspartities en historische partities gemaakt en worden rijen in deze partities geladen op basis van de datum/tijd voor elke rij.

Deze eerste vernieuwingsbewerking kan enige tijd duren, afhankelijk van de hoeveelheid gegevens die uit de gegevensbron moet worden geladen. De complexiteit van het model kan ook een belangrijke factor zijn omdat vernieuwingsbewerkingen extra verwerking en herberekening moeten uitvoeren. Deze bewerking kan worden gebootstrapt. Zie Time-outs voorkomen bij initiële volledige vernieuwing verder in dit artikel voor meer informatie.

Partities worden gemaakt voor en benoemd op puntgranulatie: Jaren, kwartalen, maanden en dagen. De meest recente partities, de vernieuwingspartities, bevatten rijen in de vernieuwingsperiode die u in het beleid opgeeft. Historische partities bevatten rijen per volledige periode tot de vernieuwingsperiode. Granulariteit voor vernieuwing en historische partities is afhankelijk van de vernieuwings- en historische perioden (winkel) die u kiest bij het definiëren van het beleid.

Als de datum van vandaag bijvoorbeeld 2 februari 2021 is en onze tabel FactInternetSales in de gegevensbron rijen bevat tot vandaag, als ons beleid vernieuwingsrijen op de laatste dag (vernieuwingsperiode) specificeert en rijen opgeslagen in de afgelopen drie jaar (historische periode), wordt er met de eerste vernieuwingsbewerking een nieuwe partitie gemaakt voor de rijen van vandaag, een historische partitie wordt gemaakt voor gisteren, een hele dag periode (1 februari 2021), een historische partitie wordt gemaakt voor de vorige hele maand periode (januari 2021), een historische partitie wordt gemaakt voor de periode van het vorige hele jaar (2020), en historische partities voor 2019 en 2018 hele jaar perioden worden gemaakt. Er worden geen hele kwartaalpartities gemaakt omdat we het eerste volledige kwartaal van 2021 nog niet hebben voltooid.

Bij elke vernieuwingsbewerking worden alleen de partities voor de vernieuwingsperiode vernieuwd. Er wordt een nieuwe partitie gemaakt voor nieuwe rijen met een nieuwe datum/tijd, en bestaande rijen met een datum/tijd binnen bestaande partities in de vernieuwingsperiode worden vernieuwd met updates. Rijen met een datum/tijd die ouder is dan de vernieuwingsperiode, worden niet meer vernieuwd.

Wanneer hele perioden worden gesloten, worden partities samengevoegd. Als er bijvoorbeeld een vernieuwingsperiode van één dag en een periode van drie jaar voor een historische opslag zijn opgegeven in het beleid, worden op de eerste dag van de maand alle dagpartities voor de vorige maand samengevoegd in een maandpartitie. Op de eerste dag van een nieuw kwartaal worden alle drie de partities van de vorige maand samengevoegd in een kwartaalpartitie. Op de eerste dag van een nieuw jaar worden alle vier de vorige kwartaalpartities samengevoegd in een jaarpartitie.

Een gegevensset behoudt partities altijd voor de hele historische opslagperiode plus gehele periodepartities tot en met de huidige vernieuwingsperiode. In ons bovenstaande voorbeeld wordt een volledige drie jaar aan historische gegevens bewaard in partities voor 2018, 2019, 2020 en ook partities voor de periode 2021Q101, de periode van 2021Q10201 en de partitie van de vernieuwingsperiode van de huidige dag. Omdat we ervoor hebben gekozen om historische gegevens drie jaar te bewaren, wordt de partitie van 2018 bewaard tot de eerste vernieuwing op 1 januari 2022.

Met Power BI incrementeel vernieuwen verwerkt de service het partitiebeheer voor u op basis van het beleid. Als u ooit in een Analysis Services hebt gewerkt, weet u dat voor effectieve partitionering vaak een programmatische oplossing met duizenden regels code moet worden gemaakt. Hoewel de service al het partitiebeheer voor u kan verwerken, kunt u partities afzonderlijk, sequentaal of parallel afzonderlijk vernieuwen met behulp van hulpprogramma's via het XMLA-eindpunt.

Vernieuwingen beheren met SQL Server Management Studio (SSMS)

SSMS kan worden gebruikt voor het weergeven en beheren van partities die zijn gemaakt door de toepassing van beleid voor incrementeel vernieuwen. Met behulp van SSMS kunt u bijvoorbeeld een specifieke historische partitie vernieuwen die zich niet in de incrementele vernieuwingsperiode voor het uitvoeren van een back-dated update zonder dat u alle historische gegevens moet vernieuwen. SSMS kan ook worden gebruikt bij het opstarten om historische gegevens voor grote gegevenssets te laden door historische partities incrementeel toe te voegen/te vernieuwen in batches.

Gedrag van incrementeel vernieuwen onderschrijven

Met SSMS hebt u ook meer controle over het aanroepen van vernieuwingen met behulp van Tabular Model Scripting Language (TMSL) en tabular Object Model (TOM). Klik bijvoorbeeld in SSMS in Objectverkenner met de rechtermuisknop op een tabel en selecteer vervolgens de menuoptie Tabel verwerken en klik vervolgens op de knop Script om een TMSL-vernieuwingsopdracht te genereren.

Deze parameters kunnen worden gebruikt met de TMSL-vernieuwingsopdracht om het standaardgedrag voor incrementeel vernieuwen te overschrijven:

• applyRefreshPolicy: als er een beleid voor incrementeel vernieuwen is gedefinieerd voor een tabel, bepaalt applyRefreshPolicy of het beleid wordt toegepast. Als het beleid niet wordt toegepast en u een volledige bewerking verwerkt, worden partitiedefinities ongewijzigd gelaten en worden alle partities in de tabel volledig vernieuwd. De standaardwaarde is Waar.

• effectiveDate: als er een beleid voor incrementeel vernieuwen wordt toegepast, moet het weten wat de huidige datum is om de lopende vensterbereiken voor de incrementele vernieuwing en historische perioden te bepalen. Met de parameter effectiveDate kunt u de huidige datum onderschrijven. Deze parameter is handig voor het testen, demo's en bedrijfsscenario's waarbij gegevens incrementeel worden vernieuwd tot een datum in het verleden of de toekomst (bijvoorbeeld budgetten in de toekomst). De standaardwaarde is de huidige datum.

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

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

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

Zie Vernieuwingsopdracht voor meer informatie over standaardgedrag bij incrementeel vernieuwen met TMSL.

Optimale prestaties garanderen

Bij elke vernieuwingsbewerking kan de Power BI-service initialisatiequery's verzenden naar de gegevensbron voor elke incrementele vernieuwingspartitie. U kunt mogelijk de prestaties van incrementeel vernieuwen verbeteren door het aantal initialisatiequery's te verminderen door het volgende te garanderen:

• De tabel waar u incrementeel vernieuwen voor configureert, moet gegevens uit één gegevensbron op halen. Als de tabel gegevens uit meer dan één gegevensbron opvraagt, wordt het aantal query's dat door de service wordt verzonden voor elke vernieuwingsbewerking vermenigvuldigd met het aantal gegevensbrons, waardoor de prestaties van het vernieuwen mogelijk worden verkleind. Zorg ervoor dat de query voor de tabel incrementeel vernieuwen voor één gegevensbron is.
• Als uw beveiligingsvereisten dit toestaan, stelt u de instelling Privacyniveau gegevensbron in op Organisatie of Openbaar. Het privacyniveau is standaard Privé, maar dit niveau kan voorkomen dat gegevens worden uitgewisseld met andere cloudbronnen. Privacyniveau instellen in Gegevensset Instellingen > Referenties voor gegevensbronInstelling privacyniveau voor deze > > gegevensbron bewerken. Als het privacyniveau in het Power BI Desktop is ingesteld voordat het naar de service wordt gepubliceerd, wordt het niet overgedragen naar de service wanneer u publiceert. U moet deze nog steeds instellen in de gegevenssetinstellingen in de service. Zie Privacyniveaus voor meer informatie.
• Als u een on-premises gegevensgateway gebruikt, moet u ervoor zorgen dat u versie 3000.77.3 of hoger gebruikt.

Time-outs voorkomen bij initiële volledige vernieuwing

Nadat de gegevensset naar de service is gepubliceerd, maakt de initiële volledige vernieuwingsbewerking voor de gegevensset partities voor de incrementele vernieuwingstabel, laadt en verwerkt historische gegevens voor de hele periode die is gedefinieerd in het incrementele vernieuwingsbeleid. Voor sommige gegevenssets die grote hoeveelheden gegevens laden en verwerken, kan de tijd die nodig is voor de initiële vernieuwingsbewerking de vernieuwingslimiet overschrijden die is opgelegd door de service of een querytijdslimiet die is opgelegd door de gegevensbron.

Door de initiële vernieuwingsbewerking op te starten, kan de service partitieobjecten maken voor de tabel voor incrementeel vernieuwen, maar geen historische gegevens laden en verwerken in een van de partities. SSMS wordt vervolgens gebruikt om partities selectief te verwerken. Afhankelijk van de hoeveelheid gegevens die voor elke partitie moet worden geladen, kunt u elke partitie opeenvolgend of in kleine batches verwerken om de kans te verkleinen dat een of meer van deze partities een time-out veroorzaken. De volgende methoden werken voor elke gegevensbron.

Vernieuwingsbeleid toepassen

Het opensource-hulpprogramma Tabular Editor 2 biedt een eenvoudige manier om een initiële vernieuwingsbewerking te bootstrappen. Nadat u een model hebt gepubliceerd met een beleid voor incrementeel vernieuwen dat is gedefinieerd vanuit Power BI Desktop naar de service, maakt u verbinding met de gegevensset met behulp van het XMLA-eindpunt in de modus Lezen/schrijven. Voer Beleid voor vernieuwen toepassen uit in de tabel incrementeel vernieuwen. Als alleen het beleid is toegepast, worden er partities gemaakt, maar worden er geen gegevens in geladen. Maak vervolgens verbinding met SSMS om de partities opeenvolgend of in batches te vernieuwen om de gegevens te laden en te verwerken. Zie Incrementeel vernieuwen in de documenten van Tabular Editor voor meer informatie.

Power Query voor lege partities

Voordat u het model naar de service publiceert, voegt u in Power Query Editor nog een filter toe aan de kolom ProductKey, waarin andere waarden dan 0 worden gefilterd, of alle gegevens uit de tabel FactInternetSales worden gefilterd.

Nadat u op Close & Apply in Power Query Editor hebt geklikt, het beleid voor incrementeel vernieuwen hebt definiëren en het model hebt op slaan, wordt het model gepubliceerd naar de service. Vanuit de service wordt de eerste vernieuwingsbewerking uitgevoerd op de gegevensset. Partities voor de tabel FactInternetSales worden gemaakt volgens het beleid, maar er worden geen gegevens geladen en verwerkt omdat alle gegevens worden gefilterd.

Nadat de initiële vernieuwingsbewerking is voltooid, wordt in Power Query Editor het extra filter op de kolom ProductKey verwijderd. Nadat u in Power Query Editor op Close & Hebt geklikt en op Close & hebt geklikt, wordt het model niet opnieuw gepubliceerd. Als het model opnieuw wordt gepubliceerd, worden de beleidsinstellingen voor incrementeel vernieuwen overschreven en wordt een volledige vernieuwing van de gegevensset geforceerd wanneer een volgende vernieuwingsbewerking wordt uitgevoerd vanuit de service. Voer in plaats daarvan een implementatie met alleen metagegevens uit met behulp van ALM Toolkit waarmee het filter voor de kolom ProductKey uit de gegevensset wordt verwijderd. SSMS kan vervolgens worden gebruikt om partities selectief te verwerken. Wanneer alle partities volledig zijn verwerkt (die een herberekening van het proces voor alle partities moeten bevatten) van SSMS, worden in volgende vernieuwingsbewerkingen op de gegevensset van de service alleen de incrementele vernieuwingspartities vernieuwd.

Zie Procesdatabase, tabel of partities (Analysis Services)voor meer informatie over het verwerken van tabellen en partities van SSMS. Zie Opdracht vernieuwen (TMSL)voor meer informatie over het verwerken van gegevenssets, tabellen en partities met behulp van TMSL.

Aangepaste query's voor het detecteren van gegevenswijzigingen

TMSL en/of TOM kunnen worden gebruikt om het gedrag van gedetecteerde gegevenswijzigingen te overschrijven. Deze methode kan niet alleen worden gebruikt om te voorkomen dat de kolom voor de laatste update in de geheugencache wordt opgeslagen, maar kan ook scenario's inschakelen waarbij een configuratie-/instructietabel wordt voorbereid door ETL-processen om alleen de partities te markeren die moeten worden vernieuwd. Met deze methode kunt u een efficiënter incrementeel vernieuwingsproces maken waarbij alleen de vereiste perioden worden vernieuwd, ongeacht hoe lang geleden gegevens zijn bijgewerkt.

De pollingExpression is bedoeld als lichtgewicht M-uitdrukking of naam van een andere M-query. Deze moet een scalaire waarde retourneren en wordt uitgevoerd voor elke partitie. Als de geretourneerde waarde afwijkt van de laatste keer dat een incrementele vernieuwing is uitgevoerd, wordt de partitie gemarkeerd voor volledige verwerking.

In het volgende voorbeeld worden alle 120 maanden in de historische periode voor back-backdated wijzigingen beslaat. Het opgeven van 120 maanden in plaats van 10 jaar betekent dat gegevenscompressie mogelijk niet zo efficiënt is, maar voorkomt dat u een heel historisch jaar moet vernieuwen, wat duurder zou zijn wanneer een maand voldoende is voor een teruggeslagen wijziging.

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

Implementatie van alleen metagegevens

Wanneer u een nieuwe versie van een PBIX-bestand publiceert van Power BI Desktop naar een werkruimte en er al een gegevensset met dezelfde naam bestaat, wordt u gevraagd om de bestaande gegevensset te vervangen.

In sommige gevallen wilt u de gegevensset mogelijk niet vervangen, met name bij incrementeel vernieuwen. De gegevensset kan in Power BI Desktop veel kleiner zijn dan die in de service. Als op de gegevensset in de service een beleid voor incrementeel vernieuwen is toegepast, kan deze enkele jaren aan historische gegevens bevatten die verloren gaan als de gegevensset wordt vervangen. Het vernieuwen van alle historische gegevens kan uren duren en resulteert in downtime voor gebruikers van het systeem.

In plaats daarvan is het beter om een implementatie met alleen metagegevens uit te voeren, waardoor nieuwe objecten kunnen worden geïmplementeerd zonder dat de historische gegevens verloren gaan. Als u bijvoorbeeld enkele metingen hebt toegevoegd, kunt u alleen de nieuwe metingen implementeren zonder dat u de gegevens hoeft te vernieuwen, wat veel tijd bespaart.

Voor werkruimten die zijn toegewezen aan een Premium geconfigureerd voor xmla-eindpunt lezen/schrijven, kunnen compatibele hulpprogramma's alleen metagegevens implementeren. ALM Toolkit is bijvoorbeeld een hulpprogramma voor het vergelijken van schema's voor Power BI-gegevenssets en kan worden gebruikt om alleen metagegevens te implementeren.

Download en installeer de meest recent versie van ALM Toolkit van de GitHub-opslagplaats voor Analysis Services. Stapsgewijs richtlijnen voor het gebruik van ALM-Toolkit zijn niet opgenomen in de Microsoft-documentatie. AlM Toolkit koppelingen naar documentatie en informatie over ondersteuning zijn beschikbaar op het lint Help. Als u een implementatie van alleen metagegevens wilt uitvoeren, voert u een vergelijking uit en selecteert u het actieve exemplaar van Power BI Desktop als de bron en de bestaande gegevensset in de service als het doel. Houd rekening met de verschillen die worden weergegeven en sla de update van de tabel met incrementele vernieuwingspartities over of gebruik het dialoogvenster Opties om partities voor tabelupdates te behouden. Valideer de selectie om de integriteit van het doelmodel te controleren en werk deze vervolgens bij.

Zie ook

Partities in tabellaire modellen
Externe hulpprogramma's voor Power BI
Geplande vernieuwing configureren
Problemen met incrementeel vernieuwen oplossen