Dela via

Felsöka inkrementell uppdatering och realtidsdata

  • Artikel

Det finns två faser när du implementerar en inkrementell uppdaterings- och realtidsdatalösning, där den första är att konfigurera parametrar, filtrera och definiera en princip i Power BI Desktop, och den andra är den första semantiska modelluppdateringsåtgärden och efterföljande uppdateringar i tjänsten. I den här artikeln beskrivs felsökning separat för var och en av dessa faser.

Efter att ha partitionerat tabellen i Power BI-tjänst är det viktigt att komma ihåg att inkrementellt uppdaterade tabeller som också hämtar realtidsdata med DirectQuery nu fungerar i hybridläge, vilket innebär att de fungerar i både import- och DirectQuery-läge. Alla tabeller med relationer till en sådan inkrementellt uppdaterad hybridtabell måste använda dubbelt läge så att de kan användas i import- och DirectQuery-läge utan prestandapåföljder. Dessutom kan visuella rapportobjekt cachelagra resultat för att undvika att skicka frågor tillbaka till datakällan, vilket skulle hindra tabellen från att hämta de senaste datauppdateringarna i realtid. Det sista felsökningsavsnittet beskriver dessa problem med hybridläge.

Innan du felsöker inkrementell uppdatering och realtidsdata bör du granska Inkrementell uppdatering för modeller och realtidsdata och stegvis information i Konfigurera inkrementell uppdatering och realtidsdata.

Konfigurera i Power BI Desktop

De flesta problem som uppstår när du konfigurerar inkrementell uppdatering och realtidsdata har att göra med frågedelegering. Som beskrivs i Översikt över inkrementell uppdatering för modeller – Datakällor som stöds måste datakällan ha stöd för frågedelegering.

Problem: Det tar för lång tid att läsa in data

I Power Query-redigeraren tar inläsningen av data för lång tid och datorresurser efter att du har valt Använd. Det finns flera potentiella orsaker.

Orsak: Matchningsfel för datatyp

Det här problemet kan orsakas av ett matchningsfel för datatypen där Date/Time är den datatyp som krävs för parametrarna RangeStart och RangeEnd , men den tabelldatumkolumn som filtren tillämpas på inte Date/Time är datatyp eller vice versa. Både parametrarnas datatyp och den filtrerade datakolumnen måste vara Date/Time datatyp och formatet måste vara detsamma. Annars kan frågan inte vikas.

Lösning: Verifiera datatyp

Kontrollera att datum/tid-kolumnen för tabellen för inkrementell uppdatering är av Date/Time datatyp. Om tabellen inte innehåller en kolumn av Date/Time datatyp, utan i stället använder en heltalsdatatyp, kan du skapa en funktion som konverterar datum/tid-värdet i RangeStart parametrarna och RangeEnd för att matcha heltals surrogatnyckeln för datakälltabellen. Mer information finns i Konfigurera inkrementell uppdatering – Konvertera DateTime till heltal.

Orsak: Datakällan stöder inte frågedelegering

Enligt beskrivningen i Inkrementell uppdatering och realtidsdata för modeller – Krav är inkrementell uppdatering utformad för datakällor som stöder frågedelegering. Kontrollera att datakällsfrågor viks i Power BI Desktop innan du publicerar till tjänsten, där frågedelegeringsproblem kan förvärras avsevärt. Den här metoden är särskilt viktig när du inkluderar realtidsdata i en inkrementell uppdateringsprincip eftersom DirectQuery-partitionen i realtid kräver frågedelegering.

Lösning: Verifiera och testa frågor

I de flesta fall visas en varning i dialogrutan Inkrementell uppdateringsprincip som anger om frågan som ska köras mot datakällan inte stöder frågedelegering. I vissa fall kan det dock vara nödvändigt att ytterligare se till att frågedelegering är möjligt. Övervaka om möjligt frågan som skickas till datakällan med hjälp av ett verktyg som SQL Profiler. En fråga med filter baserat på RangeStart och RangeEnd måste köras i en enda fråga.

Du kan också ange en kort datum/tidsperiod i parametrarna RangeStart och RangeEnd som inte innehåller fler än några tusen rader. Om belastningen på filtrerade data från datakällan till modellen tar lång tid och är processintensiv innebär det sannolikt att frågan inte viks.

Om du fastställer att frågan inte viks kan du läsa Frågedelegeringsvägledning i Power BI Desktop och Power Query-frågedelegering för att få hjälp med att identifiera vad som kan förhindra frågedelegering och hur, eller om, datakällan till och med kan stödja frågedelegering.

Uppdatering av semantisk modell i tjänsten

Felsökningen av inkrementella uppdateringsproblem i tjänsten varierar beroende på vilken typ av kapacitet din modell har publicerats till. Semantiska modeller på Premium-kapaciteter stöder användning av verktyg som SQL Server Management Studio (SSMS) för att visa och selektivt uppdatera enskilda partitioner. Power BI Pro-modeller å andra sidan ger inte verktygsåtkomst via XMLA-slutpunkten, så felsökning av inkrementella uppdateringsproblem kan kräva lite mer utvärdering och fel.

