Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Gäller för:✅ Fabric datateknik och datavetenskap
Fabric Data Engineering och Data Science körs på en fullständigt hanterad Apache Spark-beräkningsplattform. Startpooler ger snabb start av sessioner, vanligtvis inom 5 till 10 sekunder, utan manuell installation. Med anpassade Spark-pooler kan du justera nodstorlek, skalningsbeteende och andra beräkningsinställningar för din arbetsbelastning. Kort sagt ger startpooler snabb, förkonfigurerad Spark, medan anpassade Spark-pooler ger djupare kontroll och flexibilitet.
Startpooler
Startpooler är ett snabbt och enkelt sätt att använda Spark på Microsoft Fabric plattform inom några sekunder. Du kan använda Spark-sessioner direkt i stället för att vänta på att Spark ska konfigurera noderna åt dig, vilket hjälper dig att göra mer med data och få insikter snabbare.
Startpooler har Apache Spark-kluster med sessioner som alltid är på och redo för dina begäranden. De använder medelstora noder som dynamiskt skalas upp baserat på dina Spark-jobbbehov.
När du använder en startpool utan extra biblioteksberoenden eller anpassade Spark-egenskaper börjar sessionen vanligtvis om 5 till 10 sekunder. Den här snabba starten är möjlig eftersom klustret redan är igång och inte kräver tid för provisionering.
Anteckning
Startpooler stöder endast medelhög nodstorlek. Om du väljer en annan nodstorlek eller anpassar beräkningskonfigurationer använder Fabric sessionsstart på begäran, vilket kan ta mellan 2 och 5 minuter.
Det finns dock flera scenarier där sessionen kan ta längre tid att starta.
Anpassade bibliotek eller Spark-egenskaper: Om du har konfigurerat bibliotek eller anpassade inställningar i din miljö måste Spark anpassa sessionen när den har skapats. Den här processen kan lägga till cirka 30 sekunder till 5 minuter till starttiden, beroende på antalet och storleken på dina biblioteksberoenden.
Startpooler i din region används fullt ut: I sällsynta fall kan en regions startpooler tillfälligt vara uttömda på grund av hög trafik. När det händer startar Fabric ett nytt kluster för att hantera din begäran, vilket tar cirka 2 till 5 minuter. När det nya klustret är tillgängligt startar sessionen. Om du också har anpassade bibliotek att installera lägger du till de ytterligare 30 sekunder till 5 minuter som krävs för anpassning.
Avancerade nätverks- eller säkerhetsfunktioner (privata länkar eller hanterade virtuella nätverk): När din arbetsyta har nätverksfunktioner som privata klientlänkar eller hanterade virtuella nätverk stöds inte startpooler. I det här fallet måste Fabric skapa ett kluster på begäran, vilket lägger till 2 till 5 minuter till sessionens starttid. Om du också har biblioteksberoenden kan anpassningssteget lägga till ytterligare 30 sekunder till 5 minuter.
Här följer några exempelscenarier som illustrerar potentiella starttider:
| Scenarium | Typisk starttid |
|---|---|
| Standardinställningar inga bibliotek | 5–10 sekunder |
| Standardinställningar + biblioteksberoenden | 5– 10 sekunder + 30 sekunder – 5 min (för bibliotekskonfiguration) |
| Hög trafik i regionen inga bibliotek | 2–5 minuter |
| Hög trafik + biblioteksberoenden | 2 – 5 minuter + 30 sekunder – 5 min (för bibliotek) |
| Nätverkssäkerhet (privata länkar/VNet), inga bibliotek | 2–5 minuter |
| Nätverkssäkerhet + biblioteksberoenden | 2 – 5 minuter + 30 sekunder – 5 min (för bibliotek) |
När det gäller fakturering och kapacitetsförbrukning debiteras du för kapacitetsförbrukningen när du börjar köra din notebook- eller Apache Spark-jobbdefinition. Du debiteras inte för den tid som klustren är inaktiva i poolen.
Om du till exempel skickar ett notebook-jobb till en startpool debiteras du endast för den tidsperiod då notebook-sessionen är aktiv. Den fakturerade tiden inkluderar inte inaktivitetstid eller den tid det tar att anpassa sessionen med Spark-kontexten. Mer information finns i Konfigurera startpooler i Fabric.
Sparkpooler
En Spark-pool är ett sätt att tala om för Spark vilken typ av resurser du behöver för dina dataanalysuppgifter. Du kan ge Spark-poolen ett namn och välja hur många och hur stora noderna (de datorer som utför arbetet) är. Du kan också berätta för Spark hur du justerar antalet noder beroende på hur mycket arbete du har. Det är kostnadsfritt att skapa en Spark-pool. du betalar bara när du kör ett Spark-jobb i poolen och sedan konfigurerar Spark noderna åt dig.
Om du inte använder din Spark-pool i två minuter efter att din session har gått ut deallokeras Spark-poolen. Den här standardperioden för sessionens förfallotid är inställd på 20 minuter och du kan ändra den om du vill. Om du är arbetsyteadministratör kan du också skapa anpassade Spark-pooler för din arbetsyta och göra dem till standardalternativet för andra användare. På så sätt kan du spara tid och undvika att konfigurera en ny Spark-pool varje gång du kör en notebook-fil eller ett Spark-jobb. Det tar ungefär tre minuter att starta anpassade Spark-pooler eftersom Spark måste hämta noderna från Azure.
Du kan till och med skapa Spark-pooler med en enda nod genom att ange det minsta antalet noder till en, så att drivrutinen och körkörningen körs i en enda nod som levereras med återställningsbar HA och passar för små arbetsbelastningar.
Storleken och antalet noder som du kan ha i din anpassade Spark-pool beror på din Microsoft Fabric kapacitet. Kapacitet är ett mått på hur mycket databehandlingskraft du kan använda. Ett sätt att tänka på det är att två virtuella Apache Spark-kärnor (en enhet med Spark-beräkning) är lika med en kapacitetsenhet.
Anteckning
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. F64 ger till exempel 128 virtuella Spark-kärnor och en 3x burst-multiplikator ökar det här värdet till 384 Virtuella Spark-kärnor.
En SKU F64 för Fabrickapacitet har till exempel 64 kapacitetsenheter, vilket motsvarar 384 Spark VCores (64 * 2 * 3X Burst Multiplikator). Du kan använda dessa virtuella Spark-kärnor för att skapa noder av olika storlekar för din anpassade Spark-pool, så länge det totala antalet virtuella Spark-kärnor inte överstiger 384.
Spark-pooler faktureras som startpooler. du betalar inte för de anpassade Spark-pooler som du har skapat om du inte har en aktiv Spark-session som skapats för att köra en notebook- eller Spark-jobbdefinition. Du debiteras bara under hela jobbkörningarna. Du debiteras inte för faser som klusterskapande och frigöring efter att jobbet är avslutat.
Om du till exempel skickar ett notebook-jobb till en anpassad Spark-pool debiteras du bara för den tidsperiod då sessionen är aktiv. Faktureringen för notebook-sessionen stoppas när Spark-sessionen har stoppats eller upphört att gälla. Du debiteras inte för den tid det tar att hämta klusterinstanser från molnet eller för den tid det tar att initiera Spark-kontexten.
Möjliga anpassade poolkonfigurationer för F64 baserat på föregående exempel. Mindre nodstorlekar har kapacitet fördelad över fler noder, så det maximala antalet noder är högre. Medan större noder är resursrika behövs färre noder:
| SKU för vävkapacitet | Kapacitetsenheter | Maximalt antal virtuella Spark-kärnor med överbelastningsfaktor | Nodstorlek | Maximalt antal noder |
|---|---|---|---|---|
| F64 | 64 | 384 | Liten | 96 |
| F64 | 64 | 384 | Medel | 48 |
| F64 | 64 | 384 | Stort | 24 |
| F64 | 64 | 384 | X-Large | 12 |
| F64 | 64 | 384 | XX-Large | 6 |
Anteckning
Om du vill skapa anpassade pooler behöver du administratörsbehörigheter för arbetsytan. Den Microsoft Fabric kapacitetsadministratören måste också bevilja behörigheter som gör att arbetsyteadministratörer kan ändra storlek på anpassade Spark-pooler. Mer information finns i Kom igång med anpassade Spark-pooler i Fabric.
Noder
En Apache Spark-poolinstans består av en huvudnod och en eller flera arbetsnoder. En Spark-instans kan börja med minst en nod. Huvudnoden kör hanteringstjänster som Livy, YARN Resource Manager, ZooKeeper och Apache Spark-drivrutinen. Alla noder kör tjänster som Node Agent och YARN Node Manager. Alla arbetsnoder kör Apache Spark Executor-tjänsten.
Anteckning
I Fabric är förhållandet mellan noder och exekverare alltid 1:1. När du konfigurerar en pool tilldelas en nod till styrprogrammet, och de återstående noderna används som executorer. Det enda undantaget finns i en konfiguration med en nod, där resurserna för både drivrutinen och kören halveras.
Nodstorlekar
En Spark-pool kan definieras med nodstorlekar som sträcker sig från en liten beräkningsnod (med 4 virtuella kärnor och 32 GB minne) till en dubbel extra stor beräkningsnod (med 64 virtuella kärnor och 512 GB minne per nod). Nodstorlekar kan ändras när poolen har skapats, även om den aktiva sessionen måste startas om.
| Storlek | virtuell processor kärna | Minne |
|---|---|---|
| Liten | 4 | 32 GB |
| Medel | 8 | 64 GB |
| Stort | 16 | 128 GB |
| X-Large | 32 | 256 GB |
| XX-Large | 64 | 512 GB |
Anteckning
Nodstorlekarna X-Large och XX-Large tillåts endast för icke-utvärderingsversioner av Fabric-SKU:er.
Automatisk skalning
Autoskalning för Apache Spark-pooler möjliggör automatisk upp- och nedskalning av beräkningsresurser baserat på mängden aktivitet. När du aktiverar funktionen autoskalning anger du det lägsta och högsta antalet noder som ska skalas. När du inaktiverar autoskalningsfunktionen förblir antalet noder fasta. Du kan ändra den här inställningen när poolen har skapats, men du kan behöva starta om instansen.
Anteckning
Som standard är spark.yarn.executor.decommission.enabled inställt på sant, vilket gör det möjligt att automatiskt stänga av underutnyttjade noder för att optimera beräkningseffektiviteten. Om mindre aggressiv nedskalning föredras kan den här konfigurationen ställas in på false
Dynamisk fördelning
Med dynamisk allokering kan Apache Spark-programmet begära fler utförare om uppgifterna överskrider den belastning som aktuella utförare kan bära. Den frigör också executor-komponenterna när jobben har slutförts, och om Spark-programmet övergår till ett inaktivt tillstånd. Företagsanvändare har ofta svårt att finjustera körkonfigurationerna eftersom de skiljer sig mycket mellan olika steg i en Spark-jobbkörningsprocess. Dessa konfigurationer är också beroende av mängden data som bearbetas, vilket ändras då och då. Du kan aktivera dynamisk allokering av körbara filer som en del av poolkonfigurationen, vilket möjliggör automatisk allokering av utförare till Spark-programmet baserat på de noder som är tillgängliga i Spark-poolen.
När du aktiverar alternativet dynamisk allokering för varje Spark-program som skickas reserverar systemet utförare under jobböverföringssteget baserat på de minsta noderna. Du anger maximalt antal noder som stöd för lyckade scenarier för automatisk skalning.