Merk
Tilgang til denne siden krever autorisasjon. Du kan prøve å logge på eller endre kataloger.
Tilgang til denne siden krever autorisasjon. Du kan prøve å endre kataloger.
Gjelder for:✅ Fabric Data Engineering og Data Science
Fabric Data Engineering og Data Science kjører på en fullt administrert Apache Spark-beregningsplattform. Startbassenger gir rask oppstart av økter, vanligvis på 5 til 10 sekunder, uten manuell oppsett. Egendefinerte Spark-pooler lar deg justere nodestørrelse, skaleringsatferd og andre beregningsinnstillinger for arbeidsmengden din. Kort sagt gir startbassenger rask, forhåndskonfigurert Spark, mens tilpassede Spark-pooler gir dypere kontroll og fleksibilitet.
Startbassenger
Starterpooler er en rask og enkel måte å bruke Spark på Microsoft Fabric-plattformen på sekunder. Du kan bruke Spark-økter umiddelbart, i stedet for å vente på at Spark skal konfigurere nodene for deg, noe som hjelper deg med å gjøre mer med data og få innsikt raskere.
Startutvalg har Apache Spark-klynger med økter som alltid er på og klare for forespørslene dine. De bruker middels noder som dynamisk skaleres opp basert på spark-jobbbehovene dine.
Når du bruker en startpool uten ekstra bibliotekavhengigheter eller egendefinerte Spark-egenskaper, starter økten vanligvis om 5 til 10 sekunder. Denne raske oppstarten er mulig fordi klyngen allerede kjører og ikke krever klargjøringstid.
Merk
Startbassenger støtter kun middels stor nodestørrelse. Hvis du velger en annen nodestørrelse eller tilpasser beregningskonfigurasjoner, bruker Fabric on-demand session startup, som kan ta 2 til 5 minutter.
Det finnes imidlertid flere situasjoner hvor økten din kan ta lengre tid å starte.
Egendefinerte biblioteker eller Spark-egenskaper: Hvis du har konfigurert biblioteker eller tilpassede innstillinger i miljøet ditt, må Spark personalisere sesjonen når den er opprettet. Denne prosessen kan legge til rundt 30 sekunder til fem minutter oppstartstiden, avhengig av antallet og størrelsen på bibliotekavhengighetene.
Startpoolene i din region er fullt utnyttet: I sjeldne tilfeller kan en regions startpooler midlertidig være tomme på grunn av høy trafikk. Når det skjer, spinner Fabric opp en ny klynge for å imøtekomme forespørselen, noe som tar omtrent 2 til 5 minutter. Når den nye klyngen er tilgjengelig, starter økten. Hvis du også har egendefinerte biblioteker å installere, legg til de ekstra 30 til 5 minuttene som kreves for personalisering.
Avanserte nettverks- eller sikkerhetsfunksjoner (Private Links eller Managed VNets): Når arbeidsområdet ditt har nettverksfunksjoner som Tenant Private Links eller Managed VNets, støttes ikke startpooler. I denne situasjonen må Fabric opprette en klynge ved behov, noe som legger til 2 til 5 minutter til starttidspunktet for økten. Hvis du også har bibliotekavhengigheter, kan det personaliseringssteget legge til ytterligere 30 sekunder til 5 minutter.
Her er noen eksempler på scenarioer for å illustrere potensielle starttider:
| Scenario | Vanlig oppstartstid |
|---|---|
| Standardinnstillinger, ingen biblioteker | 5–10 sekunder |
| Standardinnstillinger + bibliotekavhengigheter | 5 –10 sekunder + 30 sekunder – 5 min (for bibliotekoppsett) |
| Høy trafikk i området, ingen biblioteker | 2–5 minutter |
| avhengigheter for høy trafikk + bibliotek | 2 –5 minutter + 30 sekunder – 5 min (for biblioteker) |
| network security (Private Links/VNet), ingen biblioteker | 2–5 minutter |
| Nettverkssikkerhet + bibliotekavhengigheter | 2 –5 minutter + 30 sekunder – 5 min (for biblioteker) |
Når det gjelder fakturering og kapasitetsforbruk, belastes du for kapasitetsforbruket når du begynner å kjøre notatblokken eller Apache Spark-jobbdefinisjonen. Du belastes ikke for tiden klyngene er inaktive i utvalget.
Hvis du for eksempel sender en notatblokkjobb til et startutvalg, faktureres du bare for tidsperioden der notatblokkøkten er aktiv. Den fakturerte tiden inkluderer ikke ledig tid eller tiden det tar å tilpasse økten med Spark-konteksten. For å lære mer, se Konfigurer startbassenger i Fabric.
Spark-bassenger
Et Spark-utvalg er en måte å fortelle Spark hva slags ressurser du trenger for dataanalyseoppgavene dine. Du kan gi Spark-utvalget et navn, og velge hvor mange og hvor store nodene (maskinene som gjør arbeidet) er. Du kan også fortelle Spark hvordan du justerer antall noder avhengig av hvor mye arbeid du har. Det er gratis å opprette et Spark-basseng. du betaler bare når du kjører en Spark-jobb på bassenget, og deretter setter Spark opp nodene for deg.
Hvis du ikke bruker Spark-bassenget på 2 minutter etter at økten utløper, blir Spark-bassenget deallocated. Denne standard utløpsperioden for økten er satt til 20 minutter, og du kan endre den hvis du vil. Hvis du er administrator for arbeidsområdet, kan du også opprette egendefinerte Spark-utvalg for arbeidsområdet og gjøre dem til standardalternativ for andre brukere. På denne måten kan du spare tid og unngå å sette opp et nytt Spark-basseng hver gang du kjører en notatblokk eller en Spark-jobb. Egendefinerte Spark-pooler tar omtrent tre minutter å starte, fordi Spark må hente nodene fra Azure.
Du kan også opprette spark-bassenger for enkeltnode ved å angi minimum antall noder til én, slik at driveren og eksekutoren kjører i én enkelt node som leveres med gjenopprettelig HA og er egnet for små arbeidsbelastninger.
Størrelsen og antallet noder du kan ha i din tilpassede Spark-pool avhenger av kapasiteten din i Microsoft Fabric. Kapasitet er et mål på hvor mye datakraft du kan bruke. En måte å tenke på det er at to Apache Spark vCores (en enhet av Spark-beregning) tilsvarer én kapasitetsenhet.
Merk
I Apache Spark får brukerne to Apache Spark vCores for hver kapasitetsenhet de reserverer som en del av sin SKU. Én kapasitetsenhet = to Spark vCores. For eksempel gir F64 128 Spark vCores, og en 3x burst-multiplikator øker denne verdien til 384 Spark vCores.
En SKU F64 for stoffkapasitet har for eksempel 64 kapasitetsenheter, som tilsvarer 384 Spark VCores (64 * 2 * 3X Burst Multiplier). Du kan bruke disse Spark VCores til å opprette noder av forskjellige størrelser for det egendefinerte Spark-utvalget, så lenge det totale antallet Spark VCores ikke overskrider 384.
Spark-bassenger faktureres som startbassenger; du betaler ikke for de egendefinerte Spark-bassengene du har opprettet, med mindre du har opprettet en aktiv Spark-økt for å kjøre en notatblokk eller spark-jobbdefinisjon. Du faktureres bare for varigheten av jobbkjøringene. Du faktureres ikke for faser som oppretting av klynge og avtaleplassering etter at jobben er fullført.
Hvis du for eksempel sender inn en notatblokkjobb til et egendefinert Spark-utvalg, blir du bare belastet for tidsperioden når økten er aktiv. Faktureringen for notatblokkøkten stopper når Spark-økten er stoppet eller utløpt. Du belastes ikke for tiden det tar å skaffe klyngeforekomster fra skyen, eller for tiden det tar å initialisere Spark-konteksten.
Mulige egendefinerte utvalgskonfigurasjoner for F64 basert på forrige eksempel. Mindre nodestørrelser har kapasitet spredt over flere noder, så maksimalt antall noder er høyere. Mens større noder er ressursrike, er det derfor behov for færre noder:
| SKU for stoffkapasitet | Kapasitetsenheter | Max Spark VCores med burst-faktor | Nodestørrelse | Maksimalt antall noder |
|---|---|---|---|---|
| F64 | 64 | 384 | Liten | 96 |
| F64 | 64 | 384 | Middels | 48 |
| F64 | 64 | 384 | Stor | 24 |
| F64 | 64 | 384 | X-Large | 12 |
| F64 | 64 | 384 | XX-Large | 6 |
Merk
For å opprette tilpassede pooler trenger du administratorrettigheter for arbeidsområdet. Microsoft Fabric-kapasitetsadministratoren må også gi tillatelser som tillater arbeidsområdeadministratorer å dimensjonere tilpassede Spark-pooler. For å lære mer, se Kom i gang med tilpassede Spark-bassenger i Fabric.
Noder
En Apache Spark pool-instans består av én hodenode og én eller flere arbeidernoder. En Spark-instans kan starte med minst én node. Hovednoden kjører administrasjonstjenester som Livy, YARN Resource Manager, ZooKeeper og Apache Spark-driveren. Alle noder kjører tjenester som Node Agent og YARN Node Manager. Alle arbeidernoder kjører Apache Spark Executor-tjenesten.
Merk
I Fabric er forholdet mellom noder og utførere alltid 1:1. Når du konfigurerer et utvalg, er én node dedikert til driveren, og de gjenværende nodene brukes til utførerne. Det eneste unntaket er i en konfigurasjon med én node, der ressursene for både driveren og utføreren halveres.
Nodestørrelser
Et Spark-utvalg kan defineres med nodestørrelser som spenner fra en liten databehandlingsnode (med 4 vCore og 32 GB minne) til en dobbel ekstra stor databehandlingsnode (med 64 vCore og 512 GB minne per node). Nodestørrelser kan endres etter oppretting av utvalget, selv om den aktive økten må startes på nytt.
| Størrelse | virtuell kjerne | Minne |
|---|---|---|
| Liten | 4 | 32 GB |
| Middels | 8 | 64 GB |
| Stor | 16 | 128 GB |
| X-Large | 32 | 256 GB |
| XX-Large | 64 | 512 GB |
Merk
Nodestørrelser X-Large og XX-Large er bare tillatt for stoff-SKU-er som ikke er prøveversjoner.
Autoskaler
Autoskala for Apache Spark-bassenger tillater automatisk opp- og nedskalering av databehandlingsressurser basert på aktivitetsmengden. Når du aktiverer autoskalafunksjonen, angir du minimum og maksimalt antall noder som skal skaleres. Når du deaktiverer autoskalafunksjonen, forblir antall noder angitt fast. Du kan endre denne innstillingen etter oppretting av utvalget, selv om du kanskje må starte forekomsten på nytt.
Merk
Som standard er spark.yarn.executor.decommission.enabled satt til sann, slik at den automatiske avslutningen av underutnyttede noder kan optimalisere beregningseffektiviteten. Hvis mindre aggressiv nedskalering foretrekkes, kan denne konfigurasjonen settes til usann
Dynamisk fordeling
Dynamisk tildeling gjør at Apache Spark-programmet kan be om flere eksekutorer hvis oppgavene overskrider belastningen som gjeldende eksekutorer kan bære. Det frigir også eksekutorene når jobbene er fullført, og hvis Spark-programmet flyttes til inaktiv tilstand. Enterprise-brukere synes ofte det er vanskelig å justere konfigurasjonene for eksekutoren fordi de er svært forskjellige på tvers av ulike faser av en spark-jobbkjøringsprosess. Disse konfigurasjonene er også avhengige av datavolumet som behandles, som endres fra tid til annen. Du kan aktivere dynamisk tildeling av executors-alternativet som en del av utvalgskonfigurasjonen, som muliggjør automatisk tildeling av eksekutorer til Spark-programmet basert på nodene som er tilgjengelige i Spark-utvalget.
Når du aktiverer det dynamiske tildelingsalternativet for hvert Spark-program som sendes inn, reserverer systemet eksekutorer under innsendingstrinnet for jobben basert på minimumsnodene. Du angir maksimalt antall noder for å støtte vellykkede scenarioer for automatisk skalering.