Incrementeel vernieuwen en realtimegegevens voor gegevenssets

Artikel
03/23/2023

Incrementeel vernieuwen breidt geplande vernieuwingsbewerkingen uit door automatisch partities te maken en te beheren voor gegevenssettabellen die regelmatig nieuwe en bijgewerkte gegevens laden. Voor de meeste gegevenssets bevatten een of meer tabellen transactiegegevens die vaak veranderen en exponentieel kunnen groeien, zoals een feitentabel in een relationeel of sterdatabaseschema. Een beleid voor incrementeel vernieuwen om de tabel te partitioneren, alleen de meest recente importpartities te vernieuwen en optioneel een andere DirectQuery-partitie te gebruiken voor realtime gegevens, kan de hoeveelheid gegevens die moet worden vernieuwd, aanzienlijk verminderen. Tegelijkertijd zorgt dit beleid ervoor dat de meest recente wijzigingen in de gegevensbron worden opgenomen in de queryresultaten.

Met incrementeel vernieuwen en realtime gegevens:

Er zijn minder vernieuwingscycli nodig voor snel veranderende gegevens. In de DirectQuery-modus worden de meest recente gegevensupdates opgehaald wanneer query's worden verwerkt, zonder dat hiervoor een hoog vernieuwingsfrequentie nodig is.
Vernieuwingen worden sneller uitgevoerd. Alleen de meest recente gegevens die zijn gewijzigd, moeten worden vernieuwd.
Vernieuwingen zijn betrouwbaarder. Langdurige verbindingen met vluchtige gegevensbronnen zijn niet nodig. Query's naar brongegevens worden sneller uitgevoerd, waardoor netwerkproblemen minder kunnen worden beïnvloed.
Er worden minder resources gebruikt. Minder gegevens om te vernieuwen vermindert het totale verbruik van geheugen en andere resources in zowel Power BI als gegevensbronsystemen.
Grote gegevenssets zijn ingeschakeld. Gegevenssets met mogelijk miljarden rijen kunnen groeien zonder dat de hele gegevensset bij elke vernieuwingsbewerking volledig hoeft te worden vernieuwd.
De installatie is eenvoudig. Beleidsregels voor incrementeel vernieuwen worden gedefinieerd in Power BI Desktop met slechts enkele taken. Wanneer Power BI Desktop het rapport publiceert, past de service dit beleid automatisch toe 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 meer, kan het vernieuwen van die tabel lang duren en een overmatige hoeveelheid resources verbruiken.

Met incrementeel vernieuwen wordt de service dynamisch gepartitioneerd en gescheiden gegevens die regelmatig moeten worden vernieuwd van gegevens die minder vaak kunnen worden vernieuwd. Tabelgegevens worden gefilterd met behulp van Power Query datum-/tijdparameters met de gereserveerde, hoofdlettergevoelige namen RangeStart en RangeEnd. Wanneer u incrementeel vernieuwen configureert in Power BI Desktop, worden deze parameters gebruikt om slechts een kleine periode van gegevens te filteren die in het model worden geladen. Wanneer Power BI Desktop het rapport publiceert naar de Power BI-service, maakt de service met de eerste vernieuwingsbewerking incrementele vernieuwing en historische partities en optioneel een directquery-partitie in realtime op basis van de beleidsinstellingen voor incrementeel vernieuwen. De service 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 retourneren de queryfilters alleen die rijen binnen de vernieuwingsperiode die dynamisch is gedefinieerd door de parameters. De rijen met een datum/tijd binnen de vernieuwingsperiode worden vernieuwd. Rijen met een datum/tijd die niet meer binnen de vernieuwingsperiode vallen, worden onderdeel van de historische periode, die niet wordt vernieuwd. Als een DirectQuery-partitie in realtime is opgenomen in het beleid voor incrementeel vernieuwen, wordt het filter ook bijgewerkt, zodat eventuele wijzigingen worden opgehaald die na de vernieuwingsperiode optreden. Zowel de vernieuwingsperiode als de historische perioden worden naar voren gerold. Wanneer er nieuwe partities voor incrementeel vernieuwen worden gemaakt, worden vernieuwingspartities die niet langer in de vernieuwingsperiode vallen, historische partities. Na verloop van tijd worden historische partities minder gedetailleerd naarmate ze worden samengevoegd. Wanneer een historische partitie zich niet meer in de historische periode bevindt die is gedefinieerd door het beleid, wordt deze volledig uit de gegevensset verwijderd. Dit gedrag wordt een patroon voor een doorlopend venster genoemd.

