Dela via

Samtidighetsgränser och köer i Apache Spark för Microsoft Fabric

Gäller för:✅ Datateknik och datavetenskap i Microsoft Fabric

Microsoft Fabric tillåter allokering av beräkningsenheter via kapacitet, vilket är en dedikerad uppsättning resurser som är tillgängliga vid en viss tidpunkt som ska användas. Kapacitet definierar möjligheten för en resurs att utföra en aktivitet eller att producera utdata. Olika objekt förbrukar olika kapacitet vid en viss tidpunkt. Microsoft Fabric erbjuder kapacitet via Fabric-SKU:er och utvärderingsversioner. Mer information finns i Vad är kapacitet?.

När användarna skapar en Microsoft Fabric-kapacitet i Azure väljer de en kapacitetsstorlek baserat på deras storlek på analysarbetsbelastningen. I Apache Spark får användarna två virtuella Apache Spark-kärnor för varje kapacitetsenhet som de reserverar som en del av sin SKU.

En kapacitetsenhet = två virtuella Spark-kärnor

När de har köpt kapaciteten kan administratörer skapa arbetsytor i kapaciteten i Microsoft Fabric. De virtuella Spark-kärnor som är kopplade till kapaciteten delas mellan alla Apache Spark-baserade objekt som notebooks, Apache Spark-jobbdefinitioner och lakehouses som skapats på dessa arbetsytor.

Samtidighetsbegränsning och kösättning

Spark for Fabric tillämpar en kärnbaserad begränsnings- och kömekanism, där användare kan skicka jobb baserat på de köpta kapacitet-SKU:erna för Fabric. Kömekanismen är en enkel FIFO-baserad kö som söker efter tillgängliga jobbplatser och automatiskt försöker utföra jobben igen när kapaciteten har blivit tillgänglig.

När användare skickar notebook- eller lakehouse-jobb ( till exempel Läs in till tabell) och kapaciteten har maximal användning – på grund av samtidiga jobb med alla Virtuella Spark-kärnor – får de följande fel:

HTTP Response code 430: This Spark job can't be run because you have hit a Spark compute or API rate limit. To run this Spark job, cancel an active Spark job through the Monitoring hub, or choose a larger capacity SKU or try again later.

När köhantering är aktiverad läggs notebook-jobb som utlöses från pipeline, jobbplanerare och Spark-jobbdefinitioner till i kön och försöks automatiskt på nytt när kapacitet blir tillgänglig.

Anteckning

Köens giltighetstid är inställd på 24 timmar från tidpunkten då jobbet skickas in. Efter den här perioden tas jobb bort från kön och måste skickas manuellt igen.

Infrastrukturkapaciteter aktiveras också med bursting, vilket gör att du kan använda upp till 3× antalet Virtuella Spark-kärnor som du har köpt. Denna ökning hjälper till att förbättra samtidigheten genom att tillåta fler jobb att köras parallellt.

Anteckning

Burst-faktorn ökar det totala antalet virtuella Spark-kärnor för samtidighet och kan utnyttjas av ett enda jobb, om Spark-poolen har konfigurerats med ett högre antal kärnor.
Med andra ord avgör poolkonfigurationen de maximala kärnor som ett jobb kan använda, inte bara den grundläggande SKU-allokeringen.

Exempel

Om du har en F64 SKU med 384 Max Spark VCores med Burst Factor:

  • Du kan konfigurera en anpassad pool eller startpool med upp till 384 virtuella Spark-kärnor.
  • Om en arbetsyteadministratör skapar en sådan pool kan ett enda Spark-jobb (t.ex. en notebook-fil, jobbdefinition eller lakehouse-jobb) använda alla 384 virtuella kärnor.
  • Exempel: En pool med Medium noder (8 virtuella kärnor vardera) och 48 maxnoder = 384 virtuella kärnor.

Tips/Råd

Kontrollera att arbetsytepoolen är konfigurerad med tillräcklig nodstorlek och antal för att maximera jobbprestandan.

SKU-gränser för Spark-kapacitet

SKU för vävkapacitet Motsvarande Power BI SKU Virtuella Spark-kärnor Maximalt antal virtuella Spark-kärnor med överbelastningsfaktor Kögräns
F2 - 4 20 4
F4 - 8 24 4
F8 - 16 48 8
F16 - 32 96 16
F32 - 64 192 32
F64 P1 128 384 64
F128 P2 256 768 128
F256 P3 512 1536 256
F512 P4 1024 3072 512
F1024 - 2048 6144 1024
F2048 - 4096 12288 2048
Utvärderingskapacitet P1 128 128 NA

