Incrementeel vernieuwen en realtime gegevens voor gegevenssets

Incrementeel vernieuwen breidt geplande vernieuwingsbewerkingen uit door het automatisch maken en beheren van partities voor gegevenssettabellen die regelmatig nieuwe en bijgewerkte gegevens laden. Voor de meeste gegevenssets zijn dit een of meer tabellen die transactiegegevens bevatten die vaak veranderen en exponentieel kunnen groeien, zoals een feitentabel in een relationeel of sterdatabaseschema. Een incrementeel vernieuwingsbeleid voor het partitioneren van de tabel, het vernieuwen van alleen de meest recente importpartitie(s) en eventueel het gebruik van een extra DirectQuery-partitie voor realtimegegevens kan de hoeveelheid gegevens die moet worden vernieuwd aanzienlijk verminderen en tegelijkertijd ervoor zorgen dat zelfs de meest recente wijzigingen in de gegevensbron worden opgenomen in de queryresultaten.

Met incrementele vernieuwing en realtimegegevens:

  • Minder vernieuwingscycli voor snel veranderende gegevens : in de DirectQuery-modus worden de meest recente gegevensupdates opgehaald wanneer query's worden verwerkt zonder dat er een hoog vernieuwingsfrequentie nodig is.
  • Vernieuwingen zijn sneller . Alleen de meest recente gegevens die zijn gewijzigd, moeten worden vernieuwd.
  • Vernieuwingen zijn betrouwbaarder : langlopende verbindingen met vluchtige gegevensbronnen zijn niet nodig. Query's voor het uitvoeren van brongegevens worden sneller uitgevoerd, waardoor de kans op netwerkproblemen wordt beperkt.
  • Resourceverbruik wordt verminderd : minder gegevens om te vernieuwen vermindert het totale geheugenverbruik en andere resources in zowel Power BI- als gegevensbronsystemen.
  • Maakt grote gegevenssets mogelijk : gegevenssets met mogelijk miljarden rijen kunnen groeien zonder dat de volledige gegevensset volledig hoeft te worden vernieuwd met elke vernieuwingsbewerking.
  • Eenvoudige installatie : beleidsregels voor incrementeel vernieuwen worden gedefinieerd in Power BI Desktop met slechts een paar taken. Wanneer de service wordt gepubliceerd, wordt deze beleidsregels automatisch toegepast bij elke vernieuwing.

Wanneer u een Power BI Desktop-model naar de service publiceert, heeft elke tabel in de nieuwe gegevensset één partitie. Die ene partitie bevat alle rijen voor die tabel. Als de tabel groot is, bijvoorbeeld met tientallen miljoenen rijen of nog meer, kan een vernieuwing voor die tabel lang duren en een overmatige hoeveelheid resources verbruiken.

Met incrementeel vernieuwen worden gegevens dynamisch gepartitioneerd en gescheiden die regelmatig moeten worden vernieuwd van gegevens die minder vaak kunnen worden vernieuwd. Tabelgegevens worden gefilterd met behulp van datum-/tijdparameters van Power Query met de gereserveerde, hoofdlettergevoelige namen RangeStart en RangeEnd. Wanneer u in eerste instantie incrementeel vernieuwen configureert in Power BI Desktop, worden de parameters gebruikt om slechts een kleine periode van gegevens te filteren die in het model moeten worden geladen. Bij publicatie naar de service, met de eerste vernieuwingsbewerking, maakt de service incrementele vernieuwing en historische partities en optioneel een realtime DirectQuery-partitie op basis van beleidsinstellingen voor incrementeel vernieuwen en overschrijft vervolgens de parameterwaarden om gegevens voor elke partitie te filteren en op te vragen op basis van datum-/tijdwaarden voor elke rij.

