Arbeidsbelastningsadministrasjon

Gjelder for: SQL Analytics-endepunkt og Warehouse i Microsoft Fabric

Denne artikkelen beskriver arkitekturen og arbeidsbelastningsbehandlingen bak datalagring i Microsoft Fabric.

Databehandling

Endepunktet for lageranalyse og SQL-analyse deler den samme underliggende behandlingsarkitekturen. Når data hentes eller inntas, drar den nytte av en distribuert motor som er bygd for både små og store data- og beregningsfunksjoner.

Behandlingssystemet er serverløst i denne serverdeldatabehandlingskapasiteten skaleres opp og ned autonomt for å møte arbeidsbelastningskravene.

Diagram of the SQL engine.

Når en spørring sendes, utfører SQL frontend (FE) spørringsoptimalisering for å finne den beste planen basert på datastørrelse og kompleksitet. Når planen er generert, gis den til DQP-motoren (Distributed Query Processing). DQP orkestrerer distribuert kjøring av spørringen ved å dele den opp i mindre spørringer som utføres på serverdelberegningsnoder. Hver lille spørring kalles en oppgave og representerer en distribuert utførelsesenhet. Den leser fil(er) fra OneLake, slår sammen resultater fra andre oppgaver, grupper eller bestiller data hentet fra andre oppgaver. For inntaksjobber skriver den også data til de riktige måltabellene.

Når data behandles, returneres resultatene til SQL-frontend for å tjene tilbake til brukeren eller anropsprogrammet.

Elastisitet og robusthet

Backend-databehandlingskapasitet drar nytte av en rask klargjøringsarkitektur. Selv om det ikke finnes noen serviceavtale for ressurstildeling, anskaffes vanligvis nye noder i løpet av noen få sekunder. Etter hvert som ressursetterspørselen øker, bruker nye arbeidsbelastninger den utskalerte kapasiteten. Skalering er en tilkoblet operasjon, og spørringsbehandlingen blir uavbrutt.

Diagram that shows fast provisioning of resources.

Systemet er feiltolerante, og hvis en node blir usunn, distribueres operasjoner som utføres på noden til sunne noder for fullføring.

Lager- og SQL-analyseendepunkt gir kapasitet som kan brukes til å bruke flere ressurser for å oppnå bedre ytelse, og bruke utjevning til å tilby lindring for kunder som skaper plutselige pigger i rushtiden, mens de har mye inaktiv kapasitet som ikke brukes. Utjevning forenkler kapasitetsstyring ved å spre evalueringen av databehandling for å sikre at kundejobber kjører jevnt og effektivt.

Planlegging og omsourcing

Planleggeren for distribuert spørringsbehandling opererer på oppgavenivå. Spørringer representeres for planleggeren som en rettet acyklisk graf (DAG) av aktiviteter. Dette konseptet er kjent for Spark-brukere. En DAG gir parallellitet og samtidighet som oppgaver som ikke er avhengige av hverandre, kan utføres samtidig eller ute av drift.

Etter hvert som spørringer kommer, planlegges oppgavene deres basert på først-i-første-ut -prinsipper (FIFO). Hvis det er inaktiv kapasitet, kan planleggeren bruke en "best fit" tilnærming for å optimalisere samtidighet.

Når planleggeren identifiserer resourcing-trykk, aktiveres en skalaoperasjon. Skalering administreres autonomt og backend topologi vokser etter hvert som samtidighet øker. Siden det tar noen sekunder å skaffe noder, er ikke systemet optimalisert for konsekvent subsecond-ytelse for spørringer som krever distribuert behandling.

Når trykket avtar, skalerer backend topologi ned igjen og frigjør ressurs tilbake til området.

Inntaksisolering

Gjelder for: Lager i Microsoft Fabric

I serverdeldatabehandlingsutvalget på Warehouse i Microsoft Fabric får innlastingsaktiviteter ressursisolasjon fra analytiske arbeidsbelastninger. Dette forbedrer ytelsen og påliteligheten, ettersom inntaksjobber kan kjøre på dedikerte noder som er optimalisert for ETL og ikke konkurrerer med andre spørringer eller programmer for ressurser.

Diagram that shows isolation of ingestion activities.

Beste fremgangsmåter

Microsoft Fabric-arbeidsområdet gir en naturlig isolasjonsgrense for det distribuerte databehandlingssystemet. Arbeidsbelastninger kan dra nytte av denne grensen for å administrere både kostnader og ytelse.

OneLake-snarveier kan brukes til å opprette skrivebeskyttede replikaer av tabeller i andre arbeidsområder for å distribuere belastning på tvers av flere SQL-motorer, noe som oppretter en isolasjonsgrense. Dette kan effektivt øke maksimalt antall økter som utfører skrivebeskyttede spørringer.

Diagram that shows isolation of two workspaces, for example, the Finance and the Marketing workspace.