Delen via


Belang van Azure Synapse Analytics-workload

In dit artikel wordt uitgelegd hoe het belang van workloads van invloed kan zijn op de volgorde van uitvoering van toegewezen SQL-poolaanvragen in Azure Synapse.

Urgentie

Zakelijke behoeften kunnen vereisen dat datawarehousingworkloads belangrijker zijn dan andere. Overweeg een scenario waarin bedrijfskritieke verkoopgegevens worden geladen voordat de fiscale periode wordt afgesloten. Het laden van gegevens voor andere bronnen, zoals weergegevens, heeft geen strikte SLA's. Het instellen van hoge urgentie voor een aanvraag voor het laden van verkoopgegevens en een lage urgentie voor een aanvraag voor het laden van weergegevens zorgt ervoor dat de belasting van verkoopgegevens eerst toegang krijgt tot resources en sneller wordt voltooid.

Urgentieniveaus

Er zijn vijf niveaus van urgentie: laag, below_normal, normaal, above_normal en hoog. Aan aanvragen die geen urgentie instellen, wordt het standaardniveau van normaal toegewezen. Aanvragen met hetzelfde urgentieniveau hebben hetzelfde planningsgedrag dat momenteel bestaat.

Urgentiescenario's

Afgezien van het hierboven beschreven basisscenario met verkoop- en weergegevens, zijn er andere scenario's waarin workload belangrijk is om te voldoen aan de behoeften voor gegevensverwerking en het uitvoeren van query's.

Vergrendelen

Toegang tot vergrendelingen voor lees- en schrijfactiviteit is een natuurlijk conflictgebied. Voor activiteiten zoals schakelen tussen partities of OBJECTNAAM WIJZIGEN zijn verhoogde vergrendelingen vereist. Zonder workloadbelang wordt de toegewezen SQL-pool in Azure Synapse geoptimaliseerd voor doorvoer. Optimaliseren voor doorvoer betekent dat wanneer actieve aanvragen en aanvragen in de wachtrij dezelfde vergrendelingsbehoeften hebben en resources beschikbaar zijn, de aanvragen in de wachtrij aanvragen kunnen omzeilen met hogere vergrendelingsbehoeften die eerder in de aanvraagwachtrij zijn aangekomen. Zodra de workload belangrijk is toegepast op aanvragen met hogere vergrendelingsbehoeften. Aanvragen met een hogere urgentie worden uitgevoerd vóór een aanvraag met een lagere urgentie.

Kijk eens naar het volgende voorbeeld:

  • Q1 wordt actief uitgevoerd en selecteert gegevens uit SalesFact.
  • Q2 staat in de wachtrij tot Q1 is voltooid. Het is ingediend om 9:00 uur en probeert nieuwe gegevens te partitioneren in SalesFact.
  • Q3 wordt om 9:01 ingediend en wil gegevens uit SalesFact selecteren.

Als Q2 en Q3 hetzelfde belang hebben en Q1 nog steeds wordt uitgevoerd, wordt Q3 uitgevoerd. Q2 blijft wachten op een exclusieve vergrendeling van SalesFact. Als Q2 een hogere prioriteit heeft dan Q3, wacht Q3 tot Q2 is voltooid voordat de uitvoering kan worden gestart.

Niet-uniforme aanvragen

Een ander scenario waarin het belang kan helpen om aan queryvereisten te voldoen, is wanneer aanvragen met verschillende resourceklassen worden ingediend. Zoals eerder vermeld, wordt de toegewezen SQL-pool in Azure Synapse onder hetzelfde belang geoptimaliseerd voor doorvoer. Wanneer aanvragen van meerdere grootten (zoals smallrc of mediumrc) in de wachtrij worden geplaatst, kiest de toegewezen SQL-pool de eerste binnenkomende aanvraag die binnen de beschikbare resources past. Als de urgentie van de workload wordt toegepast, wordt de aanvraag met de hoogste urgentie gepland.

Bekijk het volgende voorbeeld op DW500c:

  • In Q1, Q2, Q3 en Q4 worden kleine query's uitgevoerd.
  • Q5 wordt om 9:00 uur verzonden met de resourceklasse mediumrc.
  • Q6 wordt om 9:01 uur verzonden met de resourceklasse smallrc.

Omdat Q5 mediumrc is, zijn twee gelijktijdigheidssleuven vereist. Q5 moet wachten tot twee van de actieve query's zijn voltooid. Wanneer een van de actieve query's (Q1-Q4) echter is voltooid, wordt Q6 onmiddellijk gepland omdat de resources aanwezig zijn om de query uit te voeren. Als Q5 een hogere prioriteit heeft dan Q6, wacht Q6 tot q5 wordt uitgevoerd voordat het kan worden uitgevoerd.

Volgende stappen