Bij elke volgende vernieuwing retourneert de queryfilters alleen die rijen binnen de vernieuwingsperiode die dynamisch is gedefinieerd door de parameters. Deze rijen met een datum/tijd binnen de vernieuwingsperiode worden vernieuwd. Rijen met een datum/tijd die niet meer binnen de vernieuwingsperiode vallen, worden vervolgens onderdeel van de historische periode, die niet wordt vernieuwd. Als een realtime DirectQuery-partitie is opgenomen in het beleid voor incrementeel vernieuwen, wordt het filter ook bijgewerkt, zodat de wijzigingen die zijn opgetreden na de vernieuwingsperiode worden opgehaald. Zowel de vernieuwings- als de historische perioden worden doorgestuurd. Naarmate er nieuwe incrementele vernieuwingspartities worden gemaakt, worden vernieuwingspartities in de vernieuwingsperiode geen historische partities meer. In de loop van de tijd worden historische partities minder gedetailleerd omdat ze samen worden samengevoegd. Wanneer een historische partitie zich niet meer in de historische periode bevindt die door het beleid is gedefinieerd, wordt deze volledig verwijderd uit de gegevensset. Dit wordt een rollend vensterpatroon genoemd.

Graphic representing a rolling window pattern.

Het mooie van incrementeel vernieuwen is dat de service dit alles voor u verwerkt op basis van het incrementele vernieuwingsbeleid dat u definieert. Het proces en de partities die ermee zijn gemaakt, zijn zelfs niet zichtbaar in de service. In de meeste gevallen is een goed gedefinieerd beleid voor incrementeel vernieuwen alles wat nodig is om de prestaties van het vernieuwen van gegevenssets aanzienlijk te verbeteren. De realtime DirectQuery-partitie wordt echter alleen ondersteund voor gegevenssets in Premium-capaciteiten, Power BI Premium maakt ook geavanceerdere partitie- en vernieuwingsscenario's mogelijk via het XMLA-eindpunt.

Vereisten

Ondersteunde abonnementen

Incrementeel vernieuwen wordt ondersteund voor Power BI Premium, Premium per gebruiker, Power BI Pro en Power BI Embedded-gegevenssets.

Het ophalen van de meest recente gegevens in realtime met DirectQuery wordt alleen ondersteund voor Power BI Premium-, Premium-gegevenssets per gebruiker en Power BI Embedded-gegevenssets.

Ondersteunde gegevensbronnen

Incrementeel vernieuwen en realtime gegevens werken het beste voor gestructureerde, relationele gegevensbronnen, zoals SQL Database en Azure Synapse, maar kunnen ook voor andere gegevensbronnen werken. In elk geval moet uw gegevensbron het volgende ondersteunen:

Datumkolom : de tabel moet een datumkolom van het gegevenstype datum/tijd of geheel getal bevatten. De parameters RangeStart en RangeEnd (dit moeten datum-/tijdgegevenstype zijn) filteren tabelgegevens op basis van de datumkolom. Voor datumkolommen met surrogaatsleutels voor gehele getallen in de vorm van yyyymmdd, kunt u een functie maken waarmee de datum/tijd-waarde in de parameters RangeStart en RangeEnd wordt geconverteerd zodat deze overeenkomen met de surrogaatsleutels voor gehele getallen van de datumkolom. Zie Incrementeel vernieuwen configureren : Datum/tijd converteren naar geheel getal voor meer informatie.

Query folding : incrementeel vernieuwen is ontworpen voor gegevensbronnen die ondersteuning bieden voor het vouwen van query's. Dit is de mogelijkheid van Power Query om één query-expressie te genereren om brongegevens op te halen en te transformeren, vooral als u de meest recente gegevens in realtime ophaalt met DirectQuery. De meeste gegevensbronnen die ondersteuning bieden voor SQL-query's, ondersteunen het vouwen van query’s. Gegevensbronnen zoals platte bestanden, blobs en sommige webfeeds doen dat vaak niet.

