Samtidighedsgrænser og kø i Microsoft Fabric Spark

  • Artikel

Gælder for: Data engineering og datavidenskab i Microsoft Fabric

Microsoft Fabric gør det muligt at tildele beregningsenheder via kapacitet, som er et dedikeret sæt ressourcer, der er tilgængelige på et givet tidspunkt, der skal bruges. Kapacitet definerer en ressources mulighed for at udføre en aktivitet eller producere output. Forskellige elementer bruger forskellig kapacitet på et bestemt tidspunkt. Microsoft Fabric tilbyder kapacitet via Fabric SKU'er og prøveversioner. Du kan få flere oplysninger under Hvad er kapacitet?

Vigtigt

Microsoft Fabric er i prøveversion.

Når brugerne opretter en Microsoft Fabric-kapacitet på Azure, kan de vælge en kapacitetsstørrelse baseret på størrelsen på deres arbejdsbelastninger til analyse. I Spark får brugerne to Spark VCores for hver kapacitetsenhed, de bliver reserveret som en del af deres SKU.

One Capacity Unit = To Spark VCores

Når kapaciteten er købt, kan administratorer oprette arbejdsområder i kapaciteten i Microsoft Fabric. De Spark VCores, der er knyttet til kapaciteten, deles mellem alle Spark-baserede elementer, f.eks. notesbøger, Spark-jobdefinitioner og det lakehouse, der er oprettet i disse arbejdsområder.

Samtidig begrænsning og kø

I følgende afsnit vises forskellige numeriske grænser for Spark-arbejdsbelastninger baseret på Microsoft Fabric-kapacitets-SKU'er:

Kapacitets-SKU Tilsvarende Power BI-SKU Kapacitetsenheder Tilsvarende Spark VCores Maksimalt antal samtidige job Køgrænse
F2 - 2 4 1 4
F4 - 4 8 1 4
F8 - 8 16 2 8
F16 - 16 32 4 16
F32 - 32 64 8 32
F64 P1 64 128 16 64
Prøveversion af stof P1 64 128 5 -
F128 P2 128 256 32 128
F256 P3 256 512 64 256
F512 P4 512 1024 128 512

Kømekanismen er en simpel FIFO-baseret kø, der søger efter tilgængelige jobpladser og automatisk prøver jobbene igen, når kapaciteten er blevet tilgængelig. Da der er forskellige elementer, f.eks. notesbøger, Spark-jobdefinition og lakehouse, som brugerne kan bruge i et hvilket som helst arbejdsområde. Da forbruget varierer på tværs af forskellige virksomhedsteams, kan brugerne støde på sultscenarier, hvor der kun er afhængighed af typen element, f.eks. en Spark-jobdefinition. Denne situation kan resultere i, at brugere deler kapaciteten fra at køre et notesbogbaseret job eller en hvilken som helst lakehouse-baseret handling, f.eks. belastning til tabel.

For at undgå disse blokeringsscenarier anvender Microsoft Fabric en dynamisk reservebaseret begrænsning for job fra disse elementer. Notebook- og lakehouse-baserede job, der er mere interaktive og i realtid, klassificeres som interaktive. Mens Spark-jobdefinition er klassificeret som batch. Som en del af denne dynamiske reserve bevares minimums- og maksimumgrænserne for disse jobtyper. Reserverne er hovedsageligt til at håndtere use cases, hvor et virksomhedsteam kan opleve scenarier med spidsbelastninger, hvor hele deres kapacitet forbruges via batchjob. I disse myldretid blokeres brugerne fra at bruge interaktive elementer, f.eks. notesbøger eller lakehouse. Med denne fremgangsmåde får hver kapacitet en minimumreserve på 30 % af de samlede job, der tildeles interaktive job (5 % til lakehouse og 25 % til notesbøger) og en minimumreserve på 10 % til batchjob.

Jobtype Element Min. % Maks. %
Batch Spark-jobdefinition 10 70
Interaktiv Interaktiv min. og maks. 30 90
Notesbog 25 85
Lakehouse 5 65

Når de overskrider disse reserver, og når kapaciteten er ved maksimal udnyttelse, begrænses interaktive job som notesbøger og lakehouse med meddelelsen HTTP-svarkode 430: Anmodningen kan ikke sendes, fordi al den tilgængelige kapacitet i øjeblikket bruges. Annuller et job, der kører i øjeblikket, forøg din tilgængelige kapacitet, eller prøv igen senere.

Når køen er aktiveret, føjes batchjob som Spark-jobdefinitioner til køen og prøves automatisk igen, når kapaciteten frigøres.

Bemærk

Jobbene har en køudløbsperiode på 24 timer, hvorefter de annulleres, og brugerne skal sende dem til udførelse af job igen.

Næste trin