Dela via

Kapacitetsplaneringsguide för Microsoft Fabric: Hantera tillväxt och styrning

Den här artikeln är del 4 i kapacitetsplaneringsguiden för Microsoft Fabric. Det hjälper Microsoft Fabric-klientadministratörer, kapacitetsadministratörer och COE-leads (Center of Excellence) att styra och skala Microsoft Fabric-kapaciteter effektivt. Artikeln beskriver metodtips för två scenarier: självbetjäning (decentraliserat) och centraliserat innehåll, följt av vanliga metoder som gäller för båda.

När flera affärsenheter använder Fabric i en självbetjäningsmodell är stark styrning och kommunikation nyckeln till hållbar kapacitetshantering. I centraliserad innehållshantering kräver Enterprise-lösningar och hanterade självbetjäningslösningar kontinuerlig övervakning och styrning för att säkerställa att de uppfyller serviceavtal (SLA) och anpassar sig till föränderliga krav.

Kapaciteter med självbetjäning (decentraliserad)

I decentraliserade självbetjäningsmiljöer delar flera affärsenheter samma kapacitet. Styrning fokuserar på att ge användare skyddsräcken för att förhindra interferens mellan team.

  • Utnyttja center of excellence (COE) för att optimera och utbilda kontinuerligt: Bekräfta roller och ansvarsområden så att det är tydligt vilka åtgärder som vidtas, varför, när och av vem. Om inte redan , upprätta en COE som innehåller IT-administratörer och power-användare från varje affärsdomän för att definiera kapacitetsprinciper och dela metodtips. COE stöder självbetjäningsanvändare, tillämpar riktlinjer och erbjuder utbildning för att optimera resursanvändningen. Det hjälper till att skapa en community av praxis i organisationen och implementerar bekräftelser och genvägar för att minska redundans. De säkerställer också att projekten uppfyller standarder innan nya lösningar lanseras och registreras. Uppmuntra varje team att följa metodtips som minskar kapacitetsanvändningen. Investera i utbildning av affärsenheter för att förstå kapacitetsmått, utföra regelbundna rensningar och använda metodtips för utveckling. Kunniga användare hjälper till att upprätthålla systemets effektivitet och stödja balansen mellan självbetjäning och styrning.
  • Definiera och kommunicera riktlinjer för "rättvis användning": Dokumentera vad som är acceptabelt för delade kapaciteter (till exempel uppdateringsfrekvensgränser och datavolymtak). Förmedla dessa till alla team och konsekvenserna för missbruk. Om en avdelning till exempel konsekvent överbelastar kapaciteten kan de flyttas till en karantänkapacitet eller krävas för att optimera sin lösning. Ett centrum för excellens (COE) hjälper till att skapa och socialisera dessa regler, vilket ger en enhetlig styrningsröst mellan avdelningar.
  • Implementera återbetalning eller showback: Använd fabric chargeback-appen för att tilldela kapacitetsanvändning till varje avdelning, vilket främjar transparens även om faktisk korsfakturering inte implementeras, till exempel att Marknadsföring förbrukade X% av resurser som översätter till $Y av den månatliga kapacitetskostnaden. Detta uppmuntrar ofta till optimering och försiktig användning. Att visa avdelningarnas resurs "faktura" uppmuntrar till effektivare användning. Det gör också kostnadsdiskussioner enklare: när du begär mer kapacitet kan du visa vilka grupper som bär kostnaden och hjälpa till att finansiera mer kapacitet när implementeringen växer.
  • Ange kontinuerlig kapacitetsövervakning och rapportering: Behandla appen Infrastrukturkapacitetsmått som källa för KPI:er (Operational Key Performance Indicators). Övervaka kapaciteter regelbundet och proaktivt dela användningsrapporter med intressenter. Dela till exempel en månatlig rapport som visar varje kapacitets användning, eventuella begränsningsincidenter och arbetsytor med högst användning. Transparent rapportering hjälper dig att identifiera tunga användare, motivera kapacitetsuppgraderingar och hålla innehållsägare informerade om deras inverkan.
  • Planera gradvis utskalning:Vänta inte på att konstant konkurrens ska lägga till kapacitet. När fler avdelningar registrerar sig eller den totala användningen ökar planerar du att skala upp eller lägga till en annan kapacitet. Förstå också att uppskalning alltid fördubblar storleken på lagerhållningsenheter (SKU), så det kanske inte är lämpligt för varje scenario. Om en enskild kapacitet till exempel körs konsekvent över ~80% under tider med hög belastning kan du överväga att dela upp arbetsbelastningar (till exempel att Finance flyttas till en ny kapacitet) eller uppgradera storleken (om budgeten tillåter en fördubbling av storleken). Gör skalningsbeslut till en del av dina styrningskontroller. Till exempel, kvartalsvis, bestäm om användningstrender kräver att du köper mer kapacitet. På så sätt håller kapacitetsutbudet jämna steg med efterfrågan på ett kontrollerat sätt.

