Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Gælder for:✅ Fabric Data Engineering og Data Science
Fabric Data Engineering og Data Science kører på en fuldt administreret Apache Spark-computeplatform. Starterpools giver hurtig session opstart, typisk på 5 til 10 sekunder, uden manuel opsætning. Brugerdefinerede Spark-pools lader dig justere nodestørrelse, skaleringsadfærd og andre beregningsindstillinger for din arbejdsbyrde. Kort sagt giver startpools hurtig, forudkonfigureret Spark, mens specialtilpassede Spark-pools giver dybere kontrol og fleksibilitet.
Startbassiner
Starterpools er en hurtig og nem måde at bruge Spark på Microsoft Fabric-platformen på få sekunder. Du kan bruge Spark-sessioner med det samme i stedet for at vente på, at Spark konfigurerer noderne for dig, hvilket hjælper dig med at gøre mere med data og få hurtigere indsigt.
Startpuljer har Apache Spark-klynger med sessioner, der altid er tændt og klar til dine anmodninger. De bruger mellemstore noder, der dynamisk skaleres op på baggrund af dine Behov for Spark-job.
Når du bruger en startpool uden ekstra biblioteksafhængigheder eller brugerdefinerede Spark-egenskaber, starter din session typisk om 5 til 10 sekunder. Denne hurtige start er mulig, fordi klyngen allerede kører og ikke kræver klargøringstid.
Bemærk
Starterpools understøtter kun medium nodestørrelse. Hvis du vælger en anden nodestørrelse eller tilpasser compute-konfigurationer, bruger Fabric on-demand sessionsopstart, som kan tage 2 til 5 minutter.
Der er dog flere situationer, hvor din session kan tage længere tid at starte.
Brugerdefinerede biblioteker eller Spark-egenskaber: Hvis du har konfigureret biblioteker eller brugerdefinerede indstillinger i dit miljø, skal Spark personalisere sessionen, når den er oprettet. Denne proces kan føje omkring 30 sekunder til 5 minutter til starttiden, afhængigt af antallet og størrelsen af biblioteksafhængighederne.
Starterpuljer i din region er fuldt udnyttede: I sjældne tilfælde kan en regions startpuljer midlertidigt være opbrugte på grund af høj trafik. Når det sker, spinner Fabric en ny klynge for at imødekomme din anmodning, hvilket tager ca. 2 til 5 minutter. Når den nye klynge er tilgængelig, starter din session. Hvis du også har brugerdefinerede biblioteker at installere, så tilføj de ekstra 30 sekunder til 5 minutter , der kræves for personalisering.
Avancerede netværks- eller sikkerhedsfunktioner (Private Links eller Managed VNets): Når dit arbejdsområde har netværksfunktioner som Tenant Private Links eller Managed VNets, understøttes starter pools ikke. I denne situation skal Fabric oprette en klynge efter behov, hvilket føjer 2 til 5 minutter til starttidspunktet for din session. Hvis du også har biblioteksafhængigheder, kan det personaliseringstrin tilføje yderligere 30 sekunder til 5 minutter.
Her er et par eksempelscenarier, der illustrerer potentielle starttider:
| Scenarie | Typisk starttidspunkt |
|---|---|
| Standardindstillinger, ingen biblioteker | 5-10 sekunder |
| Standardindstillinger + biblioteksafhængigheder | 5– 10 sekunder + 30 sekunder – 5 min. (for konfiguration af bibliotek) |
| Høj trafik i området, ingen biblioteker | 2- 5 minutter |
| Høj trafik + biblioteksafhængigheder | 2 – 5 minutter + 30 sekunder – 5 min. (for biblioteker) |
| Netværkssikkerhed (Private Links/VNet), ingen biblioteker | 2- 5 minutter |
| Afhængigheder af netværkssikkerhed og bibliotek | 2 – 5 minutter + 30 sekunder – 5 min. (for biblioteker) |
Når det kommer til fakturering og kapacitetsforbrug, bliver du opkrævet for kapacitetsforbruget, når du begynder at køre definitionen af din notesbog eller Apache Spark-job. Du faktureres ikke for den tid, klyngerne er inaktive i puljen.
Hvis du f.eks. sender et notesbogjob til en startpulje, faktureres du kun for den tidsperiode, hvor notesbogsessionen er aktiv. Den fakturerede tid inkluderer ikke inaktiv tid eller den tid det tager at tilpasse sessionen med Spark-konteksten. For at lære mere, se Konfigurér startpuljer i Fabric.
Spark-bassiner
En Spark-pulje er en måde at fortælle Spark, hvilken type ressourcer du har brug for til dine dataanalyseopgaver. Du kan give din Spark-pool et navn og vælge, hvor mange og hvor store noderne (de maskiner, der udfører arbejdet) er. Du kan også fortælle Spark, hvordan du justerer antallet af noder, afhængigt af hvor meget arbejde du har. Det er gratis at oprette en Spark-pool. du betaler kun, når du kører et Spark-job i puljen, og derefter konfigurerer Spark noderne for dig.
Hvis du ikke bruger din Spark-pool i 2 minutter, efter din session udløber, bliver din Spark-pool deallokeret. Denne standardperiode for sessionens udløb er angivet til 20 minutter, og du kan ændre den, hvis du vil. Hvis du er administrator af arbejdsområdet, kan du også oprette brugerdefinerede Spark-puljer for dit arbejdsområde og gøre dem til standardindstillingen for andre brugere. På denne måde kan du spare tid og undgå at oprette en ny Spark-pool, hver gang du kører en notesbog eller et Spark-job. Brugerdefinerede Spark-pools tager cirka tre minutter at starte, fordi Spark skal hente noderne fra Azure.
Du kan endda oprette Spark-puljer med en enkelt node ved at angive det mindste antal noder til én, så driveren og eksekveren kører i en enkelt node, der leveres med restorable HA og er velegnet til små arbejdsbelastninger.
Størrelsen og antallet af noder, du kan have i din tilpassede Spark-pool, afhænger af din Microsoft Fabric-kapacitet. Kapacitet er et mål for, hvor meget regnekraft du kan bruge. En måde at tænke på det er, at to Apache Spark vCores (en enhed af Spark-beregning) svarer til én kapacitetsenhed.
Bemærk
I Apache Spark får brugerne to Apache Spark vCores for hver kapacitetsenhed, de reserverer som en del af deres SKU. En kapacitet = to Spark vCores. For eksempel giver F64 128 Spark vCores, og en 3x burst-multiplikator øger denne værdi til 384 Spark vCores.
En Fabric-kapacitets-SKU F64 har f.eks. 64 kapacitetsenheder, hvilket svarer til 384 Spark VCores (64 * 2 * 3X Burst Multiplier). Du kan bruge disse Spark VCores til at oprette noder i forskellige størrelser til din brugerdefinerede Spark-pulje, så længe det samlede antal Spark VCores ikke overstiger 384.
Spark-puljer faktureres som startbassiner; du betaler ikke for de brugerdefinerede Spark-puljer, du har oprettet, medmindre du har oprettet en aktiv Spark-session til kørsel af en notesbog eller en Spark-jobdefinition. Du faktureres kun for varigheden af dine jobkørsler. Du faktureres ikke for faser som oprettelse af klyngen og deallocation, når jobbet er fuldført.
Hvis du f.eks. sender et notesbogjob til en brugerdefineret Spark-gruppe, faktureres du kun for den tidsperiode, hvor sessionen er aktiv. Faktureringen for notesbogsessionen stopper, når Spark-sessionen er stoppet eller udløbet. Du faktureres ikke for den tid, det tager at hente klyngeforekomster fra cloudmiljøet, eller for den tid, det tager at initialisere Spark-konteksten.
Mulige brugerdefinerede puljekonfigurationer for F64 baseret på det forrige eksempel. Mindre nodestørrelser har kapacitet fordelt på flere noder, så det maksimale antal noder er højere. Større noder er ressourcerige, så der er brug for færre noder:
| Sku'en for stofkapacitet | Kapacitetsenheder | Max Spark VCores med Burst Factor | Nodestørrelse | Maksimalt antal noder |
|---|---|---|---|---|
| F64 | 64 | 384 | Lille | 96 |
| F64 | 64 | 384 | Mellem | 48 |
| F64 | 64 | 384 | Stor | 24 |
| F64 | 64 | 384 | X-stor | 12 |
| F64 | 64 | 384 | XX-stor | 6 |
Bemærk
For at oprette brugerdefinerede pools skal du have administratorrettigheder til arbejdsområdet. Microsoft Fabric-kapacitetsadministratoren skal også give tilladelser, der tillader workspace-administratorer at dimensionere tilpassede Spark-pools. For at lære mere, se Kom i gang med specialdesignede Spark-pools i Fabric.
Noder
En Apache Spark pool-instans består af én hovednode og en eller flere arbejdernoder. En Spark-instans kan starte med mindst én node. Hovednoden kører administrationstjenester som Livy, YARN Resource Manager, ZooKeeper og Apache Spark-driveren. Alle noder kører tjenester som Node Agent og YARN Node Manager. Alle arbejdernoder kører Tjenesten Apache Spark Executor.
Bemærk
I Fabric er forholdet mellem noder og eksekutorer altid 1:1. Når du konfigurerer en gruppe, er én node dedikeret til driveren, og de resterende noder bruges til eksekutorerne. Den eneste undtagelse er i en konfiguration med en enkelt node, hvor ressourcerne for både driveren og eksekutoren halveres.
Nodestørrelser
En Spark-pulje kan defineres med nodestørrelser, der spænder fra en lille beregningsnode (med 4 vCore og 32 GB hukommelse) til en dobbelt ekstra stor beregningsnode (med 64 vCore og 512 GB hukommelse pr. node). Nodestørrelser kan ændres efter oprettelsen af gruppen, selvom den aktive session skal genstartes.
| Størrelse | vCore | Hukommelse |
|---|---|---|
| Lille | 4 | 32 GB |
| Mellem | 8 | 64 GB |
| Stor | 16 | 128 GB |
| X-stor | 32 | 256 GB |
| XX-stor | 64 | 512 GB |
Bemærk
Nodestørrelserne X-Large og XX-Large er kun tilladt for Fabric-SKU'er, der ikke er prøveversioner.
Automatisk skalering
Autoskalering for Apache Spark-puljer gør det muligt automatisk at skalere op og ned på beregningsressourcer baseret på mængden af aktivitet. Når du aktiverer funktionen til automatisk skalering, angiver du det minimum- og maksimumantal noder, der skal skaleres. Når du deaktiverer funktionen til automatisk skalering, forbliver antallet af noder, der er angivet, fast. Du kan ændre denne indstilling efter oprettelsen af puljen, selvom du muligvis skal genstarte forekomsten.
Bemærk
Spark.yarn.executor.decommission.enabled er som standard angivet til true, hvilket muliggør automatisk lukning af underudnyttede noder for at optimere beregningseffektiviteten. Hvis der foretrækkes mindre aggressiv nedskalering, kan denne konfiguration indstilles til falsk
Dynamisk fordeling
Dynamisk allokering gør det muligt for Apache Spark-programmet at anmode om flere eksekveringsanmodninger, hvis opgaverne overstiger den belastning, som de aktuelle eksekverere kan bære. Den frigiver også eksekutorerne, når jobbene er fuldført, og hvis Spark-programmet skifter til inaktiv tilstand. Virksomhedsbrugere har ofte svært ved at tilpasse eksekveringskonfigurationerne, fordi de er meget forskellige på tværs af forskellige faser i en Spark-jobudførelsesproces. Disse konfigurationer er også afhængige af mængden af behandlede data, som ændres fra tid til anden. Du kan aktivere dynamisk allokering af eksekveringsindstillingerne som en del af konfigurationen af gruppen, hvilket muliggør automatisk allokering af eksekveringsprogrammer til Spark-programmet baseret på de noder, der er tilgængelige i Spark-gruppen.
Når du aktiverer indstillingen for dynamisk allokering for hvert Spark-program, der sendes, reserverer systemet eksekutorer under jobindsendelsestrinnet baseret på minimumnoderne. Du angiver det maksimale antal noder, der understøtter vellykkede automatiske skaleringsscenarier.