Dela via

Utvärdera och optimera din Microsoft Fabric-kapacitet

  • Artikel

Den här artikeln beskriver hur du utvärderar och optimerar belastningen på dina Microsoft Fabric-kapaciteter. Den beskriver också strategier för att hantera överbelastningssituationer och ger dig vägledning för att optimera beräkningen för var och en av infrastrukturresurserna.

Infrastrukturkapacitetsmodellen förenklar konfigurationen och möjliggör samarbete, men det finns en stor chans att de delade beräkningsresurserna för en kapacitet tar slut. Det kan också vara så att du betalar för fler resurser än vad som är nödvändigt. Dessa situationer kan uppstå när designen av vissa Fabric-upplevelser inte följer metodtipsen.

Det är viktigt att minska risken för uttömning av delade resurser, Fabric som en hanterad tjänst, hanterar automatiskt sådana situationer på två sätt.

  • Bristning och utjämning säkerställer att processorintensiva aktiviteter slutförs snabbt utan att kräva en högre SKU (och kan köras när som helst på dagen).
  • Begränsning fördröjer eller avvisar åtgärder när en kapacitet upplever en varaktig och hög efterfrågan på CPU (över SKU-gränsen).

Utjämning minskar sannolikheten för begränsning (även om begränsning fortfarande kan ske). Utjämning är hur användningen allokeras mot gränser, men den är oberoende av körningen av jobb. Utjämningen ändrar inte prestanda, den sprider bara redovisningen för förbrukad beräkning under en längre period, så att en större SKU inte behövs för att hantera den högsta beräkningen.

Mer information om Infrastrukturkapacitet finns i Begrepp och licenser för Microsoft Fabric och Infrastrukturkapaciteter – Allt du behöver veta om vad som är nytt och vad som kommer.

Planerings- och budgeteringsverktyg

Att planera storleken på en kapacitet kan vara en utmaning. Det beror på att den nödvändiga beräkningen kan variera kraftigt på grund av de åtgärder som utförs, hur väl de körs (till exempel effektiviteten i en DAX-fråga eller Python-koden i en notebook-fil) eller nivån av samtidighet.

För att hjälpa dig att fastställa rätt kapacitetsstorlek kan du etablera utvärderingskapaciteter eller betala per användning F-SKU:er för att mäta den faktiska kapacitetsstorlek som krävs innan du köper en reserverad F SKU-instans.

Dricks

Det är alltid en bra strategi att börja litet och sedan gradvis öka storleken på din kapacitet efter behov.

Övervaka kapaciteter

Du bör övervaka användningen för att få ut mesta möjliga av dina kapaciteter. Först och främst är det viktigt att förstå att infrastrukturresurser antingen är interaktiva eller bakgrundsfunktioner. DAX-frågor från en Power BI-rapport är till exempel begäranden på begäran som är interaktiva åtgärder, medan semantiska modelluppdateringar är bakgrundsåtgärder. Mer information om åtgärder och hur de förbrukar resurser i Infrastrukturresurser finns i Infrastrukturåtgärder.

Övervakning kan avslöja för dig att begränsningen sker. Begränsning kan ske när det finns många eller långvariga interaktiva åtgärder. Vanligtvis jämnas bakgrundsåtgärder relaterade till SQL- och Spark-upplevelser ut, vilket innebär att de är utspridda över en 24-timmarsperiod.

Fabric Capacity Metrics-appen är det bästa sättet att övervaka och visualisera den senaste användningen. Appen delar upp till objekttyp (semantisk modell, notebook-fil, pipeline och andra) och hjälper dig att identifiera objekt eller åtgärder som använder höga beräkningsnivåer (så att de kan optimeras).

Administratörer kan använda arbetsytan Administratörsövervakning för att lära sig mer om vanliga objekt (och övergripande implementering). De kan också använda övervakningshubben för att visa aktuella och senaste aktiviteter i klientorganisationen. Mer information om vissa åtgärder kan också vara tillgänglig från Log Analytics eller lokala datagatewayloggar.

Hantera hög beräkningsanvändning

När en kapacitet används mycket och börjar visa begränsning eller avvisande finns det tre strategier för att lösa det: optimera, skala upp och skala ut.