Anmärkning

Varje Microsoft Fabric-arbetsbelastning har specifika tröskelvärden som bestäms av kapacitets-SKU-storlek och licenstyp. Se till att din valda SKU uppfyller dessa krav.

Enterprise-kapaciteter (centraliserade)

I centraliserade miljöer ansvarar ett centralt IT- eller COE-team för att hantera viktigt innehåll, inklusive business intelligence och hanterade självbetjäningsprogram. Styrning implementeras genom formella mekanismer som betonar strikta serviceavtal (SLA), proaktiv tillsyn och hierarkisk övervakning. Vi rekommenderar att organisationer konsekvent underhåller, administrerar och förbättrar sina företagskapaciteter. Följande riktlinjer är viktiga för verksamhetskritiska lösningar (nivå 1), men de är fortfarande relevanta för andra högprioriterad verksamhetsdrift (nivå 2) och väljer även icke-kritiska ad hoc-lösningar (nivå 3).

  • Framtvinga kapacitetstillsyn och SLA:Tilldela en kapacitetsadministratör eller ett teamför att hantera varje nyckelkapacitet. De övervakar användning, hanterar incidenter, planerar uppgraderingar och ser till att serviceavtalen uppfylls – till exempel drifttid och frågehastighet för verkställande rapporter. Om mått riskerar att bryta mot serviceavtal måste administratörer eskalera åtgärder (till exempel optimering eller uppskalning). Inkludera SLA-efterlevnad i regelbundna ops-möten eller rapporter. Hantera företagskapaciteter med IT-nivåområde för att säkerställa tillförlitliga prestanda och upprätthålla plattformsförtroende.

  • Implementera proaktiv skalning för toppar: Användningen kan öka oväntat. När du pausar regleras eventuell överanvändning som en engångsfaktureringshändelse via betala per användning-avgifter, vilket effektivt återställer användningen och förhindrar begränsning. Schemalagd kapacitetsändring – till exempel uppskalning i slutet av ett kvartal och tillbaka efter – kan automatiseras med Fabric CLI, Azure Automation eller Fabrics REST-API:er för att hantera förutsägbara ökningar. F-SKU:er är flexibla och tillåter både storleksändring och pausning efter behov.

  • Kombinera RI/Pay Go: Använd reserverad instans (RI) för rabatter på priser när det är möjligt och komplettera den med att pausa/återuppta/ändra storlek på kapaciteten med betala per användning-prissättning för flexibilitet. För förutsägbara ökningar kan du jämföra kostnader: att skala upp med betala per användning för tillfälliga toppar (till exempel har du en F64 som RI, med F128 på måndagar genom att lägga till betala per användning F64) kan vara billigare än att köpa extra RI. Men om det behövs mer än fyra dagar i veckan kan RI erbjuda ett bättre värde.

    Anmärkning

    Bakgrundsåtgärderna jämnas ut under 24 timmar. Om ett stort jobb eller en uppsättning jobb körs bör du därför se till att den utjämnade användningen ligger långt under det angivna tröskelvärdet för din kapacitet med lägre storlek. Till exempel bör den utjämnade kapacitetsanvändningen för F128-kapaciteten vara <40% för att den ska vara 80% när du skalar ned den till F64 och se till att den inte begränsas med F64-storleken.

  • Använd överbelastningsskydd för interaktiva arbetsbelastningar: Aktivera överspänningsskydd i kapacitetsinställningar när användarinriktade frågor (till exempel rapporter) delar kapacitet med bakgrundsuppgifter (till exempel uppdateringar, AI-jobb). Det hjälper till att prioritera interaktiva arbetsbelastningar genom att begränsa bakgrundsberäkning när 24-timmarsanvändningen är hög. Komma ihåg

    • Överspänningsskydd ersätter inte korrekt kapacitetsstorlek eller innehållsoptimering
    • När det är aktivt avvisas bakgrundsjobb för att skydda användarupplevelsen – dessa kan fördröjas eller behöva köras på nytt.
    • Många interaktiva åtgärder som SQL-fråga betraktas också som bakgrund och kan avvisas. Mer information finns i Infrastrukturresurser.
    • Kritiska arbetsbelastningar kräver fortfarande dedikerad kapacitet för fullständigt skydd.

  • Implementera Azure-kvoter för Infrastrukturkapaciteter: Baserat på resursgrupper och organisationsstruktur är det bäst att skapa flera prenumerationer eftersom prenumerationskvoter gäller för alla resurser i varje prenumeration. Planera separation på logisk eller organisationsenhetsnivå i enlighet med detta. När du har fastställt antalet prenumerationer och storlekar på infrastrukturresurser som krävs kan du tillåta en buffert på 25%-50% för maximal användning eller begränsning. Ange kvoter i Azure-portalen baserat på den här utvärderingen.