Wanneer incrementeel vernieuwen is geconfigureerd, wordt een Power Query-expressie met een datum-/tijdfilter uitgevoerd op basis van de parameters RangeStart en RangeEnd op basis van de gegevensbron. Het filter is van kracht een transformatie die is opgenomen in de query die een WHERE-component definieert op basis van de parameters. In gevallen waarin het filter niet wordt ondersteund door de gegevensbron, kan het niet worden opgenomen in de queryexpressie. Als het beleid voor incrementeel vernieuwen het ophalen van realtimegegevens met DirectQuery omvat, kunnen niet-vouwen transformaties niet worden gebruikt. Als het een puur importmodusbeleid is zonder realtime gegevens, kan de query mashup-engine het filter mogelijk compenseren en lokaal toepassen. Hiervoor moeten alle rijen voor de tabel uit de gegevensbron worden opgehaald. Dit kan ertoe leiden dat incrementeel vernieuwen traag is en het proces kan onvoldoende resources bevatten in de Power BI-service of in een on-premises gegevensgateway, waardoor het doel van incrementeel vernieuwen effectief wordt verslagen.

Omdat de ondersteuning voor het vouwen van query's verschilt voor verschillende typen gegevensbronnen, moet verificatie worden uitgevoerd om ervoor te zorgen dat de filterlogica wordt opgenomen in de query's die worden uitgevoerd op basis van de gegevensbron. In de meeste gevallen probeert Power BI Desktop deze verificatie voor u uit te voeren bij het definiëren van het beleid voor incrementeel vernieuwen. Voor op SQL gebaseerde gegevensbronnen, zoals SQL Database, Azure Synapse, Oracle en Teradata, is deze verificatie betrouwbaar. Andere gegevensbronnen kunnen echter niet worden geverifieerd zonder de query's te traceren. Als Power BI Desktop niet kan bevestigen, wordt er een waarschuwing weergegeven in het dialoogvenster Beleidsconfiguratie incrementeel vernieuwen.

Query folding warning

Als u deze waarschuwing ziet en wilt controleren of de benodigde query folding plaatsvindt, gebruikt u de functie Diagnostische gegevens van Power Query of traceerquery's met behulp van een hulpprogramma dat wordt ondersteund door de gegevensbron, zoals SQL Profiler. Als het vouwen van query's niet plaatsvindt, controleert u of de filterlogica is opgenomen in de query die wordt doorgegeven aan de gegevensbron. Zo niet, dan bevat de query waarschijnlijk een transformatie die het vouwen voorkomt.

Voordat u de oplossing voor incrementeel vernieuwen configureert, moet u de richtlijnen voor het vouwen van query's in Power BI Desktop en Het vouwen van query's in Power BI Desktop en Power Query grondig lezen en begrijpen. Deze artikelen kunnen u helpen bepalen of uw gegevensbron en query's ondersteuning bieden voor het vouwen van query's.

Eén gegevensbron

Bij het configureren van incrementele vernieuwing en realtime gegevens met behulp van Power BI Desktop of het configureren van een geavanceerde oplossing met behulp van TMSL (Tabular Model Scripting Language) of Tabular Object Model (TOM) via het XMLA-eindpunt, moeten alle partities , ongeacht of ze importeren of DirectQuery query's uitvoeren op gegevens uit één bron.

Andere typen gegevensbronnen

Met behulp van aanvullende aangepaste queryfuncties en querylogica kan incrementeel vernieuwen worden gebruikt met andere typen gegevensbronnen die filters bieden op basis van RangeStart en RangeEnd, kunnen worden doorgegeven in één query. Bijvoorbeeld Excel-werkmapbestanden die zijn opgeslagen in een map, bestanden in SharePoint of RSS-feeds. Houd er rekening mee dat dit geavanceerde scenario's zijn waarvoor extra aanpassingen en tests nodig zijn, behalve wat hier wordt beschreven. Raadpleeg de sectie Community verderop in dit artikel voor suggesties over hoe u meer informatie kunt vinden over het gebruik van incrementeel vernieuwen voor unieke scenario's, zoals deze.

