Problemen met incrementeel vernieuwen en realtimegegevens oplossen

Artikel
11/10/2023

Er zijn twee fasen bij het implementeren van een incrementele vernieuwings- en realtimegegevensoplossing, de eerste die parameters configureert, filtert en definieert een beleid in Power BI Desktop, en de tweede de eerste semantische vernieuwingsbewerking van het model en latere vernieuwingen in de service. In dit artikel wordt het oplossen van problemen afzonderlijk besproken voor elk van deze fasen.

Als u de tabel in de Power BI-service hebt gepartitioneerd, is het belangrijk om er rekening mee te houden dat incrementeel vernieuwde tabellen die ook realtimegegevens ophalen met DirectQuery nu worden uitgevoerd in de hybride modus, wat betekent dat ze werken in zowel de importmodus als de DirectQuery-modus. Tabellen met relaties met een dergelijke incrementeel vernieuwde hybride tabel moeten de Dual-modus gebruiken, zodat ze kunnen worden gebruikt in de import- en DirectQuery-modus zonder prestatiestraffen. Bovendien kunnen rapportvisuals resultaten opslaan om te voorkomen dat query's naar de gegevensbron worden verzonden, waardoor de tabel de meest recente gegevensupdates in realtime kan ophalen. In de laatste sectie over probleemoplossing worden deze problemen in de hybride modus behandeld.

Voordat u problemen met incrementeel vernieuwen en realtimegegevens gaat oplossen, moet u incrementeel vernieuwen controleren voor modellen en realtime gegevens en stapsgewijze informatie in Incrementeel vernieuwen en realtime gegevens configureren.

Configureren in Power BI Desktop

De meeste problemen die optreden bij het configureren van incrementeel vernieuwen en realtime gegevens hebben te maken met het vouwen van query's. Zoals beschreven in Incrementeel vernieuwen voor modellenoverzicht- Ondersteunde gegevensbronnen moet uw gegevensbron ondersteuning bieden voor het vouwen van query's.

Probleem: het laden van gegevens duurt te lang

Na het selecteren van Toepassen duurt het laden van gegevens in Power Query-editor te veel tijd en computerbronnen. Er zijn verschillende mogelijke oorzaken.

Oorzaak: gegevenstype komt niet overeen

Dit probleem kan worden veroorzaakt door een gegevenstype dat niet overeenkomt met het Date/Time vereiste gegevenstype voor de RangeStart en RangeEnd parameters, maar de tabeldatumkolom waarop de filters worden toegepast, zijn geen Date/Time gegevenstype of omgekeerd. Zowel het gegevenstype parameters als de gefilterde gegevenskolom moeten gegevenstype zijn Date/Time en de indeling moet hetzelfde zijn. Als dat niet het probleem is, kan de query niet worden gevouwen.

Oplossing: gegevenstype controleren

Controleer of de datum-/tijdkolom voor de tabel incrementeel vernieuwen van Date/Time het gegevenstype is. Als uw tabel geen kolom met Date/Time gegevenstype bevat, maar in plaats daarvan een gegevenstype geheel getal gebruikt, kunt u een functie maken waarmee de datum/tijd-waarde in de RangeStart en RangeEnd parameters worden geconverteerd zodat deze overeenkomt met de surrogaatsleutel voor gehele getallen van de gegevensbrontabel. Zie Incrementeel vernieuwen configureren : Datum/tijd converteren naar geheel getal voor meer informatie.

Oorzaak: De gegevensbron biedt geen ondersteuning voor het vouwen van query's

Zoals beschreven in incrementeel vernieuwen en realtime gegevens voor modellen - Vereisten, is incrementeel vernieuwen ontworpen voor gegevensbronnen die ondersteuning bieden voor het vouwen van query's. Zorg ervoor dat gegevensbronquery's worden gevouwen in Power BI Desktop voordat u naar de service publiceert, waarbij problemen met het vouwen van query's aanzienlijk kunnen worden samengesteld. Deze benadering is vooral belangrijk wanneer u realtime gegevens in een incrementeel vernieuwingsbeleid op neemt, omdat voor de realtime DirectQuery-partitie query's moeten worden gevouwen.

Oplossing: Query's controleren en testen

