Förstå och optimera uppdatering av dataflöden
Med Power BI-dataflöden kan du ansluta till, transformera, kombinera och distribuera data för nedströmsanalys. Ett nyckelelement i dataflöden är uppdateringsprocessen, som tillämpar transformeringsstegen som du skapade i dataflödena och uppdaterar data i själva objekten.
För att förstå körningstider, prestanda och om du får ut mesta möjliga av ditt dataflöde kan du ladda ned uppdateringshistoriken när du har uppdaterat ett dataflöde.
Förstå uppdateringar
Det finns två typer av uppdateringar som gäller för dataflöden:
Full, som utför en fullständig tömning och omläsning av dina data.
Inkrementell (endast Premium), som bearbetar en delmängd av dina data baserat på tidsbaserade regler, uttryckta som ett filter, som du konfigurerar. Filtret på datumkolumnen partitioneras dynamiskt data i intervall i Power BI-tjänst. När du har konfigurerat den inkrementella uppdateringen ändrar dataflödet automatiskt frågan så att den inkluderar filtrering efter datum. Du kan redigera den automatiskt genererade frågan med hjälp av Avancerad redigerare i Power Query för att finjustera eller anpassa uppdateringen. Om du tar med din egen Azure Data Lake Storage kan du se tidssektorer för dina data baserat på den uppdateringsprincip som du har angett.
Kommentar
Mer information om inkrementell uppdatering och hur det fungerar finns i Använda inkrementell uppdatering med dataflöden.
Inkrementell uppdatering möjliggör stora dataflöden i Power BI med följande fördelar:
Uppdateringarna går snabbare efter den första uppdateringen på grund av följande fakta:
- Power BI uppdaterar de senaste N-partitionerna som angetts av användaren (där partitionen är dag/vecka/månad och så vidare) eller
- Power BI uppdaterar endast data som behöver uppdateras. Till exempel uppdaterar du bara de senaste fem dagarna av en 10-årig semantisk modell.
- Power BI uppdaterar endast data som har ändrats, så länge du anger den kolumn som du vill söka efter ändringar i.
Uppdateringar är mer tillförlitliga – det är inte längre nödvändigt att underhålla långvariga anslutningar till flyktiga källsystem.
Resursförbrukningen minskar – mindre data att uppdatera minskar den totala förbrukningen av minne och andra resurser.
När det är möjligt använder Power BI parallell bearbetning på partitioner, vilket kan leda till snabbare uppdateringar.
Om en uppdatering misslyckas i något av dessa uppdateringsscenarier uppdateras inte data. Dina data kan vara inaktuella tills den senaste uppdateringen har slutförts, eller så kan du uppdatera dem manuellt och sedan slutföra dem utan fel. Uppdateringen sker vid en partition eller en entitet, så om en inkrementell uppdatering misslyckas, eller om en entitet har ett fel, sker inte hela uppdateringstransaktionen. Ett annat sätt är att om en partition (inkrementell uppdateringsprincip) eller en entitet misslyckas för ett dataflöde misslyckas hela uppdateringsåtgärden och inga data uppdateras.
Förstå och optimera uppdateringar
Om du vill förstå hur en uppdateringsåtgärd för dataflöde fungerar kan du läsa uppdateringshistoriken för dataflödet genom att navigera till ett av dina dataflöden. Välj Fler alternativ (...) för dataflödet. Välj sedan Inställningar > Uppdateringshistorik. Du kan också välja dataflödet på arbetsytan. Välj sedan Fler alternativ (...) > Uppdateringshistorik.
Uppdateringshistoriken ger en översikt över uppdateringar, inklusive typen – på begäran eller schemalagd, varaktighet och körningsstatus. Om du vill se information i form av en CSV-fil väljer du nedladdningsikonen längst till höger på uppdateringsbeskrivningens rad. Den nedladdade CSV:en innehåller de attribut som beskrivs i följande tabell. Premium-uppdateringar ger mer information baserat på de extra funktionerna för beräkning och dataflöden, jämfört med Pro-baserade dataflöden som finns på delad kapacitet. Därför är några av följande mått endast tillgängliga i Premium.
| Objekt | beskrivning | Pro | Premium |
|---|---|---|---|
| Begärd den | Tidsuppdateringen schemalades eller uppdateringen klickades nu i lokal tid. | ✔ | ✔ |
| Dataflödesnamn | Namnet på ditt dataflöde. | ✔ | ✔ |
| Uppdateringsstatus för dataflöde | Slutförda, misslyckade eller överhoppade (för en entitet) är möjliga statusar. Användningsfall som länkade entiteter är orsaker till varför man kan se överhoppade. | ✔ | ✔ |
| Enhetsnamn | Tabellnamn. | ✔ | ✔ |
| Partitionsnamn | Det här objektet är beroende av om dataflödet är premium eller inte, och om Pro visas som NA eftersom det inte stöder inkrementella uppdateringar. Premium visar antingen FullRefreshPolicyPartition eller IncrementalRefreshPolicyPartition-[DateRange]. | ✔ | |
| Uppdateringsstatus | Uppdateringsstatus för den enskilda entiteten eller partitionen, vilket ger status för den tidssektor med data som uppdateras. | ✔ | ✔ |
| Starttid | I Premium är det här objektet den tid då dataflödet köades för bearbetning för entiteten eller partitionen. Den här tiden kan skilja sig åt om dataflöden har beroenden och behöver vänta tills resultatuppsättningen för ett uppströms dataflöde börjar bearbetas. | ✔ | ✔ |
| Sluttid | Sluttiden är den tid då dataflödesentiteten eller partitionen slutfördes, om tillämpligt. | ✔ | ✔ |
| Varaktighet | Total förfluten tid för dataflödet att uppdateras uttryckt i HH:MM:SS. | ✔ | ✔ |
| Bearbetade rader | För en viss entitet eller partition genomsöks eller skrivs antalet rader av dataflödesmotorn. Det här objektet kanske inte alltid innehåller data baserat på den åtgärd som du utförde. Data kan utelämnas när beräkningsmotorn inte används eller när du använder en gateway när data bearbetas där. | ✔ | |
| Bearbetade byte | För en viss entitet eller partition, Data som skrivits av dataflödesmotorn, uttryckt i byte. När du använder en gateway i det här dataflödet tillhandahålls inte den här informationen. |
✔ | |
| Maximal incheckning (KB) | Max Commit är det högsta incheckningsminnet som är användbart för att diagnostisera fel med slut på minne när M-frågan inte är optimerad. När du använder en gateway i det här dataflödet tillhandahålls inte den här informationen. |
✔ | |
| Processortid | För en viss entitet eller partition, tid uttryckt i HH:MM:SS som dataflödesmotorn använde för att utföra transformeringar. När du använder en gateway i det här dataflödet tillhandahålls inte den här informationen. |
✔ | |
| Väntetid | För en viss entitet eller partition, den tid som en entitet tillbringade i väntestatus, baserat på arbetsbelastningen på Premium-kapaciteten. | ✔ | |
| Beräkningsmotor | Information om hur uppdateringsåtgärden använder beräkningsmotorn för en viss entitet eller partition. Värdena är: -NA -Vikta -Cachelagrade - Cachelagrad + vikt Dessa element beskrivs mer detaljerat senare i den här artikeln. |
✔ | |
| Fel | Om tillämpligt beskrivs det detaljerade felmeddelandet per entitet eller partition. | ✔ | ✔ |
Vägledning för dataflödesuppdatering
Uppdateringsstatistiken ger värdefull information som du kan använda för att optimera och påskynda prestanda för dina dataflöden. I följande avsnitt beskriver vi några scenarier, vad du bör se upp för och hur du optimerar baserat på den information som tillhandahålls.
Orkestrering
Att använda dataflöden på samma arbetsyta möjliggör enkel orkestrering. Du kan till exempel ha dataflödenA, B och C på en enda arbetsyta och länkning som A > B > C. Om du uppdaterar källan (A) uppdateras även underordnade entiteter. Men om du uppdaterar C måste du uppdatera andra oberoende av varandra. Om du lägger till en ny datakälla i dataflödet B (som inte ingår i A) uppdateras inte data som en del av orkestreringen.
Du kanske vill länka ihop objekt som inte passar den hanterade orkestrering som Power BI utför. I dessa scenarier kan du använda API:erna och/eller använda Power Automate. Du kan läsa API-dokumentationen och PowerShell-skriptet för programmatisk uppdatering. Det finns en Power Automate-anslutningsapp som gör det möjligt att göra den här proceduren utan att skriva någon kod. Du kan se detaljerade exempel med specifika genomgångar för sekventiella uppdateringar.
Övervakning
Med hjälp av den förbättrade uppdateringsstatistiken som beskrivs tidigare i den här artikeln kan du få detaljerad uppdateringsinformation per dataflöde. Men om du vill se dataflöden med en översikt över uppdateringar för hela klientorganisationen eller arbetsytan, kanske för att skapa en övervakningsinstrumentpanel, kan du använda API:er eller PowerAutomate-mallar. För användningsfall som att skicka enkla eller komplexa meddelanden kan du också använda PowerAutomate-anslutningsappen eller skapa ett eget anpassat program med hjälp av API:erna.
Timeout-fel
Det är idealiskt att optimera den tid det tar att utföra ETL-scenarier (extrahering, transformering och inläsning). I Power BI gäller följande fall:
- Vissa anslutningsappar har explicita timeout-inställningar som du kan konfigurera. Mer information finns i Anslut orer i Power Query.
- Power BI-dataflöden med Power BI Pro kan också få tidsgränser för tidskrävande frågor inom en entitet eller själva dataflöden. Den begränsningen finns inte i Power BI Premium-arbetsytor.
Vägledning om tidsgräns
Tidsgränströsklar för Power BI Pro-dataflöden är:
- Två timmar på enskild entitetsnivå.
- Tre timmar på hela dataflödesnivån.
Om du till exempel har ett dataflöde med tre tabeller kan ingen enskild tabell ta mer än två timmar och hela dataflödet överskrider tidsgränsen om varaktigheten överskrider tre timmar.
Om du har överskridna tidsgränser bör du överväga att optimera dina dataflödesfrågor och överväga att använda frågedelegering i källsystemen.
Överväg att uppgradera till Premium per användare, som inte omfattas av dessa tidsgränser och ger bättre prestanda på grund av många Power BI Premium-funktioner per användare.
Långa varaktigheter
Komplexa eller stora dataflöden kan ta längre tid att uppdatera, liksom dåligt optimerade dataflöden. Följande avsnitt innehåller vägledning om hur du minimerar långa uppdateringsvaraktighet.
Vägledning för långa uppdateringsvaraktighet
Det första steget för att förbättra varaktigheten för långa uppdateringar för dataflöden är att skapa dataflöden enligt bästa praxis. Några viktiga mönster är:
- Använd länkade entiteter för data som kan användas senare i andra transformeringar.
- Använd beräknade entiteter för att cachelagras data, vilket minskar belastningen på datainläsning och datainmatning på källsystem.
- Dela upp data i mellanlagringsdataflöden och transformeringsdataflöden, vilket separerar ETL i olika dataflöden.
- Optimera expanderande tabellåtgärder.
- Följ vägledningen för komplexa dataflöden.
Därefter kan det hjälpa dig att utvärdera om du kan använda inkrementell uppdatering.
Om du använder inkrementell uppdatering kan du förbättra prestandan. Det är viktigt att partitionsfiltren skickas till källsystemet när frågor skickas för uppdateringsåtgärder. Att skicka filtrering nedåt innebär att datakällan ska ha stöd för frågedelegering, eller så kan du uttrycka affärslogik via en funktion eller på annat sätt som kan hjälpa Power Query att eliminera och filtrera filer eller mappar. De flesta datakällor som stöder SQL-frågor stöder frågedelegering, och vissa OData-feeds kan också stödja filtrering.
Datakällor som flata filer, blobbar och API:er stöder vanligtvis inte filtrering. Om datakällans serverdel inte stöder filtret kan den inte push-överföras. I sådana fall kompenserar och tillämpar kombinationsmotorn filtret lokalt, vilket kan kräva att den fullständiga semantiska modellen hämtas från datakällan. Den här åtgärden kan göra att inkrementell uppdatering blir långsam, och processen kan ta slut på resurser antingen i Power BI-tjänst eller i den lokala datagatewayen om den används.
Med tanke på de olika nivåerna av frågedelegeringsstöd för varje datakälla bör du utföra verifiering för att säkerställa att filterlogiken ingår i källfrågorna. För att göra detta enklare försöker Power BI utföra den här verifieringen åt dig, med stegdelegeringsindikatorer för Power Query Online. Många av dessa optimeringar är designtidsupplevelser, men när en uppdatering har inträffat har du möjlighet att analysera och optimera uppdateringsprestanda.
Överväg slutligen att optimera din miljö. Du kan optimera Power BI-miljön genom att skala upp din kapacitet, ändra storlek på datagatewayer och minska nätverksfördröjningen med följande optimeringar:
När du använder kapaciteter som är tillgängliga med Power BI Premium eller Premium per användare kan du öka prestandan genom att öka din Premium-instans eller tilldela innehållet till en annan kapacitet.
En gateway krävs när Power BI behöver komma åt data som inte är tillgängliga direkt via Internet. Du kan installera den lokala datagatewayen på en lokal server eller på en virtuell dator.
- Information om gatewayarbetsbelastningar och storleksrekommendationer finns i Storleksändring för lokal datagateway.
- Utvärdera även att föra data först till ett mellanlagringsdataflöde och referera till dem nedströms med hjälp av länkade och beräknade entiteter.
Nätverksfördröjning kan påverka uppdateringsprestanda genom att öka den tid som krävs för att begäranden ska nå Power BI-tjänst och för svar som ska levereras. Klienter i Power BI tilldelas till en viss region. Information om var din klient finns finns i Hitta standardregionen för din organisation. När användare från en klientorganisation får åtkomst till Power BI-tjänst dirigeras deras begäranden alltid till den regionen. När begäranden når Power BI-tjänst kan tjänsten sedan skicka extra begäranden, till exempel till den underliggande datakällan eller till en datagateway, som också är föremål för nätverksfördröjning.
- Verktyg som Azure Speed Test ger en indikation på nätverksfördröjning mellan klienten och Azure-regionen. För att minimera effekten av nätverksfördröjning bör du i allmänhet sträva efter att hålla datakällor, gatewayer och ditt Power BI-kluster så nära som möjligt. Att vistas i samma region är att föredra. Om nätverksfördröjningen är ett problem kan du försöka hitta gatewayer och datakällor närmare ditt Power BI-kluster genom att placera dem i molnbaserade virtuella datorer.
Hög processortid
Om du ser hög processortid har du förmodligen dyra transformeringar som inte viks. Den höga processortiden beror antingen på antalet tillämpade steg som du har eller på vilken typ av omvandlingar du gör. Var och en av dessa möjligheter kan resultera i högre uppdateringstider.
Vägledning för hög processortid
Det finns två alternativ för att optimera hög processortid.
Börja med att använda frågedelegering i själva datakällan, vilket bör minska belastningen på dataflödesberäkningsmotorn direkt. Med frågedelegering i datakällan kan källsystemet utföra det mesta av arbetet. Dataflödet kan sedan skickas genom frågor på källans inbyggda språk, i stället för att behöva utföra alla beräkningar i minnet efter den första frågan.
Inte alla datakällor kan utföra frågedelegering, och även om frågedelegering är möjligt kan det finnas dataflöden som utför vissa transformeringar som inte kan vikas till källan. I sådana fall är den förbättrade beräkningsmotorn en funktion som introduceras av Power BI för att potentiellt förbättra prestanda med upp till 25 gånger, särskilt för transformeringar.
Använd beräkningsmotorn för att maximera prestanda
Power Query har designtidssynlighet för frågedelegering, men kolumnen för beräkningsmotorn innehåller information om huruvida själva den interna motorn används. Beräkningsmotorn är användbar när du har ett komplext dataflöde och utför transformeringar i minnet. I den här situationen kan den förbättrade uppdateringsstatistiken vara användbar, eftersom kolumnen för beräkningsmotorn innehåller information om huruvida själva motorn användes eller inte.
Följande avsnitt innehåller vägledning om hur du använder beräkningsmotorn och dess statistik.
Varning
Under designtiden kan vikningsindikatorn i redigeraren visa att frågan inte viks vid användning av data från ett annat dataflöde. Kontrollera källdataflödet om förbättrad beräkning är aktiverad för att säkerställa att vikning på källdataflödet är aktiverat.
Vägledning om status för beräkningsmotorn
Det är bra att aktivera den förbättrade beräkningsmotorn och förstå de olika statusarna. Internt använder den förbättrade beräkningsmotorn en SQL-databas för att läsa och lagra data. Det är bäst att dina transformeringar körs mot frågemotorn här. Följande stycken innehåller olika situationer och vägledning om vad du ska göra för var och en.
NA – Den här statusen innebär att beräkningsmotorn inte användes, antingen på grund av:
- Du använder Power BI Pro-dataflöden.
- Du stängde uttryckligen av beräkningsmotorn.
- Du använder frågedelegering på datakällan.
- Du utför komplexa omvandlingar som inte kan använda SQL-motorn som används för att påskynda frågor.
Om du har långa varaktigheter och fortfarande får statusen NA kontrollerar du att den är aktiverad och inte av misstag inaktiverad. Ett rekommenderat mönster är att använda mellanlagringsdataflöden för att först hämta dina data till Power BI-tjänst och sedan skapa dataflöden ovanpå dessa data, efter att de finns i ett mellanlagringsdataflöde. Det mönstret kan minska belastningen på källsystem och, tillsammans med beräkningsmotorn, ge en hastighetsökning för omvandlingar och förbättra prestandan.
Cachelagrad – Om du ser den cachelagrade statusen lagrades dataflödesdata i beräkningsmotorn och var tillgängliga för att refereras som en del av en annan fråga. Den här situationen är perfekt om du använder den som en länkad entitet eftersom beräkningsmotorn cachelagrar dessa data för användning nedströms. Cachelagrade data behöver inte uppdateras flera gånger i samma dataflöde. Den här situationen är också potentiellt idealisk om du vill använda den för DirectQuery.
När cachelagras lönar sig prestandapåverkan på inledande inmatning senare, i samma dataflöde eller i ett annat dataflöde på samma arbetsyta.
Om du har en stor varaktighet för entiteten kan du stänga av beräkningsmotorn. För att cachelagrat entiteten skriver Power BI den till lagring och till SQL. Om det är en entitet med en enda användning kanske prestandaförmånen för användarna inte är värd straffet för dubbel inmatning.
Vikt – Vikt innebär att dataflödet kunde använda SQL-beräkning för att läsa data. Den beräknade entiteten använde tabellen från SQL för att läsa data, och den SQL som används är relaterad till konstruktionerna i deras fråga.
Vikt status visas om du, när du använder lokala datakällor eller molndatakällor, först läste in data i ett mellanlagringsdataflöde och refererade till dem i det här dataflödet. Den här statusen gäller endast för entiteter som refererar till en annan entitet. Det innebär att dina frågor kördes ovanpå SQL-motorn och att de kan förbättras med SQL-beräkning. För att säkerställa att SQL-motorn bearbetar dina transformeringar använder du transformeringar som stöder SQL-vikning, till exempel sammanslagning (koppling), gruppera efter (aggregering) och tilläggsåtgärder (union) i Power Query-redigeraren.
Cachelagrad + vikt – När du ser cachelagrad + vikt är det troligt att datauppdateringen är optimerad, eftersom du har en entitet som båda refererar till en annan entitet och som refereras till av en annan entitet uppströms. Den här åtgärden körs också ovanpå SQL och har därför också potential att förbättras med SQL-beräkning. För att vara säker på att du får bästa möjliga prestanda använder du transformeringar som stöder SQL-vikning, till exempel sammanslagning (koppling), gruppera efter (aggregering) och tilläggsåtgärder (union) i Power Query-redigeraren.
Vägledning för prestandaoptimering för beräkningsmotorn
Följande steg gör det möjligt för arbetsbelastningar att utlösa beräkningsmotorn och därmed alltid förbättra prestandan.
Beräknade och länkade entiteter på samma arbetsyta:
För inmatning fokuserar du på att få data till lagringen så snabbt som möjligt, använd endast filter om de minskar den totala semantiska modellstorleken. Håll din omvandlingslogik åtskild från det här steget. Därefter separerar du omvandlingen och affärslogik i ett separat dataflöde på samma arbetsyta. Använd länkade eller beräknade entiteter. På så sätt kan motorn aktivera och påskynda dina beräkningar. För en enkel analogi är det som matförberedelse i ett kök: matförberedelse är vanligtvis ett separat och distinkt steg från att samla in dina råvaror och en förutsättning för att sätta maten i ugnen. På samma sätt måste du förbereda logiken separat innan den kan dra nytta av beräkningsmotorn.
Se till att du utför de åtgärder som viker, till exempel sammanslagningar, kopplingar, konvertering och andra.
Skapa även dataflöden inom publicerade riktlinjer och begränsningar.
När beräkningsmotorn är på, men prestandan är långsam:
Utför följande steg när du undersöker scenarier där beräkningsmotorn är på, men du ser dåliga prestanda:
- Begränsa beräknade och länkade entiteter som finns på arbetsytan.
- Om den första uppdateringen är med beräkningsmotorn aktiverad skrivs data i sjön och i cacheminnet. Den här dubbelskrivningen resulterar i att uppdateringarna blir långsammare.
- Om du har ett dataflöde som länkar till flera dataflöden ska du schemalägga uppdateringar av källdataflödena så att de inte uppdateras samtidigt.
Beaktanden och begränsningar
En Power BI Pro-licens har en uppdateringsgräns för dataflöden på 8 uppdateringar per dag.