Arbetsbelastningshantering

Gäller för:✅ SQL-analysslutpunkt och lager i Microsoft Fabric

Den här artikeln beskriver arkitekturen och arbetsbelastningshanteringen i Fabric Data Warehouse.

Databehandling

Slutpunkten för lager- och SQL-analys delar samma underliggande bearbetningsarkitektur. När Fabric hämtar eller matar in data hanterar en distribuerad motor både små och storskaliga data och beräkningsfunktioner.

Bearbetningssystemet är serverlöst i och med att serverdelsberäkningskapaciteten skalas upp och ned autonomt för att uppfylla arbetsbelastningskraven.

När en fråga skickas utför SQL-klientdelen (FE) frågeoptimering för att fastställa den bästa planen baserat på datastorleken och komplexiteten. När planen har genererats ges den till DQP-motorn (Distributed Query Processing). DQP samordnar distribuerad körning av frågeställningen genom att dela upp den i mindre frågeställningar som körs på beräkningsnoder på serverns baksida. Varje liten fråga är en uppgift och representerar en distribuerad körningsenhet. Den läser filer från OneLake, kopplar resultat från andra uppgifter, grupperar eller ordnar data som hämtats från andra uppgifter. För inmatningsjobb skriver den även data till rätt måltabeller.

När data bearbetas returneras resultaten till SQL-fronten för att tillhandahålla till användaren eller det anropande programmet.

Elasticitet och återhämtning

Beräkningskapacitet i backend drar nytta av en snabb provisioning-arkitektur. Även om det inte finns något serviceavtal för resurstilldelning hämtas vanligtvis nya noder inom några sekunder. När resursefterfrågan ökar använder nya arbetsbelastningar den utskalade kapaciteten. Skalning är en onlineåtgärd och frågebearbetningen avbryts inte.

Systemet är feltolerant och om en nod blir ohälsosam, redistribueras operationer som körs på noden till friska noder för att slutföras.

Slutpunkten för lager- och SQL-analys ger skalbar kapacitet som gör att arbetsbelastningar kan använda fler resurser för att uppnå bättre prestanda och använda utjämning för att underlätta för kunder som skapar plötsliga toppar under sina tider med hög belastning och har inaktiv kapacitet som inte används vid andra tillfällen. Smoothing förenklar kapacitetshanteringen genom att fördela utvärderingen av beräkningsprocesser för att säkerställa att kundernas uppgifter körs smidigt och effektivt.

Schemaläggning och resurshantering

Schemaläggaren för distribuerad frågebearbetning fungerar på aktivitetsnivå. Frågor representeras för schemaläggaren som en riktad acyklisk graf (DAG) med uppgifter. Det här konceptet är bekant för Spark-användare. En DAG möjliggör parallellitet och samtidighet eftersom uppgifter som inte är beroende av varandra kan köras samtidigt eller i fel ordning.

När frågor tas emot schemaläggs deras uppgifter baserat på FIFO-principer (first-in-first-out). Om det finns inaktiv kapacitet kan schemaläggaren använda en "best fit"-metod för att optimera samtidighet.

När schemaläggaren identifierar resurstryck anropas en skalningsåtgärd. Skalning hanteras autonomt och serverdelstopologin växer när samtidigheten ökar. Eftersom det tar några sekunder att hämta noder är systemet inte optimerat för konsekventa undersekunders prestanda för frågor som kräver distribuerad bearbetning.

När trycket minskar skalar serverdelstopologin ned igen och frigör resursen tillbaka till regionen.

Isolering av beräkningspool

Gäller för:✅ Lager i Microsoft Fabric

Den kapacitets-SKU som tilldelats en arbetsyta bestämmer den totala beräkningskapacitet som är tillgänglig för dess SQL-analysslutpunkt. Den här beräkningen delas jämnt (50/50) i två isolerade resurspooler för användarfrågor att använda:

• SELECT-pool – Hanterar alla SELECT frågor.
• Icke-SELECT-pool – hanterar alla icke-SELECT-förfrågningar, till exempel ETL- eller inmatningsåtgärder.

Varje pool skalas oberoende baserat på frågeefterfrågan men överskrider aldrig 50% av den totala beräkningen för SQL-analysslutpunkten. Den här separationen förhindrar resurskonkurrering, vilket säkerställer att inmatningsarbetsbelastningar körs på dedikerad beräkning som optimerats för ETL utan att påverka läsfrågor. Resultatet är förbättrad prestanda och tillförlitlighet för båda frågetyperna.

Sessioner

Slutpunkten för lager- och SQL-analys har en användarsessionsgräns på 724 per arbetsyta. När den här gränsen har nåtts returneras ett fel: The user session limit for the workspace is 724 and has been reached.

Bästa praxis

Microsoft Fabric-arbetsytan ger en naturlig isoleringsgräns för det distribuerade beräkningssystemet. Arbetsbelastningar kan dra nytta av den här gränsen för att hantera både kostnader och prestanda.

OneLake-genvägar kan användas för att skapa skrivskyddade repliker av tabeller i andra arbetsytor för att distribuera belastning över flera SQL-motorer, vilket skapar en isoleringsgräns. Detta kan effektivt öka det maximala antalet sessioner som utför endast-läsbara frågor.

Relaterat innehåll

• OneLake, OneDrive för data
• Vad är Fabric Data Warehouse?
• Bättre tillsammans: sjöhuset och lagret
• Kapacitet som kan brista i Infrastrukturdatalager
• Utjämning och reglering i Fabric Data Warehouse