Problem: Tidsgränsen för den första uppdateringen har överskrids

Schemalagd uppdatering för Power BI Pro-modeller på en delad kapacitet har en tidsgräns på två timmar. Den här tidsgränsen ökas till fem timmar för modeller i en Premium-kapacitet. Datakällans system kan också införa en storleksgräns för frågeretur eller tidsgräns för frågor.

Orsak: Datakällsfrågor viks inte

Även om problem med frågedelegering vanligtvis kan fastställas i Power BI Desktop innan de publiceras till tjänsten, är det möjligt att modelluppdateringsfrågor inte viks, vilket leder till för höga uppdateringstider och resursanvändning för frågekombinationsmotorn. Den här situationen inträffar eftersom en fråga skapas för varje partition i modellen. Om frågorna inte viks och data inte filtreras vid datakällan försöker motorn filtrera data.

Lösning: Verifiera frågedelegering

Använd ett spårningsverktyg vid datakällan för att fastställa att frågan som skickas för varje partition är en enda fråga som innehåller ett filter baserat på parametrarna RangeStart och RangeEnd. Om inte kontrollerar du att frågedelegering sker i Power BI Desktop-modellen när du läser in en liten filtrerad mängd data i modellen. Annars kan du först åtgärda den i modellen, utföra en metadatauppdatering till modellen (med hjälp av XMLA-slutpunkten) eller om en Power BI Pro-modell på en delad kapacitet tar bort den ofullständiga modellen i tjänsten, publicerar om och försöker utföra en inledande uppdateringsåtgärd igen.

Om du fastställer att frågor inte viks kan du läsa frågedelegeringsvägledning i Power BI Desktop och Power Query-frågedelegering för att få hjälp med att identifiera vad som kan förhindra frågedelegering.

Orsak: Data som läses in i partitioner är för stora

Lösning: Minska modellstorleken

I många fall orsakas tidsgränsen av mängden data som måste efterfrågas och läsas in i modellpartitionerna överskrider de tidsgränser som kapaciteten har infört. Minska storleken eller komplexiteten i din modell eller överväg att dela upp modellen i mindre delar.

Lösning: Aktivera lagringsformat för stora modeller

Om modellen växer över 1 GB eller mer för modeller som publicerats till Premium-kapaciteter kan du förbättra uppdateringsåtgärdens prestanda och se till att modellen inte maxar storleksgränserna genom att aktivera lagringsformatet för stora modeller innan du utför den första uppdateringsåtgärden i tjänsten. Mer information finns i Stora modeller i Power BI Premium.

Lösning: Startuppdatering för Bootstrap

För modeller som publicerats till Premium-kapaciteter kan du starta den första uppdateringsåtgärden. Bootstrapping gör att tjänsten kan skapa tabell- och partitionsobjekt för modellen, men inte läsa in och bearbeta historiska data i någon av partitionerna. Mer information finns i Avancerad inkrementell uppdatering – Förhindra tidsgränser vid den första fullständiga uppdateringen.

Orsak: Tidsgränsen för datakällans fråga

Frågor kan begränsas av en standardtidsgräns för datakällan.

Lösning: Åsidosätt tidsgränsen i frågeuttrycket

Många datakällor tillåter överskriden tidsgräns i frågeuttrycket. Mer information finns i Inkrementell uppdatering för modeller – Tidsgränser.

Problem: Uppdateringen misslyckas på grund av duplicerade värden

Orsak: Postdatum har ändrats

Med en uppdateringsåtgärd uppdateras endast data som har ändrats vid datakällan i modellen. Eftersom data delas upp med ett datum rekommenderar vi att postdatum (transaktion) inte ändras.

Om ett datum ändras av misstag kan två problem uppstå: Användare märker att vissa summor har ändrats i historiska data (som inte ska inträffa) eller under en uppdatering returneras ett fel som anger att ett unikt värde inte är unikt. För det senare kan den här situationen inträffa när tabellen med inkrementell uppdatering konfigurerad används i en relation med en 1:N annan tabell som 1 sida och bör ha unika värden. När data ändras för ett specifikt ID visas det ID:t sedan i en annan partition och motorn identifierar att värdet inte är unikt.

Lösning: Uppdatera specifika partitioner

Om det finns ett affärsbehov att ändra vissa tidigare data från datumen är en möjlig lösning att använda SSMS för att uppdatera alla partitioner från den punkt där ändringen finns upp till den aktuella uppdateringspartitionen och därmed hålla 1 sidan av relationen unik.

Problem: Data trunkeras

Orsak: Frågegränsen för datakälla har överskridits

Vissa datakällor, till exempel Azure Data Explorer, Log Analytics och Application Insights, har en gräns på 64 MB (komprimerad) för data som kan returneras för en extern fråga. Azure Data Explorer kan returnera ett explicit fel, men för andra som Log Analytics och Application Insights trunkeras de data som returneras.

