Dela via

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

  • Artikel

Gäller för:✅ Dataingenjör ing 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 Infrastruktur-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 associerade med kapaciteten delas mellan alla Apache Spark-baserade objekt som notebook-filer, Apache Spark-jobbdefinitioner och sjöhus som skapats på dessa arbetsytor.

Samtidighetsbegränsning och köning

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 SKU:erna för Infrastrukturkapacitet. 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 som Load to Table när deras kapacitet har maximal användning på grund av samtidiga jobb som körs med alla Spark Vcores som är tillgängliga för deras köpta SKU för Infrastrukturkapacitet begränsas de med meddelandet

HTTP-svarskod 430: Det här Spark-jobbet kan inte köras eftersom du har nått en Hastighetsgräns för Spark-beräkning eller API. Om du vill köra det här Spark-jobbet avbryter du ett aktivt Spark-jobb via övervakningshubben eller väljer en större kapacitets-SKU eller försöker igen senare.

När köning är aktiverat läggs notebook-jobb som utlöses från pipelines och jobbschemaläggare och Spark-jobbdefinitioner till i kön och görs automatiskt ett nytt försök när kapaciteten frigörs. Köns giltighetstid är inställd på 24 timmar från jobbets sändningstid. Efter den här perioden måste jobben skickas på nytt.

Infrastrukturkapaciteter aktiveras med bursting som gör att du kan använda extra beräkningskärnor utöver vad som har köpts för att påskynda körningen av en arbetsbelastning. För Apache Spark-arbetsbelastningar kan användare skicka jobb med totalt 3 X spark-virtuella kärnor som köpts.

Kommentar

Burst-faktorn ökar bara det totala antalet virtuella Spark-kärnor för att hjälpa till med samtidigheten, men ökar inte maximalt antal kärnor per jobb. Användare kan inte skicka ett jobb som kräver fler kärnor än vad deras infrastrukturkapacitet erbjuder.

I följande avsnitt visas olika kärnbaserade gränser för Spark-arbetsbelastningar baserat på SKU:er för Microsoft Fabric-kapacitet:

SKU för infrastrukturkapacitet Motsvarande Power BI SKU Virtuella Spark-kärnor Maximalt antal virtuella Spark-kärnor med burst-faktor 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

Exempelberäkning: F64 SKU erbjuder 128 virtuella Spark-kärnor. Burst-faktorn som tillämpas för en F64 SKU är 3, vilket ger totalt 384 Virtuella Spark-kärnor. Burst-faktorn används bara för att hjälpa till med samtidighet och ökar inte det maximala antalet tillgängliga kärnor för ett enda Spark-jobb. Det innebär att en enskild notebook- eller Spark-jobbdefinition eller lakehouse-jobb kan använda en poolkonfiguration på högst 128 virtuella kärnor och 3 jobb med samma konfiguration kan köras samtidigt. Om notebook-filer använder en mindre beräkningskonfiguration kan de köras samtidigt tills maximal användning når gränsen på 384 SparkVcore.

Kommentar

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

Spark for Fabric-begränsning har inte framtvingade godtyckliga jobbbaserade gränser och begränsningen baseras endast på antalet kärnor som tillåts för den köpta SKU:n för infrastrukturresurser. Jobbantagningen är som standard en optimistisk antagningskontroll, där jobben släpps in baserat på deras minimikrav för kärnor. Läs mer om den optimistiska jobbantagningen Jobbinträde och hantering Om standardalternativet för pool (startpool) har valts för arbetsytan, visar följande tabell maxgränsen för samtidighetsjobb.

Läs mer om standardkonfigurationerna för startpoolen baserat på SKU: n För infrastrukturkapacitet konfigurera startpooler.

Bristning på jobbnivå

Administratörer kan konfigurera sina Apache Spark-pooler så att de använder maximalt antal Spark-kärnor med burst-faktorn tillgänglig för hela kapaciteten. Till exempel kan en arbetsyteadministratör som har sin arbetsyta kopplad till en F64 Fabric-kapacitet nu konfigurera sin Spark-pool (startpool eller anpassad pool) till 384 Virtuella Spark-kärnor, där maximalt antal noder i Startpooler kan anges till 48 eller administratörer kan konfigurera en XX Stor nodstorlekspool med 6 maxnoder.

Relaterat innehåll