In de meeste gevallen wordt een waarschuwing weergegeven in het dialoogvenster incrementeel vernieuwen dat aangeeft of de query moet worden uitgevoerd op basis van de gegevensbron, geen ondersteuning biedt voor het vouwen van query's. In sommige gevallen is het echter mogelijk om ervoor te zorgen dat query's kunnen worden gevouwen. Controleer indien mogelijk de query die wordt doorgegeven aan de gegevensbron met behulp van een hulpprogramma zoals SQL Profiler. Een query met filters op RangeStart basis van en RangeEnd moet worden uitgevoerd in één query.

U kunt ook een korte datum/tijdsperiode opgeven in de RangeStart en RangeEnd parameters die niet meer dan een paar duizend rijen bevatten. Als het laden van gefilterde gegevens uit de gegevensbron naar het model lang duurt en intensief is, betekent dit waarschijnlijk dat de query niet wordt gevouwen.

Als u bepaalt dat de query niet wordt gevouwen, raadpleegt u de richtlijnen voor het vouwen van query's in Power BI Desktop en Power Query voor hulp bij het identificeren van wat mogelijk het vouwen van query's verhindert en hoe, of als de gegevensbron zelfs ondersteuning biedt voor het vouwen van query's.

Semantisch model vernieuwen in de service

Het oplossen van incrementele vernieuwingsproblemen in de service verschilt, afhankelijk van het type capaciteit waarin uw model is gepubliceerd. Semantische modellen op Premium-capaciteiten ondersteunen het gebruik van hulpprogramma's zoals SQL Server Management Studio (SSMS) om afzonderlijke partities weer te geven en selectief te vernieuwen. Power BI Pro-modellen bieden daarentegen geen toegang tot hulpprogramma's via het XMLA-eindpunt, dus het oplossen van problemen met incrementeel vernieuwen vereist mogelijk iets meer proef- en foutfouten.

Probleem: Time-out voor eerste vernieuwing

Geplande vernieuwing voor Power BI Pro-modellen op een gedeelde capaciteit heeft een tijdslimiet van twee uur. Deze tijdslimiet wordt verhoogd tot vijf uur voor modellen in een Premium-capaciteit. Gegevensbronsystemen kunnen ook een limiet voor de retourgrootte of time-out voor query's opleggen.

Oorzaak: Gegevensbronquery's worden niet gevouwen

Hoewel problemen met het vouwen van query's meestal kunnen worden vastgesteld in Power BI Desktop voordat ze naar de service worden gepubliceerd, is het mogelijk dat query's voor het vernieuwen van modellen niet worden gevouwen, wat leidt tot overmatige vernieuwingstijden en resourcegebruik van query-mashup-engine. Deze situatie treedt op omdat er een query wordt gemaakt voor elke partitie in het model. Als de query's niet worden gevouwen en gegevens niet worden gefilterd in de gegevensbron, probeert de engine de gegevens te filteren.

Oplossing: Query folding controleren

Gebruik een traceringsprogramma in de gegevensbron om te bepalen welke query voor elke partitie wordt doorgegeven, is één query die een filter bevat op basis van de parameters RangeStart en RangeEnd. Zo niet, controleert u of query folding plaatsvindt in het Power BI Desktop-model bij het laden van een kleine gefilterde hoeveelheid gegevens in het model. Als dat niet het probleem is, moet u deze eerst in het model herstellen, een metagegevensupdate uitvoeren naar het model (met behulp van XMLA-eindpunt) of als een Power BI Pro-model op een gedeelde capaciteit het onvolledige model in de service verwijdert, opnieuw publiceert en een eerste vernieuwingsbewerking opnieuw probeert uit te voeren.

Als u vaststelt dat query's niet worden gevouwen, raadpleegt u de richtlijnen voor het vouwen van query's in Power BI Desktop en Power Query voor hulp bij het identificeren van wat het vouwen van query's mogelijk verhindert.

Oorzaak: Gegevens die in partities zijn geladen, zijn te groot

Oplossing: Modelgrootte verkleinen

In veel gevallen wordt de time-out veroorzaakt door de hoeveelheid gegevens die moet worden opgevraagd en geladen in de modelpartities, groter is dan de tijdslimieten die door de capaciteit worden opgelegd. Verklein de grootte of complexiteit van uw model of overweeg het model te splitsen in kleinere stukken.