Tijdslimieten

Ongeacht incrementeel vernieuwen hebben Power BI Pro-gegevenssets een vernieuwingstijdslimiet van twee uur en bieden geen ondersteuning voor het ophalen van realtime gegevens met DirectQuery. Voor gegevenssets in een Premium-capaciteit is de tijdslimiet vijf uur. Vernieuwingsbewerkingen zijn proces- en geheugenintensief. Een volledige vernieuwingsbewerking kan zoveel gebruiken als de hoeveelheid geheugen die alleen door de gegevensset is vereist, omdat de service een momentopname van de gegevensset in het geheugen onderhoudt totdat de vernieuwingsbewerking is voltooid. Vernieuwingsbewerkingen kunnen ook intensief worden verwerkt, wat een aanzienlijke hoeveelheid beschikbare CPU-resources verbruikt. Vernieuwingsbewerkingen moeten ook afhankelijk zijn van vluchtige verbindingen met gegevensbronnen en de mogelijkheid van deze gegevensbronsystemen om snel query-uitvoer te retourneren. De tijdslimiet is een beveiliging om het oververbruik van uw beschikbare resources te beperken.

Notitie

Met Premium-capaciteiten hebben vernieuwingsbewerkingen die via het XMLA-eindpunt worden uitgevoerd, geen tijdslimiet. Zie Geavanceerde incrementele vernieuwing met het XMLA-eindpunt voor meer informatie.

Omdat incrementeel vernieuwen vernieuwingsbewerkingen optimaliseert op partitieniveau in de gegevensset, kan het resourceverbruik aanzienlijk worden verminderd. Tegelijkertijd, zelfs met incrementeel vernieuwen, tenzij het XMLA-eindpunt wordt gebruikt, worden vernieuwingsbewerkingen gebonden aan dezelfde limieten van twee en vijf uur. Een effectief incrementeel vernieuwingsbeleid vermindert niet alleen de hoeveelheid gegevens die worden verwerkt met een vernieuwingsbewerking, maar vermindert ook de hoeveelheid onnodige historische gegevens die zijn opgeslagen in uw gegevensset.

Query's kunnen ook worden beperkt door een standaardtijdlimiet voor de gegevensbron. De meeste relationele gegevensbronnen staan het overschrijven van tijdslimieten in de Power Query M-expressie toe. In de onderstaande expressie wordt bijvoorbeeld de sql Server-functie voor gegevenstoegang gebruikt om CommandTimeout in te stellen op 2 uur. Elke periode die door de beleidsbereiken wordt gedefinieerd, stuurt een query in waarbij rekening wordt gehouden met de time-outinstelling voor de opdracht.

