Stream Analytics-streaming-eenheden begrijpen en aanpassen

Artikel
01/03/2024

Inzicht in streaming-eenheid en streamingknooppunt

Streaming-eenheden (RU's) vertegenwoordigt de rekenresources die zijn toegewezen om een Stream Analytics-taak uit te voeren. Hoe hoger het aantal streaming-eenheden, hoe meer CPU- en geheugenresources worden toegewezen voor uw taak. Met deze capaciteit kunt u zich richten op de querylogica en de noodzaak om de hardware te beheren om uw Stream Analytics-taak tijdig uit te voeren.

Azure Stream Analytics ondersteunt twee structuren voor streaming-eenheden: SU V1(afgeschaft) en SU V2(aanbevolen).

Het SU V1-model is het oorspronkelijke aanbod van ASA, waarbij elke 6 SU's overeenkomen met één streamingknooppunt voor een taak. Taken kunnen ook worden uitgevoerd met 1 en 3 RU's en deze komen overeen met fractionele streamingknooppunten. Schalen vindt plaats in stappen van 6 dan 6 SU-taken, tot 12, 18, 24 en hoger door meer streamingknooppunten toe te voegen die gedistribueerde rekenresources bieden.

Het SU V2-model (aanbevolen) is een vereenvoudigde structuur met gunstige prijzen voor dezelfde rekenresources. In het SU V2-model komt 1 SU V2 overeen met één streamingknooppunt voor uw taak. 2 SU V2's komen overeen met 2, 3 tot en met 3, enzovoort. Taken met 1/3 en 2/3 SU V2's zijn ook beschikbaar met één streamingknooppunt, maar een fractie van de rekenresources. De 1/3 en 2/3 SU V2-taken bieden een rendabele optie voor workloads die kleinere schaal vereisen.

De onderliggende rekenkracht voor V1- en V2-streaming-eenheden is als volgt:

SU V1 and SU V2 mapping.

Ga naar de pagina met prijzen van Azure Stream Analytics voor informatie over SU-prijzen.

Inzicht in conversies van streaming-eenheden en waar ze van toepassing zijn

Er is een automatische conversie van streaming-eenheden die afkomstig zijn van de REST API-laag naar de gebruikersinterface (Azure Portal en Visual Studio Code). U ziet deze conversie in het activiteitenlogboek en waar SU-waarden anders worden weergegeven dan de waarden in de gebruikersinterface. Dit is standaard en de reden hiervoor is dat REST API-velden zijn beperkt tot gehele getallen en ASA-taken ondersteuning bieden voor breukknooppunten (1/3 en 2/3 streaming-eenheden). In de gebruikersinterface van ASA worden knooppuntwaarden 1/3, 2/3, 1, 2, 3, ... enzovoort, terwijl back-end (activiteitenlogboeken, REST API-laag) dezelfde waarden weergeven die respectievelijk worden vermenigvuldigd met 10 als 3, 7, 10, 20, 30.

Standaard	Standard V2 (UI)	Standard V2 (back-end, zoals logboeken, REST API, enzovoort)
1	1/3	3
3	2/3	7
6	1	10
12	2	20
18	3	30
...	...	...

Hierdoor kunnen we dezelfde granulariteit overbrengen en het decimaalteken op de API-laag voor V2-SKU's elimineren. Deze conversie is automatisch en heeft geen invloed op de prestaties van uw taak.

Inzicht in verbruik en geheugengebruik

Om verwerking met lage latentie te bereiken, voeren Azure Stream Analytics-taken alle verwerking in het geheugen uit. Wanneer er onvoldoende geheugen beschikbaar is, mislukt de streamingtaak. Als gevolg hiervan is het voor een productietaak belangrijk om het resourcegebruik van een streamingtaak te bewaken en ervoor te zorgen dat er voldoende resources zijn toegewezen om de taken 24/7 uit te voeren.

De metrische gegevens over het GEBRUIK van SU%, die variëren van 0% tot 100%, beschrijft het geheugenverbruik van uw workload. Voor een streamingtaak met minimale footprint is deze metrische waarde meestal tussen 10% en 20%. Als het GEBRUIK van SU% hoog is (boven 80%), of als invoergebeurtenissen worden teruggemeld (zelfs met een laag SU%-gebruik omdat er geen CPU-gebruik wordt weergegeven), vereist uw workload waarschijnlijk meer rekenresources. Hiervoor moet u het aantal streaming-eenheden verhogen. Het is raadzaam om de SU-meetwaarde onder de 80% te houden om rekening te houden met incidentele pieken. Als u wilt reageren op verhoogde workloads en streaming-eenheden wilt verhogen, kunt u overwegen om een waarschuwing van 80% in te stellen op de metrische waarde voor SU-gebruik. U kunt ook watermerkvertraging en metrische gegevens over vastgelegde gebeurtenissen gebruiken om te zien of er gevolgen zijn.

Stream Analytics-streaming-eenheden (SU's) configureren

Meld u aan bij de Azure-portal.
Zoek in de lijst met resources de Stream Analytics-taak die u wilt schalen en open deze.
Selecteer Op de taakpagina onder de kop Configureren de optie Schalen. Het standaardaantal RU's is 1 bij het maken van een taak.

screen shot of menu on ASA portal.

Kies de SU-optie in de vervolgkeuzelijst om de SU's voor de taak in te stellen. U ziet dat u beperkt bent tot een specifiek SU-bereik.
U kunt het aantal TOEGEWEZEN RU's aan uw taak wijzigen terwijl deze wordt uitgevoerd. U kunt niet kiezen uit een set SU-waarden wanneer de taak wordt uitgevoerd als uw taak gebruikmaakt van een niet-gepartitioneerde uitvoer. Of heeft een query met meerdere stappen met verschillende PARTITION BY-waarden.

Taakprestaties bewaken

Met behulp van Azure Portal kunt u de prestatiegerelateerde metrische gegevens van een taak bijhouden. Zie de metrische gegevens van de Azure Stream Analytics-taak voor meer informatie over de definitie van metrische gegevens. Zie Stream Analytics-taak bewaken met Azure Portal voor meer informatie over de bewaking van metrische gegevens in de portal.

Screenshot of monitor job performance.

Bereken de verwachte doorvoer van de workload. Als de doorvoer lager is dan verwacht, kunt u de invoerpartitie afstemmen, de query afstemmen en SU's toevoegen aan uw taak.

Hoeveel streaming-eenheden zijn vereist voor een taak?

Het kiezen van het aantal vereiste RU's voor een bepaalde taak is afhankelijk van de partitieconfiguratie voor de invoer en de query die in de taak is gedefinieerd. Met de pagina Schaal kunt u het juiste aantal RU's instellen. Het is een best practice om meer RU's toe te wijzen dan nodig is. De Stream Analytics-verwerkingsengine optimaliseert voor latentie en doorvoer ten koste van het toewijzen van extra geheugen.

Over het algemeen is het raadzaam om te beginnen met 1 SU V2 voor query's die geen PARTITION BY gebruiken. Bepaal vervolgens de sweet spot met behulp van een evaluatie- en foutmethode waarin u het aantal SU's wijzigt nadat u representatieve hoeveelheden gegevens hebt doorgegeven en de metrische gegevens voor SU% gebruik hebt onderzocht. Het maximum aantal streaming-eenheden dat door een Stream Analytics-taak kan worden gebruikt, is afhankelijk van het aantal stappen in de query die is gedefinieerd voor de taak en het aantal partities in elke stap. Hier vindt u meer informatie over de limieten.

Zie deze pagina voor meer informatie over het kiezen van het juiste aantal SU's: Azure Stream Analytics-taken schalen om de doorvoer te verhogen.

Notitie

Het kiezen van het aantal SU's dat nodig is voor een bepaalde taak, is afhankelijk van de partitieconfiguratie voor de invoer en van de query die voor de taak is gedefinieerd. U kunt maximaal uw quotum selecteren in RU's voor een taak. Ga naar Stream Analytics-limieten voor informatie over het quotum voor Azure Stream Analytics-abonnementen. Neem contact op met Microsoft Ondersteuning om SU's voor uw abonnementen te verhogen die buiten dit quotum vallen. Geldige waarden voor RU's per taak zijn 1/3, 2/3, 1, 2, 3, enzovoort.

Factoren die het gebruikspercentage van streaming-eenheden verhogen

Tijdelijke (tijdgeoriënteerde) queryelementen zijn de kernset stateful operators van Stream Analytics. Stream Analytics beheert de status van deze bewerkingen intern namens de gebruiker, door het geheugenverbruik, controlepunten voor tolerantie en statusherstel tijdens service-upgrades te beheren. Hoewel Stream Analytics de statussen volledig beheert, zijn er veel best practice-aanbevelingen die gebruikers moeten overwegen.

Houd er rekening mee dat een taak met complexe querylogica een hoog SU%-gebruik kan hebben, zelfs wanneer deze niet continu invoerevenementen ontvangt. Dit kan gebeuren na een plotselinge piek in invoer- en uitvoer gebeurtenissen. De taak blijft mogelijk de status in het geheugen behouden als de query complex is.

HET GEBRUIK van SU% kan plotseling dalen tot 0 gedurende een korte periode voordat u terugkeert naar de verwachte niveaus. Dit gebeurt vanwege tijdelijke fouten of door het systeem geïnitieerde upgrades. Het verhogen van het aantal streaming-eenheden voor een taak vermindert mogelijk het GEBRUIK van SU% niet als uw query niet volledig parallel is.

Gebruik metrische gegevens voor gebeurtenisfrequentie tijdens het vergelijken van het gebruik gedurende een bepaalde periode. Metrische gegevens voor InputEvents en OutputEvents laten zien hoeveel gebeurtenissen zijn gelezen en verwerkt. Er zijn metrische gegevens die ook het aantal foutevenementen aangeven, zoals deserialisatiefouten. Wanneer het aantal gebeurtenissen per tijdseenheid toeneemt, neemt SU% in de meeste gevallen toe.

Stateful querylogica in tijdelijke elementen

Een van de unieke mogelijkheden van de Azure Stream Analytics-taak is het uitvoeren van stateful verwerking, zoals vensteraggregaties, tijdelijke joins en tijdelijke analytische functies. Elk van deze operators bewaart statusinformatie. De maximale venstergrootte voor deze query-elementen is zeven dagen.

Het tijdelijke vensterconcept wordt weergegeven in verschillende Stream Analytics-queryelementen:

Gevensterde aggregaties: GROUP BY van Tumbling-, Hopping- en Schuifvensters
Tijdelijke joins: JOIN met de functie DATEDIFF
Tijdelijke analysefuncties: ISFIRST, LAST en LAG met LIMIETDUUR

De volgende factoren zijn van invloed op het geheugen dat wordt gebruikt (onderdeel van metrische streaming-eenheden) door Stream Analytics-taken:

Samengevoegde vensters

Het geheugen dat wordt verbruikt (statusgrootte) voor een gevensterde aggregatie, is niet altijd rechtstreeks evenredig met de grootte van het venster. In plaats daarvan is het gebruikte geheugen evenredig met de kardinaliteit van de gegevens of het aantal groepen in elk tijdvenster.

In de volgende query is het nummer dat is gekoppeld clusterid bijvoorbeeld de kardinaliteit van de query.

SELECT count(*)
FROM input 
GROUP BY  clusterid, tumblingwindow (minutes, 5)

Als u problemen wilt beperken die worden veroorzaakt door een hoge kardinaliteit in de vorige query, kunt u gebeurtenissen verzenden naar Event Hubs die zijn gepartitioneerd door clusteriden de query uitschalen door het systeem in staat te stellen elke invoerpartitie afzonderlijk te verwerken met BEHULP van PARTITION BY , zoals wordt weergegeven in het onderstaande voorbeeld:

SELECT count(*) 
FROM input PARTITION BY PartitionId
GROUP BY PartitionId, clusterid, tumblingwindow (minutes, 5)

Zodra de query is gepartitioneerd, wordt deze verspreid over meerdere knooppunten. Als gevolg hiervan wordt het aantal clusterid waarden dat in elk knooppunt binnenkomt verminderd, waardoor de kardinaliteit van de groep per operator wordt verminderd.

Event Hubs-partities moeten worden gepartitioneerd door de groeperingssleutel om te voorkomen dat er een reductiestap nodig is. Zie het overzicht van Event Hubs voor meer informatie.

Tijdelijke joins

Het geheugen dat wordt verbruikt (statusgrootte) van een tijdelijke join is evenredig met het aantal gebeurtenissen in de tijdelijke wiggle-ruimte van de join. Dit is de invoersnelheid van gebeurtenissen vermenigvuldigd met de grootte van de draaikamer. Met andere woorden, het geheugen dat door joins wordt gebruikt, is evenredig met het datumdiff-tijdsbereik vermenigvuldigd met de gemiddelde gebeurtenissnelheid.

Het aantal niet-overeenkomende gebeurtenissen in de join is van invloed op het geheugengebruik voor de query. Met de volgende query wordt gezocht naar advertentieweergaven waarmee klikken worden gegenereerd:

SELECT clicks.id
FROM clicks 
INNER JOIN impressions ON impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10.

In dit voorbeeld is het mogelijk dat er veel advertenties worden weergegeven en dat weinig mensen erop klikken en dat alle gebeurtenissen in het tijdvenster moeten worden bewaard. Het verbruikte geheugen is gerelateerd aan de venstergrootte en de snelheid waarmee gebeurtenissen elkaar opvolgen.

Als u dit wilt oplossen, verzendt u gebeurtenissen naar Event Hubs die zijn gepartitioneerd door de joinsleutels (id in dit geval) en schaalt u de query uit door het systeem toe te staan elke invoerpartitie afzonderlijk te verwerken met BEHULP van PARTITION BY , zoals wordt weergegeven:

SELECT clicks.id
FROM clicks PARTITION BY PartitionId
INNER JOIN impressions PARTITION BY PartitionId 
ON impression.PartitionId = clicks.PartitionId AND impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10

Zodra de query is gepartitioneerd, wordt deze verspreid over meerdere knooppunten. Als gevolg hiervan wordt het aantal gebeurtenissen dat in elk knooppunt binnenkomt verkleind, waardoor de status in het joinvenster wordt verkleind.

Tijdelijke analytische functies

Het geheugen dat wordt verbruikt (toestandsgrootte) van een tijdelijke analysefunctie is evenredig met de gebeurtenissnelheid die wordt vermenigvuldigd met de duur. Het geheugen dat door analysefuncties wordt gebruikt, is niet evenredig met de grootte van het venster, maar het aantal partities in elk tijdvenster.

Het herstel is vergelijkbaar met tijdelijke join. U kunt de query uitschalen met PARTITION BY.

Buiten de orderbuffer

De gebruiker kan de grootte van de buitenvolgordebuffer configureren in het deelvenster Configuratie van gebeurtenisvolgorde. De buffer wordt gebruikt voor het opslaan van invoer voor de duur van het venster en het opnieuw ordenen ervan. De grootte van de buffer is evenredig met de gebeurtenisinvoersnelheid vermenigvuldigd met de grootte van het venster buiten de volgorde. De standaardvenstergrootte is 0.

Als u de overloop van de buitenvolgordebuffer wilt herstellen, schaalt u de query uit met BEHULP van PARTITION BY. Zodra de query is gepartitioneerd, wordt deze verspreid over meerdere knooppunten. Als gevolg hiervan wordt het aantal gebeurtenissen dat in elk knooppunt binnenkomt, verminderd, waardoor het aantal gebeurtenissen in elke buffer voor opnieuw ordenen wordt verminderd.

Aantal invoerpartities

Elke invoerpartitie van een taakinvoer heeft een buffer. Hoe groter het aantal invoerpartities, hoe meer resource de taak verbruikt. Voor elke streaming-eenheid kan Azure Stream Analytics ongeveer 7 MB/s invoer verwerken. Daarom kunt u optimaliseren door het aantal Stream Analytics-streaming-eenheden te vergelijken met het aantal partities in uw Event Hub.

Normaal gesproken is een taak die is geconfigureerd met een streaming-eenheid van 1/3 voldoende voor een Event Hub met twee partities (wat het minimum is voor Event Hub). Als de Event Hub meer partities heeft, verbruikt uw Stream Analytics-taak meer resources, maar wordt niet noodzakelijkerwijs de extra doorvoer gebruikt die door Event Hubs wordt geleverd.

Voor een taak met 1 V2-streaming-eenheid hebt u mogelijk 4 of 8 partities van de Event Hub nodig. Vermijd echter te veel onnodige partities omdat dit overmatig resourcegebruik veroorzaakt. Een Event Hub met 16 partities of groter in een Stream Analytics-taak met 1 streaming-eenheid.

Referentiegegevens

Referentiegegevens in ASA worden in het geheugen geladen voor snelle zoekacties. Met de huidige implementatie bewaart elke joinbewerking met referentiegegevens een kopie van de referentiegegevens in het geheugen, zelfs als u meerdere keren met dezelfde referentiegegevens deelneemt. Voor query's met PARTITION BY heeft elke partitie een kopie van de referentiegegevens, zodat de partities volledig zijn losgekoppeld. Met het vermenigvuldigingseffect kan het geheugengebruik snel zeer hoog worden als u meerdere keren met referentiegegevens met meerdere partities joint.

Gebruik van UDF-functies

Wanneer u een UDF-functie toevoegt, laadt Azure Stream Analytics de JavaScript-runtime in het geheugen. Dit heeft invloed op de SU%.