Det är en bra idé att konfigurera meddelanden för att lära sig när kapacitetsanvändningen överskrider ett angivet tröskelvärde. Överväg också att använda arbetsbelastningsspecifika inställningar för att begränsa storleken på åtgärder (till exempel Tidsgräns för Power BI-frågor eller radgränser eller Spark-arbetsyteinställningar).

Optimera

Innehållsskapare bör alltid optimera designen av sina infrastrukturobjekt för att säkerställa att de är effektiva och använder minst möjliga beräkningsresurser. Specifik vägledning för varje infrastrukturresursupplevelse ges senare i den här artikeln.

Skala upp

Du skalar upp en kapacitet för att tillfälligt eller permanent öka SKU-storleken (med mer beräkningskapacitet). Uppskalning säkerställer att det finns tillräckligt med beräkningsresurser tillgängliga för alla objekt i en kapacitet och för att undvika begränsning.

Du kan också ändra storlek på, pausa och återuppta Fabric F-SKU:er så att de överensstämmer med förbrukningsmönstren.

Skala ut

Du skalar ut genom att flytta några av dina arbetsytor eller objekt till en annan infrastrukturresurskapacitet för att sprida arbetsbelastningen. Det kan vara ett bra alternativ när olika kapacitetsstrategier, inställningar eller administratörer krävs. Etablering av flera kapaciteter är också en bra strategi för att isolera beräkning för objekt med hög prioritet och även för självbetjäning eller utvecklingsinnehåll. Till exempel förväntar sig cheferna i din organisation mycket dynamiska rapporter och instrumentpaneler. Dessa rapporter och instrumentpaneler kan finnas i en separat kapacitet som är dedikerad till verkställande rapportering.

Du kan också överväga att flytta Power BI-arbetsytor till delad kapacitet, förutsatt att användarna har Power BI Pro licenser som gör att de kan fortsätta att komma åt innehållet.

Konfigurera överspänningsskydd

Överspänningsskydd hjälper till att begränsa överanvändningen av din kapacitet genom att begränsa den totala mängden beräkningsbakgrundsjobb som förbrukas. Detta minskar den totala beräkningen, så interaktiva fördröjningar eller avvisanden är mindre sannolika. Det hjälper också systemets kapacitet att återhämta sig snabbare om det finns en period av begränsningar eller avvisningar. Du konfigurerar överspänningsskydd för varje kapacitet. Överspänningsskydd hjälper till att förhindra begränsning och avslag, men ersätter inte kapacitetsoptimering, uppskalning och utskalning.

När överspänningsskydd är aktivt avvisas bakgrundsjobb. Det innebär att det påverkar din kapacitet även när överbelastningsskydd är aktiverat. Genom att använda överspänningsskydd justerar du din kapacitet för att hålla dig inom ett intervall av användning som bäst balanserar beräkningsbehoven inom kapaciteten. För att helt skydda kritiska lösningar rekommenderar vi att du isolerar dem i en korrekt dimensionerad kapacitet.

Beräkningsoptimering per infrastrukturresursupplevelse

Upplevelserna och objekten i Fabric fungerar annorlunda, så du behöver inte nödvändigtvis optimera dem på samma sätt. I det här avsnittet visas infrastrukturobjekt enligt erfarenhet och åtgärder som du kan vidta för att optimera dem.

Infrastrukturdatalager

Informationslagret använder en serverlös arkitektur och dess noder hanteras automatiskt av tjänsten. Kapacitetsanvändning beräknas baserat på aktiva kapacitetsenhetssekunder per fråga i stället för den tid som klientdels- och serverdelsnoderna etableras.

Alla informationslageråtgärder är bakgrundsåtgärder och de jämnas ut under en 24-timmarsperiod.

SQL-analysslutpunktensyftar till att tillhandahålla en prestanda som standardupplevelse. Det finns därför färre alternativ för frågejustering jämfört med SQL Server- eller Azure Synapse Analytics-dedikerade SQL-pooler.