Oplossing: Opslagindeling voor grote modellen inschakelen

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

Oplossing: Initial Refresh bootstrap

Voor modellen die zijn gepubliceerd naar Premium-capaciteiten, kunt u de eerste vernieuwingsbewerking opnieuw opstarten. Met Bootstrapping kan de service tabel- en partitieobjecten voor het model maken, maar historische gegevens niet laden en verwerken in een van de partities. Zie Geavanceerde incrementele vernieuwing: time-outs voorkomen bij de eerste volledige vernieuwing.

Oorzaak: Time-out van gegevensbronquery

Query's kunnen worden beperkt door een standaardtijdlimiet voor de gegevensbron.

Oplossing: De tijdslimiet in de query-expressie overschrijven

Veel gegevensbronnen maken het overschrijven van de tijdslimiet in de query-expressie mogelijk. Zie Incrementeel vernieuwen voor modellen - Tijdslimieten voor meer informatie.

Probleem: vernieuwen mislukt vanwege dubbele waarden

Oorzaak: Postdatums zijn gewijzigd

Met een vernieuwingsbewerking worden alleen gegevens die in de gegevensbron zijn gewijzigd, vernieuwd in het model. Omdat de gegevens worden gedeeld door een datum, is het raadzaam dat postdatums (transactiedatums) niet worden gewijzigd.

Als een datum per ongeluk wordt gewijzigd, kunnen er twee problemen optreden: gebruikers merken dat sommige totalen zijn gewijzigd in de historische gegevens (dat niet moet gebeuren), of tijdens een vernieuwing wordt een fout geretourneerd die aangeeft dat een unieke waarde niet in feite uniek is. Deze situatie kan zich voordoen wanneer de tabel met incrementeel vernieuwen wordt gebruikt in een relatie met een 1:N andere tabel als de 1 zijkant en unieke waarden moet hebben. Wanneer de gegevens voor een specifieke id worden gewijzigd, wordt die id vervolgens weergegeven in een andere partitie en detecteert de engine dat de waarde niet uniek is.

Oplossing: Specifieke partities vernieuwen

Wanneer er een zakelijke noodzaak is om enkele eerdere gegevens van de datums te wijzigen, is het mogelijk om SSMS te gebruiken om alle partities te vernieuwen vanaf het punt waar de wijziging zich tot de huidige vernieuwingspartitie bevindt, waardoor de 1 kant van de relatie uniek blijft.

Probleem: gegevens worden afgekapt

Oorzaak: De querylimiet van de gegevensbron is overschreden

Sommige gegevensbronnen, zoals Azure Data Explorer, Log Analytics en Application Insights, hebben een limiet van 64 MB (gecomprimeerd) voor gegevens die kunnen worden geretourneerd voor een externe query. Azure Data Explorer kan een expliciete fout retourneren, maar voor anderen, zoals Log Analytics en Application Insights, worden de geretourneerde gegevens afgekapt.

Oplossing: Kleinere vernieuwings- en opslagperioden opgeven

Geef kleinere vernieuwings- en archiefperioden op in het beleid. Als u bijvoorbeeld een vernieuwingsperiode van één jaar hebt opgegeven en er een queryfout wordt geretourneerd of de geretourneerde gegevens worden afgekapt, probeert u een vernieuwingsperiode van 12 maanden. U wilt ervoor zorgen dat query's voor de huidige vernieuwingspartitie of historische partities op basis van de vernieuwings- en archiefperioden niet meer dan 64 MB aan gegevens retourneren.

Probleem: vernieuwen mislukt vanwege conflicten tussen partitiesleutels

Oorzaak: Datum in de datumkolom bij de gegevensbron wordt bijgewerkt

Het filter op de datumkolom wordt gebruikt om de gegevens dynamisch te partitioneren in periodebereiken in de Power BI-service. Incrementeel vernieuwen is niet ontworpen ter ondersteuning van gevallen waarin de gefilterde datumkolom wordt bijgewerkt in het bronsysteem. Een update wordt geïnterpreteerd als een invoeging en een verwijdering, niet als een werkelijke update. Als de verwijdering plaatsvindt in het historische bereik en niet het incrementele bereik, wordt het niet opgehaald, wat kan leiden tot fouten bij het vernieuwen van gegevens vanwege conflicten tussen partitiesleutels.