Afbeelding van een patroon voor een rollend venster.

Het mooie van incrementeel vernieuwen is dat de service alles voor u afhandelt op basis van het beleid voor incrementeel vernieuwen dat u definieert. In feite zijn het proces en de partities die op basis daarvan zijn gemaakt, niet zichtbaar in de service. In de meeste gevallen is een goed gedefinieerd beleid voor incrementeel vernieuwen alles wat nodig is om de vernieuwingsprestaties 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 (XML for Analysis).

Vereisten

In de volgende secties worden de ondersteunde plannen en gegevensbronnen beschreven.

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 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:

Datumfiltering : de gegevensbron moet een mechanisme ondersteunen om gegevens te filteren op datum. Voor een relationele bron is dit meestal een datumkolom van het gegevenstype datum/tijd of geheel getal in de doeltabel. De parameters RangeStart en RangeEnd, die het gegevenstype datum/tijd moeten zijn, filteren tabelgegevens op basis van de datumkolom. Voor datumkolommen van surrogaatsleutels voor gehele getallen in de vorm van yyyymmddkunt 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.

Voor andere gegevensbronnen moeten de parameters RangeStart en RangeEnd worden doorgegeven aan de gegevensbron op een manier die filteren mogelijk maakt. Voor gegevensbronnen op basis van bestanden waarbij bestanden en mappen zijn ingedeeld op datum, kunnen de parameters RangeStart en RangeEnd worden gebruikt om de bestanden en mappen te filteren om te selecteren welke bestanden moeten worden geladen. Voor webgegevensbronnen kunnen de parameters RangeStart en RangeEnd worden geïntegreerd in de HTTP-aanvraag. De volgende query kan bijvoorbeeld worden gebruikt voor incrementeel vernieuwen van de traceringen van een AppInsights-exemplaar:

