Delen via

Azure Synapse Analytics-workload belangrijk

  • Artikel

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

Belang

Zakelijke behoeften kunnen vereisen dat datawarehousing-werkbelastingen belangrijker zijn dan andere. Overweeg een scenario waarin bedrijfskritieke verkoopgegevens vóór de fiscale periode worden geladen. Gegevensladen voor andere bronnen, zoals weergegevens, hebben geen strikte SLA's. Het instellen van een hoge urgentie voor een verzoek tot het laden van verkoopgegevens en een lage urgentie voor een verzoek tot het laden van weergegevens zorgt ervoor dat het laden van verkoopgegevens als eerste toegang krijgt tot resources en sneller wordt voltooid.

Urgentieniveaus

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

Belangscenarios

Naast het hierboven beschreven basisscenario met verkoop- en weersgegevens, zijn er andere scenario's waarin het belang van workloads helpt te voldoen aan de behoeften voor gegevensverwerking en query's.

Vergrendeling

Toegang tot vergrendelingen voor lees- en schrijfactiviteit is één gebied van natuurlijke conflicten. Voor activiteiten zoals partitieschakeling of HET HERNOEMEN VAN OBJECTEN zijn verhoogde vergrendelingen vereist. Zonder het belang van de workload, optimaliseert de toegewezen SQL-pool in Azure Synapse voor doorvoer. Optimaliseren voor doorvoer betekent dat wanneer actieve en wachtrijaanvragen dezelfde vergrendelingsbehoeften hebben en resources beschikbaar zijn, de aanvragen in de wachtrij kunnen aanvragen omzeilen met hogere vergrendelingsbehoeften die eerder in de aanvraagwachtrij zijn aangekomen. Wanneer het belang van de werkbelasting is toegepast op aanvragen met een hogere vergrendelingsbehoefte. De aanvraag met een hoger belang wordt uitgevoerd voordat de aanvraag met een lager belang wordt uitgevoerd.

Bekijk het volgende voorbeeld:

  • Q1 wordt actief uitgevoerd en selecteert gegevens uit SalesFact.
  • Q2 wordt in de wachtrij geplaatst totdat Q1 is voltooid. Deze is om 9:00 uur verzonden en probeert nieuwe gegevens te partitioneren naar SalesFact.
  • Q3 wordt ingediend om 9:01 uur en wil gegevens selecteren uit SalesFact.

Als Q2 en Q3 hetzelfde belang hebben en Q1 nog steeds wordt uitgevoerd, zal Q3 beginnen met uitvoeren. Q2 blijft wachten op een exclusieve vergrendeling op SalesFact. Als Q2 een hogere urgentie heeft dan Q3, wacht Q3 totdat Q2 is voltooid voordat de uitvoering kan worden gestart.

Niet-uniforme aanvragen

Een ander scenario waarin belang kan helpen bij het uitvoeren van query's, is wanneer aanvragen met verschillende resourceklassen worden ingediend. Zoals eerder vermeld, optimaliseert de toegewijde SQL-pool in Azure Synapse de doorvoer met dezelfde prioriteit. Wanneer aanvragen met gemengde grootte (zoals smallrc of mediumrc) in de wachtrij worden geplaatst, kiest de toegewezen SQL-pool de vroegste binnenkomende aanvraag die binnen de beschikbare resources past. Als het belang van de werkbelasting wordt toegepast, wordt de aanvraag met de hoogste prioriteit als volgende ingepland.

Bekijk het volgende voorbeeld op DW500c:

  • Q1, Q2, Q3 en Q4 voeren smallrc-query's uit.
  • Q5 wordt om 9:00 uur ingediend met de resourceklasse 'mediumrc'.
  • Q6 wordt om 9:01 uur verzonden met de smallrc resourceklasse.

Omdat Q5 mediumrc is, zijn er twee gelijktijdigheidssites 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 bestaan om de query uit te voeren. Als Q5 een groter belang heeft dan Q6, wacht Q6 tot Q5 draait voordat het met zijn uitvoering kan beginnen.

Volgende stappen