Hybride modus in de service (preview)

Wanneer Power BI een beleid voor incrementeel vernieuwen toepast met realtime gegevens, wordt de incrementeel vernieuwde tabel omgezet in een hybride tabel die werkt in zowel de importmodus als de DirectQuery-modus. Let op de DirectQuery-partitie aan het einde van de volgende partitieslijst van een voorbeeldtabel. De aanwezigheid van een DirectQuery-partitie heeft gevolgen voor gerelateerde tabellen en rapportvisuals die een query uitvoeren op deze tabel.

Probleem: queryprestaties zijn slecht

Voor hybride tabellen die worden uitgevoerd in zowel de importmodus als de DirectQuery-modus, moeten gerelateerde tabellen worden uitgevoerd in de dual-modus, zodat ze kunnen fungeren als in de cache of niet in de cache, afhankelijk van de context van de query die wordt verzonden naar het Power BI-model. Met dubbele modus kan Power BI het aantal beperkte relaties in het model verminderen en efficiënte gegevensbronquery's genereren om goede prestaties te garanderen. Beperkte relaties kunnen niet worden gepusht naar de gegevensbron waarvoor Power BI meer gegevens moet ophalen dan nodig is. Omdat Dual-tabellen kunnen fungeren als DirectQuery- of Importtabellen, wordt deze situatie vermeden.

Wanneer u een beleid voor incrementeel vernieuwen configureert, herinnert Power BI Desktop u eraan om gerelateerde tabellen over te schakelen naar de dual-modus wanneer u de meest recente gegevens in realtime ophalen selecteert met DirectQuery (alleen Premium). Zorg er bovendien voor dat u alle bestaande tabelrelaties controleert in de modelweergave.

Tabellen die momenteel worden uitgevoerd in de DirectQuery-modus, zijn eenvoudig overgeschakeld naar de Dual-modus. Selecteer Dual in de tabeleigenschappen onder Geavanceerd in de keuzelijst voor opslagmodus. Tabellen die momenteel worden uitgevoerd in de importmodus, vereisen echter handmatig werk. Dubbele tabellen hebben dezelfde functionele beperkingen als DirectQuery-tabellen. Importtabellen kunnen daarom niet worden geconverteerd in Power BI Desktop, omdat ze mogelijk afhankelijk zijn van andere functionaliteit die niet beschikbaar is in de dual-modus. U moet deze tabellen handmatig opnieuw maken in de DirectQuery-modus en deze vervolgens converteren naar de Dual-modus. Zie De opslagmodus beheren in Power BI Desktop voor meer informatie.

Probleem: rapportvisuals geven niet de meest recente gegevens weer

Oorzaak: Queryresultaten in de cache van Power BI verbeteren de prestaties en verminderen de back-endbelasting

In Power BI worden standaard queryresultaten in de cache opgeslagen, zodat query's van rapportvisuals snel kunnen worden verwerkt, zelfs als ze zijn gebaseerd op DirectQuery. Het voorkomen van onnodige gegevensbronquery's verbetert de prestaties en vermindert de belasting van de gegevensbron, maar kan ook betekenen dat de meest recente gegevenswijzigingen in de bron niet in de resultaten worden opgenomen.

Oplossing: Automatische paginavernieuwing configureren

Als u de meest recente gegevenswijzigingen van de bron wilt blijven ophalen, configureert u automatische paginavernieuwing voor uw rapporten in de Power BI-service. Het automatisch vernieuwen van pagina's kan met vaste intervallen worden uitgevoerd, zoals vijf seconden of tien minuten. Wanneer dit specifieke interval is bereikt, verzenden alle visuals op die pagina een updatequery naar de gegevensbron en worden ze dienovereenkomstig bijgewerkt. U kunt ook visuals op een pagina vernieuwen op basis van het detecteren van wijzigingen in de gegevens. Deze benadering vereist een wijzigingsdetectiemeting die Power BI vervolgens gebruikt om de gegevensbron te peilen op wijzigingen. Wijzigingsdetectie wordt alleen ondersteund in werkruimten die deel uitmaken van een Premium-capaciteit. Zie Pagina automatisch vernieuwen in Power BI voor meer informatie.