let 
    strRangeStart = DateTime.ToText(RangeStart,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    strRangeEnd = DateTime.ToText(RangeEnd,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    Source = Json.Document(Web.Contents("https://api.applicationinsights.io/v1/apps/<app-guid>/query", 
    [Query=[#"query"="traces 
    | where timestamp >= datetime(" & strRangeStart &") 
    | where timestamp < datetime("& strRangeEnd &")
    ",#"x-ms-app"="AAPBI",#"prefer"="ai.response-thinning=true"],Timeout=#duration(0,0,4,0)])),
    TypeMap = #table(
    { "AnalyticsTypes", "Type" }, 
    { 
    { "string",   Text.Type },
    { "int",      Int32.Type },
    { "long",     Int64.Type },
    { "real",     Double.Type },
    { "timespan", Duration.Type },
    { "datetime", DateTimeZone.Type },
    { "bool",     Logical.Type },
    { "guid",     Text.Type },
    { "dynamic",  Text.Type }
    }),
    DataTable = Source[tables]{0},
    Columns = Table.FromRecords(DataTable[columns]),
    ColumnsWithType = Table.Join(Columns, {"type"}, TypeMap , {"AnalyticsTypes"}),
    Rows = Table.FromRows(DataTable[rows], Columns[name]), 
    Table = Table.TransformColumnTypes(Rows, Table.ToList(ColumnsWithType, (c) => { c{0}, c{3}}))
in
Table

Wanneer incrementeel vernieuwen is geconfigureerd, wordt een Power Query-expressie met een datum/tijdfilter op basis van de parameters RangeStart en RangeEnd uitgevoerd voor de gegevensbron. Als het filter is opgegeven in een querystap na de eerste bronquery, is het belangrijk dat query folding de eerste querystap combineert met de stappen die verwijzen naar de parameters RangeStart en RangeEnd. In de volgende query-expressie Table.SelectRows wordt de bijvoorbeeld gevouwen omdat deze direct de Sql.Database stap volgt en SQL Server ondersteuning biedt voor vouwen:

let
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data  = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
  #"Filtered Rows" = Table.SelectRows(Data, each [OrderDateKey] >= Int32.From(DateTime.ToText(RangeStart,[Format="yyyyMMdd"]))),
  #"Filtered Rows1" = Table.SelectRows(#"Filtered Rows", each [OrderDateKey] < Int32.From(DateTime.ToText(RangeEnd,[Format="yyyyMMdd"])))
  
in
  #"Filtered Rows1"

Er is geen vereiste voor het vouwen van de uiteindelijke queryondersteuning . In de volgende expressie gebruiken we bijvoorbeeld een niet-vouwbare NativeQuery, maar integreren we de parameters RangeStart en RangeEnd rechtstreeks in SQL:

let
  Query = "select * from dbo.FactInternetSales where OrderDateKey >= '"& Text.From(Int32.From( DateTime.ToText(RangeStart,"yyyyMMdd") )) &"' and OrderDateKey < '"& Text.From(Int32.From( DateTime.ToText(RangeEnd,"yyyyMMdd") )) &"' ",
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data = Value.NativeQuery(Source, Query, null, [EnableFolding=false])
in
  Data

Als het beleid voor incrementeel vernieuwen echter het ophalen van realtimegegevens met DirectQuery omvat, kunnen niet-vouwbare transformaties niet worden gebruikt. Als het een puur importmodusbeleid is zonder realtimegegevens, 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 dat het proces geen resources meer heeft in de Power BI-service of in een on-premises gegevensgateway, waardoor het doel van incrementeel vernieuwen in feite wordt uitgeschakeld.

Omdat de ondersteuning voor het vouwen van query's verschilt voor verschillende typen gegevensbronnen, moet de verificatie worden uitgevoerd om ervoor te zorgen dat de filterlogica is opgenomen in de query's die worden uitgevoerd op 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 gegevensbronnen op basis van SQL, zoals SQL Database, Azure Synapse, Oracle en Teradata, is deze verificatie betrouwbaar. Andere gegevensbronnen kunnen echter mogelijk niet worden geverifieerd zonder de query's te traceren. Als Power BI Desktop de query's niet kan bevestigen, wordt er een waarschuwing weergegeven in het configuratiedialoogvenster beleid voor incrementeel vernieuwen.

Schermopname van de waarschuwing voor het vouwen van query's

Als u deze waarschuwing ziet en wilt controleren of de benodigde query folding plaatsvindt, gebruikt u de functie Power Query Diagnostische gegevens of traceer query's met behulp van een hulpprogramma dat wordt ondersteund door de gegevensbron, zoals SQL Profiler. Als er geen query folding 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 vouwen voorkomt.

Voordat u uw oplossing voor incrementeel vernieuwen configureert, moet u de richtlijnen voor 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

Wanneer u incrementeel vernieuwen en realtimegegevens configureert met behulp van Power BI Desktop, of wanneer u een geavanceerde oplossing configureert met TMSL (Tabular Model Scripting Language) of Tom (Tabular Object Model) via het XMLA-eindpunt, moeten alle partities, ongeacht of deze worden geïmporteerd of DirectQuery, query's uitvoeren op gegevens uit één bron.

Andere typen gegevensbronnen

Door meer aangepaste queryfuncties en querylogica te gebruiken, kan incrementeel vernieuwen worden gebruikt met andere typen gegevensbronnen als filters op RangeStart basis van en RangeEnd kunnen worden doorgegeven in één query, zoals met gegevensbronnen zoals Excel-werkmapbestanden die zijn opgeslagen in een map, bestanden in SharePoint en RSS-feeds. Houd er rekening mee dat dit geavanceerde scenario's zijn waarvoor verdere aanpassingen en tests nodig zijn die verder gaan dan 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.

Tijdslimieten

Ongeacht incrementeel vernieuwen hebben Power BI Pro gegevenssets een vernieuwingstijdslimiet van twee uur en bieden ze 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 het dubbele van de hoeveelheid geheugen gebruiken die alleen voor de gegevensset is vereist, omdat de service een momentopname van de gegevensset in het geheugen bijhoudt totdat de vernieuwingsbewerking is voltooid. Vernieuwingsbewerkingen kunnen ook procesintensief zijn en een aanzienlijke hoeveelheid beschikbare CPU-resources verbruiken. Vernieuwingsbewerkingen moeten ook afhankelijk zijn van vluchtige verbindingen met gegevensbronnen en de mogelijkheid van deze gegevensbronsystemen om snel queryuitvoer te retourneren. De tijdslimiet is een beveiliging om het overgebruik van uw beschikbare resources te beperken.

Notitie

Met Premium-capaciteiten hebben vernieuwingsbewerkingen die worden uitgevoerd via het XMLA-eindpunt geen tijdslimiet. Zie Geavanceerd incrementeel vernieuwen met het XMLA-eindpunt voor meer informatie.

Omdat incrementeel vernieuwen vernieuwingsbewerkingen op partitieniveau in de gegevensset optimaliseert, kan het resourceverbruik aanzienlijk worden verminderd. Tegelijkertijd, zelfs met incrementeel vernieuwen, tenzij ze het XMLA-eindpunt doorlopen, zijn vernieuwingsbewerkingen gebonden aan dezelfde limieten van twee en vijf uur. Een effectief beleid voor incrementeel vernieuwen 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 standaardtijdslimiet voor de gegevensbron. De meeste relationele gegevensbronnen staan het overschrijven van tijdslimieten toe in de Power Query M-expressie. In de onderstaande expressie wordt bijvoorbeeld de functie SQL Server data-access gebruikt om CommandTimeout in te stellen op 2 uur. Elke periode die wordt gedefinieerd door de beleidsbereiken, verzendt een query die de time-outinstelling van de opdracht observeert:

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 voor de gegevensset maken, maar worden gegevens niet in een van de partities geladen en verwerkt. Met behulp van SQL Server Management Studio kunt u instellen dat partities afzonderlijk, opeenvolgend of parallel worden verwerkt, om zowel de hoeveelheid gegevens te verminderen die in één query worden geretourneerd als om de tijdslimiet van vijf uur te omzeilen. Zie Geavanceerde incrementele vernieuwing: time-outs voorkomen bij de eerste volledige vernieuwing voor meer informatie.

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 houden rekening met de tijdzone, indien beschikbaar. Een vernieuwing die bijvoorbeeld plaatsvindt om 20:00 uur Pacific Time (VS en Canada) met een opgegeven tijdzone bepaalt de huidige datum en tijd op basis van Pacific Time, niet Coordinated Universal Time (UTC), die de volgende dag wordt geretourneerd. Vernieuwingsbewerkingen die niet worden aangeroepen via de Power BI-service, zoals de TMSL-vernieuwingsopdracht, houden geen rekening met de geplande vernieuwingstijdzone.

Schermopname van het dialoogvenster Gepland vernieuwen met het invoerveld Tijdzone

Incrementele vernieuwing en realtimegegevens configureren

In deze secties worden belangrijke concepten beschreven voor het configureren van incrementeel vernieuwen en realtime gegevens. Wanneer u klaar bent voor meer gedetailleerde stapsgewijze instructies, raadpleegt u Incrementeel vernieuwen en realtimegegevens voor gegevenssets configureren.

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

Nadat u naar de Power BI-service hebt gepubliceerd, kunt u hetzelfde model niet opnieuw publiceren vanuit Power BI Desktop. Als u opnieuw publiceert, worden alle 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. Zie Geavanceerde incrementele vernieuwing - Implementatie met alleen metagegevens voor meer informatie.
Nadat u naar de Power BI-service hebt gepubliceerd, kunt u de gegevensset niet meer als pbix downloaden naar Power BI Desktop. Omdat gegevenssets in de service zo groot kunnen worden, is het niet praktisch om ze te downloaden en te openen op een gewone desktopcomputer.
Wanneer u realtime gegevens ophaalt met DirectQuery, kunt u de gegevensset niet publiceren naar een niet-Premium-werkruimte. Incrementeel vernieuwen met realtimegegevens wordt alleen ondersteund met Power BI Premium.

Parameters maken

Als u incrementeel vernieuwen wilt configureren in Power BI Desktop, maakt u eerst twee Power Query datum-/tijdparameters met de gereserveerde, hoofdlettergevoelige namen RangeStart en RangeEnd. Deze parameters, gedefinieerd in het dialoogvenster Parameters beheren in Power Query-editor, worden in eerste instantie gebruikt om de gegevens te filteren die in de Power BI Desktop modeltabel worden geladen, zodat alleen die rijen met een datum/tijd binnen die periode worden opgenomen. RangeStart vertegenwoordigt de oudste of vroegste datum/tijd, en RangeEnd vertegenwoordigt de nieuwste of laatste datum/tijd. Nadat het model is gepubliceerd naar de service en RangeStartRangeEnd automatisch worden overschreven door de service om query's uit te voeren op gegevens die zijn gedefinieerd door de vernieuwingsperiode die is opgegeven in de beleidsinstellingen voor incrementeel vernieuwen.

De gegevensbrontabel FactInternetSales bevat bijvoorbeeld gemiddeld 10.000 nieuwe rijen per dag. Als u het aantal rijen dat in eerste instantie in het model in Power BI Desktop wordt geladen, wilt beperken, geeft u een periode van twee dagen op tussen RangeStart en RangeEnd.

Schermopname van het dialoogvenster Parameters beheren met de parameters RangeStart en RangeEnd.

Gegevens filteren

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

Schermopname van het contextmenu van de kolom met Aangepast filter geselecteerd

In ons FactInternetSales-voorbeeld worden na het maken van filters op basis van de parameters en het toepassen van stappen twee dagen aan gegevens (ongeveer 20.000 rijen) in het model geladen.

Beleid definiëren

Nadat filters zijn toegepast en een subset van gegevens in het model is geladen, definieert u een beleid voor incrementele vernieuwing 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 als optionele instellingen op te geven.

Schermopname van het dialoogvenster Incrementeel vernieuwen en realtime gegevens met de optie Deze tabel incrementeel vernieuwen op.

Tabel

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

Verplichte instellingen

De instelling Gegevens archiveren vanaf de vernieuwingsdatum bepaalt de historische periode waarin rijen met een datum/tijd in die periode worden opgenomen in de gegevensset, plus rijen voor de huidige onvolledige historische periode, plus rijen in de vernieuwingsperiode tot de huidige datum en tijd.

Als u bijvoorbeeld vijf jaar opgeeft, worden in de tabel de laatste vijf hele jaren aan historische gegevens opgeslagen in jaarpartities. De tabel bevat ook 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 instelling Gegevens incrementeel vernieuwen vanaf de vernieuwingsdatum bepaalt de incrementele vernieuwingsperiode waarin alle rijen met een datum/tijd in die periode worden opgenomen in de vernieuwingspartities en worden vernieuwd bij elke vernieuwingsbewerking.

Als u bijvoorbeeld een vernieuwingsperiode van drie dagen opgeeft, overschrijft de service bij elke vernieuwingsbewerking de RangeStart parameters en RangeEnd om een query te maken voor rijen met een datum/tijd binnen een periode van drie dagen, waarbij het begin en einde afhankelijk zijn van de huidige datum en tijd. Rijen met een datum/tijd in de afgelopen drie dagen tot de huidige vernieuwingsbewerkingstijd worden vernieuwd. Met dit type beleid kunt u verwachten dat onze gegevenssettabel FactInternetSales in de service, die gemiddeld 10.000 nieuwe rijen per dag bevat, ongeveer 30.000 rijen vernieuwt bij elke vernieuwingsbewerking.

Geef een periode op die alleen het minimale aantal rijen bevat dat is vereist om nauwkeurige rapportage te garanderen. Wanneer u beleidsregels voor meer dan één tabel definieert, moeten dezelfde RangeStart parameters en RangeEnd 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 DirectQuery (alleen Premium) kunt u de meest recente wijzigingen ophalen uit de geselecteerde tabel bij de gegevensbron na de periode voor incrementeel vernieuwen met behulp van DirectQuery. Alle rijen met een datum/tijd later dan de periode voor incrementeel vernieuwen worden opgenomen in een DirectQuery-partitie en opgehaald uit de gegevensbron met elke gegevenssetquery.

Als deze instelling bijvoorbeeld is ingeschakeld, overschrijft de service bij elke vernieuwingsbewerking nog steeds de RangeStart parameters en RangeEnd om een query te maken voor rijen met een datum/tijd na de vernieuwingsperiode, waarbij het begin afhankelijk is van de huidige datum en tijd. Rijen met een datum/tijd na de huidige vernieuwingsbewerkingstijd worden ook opgenomen. Met dit type beleid bevat de gegevenssettabel FactInternetSales in de service de meest recente gegevensupdates.

De instelling Alleen volledige dagen vernieuwen zorgt ervoor dat alle rijen voor de hele dag worden opgenomen in de vernieuwingsbewerking. Deze instelling is optioneel , tenzij u de instelling De meest recente gegevens in realtime ophalen met DirectQuery (alleen Premium) inschakelt. Stel dat de vernieuwing is gepland om elke ochtend om 4:00 uur te worden uitgevoerd. Als er tussen middernacht en 4:00 uur tussen middernacht en 4:00 uur nieuwe rijen met gegevens worden weergegeven in de gegevensbrontabel, wilt u daar 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 uit een financieel systeem waarbij gegevens voor de vorige maand worden goedgekeurd op de twaalfde kalenderdag van de maand. U kunt de vernieuwingsperiode instellen op één maand en de vernieuwing instellen op de twaalfde dag van de maand. Als deze optie is geselecteerd, worden bijvoorbeeld de gegevens van januari 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 ingangsdatum en volledige perioden kunnen worden bepaald.

Met de instelling Gegevenswijzigingen detecteren kunt u nog selectiever vernieuwen. U kunt een datum/tijd-kolom selecteren die wordt gebruikt om alleen de dagen te identificeren en te vernieuwen waarop de gegevens zijn gewijzigd. Bij deze instelling wordt ervan uitgegaan dat een dergelijke kolom bestaat in de gegevensbron, die doorgaans voor controledoeleinden is bedoeld. Deze kolom mag niet dezelfde kolom zijn die wordt gebruikt om de gegevens te partitioneren met de RangeStart parameters 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, is het niet nodig om de periode te vernieuwen, waardoor het aantal dagen dat incrementeel wordt vernieuwd mogelijk verder kan worden teruggebracht van drie naar één.

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:

Alleen de maximale waarde van de kolom behouden 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 behouden blijft.

In sommige gevallen kan het inschakelen van de optie Gegevenswijzigingen detecteren* verder worden uitgebreid. U kunt bijvoorbeeld voorkomen dat een kolom voor de laatste update wordt bewaard in de cache in het geheugen, of scenario's inschakelen waarin een configuratie-/instructietabel wordt voorbereid door ETL-processen (extract-transform-load) om alleen de partities te markeren die moeten worden vernieuwd. In dergelijke gevallen gebruikt u voor Premium-capaciteiten TMSL en/of de TOM om het gedrag voor het detecteren 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 beleid voor incrementeel vernieuwen 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, de prestaties van de vernieuwingsbewerking verbeteren en ervoor zorgen dat de gegevensset geen maximale groottelimieten heeft door de opslagindeling Grote gegevensset in te schakelen voordat de eerste vernieuwingsbewerking in de service wordt uitgevoerd. Zie Grote gegevenssets in Power BI Premium voor meer informatie.

Belangrijk

Nadat Power BI Desktop het model naar de service heeft gepubliceerd, kunt u dat PBIX-bestand niet meer terug downloaden.

Vernieuwen

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

Volgende vernieuwingsbewerkingen, afzonderlijk of gepland, zijn veel sneller omdat alleen de partities voor incrementeel vernieuwen worden vernieuwd. Andere verwerkingsbewerkingen moeten nog steeds plaatsvinden, zoals het samenvoegen van partities en het opnieuw berekenen, maar dit duurt meestal veel minder tijd dan de eerste vernieuwing.

Rapport automatisch vernieuwen

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

Geavanceerde incrementele vernieuwing

Als uw gegevensset zich in een Premium-capaciteit bevindt waarvoor een 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 op te starten of om historische partities met een back-datum te vernieuwen. Zie Geavanceerd incrementeel vernieuwen met het XMLA-eindpunt voor meer informatie.

Community

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