Not
Å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:✅ Dataingenjörskonst och Datavetenskap i Microsoft Fabric
Microsoft Fabric dataingenjörs- och datavetenskapsupplevelser körs på en fullständigt hanterad beräkningsplattform baserad på Apache Spark. Den här plattformen är utformad för att leverera oöverträffad hastighet och effektivitet. Med startpooler kan du förvänta dig snabb Apache Spark-sessionsinitiering, vanligtvis inom 5 till 10 sekunder, utan att behöva konfigureras manuellt. Du får också flexibiliteten att anpassa Apache Spark-pooler enligt dina specifika datateknik- och datavetenskapskrav. Plattformen möjliggör en optimerad och skräddarsydd analysupplevelse. Kort och kort är en startpool ett snabbt sätt att använda förkonfigurerad Spark, medan en Spark-pool erbjuder anpassning och flexibilitet.
Startpooler
Startpooler är ett snabbt och enkelt sätt att använda Spark på Microsoft Fabric-plattformen 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-egenskaperstartar sessionen vanligtvis inom 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öds endast för medelstora nodstorlekar, och om du väljer andra nodstorlekar eller anpassar beräkningskonfigurationer kan det ta mellan 2 och 5 minuter att starta sessionen på begäran.
Det finns dock flera scenarier där sessionen kan ta längre tid att starta:
Du har 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 är fullständigt utnyttjade
I sällsynta fall kan en regions startpooler vara tillfälligt 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 måste du lägga till ytterligare 30 sekunder till 5 minuter 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ätverkstö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 en 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 inaktivitetstiden eller den tid det tar att anpassa sessionen med Spark-kontexten. Mer information finns i hur du konfigurerar 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 i Azure. Ett sätt att tänka på det är att två virtuella Apache Spark-kärnor (en enhet för beräkningskraft för Spark) ä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 motsvarar två Spark VCores. Så F64 => 128 Spark VCores och där en 3x Burst-multiplikator tillämpas vilket ger totalt 384 Spark VCores.
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
För att skapa anpassade pooler behöver du administratörsbehörigheter för arbetsytan. Och Kapacitetsadministratören för Microsoft Fabric måste bevilja behörigheter så att administratörer för arbetsytor kan ändra storlek på sina 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 arbetsnoder, kan starta minst en nod i en Spark-instans. Huvudnoden kör extra 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.