Del via

Samtidighedsgrænser og kø i Apache Spark til Microsoft Fabric

Gælder for:✅ Dataudvikler ing og datavidenskab i Microsoft Fabric

Microsoft Fabric tillader tildeling af beregningsenheder via kapacitet, som er et dedikeret sæt ressourcer, der er tilgængelige på et givet tidspunkt, og som 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?.

Når brugerne opretter en Microsoft Fabric-kapacitet på Azure, vælger de en kapacitetsstørrelse baseret på deres størrelse af analysearbejdsbelastninger. I Apache Spark får brugerne to Apache Spark VCores for hver kapacitetsenhed, de reserverer som en del af deres SKU.

En kapacitetsenhed = to Spark VCores

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

Samtidighedsbegrænsning og -kø

Spark for Fabric gennemtvinger en kernebaseret begrænsnings- og kømekanisme, hvor brugerne kan indsende job baseret på de købte Sku'er for Fabric-kapacitet. 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.

Når brugerne indsender notebook- eller lakehouse-job (f.eks . Indlæs til tabel), og kapaciteten har maksimal udnyttelse – på grund af samtidige job, der bruger alle Spark VCores – får de vist følgende fejl:

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øen er aktiveret, føjes notesbogjob, der udløses fra pipelines, jobstyring og Spark-jobdefinitioner , til køen og prøves automatisk igen, når kapaciteten bliver tilgængelig.

Bemærk

Køudløb er indstillet til 24 timer fra tidspunktet for indsendelse af job. Efter denne periode fjernes job fra køen og skal sendes igen manuelt.

Fabric-kapaciteter er også aktiveret med sprængning, så du kan forbruge op til 3× antallet af Spark VCores, du har købt. Dette burst hjælper med at forbedre samtidigheden ved at tillade, at flere job kører parallelt.

Bemærk

Sprængningsfaktoren øger det samlede antal Spark VCores for samtidighed og kan udnyttes af et enkelt job, hvis Spark-puljen er konfigureret med et højere kerneantal.
Med andre ord bestemmer konfigurationen af puljen de maksimale kerner, et job kan bruge – ikke kun den grundlæggende SKU-allokering.

Eksempel

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

  • Du kan konfigurere en brugerdefineret gruppe eller startpulje med op til 384 Spark VCores.
  • Hvis en arbejdsområdeadministrator opretter en sådan pulje, kan et enkelt Spark-job (f.eks. en notesbog, jobdefinition eller lakehouse-job) bruge alle 384 VCores.
  • Eksempel: En pulje med Medium noder (8 VCores hver) og 48 maks. noder = 384 VCores.

Tips

Hvis du vil maksimere jobydeevnen, skal du bekræfte, at din arbejdsområdepulje er konfigureret med tilstrækkelig nodestørrelse og -antal.

Sku-grænser for Spark-kapacitet

Sku'en for stofkapacitet Tilsvarende Power BI-SKU Spark VCores Max Spark VCores med Burst Factor Køgrænse
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
Prøveversionskapacitet P1 128 128 I/T

Vigtigt

Tabellen gælder kun for Spark-job, der kører på Fabric Capacity. Når fakturering af automatisk skalering er aktiveret, kører Spark-job separat fra Fabric-kapacitet, så du undgår sprængning eller udjævning. Det samlede antal Spark VCores vil være det dobbelte af det maksimale antal kapacitetsenheder, der er angivet i indstillinger for automatisk skalering.

Eksempel på beregning

  • En F64 SKU tilbyder 128 Spark VCores.
  • Med en burstfaktor på 3 understøtter den op til 384 Spark VCores til samtidig udførelse.
  • Hvis en pulje er konfigureret med de fulde 384 VCores, kan et enkelt job bruge dem alle, forudsat at ingen andre job bruger kapacitet.
  • Eksempel: 3 job, der bruger 128 VCores, kan køre samtidigt ELLER 1 job ved hjælp af 384 VCores kan køre.

Bemærk

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

Spark for Fabric-begrænsning har ikke gennemtvunget vilkårlige jobbaserede grænser, og begrænsningen er kun baseret på det antal kerner, der er tilladt for den købte Sku for Fabric-kapacitet. Jobindlæggelse som standard er en optimistisk optagelseskontrol, hvor job er optaget på baggrund af deres minimumskrav. Få mere at vide: Jobindlæggelse og ledelse.

Hvis standardgruppen (Startgruppe) er valgt for arbejdsområdet, vises de maksimale grænser for samtidighedsjob i følgende tabel.

Få mere at vide: Konfiguration af startpuljer.

Administratorer kan konfigurere deres Apache Spark-puljer for at udnytte det maksimale antal Spark VCores, der er tilgængelige i kapaciteten, herunder burstfaktoren på 3×, som Fabric tilbyder til samtidig udførelse. En arbejdsområdeadministrator med en F64 Fabric-kapacitet kan f.eks. konfigurere deres Spark-pulje (starterpulje eller brugerdefineret pulje) til at bruge op til 384 Spark VCores ved at:

Indstilling af maks. noder for startpuljen til 48 (med mellemnoder = 8 VCores hver), eller

Konfiguration af en brugerdefineret gruppe ved hjælp af større noder (f.eks. XXLarge = 64 VCores hver) med et passende nodeantal for at nå den ønskede kapacitet.

Med denne konfiguration kan et enkelt Spark-job forbruge hele burst-kapaciteten, hvilket er ideelt til databehandling i stor skala, der prioriterer ydeevnen.

Ny: Sprængningskontrol på jobniveau via administrationsportalen Kapacitetsadministratorer har nu kontrol over aktivering eller deaktivering af sprængning på jobniveau via en ny indstilling på administrationsportalen:

Gå til administrationsportalen → kapacitetsindstillinger → fanen Data engineering/Videnskab

Brug den nye switch "Disable Job-Level Bursting" for at forhindre, at et enkelt Spark-job bruger al tilgængelig burst-kapacitet

Bemærk

Når sprængning på jobniveau er deaktiveret, gennemtvinger Spark-programmet, at intet enkelt job kan udnytte al tilgængelig kapacitet (herunder burst-kerner). Dette sikrer, at kapaciteten forbliver tilgængelig for samtidige job, så dataoverførselshastigheden og samtidighed med flere brugere forbedres.

Denne funktion er især nyttig i miljøer med flere lejere eller miljøer med høj samtidighed, hvor arbejdsbelastninger skal balanceres på tværs af flere teams og pipelines. Administratorer kan justere denne indstilling baseret på, om kapaciteten er optimeret til det maksimale antal joboverførselshastigheder (sprængning aktiveret) eller højere samtidighed og retfærdighed (sprængning deaktiveret).

Eksempelscenarier med sprængning aktiveret (standard): Et stort batchnotesbogsjob kan forbruge alle 384 Spark VCores i en F64-kapacitet, forudsat at der ikke kører andre job.

Sprængning er deaktiveret: Et job kan begrænses til basiskernegrænsen (f.eks. 128 Spark VCores til F64), hvilket gør det muligt for andre job at starte samtidigt.

Tips

For teams med forskellige jobtyper (ETL, ML, Adhoc) kan deaktivering af sprængning på jobniveau hjælpe med at forhindre kapacitetsmonopolisering og reducere forsinkelser i jobkøen.

Relateret indhold