Här följer några saker att tänka på för att minimera beräkningen.

  • Skriv frågor med hjälp av den mest optimala T-SQL som möjligt. När det är möjligt begränsar du antalet kolumner, beräkningar, aggregeringar och andra åtgärder som i onödan kan öka frågeresursanvändningen.
  • Utforma tabeller för att använda de minsta möjliga datatyperna . Ditt val av datatyp kan påverka frågeplaner som genereras av SQL-motorn kraftigt. Om du till exempel minskar ett VARCHAR fält från längd 500 till 25 eller ändras DECIMAL(32, 8) till kan det leda till DECIMAL(10, 2) en betydande minskning av resurser som allokerats för en fråga.
  • Använd star-schemadesign för att minska antalet rader som lästs och för att minimera frågekopplingar.
  • Se till att statistik finns och att de är uppdaterade. Statistik spelar en viktig roll för att generera den mest optimala körningsplanen. De skapas automatiskt vid körning, men du kan behöva uppdatera dem manuellt, särskilt när data har lästs in eller uppdaterats. Överväg att skapa statistik med hjälp FULLSCAN av alternativet i stället för att förlita dig på den automatiskt genererade statistik som använder sampling.
  • Använd inbyggda vyer för att övervaka frågor och användning, särskilt vid felsökning av problem.
    • Den sys.dm_exec_requests dynamiska hanteringsvyn (DMV) innehåller information om alla frågor som körs aktivt, men den lagrar ingen historisk information. Verktygslådan Infrastruktur innehåller en fråga som använder denna DMV och gör frågeresultatet användarvänligt genom att ansluta till andra vyer för att ge information som frågetexten.
    • Frågeinsikter, som är en funktion i fabric-datalager, ger en holistisk vy över historisk frågeaktivitet på SQL-analysslutpunkten. Mer specifikt innehåller vyn queryinsights.exec_requests_history information om varje fullständig SQL-begäran. Den visar all relevant information för varje frågekörning som kan korreleras med åtgärds-ID:t som finns i appen för kapacitetsmått. De viktigaste kolumnerna för övervakning av kapacitetsanvändning är: distributed_statement_id, kommando (frågetext), start_time och end_time.

Infrastrukturresurser Dataingenjör och infrastrukturresurser Datavetenskap

Funktionerna Dataingenjör ing och Datavetenskap använder Spark-beräkning för att bearbeta, analysera och lagra data i en Infrastruktursjöhus. Spark-beräkning konfigureras och mäts när det gäller virtuella kärnor. Fabric använder dock processorer som ett mått på beräkning som används av olika objekt, inklusive Spark-notebook-filer, Spark-jobbdefinitioner och lakehouse-jobb.

I Spark översätts en CU till två virtuella spark-kärnor för beräkning. När en kund till exempel köper en F64 SKU är 128 spark v-kärnor tillgängliga för Spark-upplevelser.

Alla Spark-åtgärder är bakgrundsåtgärder och de jämnas ut under en 24-timmarsperiod.

Mer information finns i Fakturerings- och användningsrapportering i Fabric Spark.

Här följer några saker att tänka på för att minimera beräkningen.

  • Sträva alltid efter att skriva effektiv Spark-kod. Mer information finns i Optimera Apache Spark-jobb i Azure Synapse Analytics och Behovet av att optimera skrivning på Apache Spark.
  • Reservera nödvändiga utförare för dina Spark-jobb för att frigöra resurser för andra Spark-jobb eller arbetsbelastningar. Annars ökar du risken för att Spark-jobb misslyckas med http 430-status, vilket innebär för många begäranden för kapaciteten. Du kan visa antalet exekutorer som allokerats till en notebook-fil i övervakningshubben för infrastrukturresurser, där du även kan fastställa det faktiska antalet utförare som används av notebook-filen. Spark-jobb reserverar endast de noder som krävs och tillåter parallella inlämningar inom SKU-gränser.
  • Spark-poolen kan bara konfigureras för att använda det maximala antalet virtuella kärnor som stöds av SKU:n. Du kan dock skala ut datateknikarbetsbelastningar genom att acceptera parallella Spark-jobb inom SKU-gränser. Den här metoden kallas ofta burst-faktor och aktiveras som standard för Spark-arbetsbelastningar på kapacitetsnivå. Mer information finns i Samtidighetsbegränsning och köning.
  • Aktiva Spark-sessioner kan ackumulera CU-användning på en kapacitet. Därför är det viktigt att stoppa aktiva Spark-sessioner när de inte används. Observera att standardtiden för Spark-sessionens förfallotid är inställd på 20 minuter. Användare kan ändra tidsgränsen för sessionen i en notebook-fil eller Spark-jobbdefinitionen.

