Samtidighetsgrenser og kø i Microsoft Fabric Spark

Gjelder for: Datateknikk og datavitenskap i Microsoft Fabric

Microsoft Fabric tillater tildeling av databehandlingsenheter gjennom kapasitet, som er et dedikert sett med ressurser som er tilgjengelig på et gitt tidspunkt som skal brukes. Kapasitet definerer en ressurss mulighet til å utføre en aktivitet eller produsere utdata. Ulike elementer bruker forskjellig kapasitet på et bestemt tidspunkt. Microsoft Fabric tilbyr kapasitet gjennom Fabric SKU-er og prøveversjoner. Hvis du vil ha mer informasjon, kan du se Hva er kapasitet?

Viktig

Microsoft Fabric er for øyeblikket i FORHÅNDSVERSJON. Denne informasjonen er knyttet til et forhåndsutgitt produkt som kan endres vesentlig før det utgis. Microsoft gir ingen garantier, uttrykt eller underforstått, med hensyn til informasjonen som er oppgitt her.

Når brukere oppretter en Microsoft Fabric-kapasitet på Azure, får de velge en kapasitetsstørrelse basert på størrelsen på analysearbeidsbelastningen. I Spark får brukerne to Spark VCores for hver kapasitetsenhet de blir reservert som en del av SKU-en.

Én kapasitetsenhet = to Spark VCores

Når kapasiteten er kjøpt, kan administratorer opprette arbeidsområder i kapasiteten i Microsoft Fabric. Spark VCores som er knyttet til kapasiteten, deles mellom alle Spark-baserte elementer som notatblokker, Spark-jobbdefinisjoner og lakehouse opprettet i disse arbeidsområdene.

Samtidighetsbegrensning og kø

Den følgende delen viser ulike numeriske grenser for Spark-arbeidsbelastninger basert på SKU-er for Microsoft Fabric-kapasitet:

Kapasitets-SKU Tilsvarende Power BI SKU Kapasitetsenheter Tilsvarende spark-VCores Maksimalt antall samtidige jobber Køgrense
F2 - 2 4 1 4
F4 - 4 8 1 4
F8 - 8 16 2 8
F16 - 16 32 5 20
F32 - 32 64 10 40
F64 P1 64 128 20 80
Stoff prøveversjon P1 64 128 5 -
F128 P2 128 256 40 160
F256 P3 256 512 80 320
F512 P4 512 1024 160 640

Kømekanismen er en enkel FIFO-basert kø, som ser etter tilgjengelige jobbplasser og automatisk registrerer jobbene på nytt når kapasiteten er tilgjengelig. Ettersom det finnes forskjellige elementer som notatblokker, Spark-jobbdefinisjon og lakehouse som brukere kan bruke i et hvilket som helst arbeidsområde. Ettersom bruken varierer på tvers av ulike virksomhetsgrupper, kan brukerne støte på sultscenarioer der det bare er avhengighet av elementtypen, for eksempel en Spark-jobbdefinisjon. Denne situasjonen kan føre til at brukere deler kapasiteten fra å kjøre en notatblokkbasert jobb eller en lakehouse-basert operasjon som laster til tabell.

For å unngå disse blokkeringsscenarioene bruker Microsoft Fabric en dynamisk reservebasert begrensning for jobber fra disse elementene. Notatblokk- og lakehouse-baserte jobber som er mer interaktive og sanntid klassifiseres som interaktive. Mens Spark-jobbdefinisjonen klassifiseres som satsvis. Som en del av denne dynamiske reserven opprettholdes minimums- og maksimumsreservegrenser for disse jobbtypene. Reservene er hovedsakelig for å håndtere brukstilfeller der et virksomhetsteam kan oppleve de beste bruksscenarioene når hele kapasiteten forbrukes gjennom satsvise jobber. I rushtiden blokkeres brukere fra å bruke interaktive elementer som notatblokker eller lakehouse. Med denne tilnærmingen får hver kapasitet en minimumsreserve på 30 % av de totale jobbene som er tildelt interaktive jobber (5 % for lakehouse og 25 % for notatblokker) og en minimumsreserve på 10 % for satsvise jobber.

Jobbtype Element Min. % Maks. %
Batch Spark-jobbdefinisjon 10 70
Interaktivitet Interaktiv minimum og maks 30 90
Notatblokk 25 85
Lakehouse 5 65

Når de overskrider disse reservene, og når kapasiteten er på sitt maksimale utnyttelse, begrenses interaktive jobber som notatblokker og lakehouse med meldingen HTTP Response code 430: Kan ikke sende inn denne forespørselen fordi all tilgjengelig kapasitet for øyeblikket brukes. Avbryt en jobb som kjører, øk den tilgjengelige kapasiteten, eller prøv på nytt senere.

Når kø er aktivert, legges satsvise jobber som Spark-jobbdefinisjoner til i køen og prøves automatisk på nytt når kapasiteten frigjøres.

Obs!

Jobbene har en utløpsperiode for kø på 24 timer, og deretter avbrytes de, og brukerne må sende dem på nytt for jobbkjøring.

Neste trinn