Lösning: Ange mindre uppdaterings- och lagringsperioder

Ange mindre uppdaterings- och lagringsperioder i principen. Om du till exempel har angett en uppdateringsperiod på ett år och ett frågefel returneras eller om data som returneras trunkeras kan du prova en uppdateringsperiod på 12 månader. Du vill se till att frågor för den aktuella uppdateringspartitionen eller historiska partitioner som baseras på perioderna Uppdatera och Lagra inte returnerar mer än 64 MB data.

Problem: Uppdateringen misslyckas på grund av partitionsnyckelkonflikter

Orsak: Datum i datumkolumnen i datakällan uppdateras

Filtret på datumkolumnen används för att dynamiskt partitionera data i periodintervall i Power BI-tjänst. Inkrementell uppdatering är inte utformad för att stödja fall där den filtrerade datumkolumnen uppdateras i källsystemet. En uppdatering tolkas som en infogning och en borttagning, inte en faktisk uppdatering. Om borttagningen sker i det historiska intervallet och inte det inkrementella intervallet hämtas den inte, vilket kan orsaka datauppdateringsfel på grund av partitionsnyckelkonflikter.

Hybridläge i tjänsten (förhandsversion)

När Power BI tillämpar en inkrementell uppdateringsprincip med realtidsdata omvandlas den inkrementellt uppdaterade tabellen till en hybridtabell som fungerar i både import- och DirectQuery-läge. Observera DirectQuery-partitionen i slutet av följande partitionslista för en exempeltabell. Förekomsten av en DirectQuery-partition har konsekvenser för relaterade tabeller och visuella rapportobjekt som kör frågor mot den här tabellen.

Skärmbild av hybridtabellen.

Problem: Frågeprestandan är dålig

Hybridtabeller som körs i både import- och DirectQuery-läge kräver att alla relaterade tabeller körs i dubbelt läge så att de kan fungera som antingen cachelagrade eller inte cachelagrade, beroende på kontexten för frågan som skickas till Power BI-modellen. Med dubbla lägen kan Power BI minska antalet begränsade relationer i modellen och generera effektiva datakällsfrågor för att säkerställa bra prestanda. Begränsade relationer kan inte skickas till datakällan som kräver att Power BI hämtar mer data än nödvändigt. Eftersom dubbla tabeller kan fungera som directquery- eller importtabeller undviks den här situationen.

När du konfigurerar en inkrementell uppdateringsprincip påminner Power BI Desktop dig om att växla relaterade tabeller till dubbelt läge när du väljer Hämta de senaste data i realtid med DirectQuery (endast Premium). Kontrollera dessutom att du granskar alla befintliga tabellrelationer i modellvyn.

Skärmbild som visar konvertering av relaterade tabeller till dubbla lägen.

Tabeller som för närvarande körs i DirectQuery-läge, växlas enkelt till dubbla lägen. I tabellegenskaperna går du till Avancerat och väljer Dubbla i listrutan Lagringsläge. Tabeller som för närvarande körs i importläge kräver dock manuellt arbete. Dubbla tabeller har samma funktionsbegränsningar som DirectQuery-tabeller. Power BI Desktop kan därför inte konvertera importtabeller eftersom de kan förlita sig på andra funktioner som inte är tillgängliga i dubbelt läge. Du måste återskapa tabellerna manuellt i DirectQuery-läge och sedan konvertera dem till dubbla lägen. Mer information finns i Hantera lagringsläge i Power BI Desktop.

Problem: Rapportvisualiseringar visar inte de senaste data

Orsak: Power BI cachelagrar frågeresultat förbättrar prestanda och minskar serverdelsbelastningen

Som standard cachelagrar Power BI frågeresultat så att frågor för visuella rapportobjekt kan bearbetas snabbt även om de baseras på DirectQuery. Att undvika onödiga datakällafrågor förbättrar prestandan och minskar datakällans belastning, men det kan också innebära att de senaste dataändringarna i källan inte ingår i resultatet.

Lösning: Konfigurera automatisk siduppdatering

Om du vill fortsätta att hämta de senaste dataändringarna från källan konfigurerar du automatisk siduppdatering för dina rapporter i Power BI-tjänst. Automatisk siduppdatering kan utföras med fasta intervall, till exempel fem sekunder eller tio minuter. När det specifika intervallet har nåtts skickar alla visuella objekt på den sidan en uppdateringsfråga till datakällan och uppdaterar därefter. Du kan också uppdatera visuella objekt på en sida baserat på identifiering av ändringar i data. Den här metoden kräver ett mått för ändringsidentifiering som Power BI sedan använder för att avsöka datakällan efter ändringar. Ändringsidentifiering stöds endast i arbetsytor som ingår i en Premium-kapacitet. Mer information finns i Automatisk siduppdatering i Power BI.

Relaterat innehåll