Realtidsinformation

KQL-databasens CU-förbrukning beräknas baserat på antalet sekunder som databasen är aktiv och antalet virtuella kärnor som används. När din databas till exempel använder fyra virtuella kärnor och är aktiv i 10 minuter använder du 2 400 (4 x 10 x 60) sekunders CU.

Alla KQL-databasåtgärder är interaktiva åtgärder.

En autoskalningsmekanism används för att fastställa storleken på din KQL-databas. Det säkerställer att den mest kostnadsoptimerade och bästa prestandan uppnås baserat på användningsmönster.

För att tillåta att data blir tillgängliga för andra Fabric-motorer synkroniseras KQL-databasen med OneLake. Baserat på antalet läs- och skrivtransaktioner som KQL-databasen utför, används processorer från din kapacitet. Den använder onelake-mätare för läsning och skrivning, vilket motsvarar läs- och skrivåtgärder på Azure Data Lake Storage-konton (ADLS) Gen2.

Data Factory

Det här avsnittet handlar om optimeringar för dataflöden och datapipelines i Data Factory.

Alla åtgärder är bakgrundsåtgärder och de jämnas ut under en 24-timmarsperiod.

Här följer några saker att tänka på för att minimera beräkningen.

  • Undvik ineffektiv Power Query-logik för att minimera och optimera dyra datatransformeringar, till exempel sammanslagning och sortering.
  • Sträva efter att uppnå frågedelegering när det är möjligt. Det kan förbättra prestandan för dina dataflöden genom att minska mängden data som måste överföras mellan datakällan och målet. När frågedelegering inte sker hämtar Power Query alla data från datakällan och utför transformeringar lokalt, vilket kan vara ineffektivt och långsamt.
  • Inaktivera mellanlagring när du arbetar med små datavolymer och/eller utför enkla transformeringar. Mellanlagring kan krävas i vissa fall, till exempel när du läser in ett informationslager.
  • Undvik att uppdatera data oftare än vad datakällan kräver. Om datakällan till exempel bara uppdateras en gång var 24:e timme ger uppdatering av data per timme inget mer värde. Överväg i stället att uppdatera data med en lämplig frekvens för att säkerställa att de är uppdaterade och korrekta.

Power BI

Power BI-åtgärder är antingen interaktiva eller bakgrundsfunktioner.

Följande interaktiva åtgärder resulterar vanligtvis i hög beräkningsanvändning.

  • Semantiska modeller som inte följer bästa praxis. De kanske till exempel inte använder star-schemadesign med en-till-många-relationer. Eller så kan de innehålla komplexa och dyra säkerhetsfilter på radnivå (RLS). Överväg att använda Tabellredigeraren och Best Practice Analyzer för att avgöra om bästa praxis följs.
  • DAX-mått är ineffektiva.
  • Rapportsidor innehåller för många visuella objekt, vilket kan leda till långsam visuell uppdatering.
  • Visuella rapportobjekt visar resultat med hög kardinalitet (för många rader eller kolumner), eller så innehåller de för många mått.
  • Kapaciteten har hög samtidighet eftersom det finns för många användare för kapacitetsstorleken. Överväg att aktivera utskalning av frågor för att förbättra användarupplevelsen för semantiska modeller med hög samtidighet (men det resulterar inte i mer total beräkning).

Följande bakgrundsåtgärder resulterar vanligtvis i hög beräkningsanvändning.

  • Ineffektiva eller alltför komplexa datatransformeringar i Power Query-logiken.
  • Avsaknad av frågedelegering eller inkrementell uppdatering för stora faktatabeller.
  • Rapportsprängning, vilket är när ett stort antal Power BI-rapporter eller sidnumrerade rapporter genereras samtidigt.

Relaterat innehåll

Har du fler frågor? Försök att fråga Fabric Community.