Vanliga metodtips (båda scenarierna)

Vissa styrningsmetoder gäller universellt, oavsett om innehållet är självbetjäning eller centralt hanterat. Dessa metoder säkerställer effektiv och tillförlitlig kapacitetsanvändning:

  • Övervaka kapacitetsanvändningen kontinuerligt: Oavsett scenario är det viktigt att du får insyn i kapacitetsprestanda. Gör appen Infrastrukturkapacitetsmått till din kompass för varje kapacitets hälsa. Kontrollera regelbundet användningsdiagrammen och tabellerna för att se hur varje kapacitet presterar. Viktiga mått att övervaka:

    • Trender i CU-användning: Kontrollera om kapaciteten ofta körs nära gränsen. Identifiera tider på dagen eller specifika åtgärder som ökar användningen.
    • Begränsning eller fördröjningar: Måttappens diagram och systemhändelser visar om några åtgärder begränsas, fördröjs eller avvisas på grund av överanvändning. Helst stannar detta på 0; om inte, notera när och varför det händer.
    • Främsta konsumenter – Identifiera vilka arbetsytor eller objekt (semantiska modeller, Spark-jobb osv.) som förbrukar flest kapacitetsenheter (CUS). Detta kan markera ett avvikande objekt som kan behöva optimering eller isolering.
    • Underutnyttjande: Observera om en kapacitet mestadels är inaktiv (till exempel aldrig över 30% användning). Detta kan tyda på en möjlighet att konsolidera arbetsbelastningar och minska kostnaderna.
    • Aviseringar:Konfigurera aviseringar så att du får aviseringar när tröskelvärden överskrids. Du kan till exempel aktivera klientinställningen för att varna administratörer om en kapacitet blir överbelastad eller om ett avbrott inträffar.

    Målet är att åtgärda problem proaktivt: om du märker ett mönster av tung användning bör du agera innan användarna klagar.

  • Prognostisera och justera kapaciteten: Utför regelbundna utvärderingar, till exempel månadsvis eller kvartalsvis, för att säkerställa att kapacitetsallokeringen överensstämmer med aktuella användningskrav.

    • Om den högsta användningen för en viss kapacitet ökar stadigt (till exempel 60% → 75% → 90%) bör du skala upp till nästa SKU innan du når full användning. Analysera användningstrender för att exakt förutsäga när skalning är nödvändigt. Detta kan innebära att uppgradera från F32 till F64 eller utöka kapaciteten genom att lägga till fler enheter för att distribuera arbetsbelastningar mer effektivt.
    • Å andra sidan kan du överväga att konsolidera arbetsbelastningar på den eller skala ned för att optimera kostnader som tillhandahålls serviceavtal om en kapacitet är under 30%.
    • Använd insamlade data – inklusive måttprogram och loggar – för kapacitetsprognoser. Till exempel: "Efter en ökning med 50 användare förra kvartalet ökade cu-toppen med 20%. Vi räknar med att registrera ytterligare 100 användare nästa kvartal, vilket tyder på en ökning med cirka 40% CU. Att uppgradera från F64 till F128 skulle därför vara klokt." Den här metoden underlättar proaktiv upphandling och budgetering.
    • Se till att regionala datahemvistkrav uppfylls under nya projektexpansioner. Om organisationen etablerar en ny gren som använder centrala analysresurser granskar du multigeo-kapaciteter i enlighet med detta.
    • Varje Microsoft Fabric-arbetsbelastning har specifika tröskelvärden som bestäms av kapacitets-SKU-storlek och licenstyp. Se till att din valda SKU uppfyller dessa krav. Granska till exempel kapacitetskrav för infrastrukturresurser när du implementerar semantisk modell. Om den semantiska modellen kräver F128-kapacitet börjar du med F128 SKU.

  • Optimera före skalning:Optimera alltid arbetsbelastningar innan du ökar kapaciteten. Ineffektivitet leder till onödiga kostnader, så se till att åtgärderna körs effektivt. Prestandajustering kan stödjas av central IT eller COE. Till exempel:

    • Optimera långsamma Power BI-mått eller SQL-frågor och få råd om bästa praxis för COE.
    • Schemalägg om efterföljande pipelines för att undvika resurstoppar.
    • Använd inkrementell uppdatering för stora semantiska modeller när det är möjligt.
    • Träna rapportförfattare att använda exakta filter och begränsa stora ad hoc-datahämtningar.

    När kapacitetsanvändningen är effektiv skalar du proaktivt för ökad efterfrågan. Vänta inte på fullständig användning eller klagomål. Disciplinerad hantering säkerställer att investeringar uppfyller verkliga behov, oavsett om de är under centraliserade eller decentraliserade modeller, med fokus på optimal resursanvändning. Kort och kort: optimera först, expandera endast när det behövs.

  • Använd återbetalning för ansvarsskyldighet: Chargeback spårar avdelningsanvändning av delad kapacitet för transparens, oavsett om det är i decentraliserade eller centraliserade modeller. Den tillskriver kostnader till företagssponsorer och visar avkastning på investeringar (ROI), till exempel användningsprocent per ekonomi och försäljning, via appen Fabric chargeback. Avdelningar kan behöva investera i fler resurser om användningen ökar, med återbetalningsdata som stöder beslut. Att veta att deras användning övervakas uppmuntrar användarna att justera beteendet, till exempel att undvika tunga uppgifter under hög belastning. Återbetalning informerar också budgetdiskussioner när ökad efterfrågan från en avdelning kräver ny kapacitet.

  • Följ COE eller central teamstyrning för att undvika silor: Att ha ett centralt organ (oavsett om det är en formell COE, IT-administratörsteamet eller ett "kapacitetsråd") är en bästa praxis för alla installationer. Gruppens roll är att hålla ett öga på helheten – att säkerställa att en avdelnings beslut eller ett projekts behov överensstämmer med organisationens kapacitetsstrategi. I självbetjäning tillhandahåller COE vägledning, utbildning och medling (de hjälper användarna att hjälpa sig själva men kliver in när det behövs). I centraliserad form är COE/IT-teamet de facto ägare av kapacitet och tillämpar standarder och processer. I båda fallen kan coe underlätta kunskapsdelning (bästa praxis, framgångar) och anpassa kapacitetshanteringen till affärsmålen. De kan till exempel skapa en styrningsrapport som kombinerar mått från alla kapaciteter för att dela kvartalsvis med ledarskap. De ser till att oavsett om kapaciteten är spridd över team eller centralt, finns det en holistisk strategi och tillsyn snarare än siloed beslutsfattande.

Conclusion

Genom att införa robusta metoder för tillväxt och styrning ser infrastrukturadministratörer till att kapaciteten utökas i enlighet med användarimplementeringen, tar emot fler användare och projekt utan att äventyra prestandan och undviker att överskrida budgetbegränsningarna. I decentraliserade miljöer minskar effektiv styrning bullriga grannsituationer och främjar ett välreglerat, stödjande självbetjäningssystem. I centraliserade miljöer bevarar noggrann hantering höga servicestandarder som krävs för verksamhetskritisk analys. Genom att följa erkända bästa praxis – inklusive övervakning, tekniska skyddsåtgärder, transparens, optimering och omfattande tillsyn – odlas en kultur av kapacitetshantering som är datadriven, proaktiv och samarbetsinriktad. Därför kan alla användare dra nytta av en stabil och effektiv infrastrukturplattform, även när arbetsbelastningarna skalas.

Relaterat innehåll

  • Last updated on