Administration af arbejdsbelastning

Gælder for: SQL Endpoint og Warehouse i Microsoft Fabric

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

Vigtigt

Microsoft Fabric er i øjeblikket i PRØVEVERSION. Disse oplysninger relaterer til et foreløbig produkt, der kan ændres væsentligt, før de udgives. Microsoft giver ingen garantier, udtrykt eller stiltiende, med hensyn til de oplysninger, der er angivet her.

Databehandling

Warehouse- og SQL-slutpunktet deler den samme underliggende behandlingsarkitektur. Da 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 arbejdsbelastningskrav.

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 indtagelse af job skriver den også data til de korrekte destinationstabeller.

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

Elasticitet og robusthed

Backend-beregningskapaciteten drager fordel af en hurtig klargøringsarkitektur. Selvom der ikke er nogen SLA for ressourcetildeling, hentes der typisk nye noder inden for nogle få sekunder. Efterhånden som ressourcebehovet stiger, udnytter nye arbejdsbelastninger den skalerede kapacitet. Skalering er en onlinehandling, og forespørgselsbehandling bliver afbrudt.

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.

Planlægning og resourcing

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 samtidig eller ude af drift.

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

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

Når presset aftager, skaleres backendtopologien ned igen og frigiver ressourcen 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 som 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 belastning på tværs af flere SQL-motorer, der opretter en isolationsgrænse.

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

Næste trin