Styring af arbejdsbelastning

Gælder for: SQL Analytics-slutpunkt og warehouse i Microsoft Fabric

I denne artikel beskrives arkitektur- og arbejdsbelastningsstyringen bag datawarehousing i Microsoft Fabric.

Databehandling

Slutpunktet for Warehouse og SQL Analytics deler den samme underliggende behandlingsarkitektur. I takt med at data hentes eller indtages, udnytter det et distribueret program, der er bygget til både små og store data- og beregningsfunktioner.

Behandlingssystemet er serveruafhængigt, da backend-beregningskapaciteten skaleres op og ned autonomt for at imødekomme arbejdsbelastningsbehov.

Diagram over SQL-programmet.

Når en forespørgsel sendes, udfører SQL-frontend (FE) forespørgselsoptimering for at bestemme den bedste plan baseret på datastørrelsen og -kompleksiteten. Når planen er genereret, gives den til DQP-programmet (Distributed Query Processing). DQP orkestrerer distribueret udførelse af forespørgslen ved at opdele den i mindre forespørgsler, der udføres på backend-beregningsnoder. Hver lille forespørgsel kaldes en opgave og repræsenterer en distribueret udførelsesenhed. Den læser filer fra OneLake, joinforbinder resultater fra andre opgaver, grupper eller ordredata, der er hentet fra andre opgaver. I forbindelse med dataindtagelsesjob skrives der også data til de korrekte destinationstabeller.

Når data behandles, returneres resultaterne til SQL-frontend for at vise brugeren tilbage eller kalde programmet.

Elasticitet og robusthed

Backend-beregningskapaciteten drager fordel af en arkitektur med hurtig klargøring. Selvom der ikke er nogen SLA for ressourcetildeling, hentes der typisk nye noder inden for nogle få sekunder. I takt med at ressourceefterspørgslen øges, bruger nye arbejdsbelastninger den skalerede kapacitet. Skalering er en onlinehandling, og behandling af forespørgsler afbrydes uden afbrydelser.

Diagram, der viser hurtig klargøring af ressourcer.

Systemet er fejltolerant, og hvis en node bliver usund, omfordeles de handlinger, der udføres på noden, til sunde noder, så de kan fuldføres.

Slutpunktet for lager- og SQL-analyse giver burstable kapacitet , der gør det muligt for arbejdsbelastninger at bruge flere ressourcer til at opnå en bedre ydeevne og bruge udjævning til at give lettelse for kunder, der opretter pludselige spidsbelastninger i spidsbelastninger, mens de har en masse inaktiv kapacitet, der ikke bruges. Udjævning forenkler kapacitetsstyringen ved at sprede evalueringen af beregning for at sikre, at kundejob kører problemfrit og effektivt.

Planlægning og tilpasning

Den distribuerede tidsplan for behandling af forespørgsler fungerer på opgaveniveau. Forespørgsler repræsenteres af planlæggeren som en styret acyclisk graf (DAG) over opgaver. Dette koncept er velkendt for Spark-brugere. En DAG giver mulighed for parallelitet og samtidighed, da opgaver, der ikke er afhængige af hinanden, kan udføres samtidigt eller ude af drift.

Når forespørgsler modtages, planlægges deres opgaver baseret på FIFO-principper (first-in-first-out). Hvis der er inaktiv kapacitet, bruger planlæggeren muligvis en "bedst egnet" tilgang til at optimere samtidighed.

Når planlæggeren identificerer resourcing-pres, aktiverer den en skaleringshandling. Skalering administreres autonomt, og backendtopologien vokser, efterhånden som samtidighed øges. Da det tager et par sekunder at hente noder, er systemet ikke optimeret til ensartet ydeevne i undersekunder for forespørgsler, der kræver distribueret behandling.

Når presset falder, skaleres backendtopologien ned igen og frigiver ressourcer tilbage til området.

Isolering af indtagelse

Gælder for: Warehouse i Microsoft Fabric

I backend-beregningspuljen for Warehouse i Microsoft Fabric leveres indlæsningsaktiviteter til ressourceisolation fra analytiske arbejdsbelastninger. Dette forbedrer ydeevnen og pålideligheden, da indtagelsesjob kan køre på dedikerede noder, der er optimeret til ETL og ikke konkurrerer med andre forespørgsler eller programmer til ressourcer.

Diagram, der viser isolation af indtagelsesaktiviteter.

Bedste praksis

Microsoft Fabric-arbejdsområdet giver en naturlig isolationsgrænse for det distribuerede beregningssystem. Arbejdsbelastninger kan drage fordel af denne grænse til at administrere både omkostninger og ydeevne.

OneLake-genveje kan bruges til at oprette skrivebeskyttede replikaer af tabeller i andre arbejdsområder for at distribuere belastningen på tværs af flere SQL-motorer og dermed oprette en isolationsgrænse. Dette kan effektivt øge det maksimale antal sessioner, der udfører skrivebeskyttede forespørgsler.

Diagram, der viser isolationen af to arbejdsområder, f.eks. arbejdsområdet Finance og Marketing.