Arbeidsbelastningsadministrasjon

Gjelder for: SQL Endpoint and Warehouse i Microsoft Fabric

Denne artikkelen beskriver arkitektur- og arbeidsbelastningsbehandlingen bak datalager i Microsoft Fabric.

Viktig

Microsoft Fabric er i forhåndsversjon.

Databehandling

Warehouse og SQL Endpoint deler den samme underliggende behandlingsarkitekturen. Når data hentes eller tas inn, 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 serverdelkapasiteten skaleres opp og ned autonomt for å møte arbeidsbelastningskravene.

Diagram over SQL-motoren.

Når en spørring sendes, utfører SQL frontdel (FE) spørringsoptimalisering for å finne den beste planen basert på datastørrelsen og kompleksiteten. 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, sammenføyer 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-frontserveren for å gå tilbake til brukeren eller kalle programmet.

Elastisitet og robusthet

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

Diagram som viser rask klargjøring av ressurser.

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

Planlegging og resourcing

Den distribuerte spørringsbehandlingsplanleggeren opererer på et aktivitetsnivå . Spørringer representeres for planleggeren som en rettet acyklisk graf (DAG) av oppgaver. Dette konseptet er kjent for Spark-brukere. En DAG muliggjør parallellitet og samtidighet som oppgaver som ikke er avhengige av hverandre, kan utføres samtidig eller ute av drift.

Etter hvert som spørringer ankommer, planlegges oppgavene 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-trykket, aktiveres en skaleringsoperasjon. Skalering administreres autonomt og backend topologi vokser etter hvert som samtidigheten øker. Siden det tar noen sekunder å skaffe noder, er ikke systemet optimalisert for konsekvent subsekund-ytelse for spørringer som krever distribuert behandling.

Når trykket avtar, skaleres topologien for serverdel ned igjen og frigjør ressursen tilbake til området.

Isolering av inntak

Gjelder for: Lager i Microsoft Fabric

I serverdeldatautvalget på Warehouse i Microsoft Fabric gis 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 som viser isolering av inntaksaktiviteter.

Anbefalte 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 som oppretter en isolasjonsgrense.

Diagram som viser isolering av to arbeidsområder, for eksempel arbeidsområdet Økonomi og Markedsføring.

Neste trinn