Stream Analytics-streaming-eenheden begrijpen en aanpassen

Artikel
08/09/2023

Informatie over streaming-eenheid en streamingknooppunt

Streaming-eenheden (RU's) vertegenwoordigen de rekenresources die zijn toegewezen voor het uitvoeren van een Stream Analytics-taak. 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 abstraheert u de noodzaak om de hardware te beheren om uw Stream Analytics-taak tijdig uit te voeren.

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

Het SU V1-model is het oorspronkelijke aanbod van ASA, waarbij elke 6 SU's overeenkomt met één streamingknooppunt voor een taak. Taken kunnen ook worden uitgevoerd met 1 en 3 RU's en deze komen overeen met fractionele streaming-knooppunten. Schalen vindt plaats in stappen van 6 na 6 SU-taken, tot 12, 18, 24 en meer door meer streamingknooppunten toe te voegen die gedistribueerde computingresources 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 komt overeen met 2, 3 tot 3, enzovoort. Taken met 1/3 en 2/3 SU V2's zijn ook beschikbaar met één streamingknooppunt, maar een fractie van de computerresources. 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:

TOEWIJZING VAN SU V1 en SU V2.

Ga naar de pagina met prijzen voor 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 plaatsvindt van de REST API-laag naar de gebruikersinterface. Mogelijk ziet u deze conversie ook in uw activiteitenlogboek , waarbij het aantal SU's anders wordt weergegeven dan de waarde die is opgegeven in de gebruikersinterface voor een bepaalde taak. Dit is standaard en het is omdat REST API-velden moeten worden beperkt tot gehele getallen en ASA-taken ondersteuning bieden voor fractionele knooppunten (1/3 SUV2 en 2/3 SUV2). Om dit te ondersteunen, hebben we een automatische conversie uitgevoerd van Azure Portal naar back-end. In de portal ziet u 1/3, 2/3, 1, 2, 3, ... enzovoort. In activiteitenlogboeken, REST API, enzovoort. SU V2-waarden zijn 3, 7, 10, 20, 30, enzovoort. De back-endstructuur is het voorstel vermenigvuldigd met 10 (in sommige gevallen naar boven afgerond). Hierdoor kunnen we dezelfde granulariteit overbrengen en het decimaalteken op de API-laag elimineren. Deze conversie is automatisch en heeft geen invloed op de prestaties van uw taak.

Standard	Standard V2 (UI)	Standard V2 (back-end)
1	1/3	3
3	2/3	7
6	1	10
12	2	20
18	3	30
...	...	...

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 is, mislukt de streamingtaak. Als gevolg hiervan is het voor een productietaak belangrijk om het resourcegebruik van een streamingtaak te controleren en ervoor te zorgen dat er voldoende resources zijn toegewezen om de taken 24/7 te laten werken.

De metrische waarde voor su-gebruikspercentage, die varieert van 0% tot 100%, beschrijft het geheugenverbruik van uw workload. Voor een streamingtaak met minimale footprint ligt deze metrische waarde meestal tussen 10% en 20%. Als het SU%-gebruik hoog is (meer dan 80%), of als invoergebeurtenissen worden geregistreerd (zelfs bij een laag SU-gebruik omdat het CPU-gebruik niet wordt weergegeven), vereist uw workload waarschijnlijk meer rekenresources, waardoor u het aantal streaming-eenheden moet verhogen. Het is het beste om de SU-metrische waarde onder de 80% te houden om rekening te houden met incidentele pieken. Als u wilt reageren op verhoogde workloads en het aantal streaming-eenheden wilt verhogen, kunt u overwegen om een waarschuwing van 80% in te stellen voor de metrische gegevens over het SU-gebruik. U kunt ook metrische gegevens over watermerkvertraging en backloggebeurtenissen gebruiken om te zien of er een impact is.

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

Meld u aan bij 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.

schermafbeelding van het menu in de 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 RU's wijzigen dat is toegewezen aan uw taak terwijl deze wordt uitgevoerd. U bent mogelijk beperkt tot het kiezen uit een set SU-waarden wanneer de taak wordt uitgevoerd als uw taak een niet-gepartitioneerde uitvoer gebruikt of een query met meerdere stappen heeft met verschillende PARTITION BY-waarden.

Taakprestaties bewaken

Met behulp van de Azure Portal kunt u de prestatiegerelateerde metrische gegevens van een taak bijhouden. Zie Metrische gegevens van Azure Stream Analytics-taken 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.

Schermopname van de prestaties van de bewakingstaak.

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

Hoeveel streaming-eenheden zijn vereist voor een taak?

Het kiezen van het aantal vereiste SU's voor een bepaalde taak is afhankelijk van de partitieconfiguratie voor de invoer en de query die in de taak is gedefinieerd. Op de pagina Schalen kunt u het juiste aantal SU'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 de aanbevolen procedure om te beginnen met 1 SU V2 voor query's die geen gebruik maken van PARTITION BY. Bepaal vervolgens de sweet spot met behulp van een trial-and-error-methode waarbij u het aantal SU's wijzigt nadat u representatieve hoeveelheden gegevens hebt doorgegeven en de metrische waarde voor het gebruikspercentage van de SU 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 voor de taak is gedefinieerd en het aantal partities in elke stap. Meer informatie over de limieten vindt u hier.

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

Notitie

Het kiezen van het aantal SU's dat vereist 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 uw quotum in SU's voor een taak selecteren. Ga naar Stream Analytics-limieten voor informatie over het quotum voor Azure Stream Analytics-abonnementen. Neem contact op met Microsoft Ondersteuning als u de SU's voor uw abonnementen boven dit quotum wilt verhogen. 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) query-elementen vormen de kernset stateful operators die door Stream Analytics worden geleverd. 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 aanbevelingen voor best practices waarmee gebruikers rekening moeten houden.

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

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

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

Stateful querylogica in tijdelijke elementen

Een van de unieke mogelijkheden van een Azure Stream Analytics-taak is het uitvoeren van stateful verwerking, zoals aggregaties in vensters, tijdelijke joins en tijdelijke analysefuncties. 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:

Aggregaties met vensters: GROUP BY van Tumbling-, Hopping- en Sliding-vensters
Tijdelijke joins: JOIN met de functie DATEDIFF
Tijdelijke analysefuncties: ISFIRST, LAST en LAG met LIMIT DURATION

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

Aggregaties in vensters

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

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

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

Om eventuele problemen te verhelpen die worden veroorzaakt door hoge kardinaliteit in de vorige query, kunt u gebeurtenissen verzenden naar Event Hubs gepartitioneerd door clusteriden de query uitschalen door het systeem toe te staan elke invoerpartitie afzonderlijk te verwerken met partitioneren door , 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 verdeeld 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 met de groeperingssleutel om te voorkomen dat een reductiestap nodig is. Zie 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 wiggleruimte van de join. Dit is de invoersnelheid van de gebeurtenis vermenigvuldigd met de grootte van de wiggle-ruimte. Met andere woorden, het geheugen dat wordt verbruikt door joins 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 er maar weinig mensen op 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 met de join-sleutels (id in dit geval) en schaalt u de query uit door het systeem toe te staan elke invoerpartitie afzonderlijk te verwerken met 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 verdeeld over meerdere knooppunten. Als gevolg hiervan wordt het aantal gebeurtenissen dat in elk knooppunt binnenkomt, verminderd, waardoor de status die in het join-venster wordt bewaard, kleiner wordt.

Tijdelijke analytische functies

Het verbruikte geheugen (statusgrootte) van een tijdelijke analytische functie is evenredig met de gebeurtenissnelheid vermenigvuldigd met de duur. Het geheugen dat door analytische functies wordt gebruikt, is niet evenredig met de venstergrootte, maar eerder met het aantal partities in elk tijdvenster.

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

Buffer voor niet-order

De gebruiker kan de buffergrootte buiten bestelling configureren in het configuratievenster Gebeurtenisvolgorde. De buffer wordt gebruikt om invoer voor de duur van het venster op te slaan en deze opnieuw te ordenen. De grootte van de buffer is proportioneel met de gebeurtenisinvoersnelheid vermenigvuldigd met de grootte van het venster Buiten order. De standaardvenstergrootte is 0.

Als u de overloop van de buffer voor out-of-order wilt herstellen, schaalt u de query uit met behulp van PARTITION BY. Zodra de query is gepartitioneerd, wordt deze verdeeld 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 resources de taak verbruikt. Voor elke streaming-eenheid kan Azure Stream Analytics ongeveer 1 MB/s aan 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 1/3 streaming-eenheid 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 maakt niet noodzakelijkerwijs gebruik van de extra doorvoer die door Event Hubs wordt geboden.

Voor een taak met 1 V2-streamingeenheid hebt u mogelijk 4 of 8 partities van de Event Hub nodig. Vermijd echter te veel onnodige partities, omdat dit overmatig resourcegebruik veroorzaakt. Bijvoorbeeld 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 snel zoeken. Met de huidige implementatie wordt bij elke koppelingsbewerking met referentiegegevens een kopie van de referentiegegevens in het geheugen opgeslagen, zelfs als u meerdere keren met dezelfde referentiegegevens koppelt. 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 erg hoog worden als u meerdere keren koppelt met referentiegegevens met meerdere partities.

Gebruik van UDF-functies

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