Viktigt!

Tabellen gäller endast för Spark-jobb som körs på Fabric Capacity. När autoskalningsfakturering är aktiverad körs Spark-jobb separat från Fabric-kapacitet, vilket undviker överbelastning eller jämna ut resurser. Det totala antalet virtuella Spark-kärnor är dubbelt så många som de maximala kapacitetsenheter som anges i autoskalningsinställningarna.

Beräkningsexempel

  • En F64 SKU erbjuder 128 Virtuella Spark-kärnor.
  • Med en burst-faktor på 3 stöder den upp till 384 Spark VCores för parallell körning.
  • Om en pool har konfigurerats med hela 384 virtuella kärnor kan ett enda jobb använda dem alla, förutsatt att inga andra jobb förbrukar kapacitet.
  • Exempel: 3 jobb med 128 virtuella kärnor kan köras samtidigt eller 1 jobb med 384 virtuella kärnor kan köras.

Anteckning

Jobb har en kös giltighetstid på 24 timmar, varefter de avbryts, och användarna måste skicka in dem igen för körning.

Spark för Fabric-reglering har inte några tvingande godtyckliga begränsningar baserade på jobb, och regleringen baseras endast på antalet kärnor som tillåts för den köpta kapacitet-SKU:n för Fabric. Jobbantagning är i normalläget en optimistisk antagningskontroll, där jobb tillåts baserat på deras minimikärnkrav. Läs mer: Jobbinträde och hantering.

Om standardalternativet pool (startpool) har valts för arbetsytan, visar följande tabell de maximala gränserna för samtidighetsjobb.

Läs mer: Konfigurera startpooler.

Administratörer kan konfigurera sina Apache Spark-pooler så att de använder det maximala antalet virtuella Spark-kärnor som är tillgängliga inom kapaciteten, inklusive en burst-faktor på 3× som Fabric erbjuder för samtidig exekvering. En arbetsyteadministratör med en F64 Fabric-kapacitet kan till exempel konfigurera sin Spark-pool (startpool eller anpassad pool) för att använda upp till 384 virtuella Spark-kärnor genom att:

Ange maximalt antal noder för startpoolen till 48 (med Medium noder = 8 virtuella kärnor vardera) eller

Konfigurera en anpassad pool med större noder (t.ex. XXLarge = 64 virtuella kärnor vardera) med ett lämpligt nodantal för att nå önskad kapacitet.

Med den här konfigurationen kan ett enda Spark-jobb förbruka hela burst-kapaciteten, vilket är idealiskt för storskalig databearbetning som prioriterar prestanda.

Ny funktion: Kontroll av elasticitet på jobbnivå via administratörsportalen. Administratörer för kapacitet har nu kontroll över att aktivera eller inaktivera elasticitet på jobbnivå genom en ny inställning i administratörsportalen.

Gå till administrationsportalen → kapacitetsinställningar → fliken Datateknik/Vetenskap

Använd det nya reglaget "Inaktivera Job-Level Bursting" för att förhindra att ett enskilt Spark-jobb förbrukar den tillgängliga burstkapaciteten.

Anteckning

När bursting på jobbnivå är inaktiverat ser Spark-motorn till att inget enskilt jobb kan utnyttja all tillgänglig kapacitet (inklusive burst-kärnor). Detta säkerställer att kapaciteten förblir tillgänglig för samtidiga jobb, vilket förbättrar dataflödet och samtidigheten mellan flera användare.

Den här funktionen är särskilt användbar i miljöer med flera klientorganisationer eller miljöer med hög samtidighet, där arbetsbelastningar måste balanseras mellan flera team och pipelines. Administratörer kan justera den här inställningen baserat på om kapaciteten är optimerad för maximalt jobbdataflöde (bursting aktiverat) eller högre samtidighet och rättvisa (bursting inaktiverad).

Exempelscenarier Bursting aktiverat (standard): Ett stort batch notebook-jobb kan använda alla 384 virtuella Spark-kärnor i en F64-kapacitet, förutsatt att inga andra jobb körs.

Bursting inaktiverad: Ett jobb kan vara begränsat till baskärngränsen (t.ex. 128 Virtuella Spark-kärnor för F64), vilket gör att utrymme för andra jobb kan starta samtidigt.

Tips/Råd

För team med olika jobbtyper (ETL, ML, Adhoc) kan inaktivering av bristningar på jobbnivå bidra till att förhindra kapacitetsmonopolisering och minska fördröjningar i jobbköer.

Relaterat innehåll