Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Gælder for:✅ SQL Analytics-slutpunkt og warehouse i Microsoft Fabric
Denne artikel beskriver arkitekturen og arbejdsbelastningsstyringen i Fabric Data Warehouse.
Databehandling
Slutpunktet for Warehouse og SQL Analytics deler den samme underliggende behandlingsarkitektur. Når Fabric henter eller indlæser data, håndterer en distribueret motor både små og store data samt beregningsfunktioner.
Behandlingssystemet er serveruafhængigt, da backend-beregningskapaciteten skaleres op og ned autonomt for at imødekomme arbejdsbelastningsbehov.
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 Distributed Query Processing (DQP)-motoren. 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 er en opgave og repræsenterer en distribueret eksekveringsenhed. Den læser filer fra OneLake, sammensætter resultater fra andre opgaver, grupper eller ordrer data, der hentes 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, bliver nye noder typisk erhvervet inden for 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.
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.
Lager- og SQL-analyseendpoint tilbyder burstbar kapacitet , der gør det muligt for arbejdsbelastninger at bruge flere ressourcer for at opnå bedre ydeevne, og bruge smoothing til at give aflastning til kunder, der skaber pludselige spikes i deres spidsbelastningstider og har ubrugt kapacitet på andre tidspunkter. 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 tillader parallelisme og samtidighed, da opgaver, der ikke er afhængige af hinanden, kan udføres samtidig eller i ude af rækkefølge.
Når forespørgsler modtages, planlægges deres opgaver baseret på FIFO-principper (first-in-first-out). Hvis der er ledig kapacitet, kan planlæggeren bruge en "best fit"-tilgang til at optimere samtidigheden.
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.
Beregningspool-isolering
Gælder for:✅ Warehouse i Microsoft Fabric
Den kapacitets-SKU, der tildeles et arbejdsområde, bestemmer den samlede tilgængelige compute for dets SQL-analyseendepunkt. Denne beregning deles ligeligt (50/50) i to isolerede ressourcepuljer, som brugerforespørgsler kan benytte:
-
SELECT Pool - Håndterer alle
SELECTforespørgsler. -
Non-SELECT Pool - Håndterer alle ikke-forespørgsler
SELECT, såsom ETL eller indlæsningsoperationer.
Hver pool skalerer uafhængigt baseret på forespørgselsbehov, men overstiger aldrig 50% af den samlede compute for SQL-analyse-endpointet. Denne adskillelse forhindrer ressourcekonkurrence og sikrer, at indtagelsesarbejdsbelastninger kører på dedikeret compute optimeret til ETL uden at påvirke læseforespørgsler. Resultatet er forbedret ydeevne og pålidelighed for begge forespørgselstyper.
Bemærk
Og SELECT ikke-pool-isolationenSELECT er den standard autonome arbejdsbelastningsstyring, der anvendes på alle arbejdsområder. Dog kan workspace-administratorer tilpasse dette ved at bruge brugerdefinerede SQL-pools.
Sessioner
Warehouse- og SQL-analyse-endpointet har en brugersessionsgrænse på 724 pr. arbejdsområde. Når denne grænse nås, returneres der en fejl: The user session limit for the workspace is 724 and has been reached.
Bemærk
Da Microsoft Fabric er en SaaS-platform, er der mange systemforbindelser, der kører for løbende at optimere miljøet. DMV'er viser både system- og brugersessioner. Du kan få flere oplysninger under Overvåg forbindelser, sessioner og anmodninger ved hjælp af DMV'er.
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.