let
    Source = Sql.Database("myserver.database.windows.net", "AdventureWorks", [CommandTimeout=#duration(0, 2, 0, 0)]),
    dbo_Fact = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)
in
    #"Filtered Rows"

Voor zeer grote gegevenssets in Premium-capaciteiten die waarschijnlijk miljarden rijen bevatten, kan de eerste vernieuwingsbewerking worden opgestart. Met Bootstrapping kan de service tabel- en partitieobjecten maken voor de gegevensset, maar geen gegevens laden en verwerken in een van de partities. Met behulp van SQL Server Management Studio kunnen partities vervolgens afzonderlijk, opeenvolgend of parallel worden verwerkt, waardoor de hoeveelheid gegevens die in één query worden geretourneerd, kan worden verminderd, maar ook de tijdslimiet van vijf uur kan worden overgeslagen. Zie Geavanceerde incrementele vernieuwing voor meer informatie: time-outs voorkomen bij de eerste volledige vernieuwing.

Huidige datum en tijd

De huidige datum en tijd zijn gebaseerd op de systeemdatum op het moment van vernieuwen. Als geplande vernieuwing is ingeschakeld voor de gegevensset in de service, wordt rekening gehouden met de opgegeven tijdzone bij het bepalen van de huidige datum en tijd. Zowel afzonderlijke als geplande vernieuwingen via de service observeren de tijdzone indien beschikbaar. Een vernieuwing die plaatsvindt om 18:00 uur Pacific Time (VS en Canada) met een opgegeven tijdzone, bepaalt bijvoorbeeld de huidige datum en tijd op basis van Pacific Time, niet GMT (wat anders de volgende dag zou zijn). Vernieuwingsbewerkingen die niet worden aangeroepen via de service, zoals de opdracht TMSL-vernieuwing, houden geen rekening met de geplande tijdzone voor vernieuwen.

Time zone

Incrementele vernieuwing en realtime gegevens configureren

We behandelen hier belangrijke concepten voor het configureren van incrementele vernieuwing en realtime gegevens. Wanneer u klaar bent voor gedetailleerde stapsgewijze instructies, moet u incrementele vernieuwing en realtime gegevens configureren voor gegevenssets uitchecken.

Het configureren van incrementeel vernieuwen wordt uitgevoerd in Power BI Desktop. Voor de meeste modellen zijn slechts enkele taken vereist. Houd echter rekening met het volgende:

  • Wanneer u naar de service bent gepubliceerd, kunt u hetzelfde model niet opnieuw publiceren vanuit Power BI Desktop. Als u opnieuw publiceert, worden bestaande partities en gegevens die al in de gegevensset staan, verwijderd. Als u publiceert naar een Premium-capaciteit, kunnen volgende wijzigingen in het metagegevensschema worden aangebracht met hulpprogramma's zoals de opensource ALM Toolkit of met behulp van TMSL (Tabular Model Scripting Language). Zie Geavanceerde incrementele vernieuwing : implementatie met alleen metagegevens voor meer informatie.
  • Wanneer de gegevensset is gepubliceerd naar de service, kunt u de gegevensset niet terug downloaden als PBIX naar Power BI Desktop. Omdat gegevenssets in de service zo groot kunnen worden, is het niet praktisch om terug te downloaden en te openen op een typische desktopcomputer.
  • Wanneer u realtime gegevens met DirectQuery ophaalt, kunt u de gegevensset niet publiceren naar een niet-Premium-werkruimte. Incrementeel vernieuwen met realtime gegevens wordt alleen ondersteund met Power BI Premium.

Parameters maken

Wanneer u incrementeel vernieuwen configureert in Power BI Desktop, maakt u eerst twee datum-/tijdparameters voor Power Query met de gereserveerde, hoofdlettergevoelige namen RangeStart en RangeEnd. Deze parameters, gedefinieerd in het dialoogvenster Parameters beheren in De Power Query-editor, worden in eerste instantie gebruikt om de gegevens te filteren die in de Power BI Desktop-modeltabel zijn geladen, zodat alleen die rijen met een datum/tijd binnen die periode worden opgenomen. Nadat het model is gepubliceerd naar de service, worden RangeStart en RangeEnd automatisch overschreven door de service om gegevens op te vragen die zijn gedefinieerd door de vernieuwingsperiode die is opgegeven in de beleidsinstellingen voor incrementeel vernieuwen.

De gegevensbrontabel FactInternetSales gemiddelden 10k nieuwe rijen per dag. Om het aantal rijen dat in eerste instantie in het model in Power BI Desktop is geladen, te beperken, geven we een periode van twee dagen op tussen RangeStart en RangeEnd.

Manage Parameters dialogue

Gegevens filteren

Als de parameters RangeStart en RangeEnd zijn gedefinieerd, past u vervolgens aangepaste datumfilters toe op de datumkolom van uw tabel. Met de filters die u toepast, selecteert u een subset met gegevens die in het model worden geladen wanneer u op Toepassen klikt.

Custom filter

Met behulp van ons FactInternetSales-voorbeeld wordt na het maken van filters op basis van de parameters en het toepassen van stappen, twee dagen aan gegevens, ongeveer 20k rijen in ons model geladen.

Beleid definiëren

Nadat filters zijn toegepast en er een subset met gegevens in het model is geladen, definieert u vervolgens een incrementeel vernieuwingsbeleid voor de tabel. Nadat het model naar de service is gepubliceerd, wordt het beleid door de service gebruikt om tabelpartities te maken en te beheren en vernieuwingsbewerkingen uit te voeren. Als u het beleid wilt definiëren, gebruikt u het dialoogvenster Incrementeel vernieuwen en realtime gegevens om zowel vereiste instellingen als optionele instellingen op te geven.

Define policy dialog

Tabel

De keuzelijst Tabel selecteren is standaard ingesteld op de tabel die u selecteert in de gegevensweergave. Schakel incrementeel vernieuwen in voor de tabel met de schuifregelaar. Als de Power Query-expressie voor de tabel geen filter bevat op basis van de parameters RangeStart en RangeEnd, wordt de wisselknop uitgeschakeld.

Verplichte instellingen

De instelling Archiefgegevens die vóór de vernieuwingsdatum beginnen , bepaalt de historische periode waarin rijen met een datum/tijd in die periode zijn opgenomen in de gegevensset, plus rijen voor de huidige onvolledige historische periode, plus rijen in de vernieuwingsperiode tot aan de huidige datum en tijd.

Als we bijvoorbeeld vijf jaar opgeven, worden in onze tabel de laatste vijf jaar historische gegevens opgeslagen in jaarpartities, plus rijen voor het huidige jaar in kwartaal-, maand- of dagpartities, tot en met de vernieuwingsperiode.

Voor gegevenssets in Premium-capaciteiten kunnen backdated historische partities selectief worden vernieuwd met een granulariteit die wordt bepaald door deze instelling. Zie Geavanceerde incrementele vernieuwing - Partities voor meer informatie.

De incrementeel vernieuwen van gegevens die vóór de instelling voor de vernieuwingsdatum beginnen , bepaalt de incrementele vernieuwingsperiode waarin alle rijen met een datum/tijd in die periode zijn opgenomen in de vernieuwingspartitie(s) en worden vernieuwd met elke vernieuwingsbewerking.

Als we bijvoorbeeld een vernieuwingsperiode van 3 dagen opgeven, worden met elke vernieuwingsbewerking de parameters RangeStart en RangeEnd overschreven om een query te maken voor rijen met een datum/tijd binnen een periode van drie dagen, afhankelijk van de huidige datum en tijd. Rijen met een datum/tijd in de afgelopen 3 dagen tot de huidige vernieuwingsbewerkingstijd worden vernieuwd. Met dit type beleid kunnen we onze gegevenssettabel FactInternetSales verwachten in de service, die gemiddelden 10k nieuwe rijen per dag heeft, om ongeveer 30k rijen te vernieuwen met elke vernieuwingsbewerking.

Zorg ervoor dat u een periode opgeeft die alleen het minimale aantal rijen bevat dat nodig is om nauwkeurige rapportage te garanderen. Als u beleidsregels voor meer dan één tabel definieert, moeten dezelfde RangeStart- en RangeEnd-parameters worden gebruikt, zelfs als voor elke tabel verschillende opslag- en vernieuwingsperioden zijn gedefinieerd.

Optionele instellingen

Met de instelling De meest recente gegevens in realtime ophalen met de instelling DirectQuery (alleen Premium) kunt u de meest recente wijzigingen uit de geselecteerde tabel in de gegevensbron ophalen na de incrementele vernieuwingsperiode met behulp van DirectQuery. Alle rijen met een datum/tijd later dan de incrementele vernieuwingsperiode worden opgenomen in een DirectQuery-partitie en opgehaald uit de gegevensbron met elke gegevenssetquery.

Als dit bijvoorbeeld is ingeschakeld, overschrijft de service bij elke vernieuwingsbewerking nog steeds de parameters RangeStart en RangeEnd om een query te maken voor rijen met een datum/tijd na de vernieuwingsperiode, afhankelijk van de huidige datum en tijd. Rijen met een datum/tijd na de huidige vernieuwingsbewerkingstijd zijn opgenomen. Met dit type beleid kunnen we verwachten dat de gegevenssettabel FactInternetSales in de service zelfs de meest recente gegevensupdates bevat.

De alleen voltooide dagen voor vernieuwen zorgen ervoor dat alle rijen voor de hele dag worden opgenomen in de vernieuwingsbewerking. Deze instelling is optioneel , tenzij u de meest recente gegevens in realtime inschakelt met de instelling DirectQuery (alleen Premium). Stel dat u hebt gepland dat vernieuwing elke ochtend om 4:00 uur wordt uitgevoerd. Als er tijdens die vier uur tussen middernacht en 4:00 uur nieuwe rijen met gegevens worden weergegeven in de gegevensbrontabel, wilt u er geen rekening mee houden. Sommige zakelijke metrische gegevens, zoals vaten per dag in de olie- en gasindustrie, zijn niet logisch met gedeeltelijke dagen. Een ander voorbeeld is het vernieuwen van gegevens in een financieel systeem waar gegevens voor de vorige maand op de 12e kalenderdag van de maand worden goedgekeurd. U kunt de vernieuwingsperiode instellen op 1 maand en de vernieuwing plannen op de 12e dag van de maand. Als deze optie is geselecteerd, worden bijvoorbeeld januarigegevens op 12 februari vernieuwd.

Houd er rekening mee dat, tenzij geplande vernieuwing is geconfigureerd voor een niet-UTC-tijdzone, vernieuwingsbewerkingen in de service worden uitgevoerd onder UTC-tijd, waarmee de effectieve datum en effect voltooide perioden kunnen worden bepaald.

Met de instelling Gegevenswijzigingen detecteren kunt u nog selectiever vernieuwen. U kunt een datum-/tijdkolom selecteren die wordt gebruikt om alleen die dagen te identificeren en vernieuwen waarop de gegevens zijn gewijzigd. Hierbij wordt ervan uitgegaan dat een dergelijke kolom bestaat in de gegevensbron, wat doorgaans voor controledoeleinden is. Dit mag niet dezelfde kolom zijn die wordt gebruikt om de gegevens te partitioneren met de parameters RangeStart en RangeEnd. De maximumwaarde van deze kolom wordt geëvalueerd voor elke periode in het incrementele bereik. Als deze niet is gewijzigd sinds de laatste vernieuwing, hoeft u de periode niet te vernieuwen. In dit voorbeeld kan dit de dagen die incrementeel worden vernieuwd mogelijk verder verminderen van 3 tot en met 1.

Voor het huidige ontwerp moet de kolom die gegevenswijzigingen detecteert persistent zijn en in het cachegeheugen worden geplaatst. De volgende technieken kunnen worden gebruikt om kardinaliteit en geheugenverbruik te verminderen:

  • Behoud alleen de maximumwaarde van de kolom op het moment van vernieuwen, mogelijk met behulp van een Power Query-functie.
  • Verminder de precisie tot een acceptabel niveau, gezien de vereisten voor de vernieuwingsfrequentie.
  • Definieer een aangepaste query voor het detecteren van gegevenswijzigingen met behulp van het XMLA-eindpunt en voorkom dat de kolomwaarde helemaal wordt behouden.

In sommige gevallen kan het inschakelen van de optie Gegevenswijzigingen detecteren verder worden verbeterd. U kunt bijvoorbeeld voorkomen dat een kolom voor de laatste update in de cache in het geheugen behouden blijft of scenario's inschakelt waarin een configuratie-/instructietabel wordt voorbereid door ETL-processen voor het markeren van alleen die partities die moeten worden vernieuwd. In dergelijke gevallen gebruikt u voor Premium-capaciteiten TMSL (Tabular Model Scripting Language) en/of het TOM (Tabular Object Model) om het gedrag van gegevenswijzigingen te overschrijven. Zie Geavanceerde incrementele vernieuwing: aangepaste query's voor het detecteren van gegevenswijzigingen voor meer informatie.

Publiceren

Nadat u het beleid voor incrementeel vernieuwen hebt geconfigureerd, publiceert u het model naar de service. Wanneer het publiceren is voltooid, kunt u de eerste vernieuwingsbewerking uitvoeren op de gegevensset.

Notitie

Gegevenssets met een incrementeel vernieuwingsbeleid om de meest recente gegevens in realtime op te halen met DirectQuery, kunnen alleen worden gepubliceerd naar een Premium-werkruimte.

Voor gegevenssets die zijn gepubliceerd naar werkruimten die zijn toegewezen aan Premium-capaciteiten, kunt u, als u denkt dat de gegevensset groter wordt dan 1 GB of meer, de prestaties van de vernieuwingsbewerking verbeteren en ervoor zorgen dat de gegevensset de maximale groottelimieten niet overschrijdt door de opslagindeling voor grote gegevenssets in te schakelen voordat u de eerste vernieuwingsbewerking in de service uitvoert. Zie Grote gegevenssets in Power BI Premium voor meer informatie.

Belangrijk

Nadat u naar de service hebt gepubliceerd, kunt u het PBIX-bestand niet meer downloaden.

Vernieuwen

Nadat u naar de service hebt gepubliceerd, voert u een eerste vernieuwingsbewerking uit op de gegevensset. Dit moet een afzonderlijke (handmatige) vernieuwing zijn, zodat u de voortgang kunt controleren. Het kan even duren voordat de eerste vernieuwingsbewerking is voltooid. Partities moeten worden gemaakt, historische gegevens worden geladen, objecten zoals relaties en hiërarchieën worden gebouwd of opnieuw opgebouwd en berekende objecten worden opnieuw berekend.

Volgende vernieuwingsbewerkingen, afzonderlijk of gepland, zijn veel sneller omdat alleen de incrementele vernieuwingspartitie(s) wordt vernieuwd. Andere verwerkingsbewerkingen moeten nog steeds plaatsvinden, zoals het samenvoegen van partities en herberekening, maar het duurt meestal slechts een klein deel van de tijd in vergelijking met de eerste vernieuwing.

Automatisch vernieuwen van rapporten

Voor rapporten met behulp van een gegevensset met een incrementeel vernieuwingsbeleid om de meest recente gegevens in realtime op te halen met DirectQuery, is het een goed idee om automatische paginavernieuwing met een vast interval in te schakelen of op basis van wijzigingsdetectie, zodat de rapporten de meest recente gegevens zonder vertraging bevatten. Zie Automatisch paginavernieuwing in Power BI voor meer informatie.

Geavanceerde incrementele vernieuwing

Als uw gegevensset een Premium-capaciteit heeft waarvoor het XMLA-eindpunt is ingeschakeld, kan incrementeel vernieuwen verder worden uitgebreid voor geavanceerde scenario's. U kunt bijvoorbeeld SQL Server Management Studio gebruiken om partities weer te geven en te beheren, de eerste vernieuwingsbewerking te bootstrapen of backdated historische partities te vernieuwen. Zie Geavanceerde incrementele vernieuwing met het XMLA-eindpunt voor meer informatie.

Community

Power BI heeft een levendige community waar MVP's, BI-professionals en peers expertise delen in discussiegroepen, video's, blogs en meer. Als u meer wilt weten over incrementeel vernieuwen, raadpleegt u deze aanvullende resources:

Volgende stappen

Incrementeel vernieuwen configureren voor gegevenssets
Geavanceerde incrementele vernieuwing met het XMLA-eindpunt
Problemen met incrementeel vernieuwen oplossen
Incrementeel vernieuwen voor gegevensstromen